In this article I am going to show you step-by-step instructions on how to build a hybrid app collection in Azure RemoteApp.
Quick Reminder of Hybrid App Collections
The benefit of a hybrid app collection is that it allows you to enable users to log into Azure-based and Azure-managed RDS session hosts, while still using company owned servers and services. The below illustration depicts such a scenario:
- A domain controller provides either single sign-on (ADFS) or shared sign-on (DirSync or AD Connect) integration with Azure AD (AAD). The Azure directory is used by RemoteApp to authenticate user login requests.
- A custom template is created and loaded into Azure Remote App. A hybrid app collection is created with the ability to join the resulting session hosts to the customer’s Active Directory (not AAD, but the actual domain). The session host virtual machines run on a dedicated VNET, which has a VPN connection to the customer network. This means that the RemoteApp-managed machines are members of the domain and are subject to Group Policy, which can access customer services.
- Users sign into RemoteApp to use the published applications.
- The users can use the published client applications to access services on the customer’s servers via traditional AD authentication and the VPN connection.
The ability to integrate a hybrid app collection so deeply with an Active Directory and with customer services is what makes this solution so interesting to me. It takes very new technologies and concepts and brings them within the scope of technologies that we have been using for up to 15 years. It can also make legacy services accessible to users all over the world in a very secure manner.
Creating a Custom Template
The first step of the process is to create a custom template, which you can learn how to do in my article, How to Create an Azure RemoteApp Template. This allows you to publish applications of your own in the Azure cloud, subject to technical and licensing requirements.
Integrate Azure Active Directory
This is a subject that’s bigger than the scope of this guide. You have multiple options including:
- AD Connect, which is currently in preview
The good news is that if you have configured Office 365, then you probably already know how to do this stuff. Make sure that the UPN of your users in Active Directory (example: email@example.com in a domain called petri.com) matches the UPN in AAD. If you don’t do this, then users will not be able to sign into RemoteApp and will get an unambiguous “resources not available” error.
Create a RemoteApp App Collection
Log into the Azure management portal and browse to RemoteApp and click Create A RemoteApp Collection. A dialog appears:
- Click Create With VPN to create a hybrid collection.
- Enter a unique name for your collection.
- Choose a plan: a Basic plan is for light-weight users, and a Standard plan is for productivity users.
Create a Virtual Network
The session hosts of a hybrid app collection will be connected to an Azure virtual network. You will create one of these with a gateway for VPN connectivity. Browse into your new app collection, and you should be greeted with the quick start instructions. Click the blue cloud with a lightning bolt in the top navigation bar. Click Link A Virtual Network, where you can create a new RemoteApp virtual network or reuse an existing RemoteApp virtual network.
Click Create A New RemoteApp Virtual Network, name it, and select a region. In the Network Address Spaces screen, you need to enter the addresses of two networks:
- Virtual Network Address Space: This is the private network address of the new network that your session host virtual machines will run in. Ensure that this will not overlap with your existing network(s) and that routing should be OK once a VPN connection is created.
- Local Network Address Space: This is the private network address(es) of your server network(s) that the RemoteApp virtual network will connect to.
The next screen is very important and must be completed correctly. Three pieces of information are required:
- DNS server IP addresses: These addresses will be used to dynamically configure the IP stacks of the new RemoteApp session hosts. Ensure that the addresses can resolve the domain name of your private Active Directory. Tip: use your domain controllers’ IP addresses because they are DNS servers. The DNS traffic will traverse the VPN connection.
- VPN Device IP Address: This is the public IP address of your server network’s VPN device. This is required to connect the gateway of the new RemoteApp virtual network to your server network with a VPN connection.
The third item is whether you want to create a static or a dynamic gateway. This will be determined by:
- How many networks you want to connect together: A static gateway allows two networks to be connected in a 1:1 fashion. A dynamic gateway is required for multiple (1:N) networks to be connected.
- Your server network’s gateway: Some firewalls only support a static gateway. Some will require a dynamic gateway.
Note: An Azure virtual network requires a dynamic gateway for a VNET to VNET VPN — have you figured out how that could make for an interesting solution?
When you finish the wizard, a little box beside Link A Virtual Network indicates that a job is running behind the scenes to create the virtual network. Wait until this is completed.
Complete the VPN Connection
A VPN shared-secret key is created for the gateway of the RemoteApp virtual network. Click Get Key to copy this key and use it to create a VPN connection between your server network and the new RemoteApp app collection. Consult your network device manufacturer’s instructions on how to complete this step.
Prepare Active Directory
Open Active Directory Users and Computers to manage your Active Directory (not AAD). Enable the Advanced view and create an OU for RemoteApp session hosts. Azure RemoteApp will join the Azure-based virtual session hosts to your domain and place the computer objects in this OU. In my example, I created a sub-OU called RemoteApp in a root OU called Petri, in a domain called petri.com.
To enable this, you will need a service account. Create a normal and non-administrative user in Active Directory. In my example, I created a user called RemoteApp, with a UPN of RemoteApp@petri.com. Open the properties of the RemoteApp OU, select Security, and click Advanced.
Click Select Principal and select the new service account, which is RemoteApp@petri.com in my example. Ensure that any permission change will effect this object (the OU) and all descendent objects. Next, add the Create Computer Objects and Delete Computer Objects rights to the account before saving all of the changes.