Q. What's the simplest configuration for testing Remote Desktop Gateway (RDG)?

A. Leevi Hertteli wrote me this month to ask about Microsoft's Remote Desktop Services (RDS), and specifically testing its RDG functionality. Over a series of emails, his question drills down to this: "I've installed an RDS environment for testing purposes on an internal network. Now I want to test that system with clients on an external network. What's the simplest way I can build such a proof of concept, just to see how it works?"

Microsoft's RDG is intended to operate on a separate server, particularly one that isn't a Remote Desktop Session Host. This separation of duties allows the RDG to proxy network traffic from external clients. To do this, many people want to locate the RDG server in a DMZ.

There's a problem with this configuration: Most DMZs don't have access to your internal Active Directory domain, and the RDG must be domain-joined in order to authenticate and authorize internal domain users. It's possible (see my next FAQ  for more information), but creating the necessary domain presence might be more effort than it's worth for a simple proof of concept.

Because of this limitation, you might find it easier simply to locate the RDG inside the firewall for testing and proof of concept environments. Running as a virtual machine, you can use multiple virtual network cards to segregate traffic between your "internal" and "external" networks. These network cards help you realize the RDG's intended design, but without the complex domain-extending needs a DMZ requires.

You obviously won't use this configuration in production, because it doesn't truly protect internal resources. For testing and proof of concepts only, however, keeping everything around in an all-internal configuration gets you up and running quickly.