Addressing RDP Failures for EC2 Virtual Machines (Part 1)

If you would like to read the next part of this article series please go to Containerization Proliferation: The Docker Effect (Part 2).

Last week I encountered a frustrating issue with a virtual machine. The issue was an RDP failure. While this issue might not initially seem catastrophic, it soon turned into one of those chicken and the egg type situations that every IT professional dreads. My problem was that I was unable to establish a Remote Desktop connection to my virtual machine. Unfortunately however, I couldn’t fix the problem (at least not through traditional means) because I could not connect to the virtual machine.

Needless to say, this was a frustrating situation. Even so, all was not lost. If you ever run into a situation in which Remote Desktop is unable to connect to your virtual machine, there are some things that you can do to potentially resolve the issue.

Unfortunately, there is no universal magical cure all for an RDP connection failure. The solution to the problem will ultimately depend on the condition that caused the problem in the first place. That being the case, I will discuss a few different issues.

Remote Access has been Disabled

One somewhat common problem is that remote access to a virtual machine is accidentally disabled. Perhaps an inexperienced administrator notices that remote access is enabled for the virtual machine, and disables it thinking that they are addressing a security risk. I have also heard stories of administrators accidentally disabling remote access by clicking the wrong option on the screen.

If you are unable to establish an RDP connection to a virtual machine because remote access has been disabled for that virtual machine, then the easiest option for getting back in is to configure your group policy to allow remote access. The group policy setting that enables or disables RDP connectivity can be found within the Group Policy Object Editor at: Computer Configuration | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Connection. You must set the Allow Users to Connect Remotely Using Remote Desktop Services setting to Enabled.

The Windows Firewall is Blocking RDP Traffic

Another common cause of RDP connection failures is that the Windows firewall is blocking Remote Desktop traffic. Again, this can happen if someone decides to close and RDP related firewall port in an effort to improve security.

Like the Remote Access Service, the Windows Firewall can be controlled through group policy settings. The Windows Firewall related group policy settings are located within the Group Policy Object Editor at Computer Configuration | Administrative Templates | Network | Network Connections | Windows Firewall | Domain Profile.

Although it is sometimes possible to fix a Windows firewall problem by using group policy settings, some situations may require you to be a bit more creative. I would recommend trying the group policy approach first however, because it is the easiest.

If you find that you are unable to reconfigure the Windows firewall through the use of group policy settings then you will need to create a temporary virtual machine and then attach the malfunctioning virtual machine’s virtual hard disk to the temporary virtual machine. If done correctly, you can boot from the temporary virtual machine’s operating system and then modify the registry on the original virtual hard disk.

Begin the process by stopping the malfunctioning virtual machine and then creating a new virtual machine. It is extremely important that your temporary virtual machine runs a different version of Windows than the virtual machine that you are trying to fix. Otherwise, you will create a disk signature collision that will render the already malfunctioning virtual machine unbootable.

If you do accidentally use the same version of Windows on both virtual machines then it is possible to correct a disk signature collision, but the process is kind of tedious. Besides, why introduce another problem before you even fix the original problem? My advice is that if your malfunctioning virtual machine is running Windows Server 2012 or 2012 R2, then create a temporary virtual machine that runs Windows Server 2008. Similarly, if your malfunctioning virtual machine is running Windows Server 2008, then create a temporary virtual machine that runs Windows Server 2012 R2. It doesn’t really matter what version of Windows is running on your temporary virtual machine so long as it is newer than Windows Server 2003 and does not match the version of Windows that is running on the virtual machine that you are trying to fix. Incidentally, if you do accidentally use the same version of Windows on both virtual machines, then you can find instructions for fixing the disk signature collision here.

Once the new virtual machine has been created, you will need to attach the malfunctioning virtual machine’s root volume to the new virtual machine as a secondary disk. After doing so, log into the temporary virtual machine and open the Disk Management Console by entering the diskmgmt.msc command at the server’s Run prompt.

When the Disk Management Console opens, you should see the virtual hard disk from the malfunctioning virtual machine, but the disk may be listed as being offline. If this happens, then right click on the disk and choose the Online command from the shortcut menu.

Once the virtual hard disk has been brought online, the next thing that you will need to do is to edit the copy of the registry that exists on the virtual hard disk from the malfunctioning virtual machine. This is easy to do, but you do have to exercise care.

Enter the Regedit command at the server’s Run prompt. When the Registry Editor opens, select the HKEY_LOCAL_MACHINE hive. Now, select the Load Hive command from the Registry Editor’s File menu. You will need to load the required hive from the disk from the malfunctioning computer. Select the appropriate drive and then go to Windows\System32\config\SYSTEM. You will be prompted to specify a key name, but you can enter any name that you want. The name is irrelevant.

Now, navigate through the registry editor to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy. Now, look for keys with names resembling xxxxProfile. This includes the DomainProfile, PublicProfile, and possibly other profiles. Select these profiles one by one and then change the value of EnableFirewall from 1 to 0. This will disable the firewall for the virtual machine. You can later log into the virtual machine and configure the firewall to support RDP.

To complete the procedure, close the Registry Editor and re-open the Disk Management console. Right click on the disk from the malfunctioning virtual machine, and choose the Offline command from the shortcut menu. This will take the virtual hard disk offline. Now, shut down the temporary virtual machine and detach the disk from the malfunctioning virtual machine. You can now restore the root volume to the virtual machine where it came from (it should be attached as /dev/sda1). Go ahead and boot the virtual machine and test your ability to establish an RDP connection. If you are able to establish RDP connectivity then you can get rid of your temporary virtual machine.

Conclusion

As you can see, there are ways to correct RDP connectivity problems for virtual machines running within the Amazon cloud. In Part 2 I will conclude this series by showing you some more things that you can do to solve RDP connectivity problems.

If you would like to read the next part of this article series please go to Containerization Proliferation: The Docker Effect (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top