This small blogpost is dedicated to inform you about an important hotfix and the release of the Remote Desktop Planning poster which is available for some weeks now.
KB3192404 (Preview of Monthly Rollup)
Within this Rollup update a hotfix for the User Profile Mechanism is included. In the article this is described as:
“Addressed issue where the user profile disk (UPD) does not get unmounted when a user logs off. Therefore, users get temporary profiles and are not able to work with their own profiles during their next logon. The Event ID 20491 with a description of “Remote Desktop Services could not disconnect a user disk for the user account with a SID of <SID>. The error code is 0xAA.93″ will be logged”
The preview of this Monthly Quality Rollup update can be found here: https://support.microsoft.com/en-us/kb/3192404.
Remote Desktop Service Planning Poster
The Remote Desktop Services Poster is already some weeks available but I never had the time to mention it in one of my blogposts. This poster covers Planning and Designing a Remote Desktop Services. Beside this phase the poster also covers the Build and Deploy phase as well the Run and Tune phase. This is a very complete overview of Remote Desktop Services 2016.
In this series of blogposts I’m showing you how you can deploy your ‘Cloud-Only’ RDS environment. This environment consists of as much PaaS services as possible and all components are hosted on Microsoft Azure. In the first blogpost I’ve explained how to create and prepare Azure AD Domain Services together with the corresponding Virtual Networks. In the second post I described the deployment of all Remote Desktop Services resources and roles through an Azure ARM template and explained how the initial configuration can be done from this template. In this blogpost I want to focus on providing high-available storage for hosting the User Profile disks. Since the GA of Windows Server 2016 we can use Storage Spaces Direct for this. So this blogpost describes the deployment and configuration of a Storage Spaces Direct Cluster from an Azure ARM template.
Unfortunately this year It was not possible for me to attend the ignite conference. So the news came through the social media platforms to me. One week later I want to summarize some important announcements and news presented on Ignite. Of course the most important announcement was about the General Availability of Windows Server 2016 and System Center 2016. Windows Server can be download as evaluation from this location and become available on MSDN later this month. But what about other announcements about Remote Desktop Services presented in several sessions on Ignite.
In this second blogpost of the series deploying a ‘Cloud-Only’ RDS environment I want to focus on deploying all needed roles on Azure by using an Azure Resource Manager Template. After the deployment of the resources I also want to show how the deployment of the RDS environment itself can be initiated from an ARM template. Part 1 of the series contained the creation of a AzureAD with Domain Services and the VNET peering configuration between the Classic VNET (Needed for AzureAD Domain Services) and the ARM VNET used within the ARM template for the RDS Resources. The steps described in this first blogpost are required to execute the steps in this blogpost.
In the next two blogposts I want to describe how you can create a cloud-only RDS environment with using as much Azure PaaS services as possible. In these two blogposts I want to focus on setting up a RDS environment based on Windows Server 2016 and using Azure AD Domain Services, Azure AD Application Proxy and Azure SQL Database. The support for these Azure PaaS services is added in Windows Server 2016. So this blogpost is not compatible with earlier versions of RDS. This blogpost will focus on setting up the virtual networks, virtual network peering and the Azure Active Directory including Domain Services. The second blogpost will focus on deploying the RDS environment in this newly created environment.
This is the last blogpost in the series of publishing your RDS environment with Azure AD Application Proxy. In the first post of this series I’ve described the steps needed to configure Azure AD Application Proxy pass-through authentication to publish a RDS environment. In the second post of this series I’ve focused on pre-authentication and explained the steps needed to configure pre-authentication for a RDS environment. In this last part of the series I’m focusing on High Availability of both the RD Web and RD Gateway roles and the Azure AD Application Proxy. I’m ending the series with sharing some excellent guidance provided by Microsoft of designing your Azure AD Application Proxy environment.
This blogpost is the second part in the series about publishing your RDS environment with Azure AD Application Proxy. In the first part of the series I’ve described the improvements made to RDS 2016 and the basic configuration of Azure AD Application Proxy for publishing both the RDWeb and RD Gateway role. In the first part we’ve configured pass-through authentication, this blogpost will cover all the changes needed to configure pre-authentication with Azure AD. When configured users will be redirected to the AzureAD login form and after a successful logon you will get the logged-in RDWeb feed.
In the coming series of blogposts, I want to focus on publishing your RDS environment through the Azure AD Application Proxy. Publishing your RDS environment with the Azure AD Application Proxy has several advantages compared to publishing it without the Azure AD Application Proxy. This blogpost will cover the advantages and disadvantages of publishing your environment through the Azure AD application Proxy and this part will also cover the configuration of Azure AD Application Proxy with pass-through authentication. In the next blogpost I want to focus on pre-authentication with Azure AD and in the last part I want to focus on making all components high-available. All blogposts are based on Windows Server 2016 TP5 which is in public preview at this moment.
The last couple of months I was involved in a project of building a fresh new Remote Desktop Services environment on Microsoft Azure. One of the advantages of having your RDS environment on Azure is that you can scale the number of Session Hosts based on the user load. In this project the number of Session Hosts were defined upfront, so no dynamic scaling based on the actual user load. Based on Tags on the Azure Virtual Machines we defined the different Start/Stop Profiles and based on those profiles servers were stopped and started on pre-defined times. The tags on the virtual machines needed to rotate so that not always the same servers will stay on and every server gets a shutdown. After building this solution we faced a strange error.
During my summer holiday Microsoft has announced the retirement of Azure RemoteApp. You can find the information in this blogpost of the RDS team. Citrix announced their replacement product ‘XenApp Express’, in their words they call it ‘Azure RemoteApp v2.0’. You can find more information about Citrix XenApp Express here, here and here. So based on all information the following timelines will apply to the retirement of Azure RemoteApp and the release of XenApp Express:
- [Microsoft RemoteApp] –> Retirement announcement made on 12th of August
- [Microsoft RemoteApp] –> New purchases of Azure RemoteApp will end as of October 1st, 2016
- [Citrix XenApp “express”] –> Tech Preview of Citrix XenApp Express in Q4 2016
- [Citrix XenApp “express”] –> General Availability of Citrix XenApp Express in early 2017
- [Microsoft RemoteApp] –> End of service on August 31st, 2017
Citrix will host an event where more information will be provided about the strategy of both Citrix and Microsoft. You can register here.
The last 2 years I’ve blogged and presented a lot of information about Azure RemoteApp. I really liked the product and the future of the product(roadmap). Of course based on the announcement blogging about Azure RemoteApp will end and I will focus more on Remote Desktop Services. With the release of Windows Server 2016 a lot of improvements are made to Remote Desktop Services. I will also focus on building RDS environment on Microsoft Azure. Next week I should present together with Maarten Goet on Monitoring Azure RemoteApp with OMS at System Center Universe Europe. This session will change so that it will include Remote Desktop Services 2016 instead of Azure RemoteApp. In this session I will discuss all new things in RDS 2016 but also the migration steps needed to migrate to RDS 2016. You can find the session here.