Thursday, November 5, 2015

Azure RemoteApp: Script to clean up orphaned RDSH computer objects in Active Directory

When using a Hybrid (domain joined) collection of Azure RemoteApp, RD Session Host servers deployed as part of the collection will become members of your on premises Active Directory Domain.
These computer objects are placed in a designated OU, which is configured during the creation of the collection. Below is an example of those computer objects.
Notice that there is a naming convention in place which consists of eight random letters followed by a number starting from 0000, so for example JWBQPQTO0000.
Also note that in the example above, two combinations of eight random letters objects are shown.If you update your custom template image, or Microsoft updates their template image and you initiate the Update sequence on the collection (as shown below), Azure RemoteApp will start a new eight random letters combination for the RD Session Host servers based on the updated template image.
What Azure RemoteApp currently does not do however, is clean up the RD Session Host Computer objects based on the previously used Template Image. This means you will end up with orphaned computer objects in your Active Directory. This is something that your Active Directory Administrator is generally not happy with. Plus, as you start doing more & more updates on your template, things could get really messy in Active Directory.
You can of course manually remove those orphaned computer objects from Active Directory. This is however not only a time consuming task, it’s also hard to tell which computer objects are still part of Azure RemoteApp and which ones are orphaned.
The good news is, there now is a new PowerShell command available that is able to retrieve the list of active RD Session Host servers for a specified collection.

    Get-AzureRemoteAppVM [-CollectionName] <string> [-Profile <AzureSMProfile>]  [<CommonParameters>]

I have used this command to create a PowerShell script that automatically deletes all RD Session Host Servers in a specified OU that are not active in the specified Azure RemoteApp Collection.
For example, this is my OU where Azure RemoteApp stores my RD Session Host servers. As you can tell by the naming, it has multiple sets so it’s likely we have orphaned computers here.
If we run the PowerShell script it will output which orphaned RDSH objects are found and they will be deleted.
These orphaned RD Session Host objects are now cleaned from Active Directory. You can use the PowerShell script to create a scheduled task to perform clean up every month or so, or decide to run this script manually as part of your Template Image update process. Two notes to the script:
- Make sure you provide the correct OU when running this script, because there is no warning before the deletion of the computer objects
- The script currently does not handle scenarios where you might have deployed multiple Azure RemoteApp Collections in the same OU. I’ll be adding that functionality later.
I have published the script on TechNet Gallery here:
There is also an additional advantage of this command. It also shows which users are logged on on which RD Session Host server! This means its now also easier to determine where a specific user is logged on and maybe offer support, do shadowing or troubleshoot a specific user session. See the example below;
Get-AzureRemoteAppVM -CollectionName Hybrid
LoggedOnUserUpns                           VirtualMachineName
----------------                                     ------------------
{}                                                      jwbqpqto0000
{}                                                      jwbqpqto0001
{}  jwbqpqto0002


In the mean time Microsoft has released two new PowerShell Cmdlets to perform clean up:


  1. I get the unknown cmdlet error when attempting this:

    Get-AzureRemoteAppVM : The term 'Get-AzureRemoteAppVM' is not recognized as the name of a cmdlet, function, script
    file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct
    and try again.

  2. Hi,

    Currently, the cmdlet needs to be enabled on a Azure Subscription basis. If you want, I could contact the team and have it enabled for you. If so, please drop me an email at