A couple of months ago I published a blogpost describing a cloud-only Azure RemoteApp hybrid deployment. You can find this blogpost here. This blogpost describes a hybrid Azure RemoteApp deployment with the AD Domain Services hosted in Azure IaaS. Based on the recent announcement from Microsoft that Azure AD Domain Services is in preview I wanted to test if this functionality supports a cloud only hybrid Azure RemoteApp deployment without the need of AD domain controllers in Azure IaaS.
The first step is to activate the Microsoft Azure AD Domain Services. This can be done from the Azure Management Portal. Go to your Directory -> Configure and look for this section: 
Before you can activate this setting you have to execute the following steps:
- Create a virtual network in Azure in a Region which supports Azure AD Domain Services
- Create a Domain Admin User with a Domain Admins User Group inside the Azure Active Directory
- The next step is to activate the Azure AD domain services:
- Click on Save. The provisioning process should start
- The Next step is to add both AD Domain Controllers to your Azure Virtual Network as a DNS server
The next step is to create a Master Image and prepare and upload the image to Azure RemoteApp. Since the Azure AD Domain Services is a ‘Managed Service’ we cannot configure this domain as we normally do with a hybrid Azure RemoteApp deployment. I only created an extra ‘service’ account which I will use to add the instances to the Azure AD domain. Execute the following steps to create the Azure RemoteApp hybrid collection:
- Create new hybrid collection
- Go into you newly created hybrid collection and configure the ‘Join Local Domain’ section
- Link your Azure RemoteApp image to this collection and afterwards the provisioning proces should start automatically
- When adding users to the collection the following error occurred:
The users created in Azure AD are automatically synced to the Azure AD Domain, but the users are not ‘synced’ users. The user remains a ‘Azure Active Directory’ user. There is a uservoice item in the Azure RemoteApp uservoice system. If you would like to see that Azure AD Domain Services will be supported in the future please vote on this uservoice item.
Update 5-11-2015: Note: In the above scenario I focused on a Cloud Only setup. When you are using an on premise Active Directory to sync users to the Azure AD and then use Azure AD Domain Services with Azure RemoteApp it will work. As Peter Ciszewski explained below Azure RemoteApp is checking if the user is ‘dir synced’, if not those users cannot be added to Azure RemoteApp. With this note I wanted to clarify that Azure RemoteApp can work with Azure AD Domain Services, but then you need another Active Directory.
Great test!! I totally agree with this. For my RemoteApp hybrid collection, I currently have a 2012 R2 VM in my Azure VNET running good old local AD sync’d via the AAD Connect utility to my AAD tenant. It would be much cheaper to be able to use the new Domain Services preview instead of full blown VM’s.
Hi Arjan,
Thanks for writing about this.
I have just successfully deployed an Azure RemoteApp (ARA) collection and domain-joined it to an Azure Active Directory Domain Services (AAD-DS) domain controller. Here are the things I did differently:
1. The problem you ran into is currently by design in ARA. When you select a domain-joined collection we will make sure that you can only add users who have been “dir synced”; this means they exist in an Active Directory (AD) and where copied into Azure Active Directory (AAD).
We do this because in a domain-joined collection the user must be able to authenticate against the AD. If they don’t exist in AD they would always fail to launch a remote application.
This check is somewhat redundant when using AAD-DS. That is because AAD-DS always has all the users from AAD in it even if they were not originally “dir synced” but created directly in AAD. We need to figure out how to handle this in the future so AAD-DS deployments are not constrained by this yet we still have the check in place for AD.
2. I originally ran into some problems around your Steps 2 and 3. I was getting errors from ARA saying that domain join was failing due to invalid credentials. I verified I got the same errors with my “private VM” – I was not able to domain-join it using the same creds.
The solution is to follow the instructions documented here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-getting-started-password-sync/
This makes sure the password sync into AAD is done using a method that is usable with AAD-DS.
I assume in your test you created the accounts from scratch so they already had the correct type of password sync.
I hope this helps with your future experiments. Please let me know your feedback!
Hi Peter,
Thank you for your comments. I’ve created a new trial subscription to test this functionality. During the launch it was not available in Europe. Based on your comments I will try to deploy a complete new collection tomorrow. I will inform you about the results!
Regards, Arjan
Hi Peter,
I tried it also, and got the same results as Arjan wrote about. Also I can confirm you need to recreate the password if it is you’re an existing user.
@arjan, the remote app is now available (and working) in Europe also.
Greets,
Reinout