If you are implementing a Remote Desktop Services (RDS) environment in an Azure Virtual Network (Vnet) or AWS VPC, this post is for you. It describes a configuration issue that, AFIK, is documented nowhere else.
Better than giving end users access to a remote Windows desktop via a Windows jump box, RemoteApp integrates RDP with Windows and Mac desktops to make remote applications appear as if the application is running locally. The application has its own desktop icon and windows so it looks and feels just like it’s running on the local machine. Except it isn’t.
Setting up RDS RemoteApp with all its roles — RD Web, RD Gateway, Session Host, Licensing, Connection Broker — is well documented elsewhere. The tip in this post is for a very specific situation.
When using Azure or AWS for your RDS environment, you are likely to put the RD Web and RD Gateway VMs in a public-facing subnet and the other VMs with RDS roles in a non-public-facing subnet in the Vnet or VPC. Consider the following incredibly basic Azure Vnet. It has exactly two subnets in the slash-16 network. The RD Web and RD Gateway VM is in a public-facing subnet; the remaining roles are running on VMs which are in a non-public-facing subnet.
If you architect it this way (and you should), you must change the default WinRM rule to permit the back-end VMs’ subnet(s) to allow inbound requests to WinRM. If you do not change this rule, you will receive this error in Server Manager when attempting to manage the RDS Collection.
You can refresh the list of servers in Server Manager until you are blue in the face — RDS will never see the collection without WinRM connections to the back-end (that is, non-public-facing) VMs. But, if you look carefully at the Server Manager errors when refreshing the server list, you’ll see the clue.
I guess it’s par for the course for Microsoft to put the most important problem determination info at the end — but it’s there…and it’s (fortunately) very specific. Now that we know what the problem is, it’s easy to fix. On the RDS collection VMs running in the non-public-facing Vnet subnet, simply add the “outside” subnet to the public rule for WinRM.
I’m not precisely sure why the WinRM public firewall rule needs to be changed. After all, all RDS VMs must be domain joined. But the Server Manager refresh error message is very specific — and if you do what it says, your problems disappear.
That was kinda fun, wasn’t it? I hope this helps you.
Leave a Reply