Don’t Forget To Leverage The Benefits of RD Gateway On Hyper-V & RDP 8/8.1

So you upgraded your TS Gateway virtual machine on W2K8(R2) to RDS Gateway on W2K12(R2) too make sure you get the latest and the greatest functionality and cut off any signs of technology debt way in advance. Perhaps you were inspired by my blog series on how to do this, and maybe you jumped through the x86 to x64 bit hoop whilst at it. Well done.

Now when upgrading or migrating from W2K8(R2) a lot of people forget about some of the enhancements in W2K12(R2). This is especially true of you don’t notice much by doing so. That’s why I see people forget about UDP. Why? Well things will keep working as they did before Windows Server 2012 RDS Gateway over HTTP or over RPC-HTTP (legacy clients). I have seen deployments where both the Windows and the perimeter firewall rules to allow UDP over 3391 were missing. Let alone that UDP Transport over port 3391 was enabled in the transport settings.  But then you miss out on the benefits it offers (a better user experience over less than great network connections and with graphics) ass well on those of that ever more capable thingy called RemoteFX, if you use that.

For you that don’t know yet:  HTTP and UDP protocols are both used preferably by RD Gateway and are more efficient than RPC over HTTP which is better for scaling and experience under low bandwidth and bad connectivity conditions. When HTTP transport channels are up (in & outgoing traffic), two UDP side channels are set up that can be used to provide both reliable (RDP-UDP-R) and best-effort (RDP-UDP-L) delivery of data. UDP also leveraged SSL via the RD gateway because is uses Datagram Transport Layer Security (DTLS). For more info RD Gateway Capacity Planning in Windows Server 2012. Further more it proves you have no reason not to virtualize this workload and I concur!

So why not set it up!?  So check you firewall rules on the RD Gateway Server and set the rules accordingly. Do the same for your perimeter firewalls or any other in between your users and your RD Gateway.


Under properties of your RS Gateway server you need to make sure UDP is enabled and listening on the needed IP address(es)


A client who connects over your RDS Gateway server, Windows Server 2012(R2) that is, and checks the network connection properties (click the “wireless NIC” like icon in the connection bar) sees the following: UDP is enabled. imageIf they don’t see UDP as enabled and they aren’t running Windows 8 or 8.1 (or W2K12R2) they can upgrade to RDP 8.1 on windows 7 or Windows Server 2008 R2! When they connect to a Windows 7 SP1 or Windows 2008R2  machine make sure you read this blog post Get the best RDP 8.0 experience when connecting to Windows 7: What you need to know as it contains some great information on what you need to do to enable RDP 8/8.1 when connecting to Windows 7 SP1 or Windows 2008 R2:

  1. “Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostRemote Session EnvironmentEnable Remote Desktop Protocol 8.0” should be set to “Enabled”
  2. “Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostConnectionsSelect RDP Transport Protocols” should be set to “Use both UDP and TCP” => Important: After the above 2 policy settings have been configured, restart your computer.
  3. Allow port traffic: If you’re connecting directly to the Windows 7 system, make sure that traffic is allowed on TCP and UDP for port 3389. If you’re connecting via Remote Desktop Gateway, make sure you use RD Gateway in Windows Server 2012 and allow TCP port 443 and UDP port 3391 traffic to the gateway

Cool you’ve done it and you verify it works. Under monitoring in the RD Gateway Manager you can see 3 connections per session: one is HTTP and the two others are UDP.


Life is good. But if you want to see the difference really well demonstrated try to connect to Windows 7 SP1 computer with RDP8 & TCP/UDP disabled and play a YouTube video, then to the same with RDP8 & TCP/UDP enabled, the difference is rather impressive. Likewise if you leverage RemoteFX in VM. The difference is very clear in experience, just try it! While you’re doing this look a the UDP “Kilobytes Sent” stats (refresh the monitoring tab, you’ll see UDP being put to work when playing a video on in your RDP session.


Load balancing Hyper-V Workloads With High To Continuous Availability With a KEMP Loadmaster

I’m working on some labs and projects with KEMP Loadmaster load balancing appliances (LM 2400, LM-R320) That will lead to some blog post on  load balancing several workloads, which are all on Windows Server 2012 R2  Hyper-V or integrate in to Azure. The load balancers used in the labs are the virtual appliances, depending on the needs and environment these are a very good, cost effective option for production as well and depending on the version you get they scale very well. Hence their use in cloud environments, they will not hold you back at all!

To stimulate your interest in load balancing and high availability I’ve put up a video on load balancing RD Gateway services. Consider it a teaser or introduction to more about the subject.

Why use an appliance (hardware/virtual)? Well let’s look at the 2 alternatives:

  • Round robin DNS, which is also sometimes used is just to low tech for most real life scenarios and sometimes can’t be used or is less efficient which impacts scalability and performance. On top of that it doesn’t provide health checking for failover purposes.
  • I’ve also said  before that while Windows NLB  provides layer 4 load balancing out of the box it’s pretty basic. It also often causes a lot of network grief and the implementation can be tedious. This has not improved in an ever more virtualized & cloud based world. On top of that, when network virtualization comes into play you might paint yourself into a corner as those two don’t mix. But if that’s not a concern and you’re on a budget, I’ve used it with success in the past as well.

RD Gateway Messaging Tab Windows Server 2008 R2 & 2012

Since Windows 2008 R2 and as such in Windows Server 2012 RD Gateway has a nice couple of new features in it’s properties under the tab Messaging.

System Message


That’s great as now you can warn logged on users of the gateway of any impending maintenance actions that otherwise might be a disconcerting loss of connectivity to them. Just go to the messaging tab and type in your message. Set the start and end date/time and that’s all there is to it. A user that is logged or logs in during the specified time frame will see this window appear. I like the fact that we can communicate to the active users via the system message. It makes for a better experience of the service delivered.


Logon Message

Another option you have under the messaging tab is to to specify a logon messageimage

You simply type this into text file that you then browse to and apply so that it will be displayed.image

You have to browse and apply every time you edit the text file. 

Below is a screen shot what a user logging on to a system via your RD Gateway would see. It all depends on the legal department of the manager what will go in here. Do note that you cannot continue until you accept the terms. This could be annoying to regular users after a while. That’s why you have the option of selecting “Do not ask again unless changes to the policy occur”. That should keep both legal and the users happy Smile.


Fixing Event ID 2002 “The policy and configuration settings could not be imported to the RD Gateway server “%1” because they are associated with local computer groups on another RD Gateway server”


I was working on a little project for a company that was running TS Gateway on 32bit Windows 2008. The reason they did not go for x64 at the time was that they used Virtual Server as their virtualization platform for some years and not Hyper-V. One of the drawbacks was that they could not use x64 guest VMs. Since then they have move to Hyper-V and now also run Window Server 2012. So after more than 5 years of service and to make sure they did not keep relying on aging technology it is time to move to Windows Server 2012 RD Gateway and reap the benefits of the latest OS.

All in all the Microsoft documentation is not to bad, all be it that the information is a bit distributed as you need to use various tools to complete the process. Basically, depending on the original setup of the source server you’ll need to use the TS/RD Gateway Export & Import functionality, Web Deploy (we’re at version 3.0 at the time of writing) and the Windows Server Migration Tools that were introduced with Windows 2008 R2 and are also available in Windows Server 2012.

In a number of posts I’ll be discussing some of the steps we took. You are reading Part 3.

  1. x86 Windows Server 2008 TS Gateway Migration To x64 Windows Server 2012 RD Gateway
  2. Installing & using the Windows Server Migration Tools To Migrate Local Users & Groups
  3. TS/RD Gateway Export & Import policy and configuration settings a.k.a  “Fixing “The policy and configuration settings could not be imported to the RD Gateway server "TARGETSERVER" because they are associated with local computer groups on another RD Gateway server”

The Migration

Their is no in place upgrade from a x86 to an x64 OS. So this has to be a migration. No worries this is supported. With some insight, creativity and experience you can make this happen. The process reasonably well documented on TechNet, but not perfectly, and your starting point is right here RD Gateway Migration: Migrating the RD Gateway Role Service. These docs are for Windows Server 2008 R2 but still work for Windows Server 2012. Another challenge was we needed to also migrate their custom website used for the employees to check whether their PC is still on and if not wake it up or start it up remotely.

As you read in the previous part we had to migrate local users and groups that are also used by the TS Gateway x86 Windows 2008 Server as we still need those in the Windows Server 2012 RD Gateway. The Active Directory users and groups used in Connection Authorization Policies (CAP) and Resource Authorization Policies (RAP) require no further work.

TS/RD Gateway Export & Import

I’m not going to write on how to install  a brand new RD Gateway. That’s been done just fine by Microsoft and many other. I’ll just discuss the import and export functionality in the TS/RD Gateway manager and help you with a potential issue.


This is easy. On the source TS/RD Gateways server you just right click the server in TS/RD Gateway Manager and select Export policy and configuration settings. In our case this is a Windows Server 2008 TS Gateway, X86, so 32 bit. But that doesn’t matter here.


Give the export file a name and chose a location.


You’ll get a notification of a successful import.



Ordinarily you’ll launch the RD Gateway Manager Import policy and configuration settings feature and follow the wizard.image

Select a export file (from the old TS Gateway server) to import




But instead of getting a success message you get an error.


If you are moving the TS/RDGateway to a new server and will not recuperate the name you’ll have to deal with the following issue: The policy and configuration settings could not be imported to the RD Gateway server "TARGETSERVER" because they are associated with local computer groups on another RD Gateway server.

This also manifests itself as an error in the TerminalServices-Gateway Admin log with Event 2002


“The policy and server configuration settings for the TS Gateway server "%1" could not be imported. This problem might occur if the settings have become corrupted.”

What? Corrupt? The Export went fine!? Now if you start researching this error you’ll end up here which will tell you what to do if you get this error duse to a bad export but basically tells you you’re stuck otherwise. Not so! The solution to this is very easy, you just have to know it works. I found out by testing & verifying this. All you have to do is edit the source TS/RD Gateway export XML file.

Open op the XML file in notepad. Select Edit/Replace from the menu and do a Find "SOURCESERVER" with Replace All "TARGETSERVER" and use that XML File. Save the file and use that for the import.


So now start the import again with your edited file and after a while you’ll see that you have been successful this time.


If you are recuperating the name you will not have this issue as the name in the export file will match the host name. However as this server is domain joined to the same domain as the original one you’ll have to respect the order of taking down the original one, resetting it’s AD computer account and reusing it for then new RD gateway server. This is more risky as you take down the service before you switch over. With a new server and a DNS alias you can just swap between the old and the new one by simply updating the DNS record(s) or even recuperating the old IP address, that switch can go fast.