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.
One of the new features which will be introduced in Windows Server 2016 Remote Desktop Services is storing the RD Database in Azure ‘SQL Database as a Service’. Since Windows Server 2016 is now in the Technical Preview stage we can test this feature. More information about all improvements can be found here. In this blogpost I want to describe the end-to-end process to update your existing RDS single Connection Broker environment to a RDS High-Available Connection Broker environment and storing the RD Database on Azure SQL.
Since a couple of weeks the documentation around the support of SharePoint Online and OneDrive for Business is changed. So I want to describe the current support state is this short blogpost. The Azure RemoteApp documentation is updated and now states ‘OneDrive for Business is not supported with Azure RemoteApp’. You can find this information here. This information also applies to Remote Desktop Services which is described here. But some remarks can be made to these statements and I want to describe them here.
Since a couple of weeks there are some improvements made to Azure RemoteApp regarding the management of the User Profile Disks. Management of the User Profile disks was not possible for the users of Azure RemoteApp. If a copy of the User Profile disk was needed you had to contact Azure Support and they could provide you the link to the User Profile Disk. Also removing a corrupted User Profile disk was also only possible through contacting Azure Support. With the release of the following 2 PowerShell cmdlets the user can now execute these actions themselves: Copy-AzureRemoteAppUserDisk and Remove-AzureRemoteAppUserDisk. Both cmdlets are available from Azure Module version 1.5.0.
This is the 5th part of the blog series about User Environment Management within Azure RemoteApp. In the first 2 blogposts which you can find here and here I discussed the use of Microsoft User Experience Virtualization in combination with Azure RemoteApp. In the 3rd part I explained why you should disable the User Profile Disk when using another solution for User Environment Virtualization. In the 4th blogpost I showed how AppSense can be used in combination with Azure RemoteApp. This post will describe the use of RES ONE Workspace in combination with Azure RemoteApp. A couple of months ago RES contacted me about writing this last part of the series. They give me access to their Azure RemoteApp environment where they had implemented RES ONE Workspace. Continue reading