Scott Hanselman

CSI: Re-enabling Remote Desktop with PowerShell after you've blocked it with your own firewall rule

October 15, 2013 Comment on this post [8] Posted in Azure | PowerShell
Sponsored By

Got a great email from reader Seán McDonnell.

The Big Problem:

I set up an Azure virtual machine running Windows Server 2012.

I accidentally disabled the Remote Desktop Windows firewall rule (while I was remotely connected). The connection dropped as you would expect.

I have been pulling my hair out ever since trying to re-enable this rule.

Doh. Ouch. I didn't ask how this happened, but you know, one gets to clicking and typing and you can feel the mistake about to happen as your hand drops towards the keyboard, but by then it's too late. Gravity has screwed you.

I suggested that Seán use Remote Powershell to get in and add the enabling Firewall Rule for RDC. Remote PowerShell is like "SSH" in *nix. You get a remote terminal and can pretty much do whatever you want from there.

TL;DR version of Seán's experience.

  • Make sure PowerShell is enabled in the Endpoints section of the Azure portal.
  • Get the server's certificate (PowerShell needs this for remote commands). You can get the server certificate by going to your domains' URL: https://yourdomain.cloudapp.net:12345 (where :12345 is the port that PowerShell uses).
  • Export the SSL certificate of the site as a .CER file and install it on your local machine.
  • Save it to the "Trusted Root Certification Authorities" store on your machine.
  • Open PowerShell with administrative privileges on your local machine and type:
    Enter-PSSession -ComputerName yourdomain.cloudapp.net -Port 5986 -Credential YourUserName -UseSSL
  • A login popup will appear, enter your VM's login credentials here.
  • You will now be able to execute commands against the Azure VM. In Seán's case, he ran
    netsh advfirewall firewall set rule group="remote desktop" new enable=Yes
    and exited the PowerShell session and was able to remotely connect to my machine.

Long Detailed Version with Screenshots

Long version with screenshots:

Make sure PowerShell is publically accessible in the 'endpoints' section of the Azure portal.

 01 - VM Endpoints

Get the server's certificate (PowerShell needs this for establishing a remote session). You can get the server certificate by going to your domains' URL: https://yourdomain.cloudapp.net:5986 (where :5986 is the port that PowerShell uses).

 image

Go to the Details tab and click Copy to File...

 03 - Certificate Export

Leave the first option selected and save the file to a local drive. 

 04 - Certificate Export

05 - Certificate Export

Once the file is generated and saved locally, install the certificate by double clicking on the certificate-name.cer file.

 06 - Certificate Install

Install the certificate in the following store:

cert install

Open up PowerShell with administrative privileges and execute the following command (replacing the domain name and username with your own one):

 08 - Remote PowerShell Session

A logon credential popup should appear where you will need to enter your VM's username and password:

07 - Remote PowerShell Session

If successful, it should be pretty obvious that you have successfully initiated a remote session with the VM.

Enter-PSSession -ComputerName yourdomain.cloudapp.net -Port 5986 -Credential YourUserName -UseSSL

09 - Remote PowerShell Session Verification

To open re-enable the firewall rule you issue the command:

netsh advfirewall firewall set rule group="remote desktop" new enable=Yes  

 10 - Remote PowerShell Session Firewall Rule Update

The final step was to quit the PowerShell session and RDC to the VM. Success! 

I hope this write-up helps other people as well. Thanks Seán for a great question and for sharing the screenshot of your experience!


Sponsor: Thanks to Red Gate for sponsoring the feed this week! Check out a simpler way to deploy with Red Gate’s Deployment Manager. It can deploy your .NET apps, services, and databases in a single, repeatable process. Get your free Starter edition now.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
October 15, 2013 3:15
Lol, nice one, how to heal it, after you did shot yourself in the foot ;)
October 15, 2013 12:16
nice :) good way to recover from those "oh oh" moments ^^
October 15, 2013 14:46
Nice post. PowerShell remoting is awesome. One thing, shouldn't the server certificate go in Trusted People instead of Trusted Root Cert Auth?
October 15, 2013 20:56
That was a nice one Scott.

Now, what would have been different in this process if the VM didn't have Remote PowerShell enabled? In that situation, would this still be possible?

Thanks.
October 15, 2013 22:29
Michael Washam has a post on using Remote PowerShell in Windows Azure that includes a PowerShell script to download the cert and install it in the local cert store.

October 16, 2013 6:19
Is there anyway to connect without providing password (or may be cert with empty passphrase) so that we can automate deployment from our build server?
October 22, 2013 11:20
In the past the Windows Firewall used to keep the existing connections alive, even if you changed the rules to deny them. Has this changed? Or are we talking about a different kind of firewall? (one baked into the Azure infrastructure).
December 19, 2013 12:36
That's tons easier than what I had to do with an Amazon EC2 instance I did the same thing to.

1. Stop the instance
2. Detach the EBS volume for the C: drive
3. Attach the EBS volume to a different EC2 instance
4. RDP into THAT instance and add the drive in Disk Manager
5. Remote mount the registry hive
6. Fiddle around turning off the Windows firewall, enabling RDP.
7. Detach hive
8. Detach drive in Windows
9. Detach EBS in EC2
10. Reattach EBS to original EC2 instance
11. Start EC2 instance, RDP in, fix everything more permanently

Ugh...

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.