Recovering/resetting a Windows Server password from an AWS AMI -or- "I'm paying for this, so let me in already!"

Love me some AWS (Amazon Web Services); however, if you use a public AMI, you're more than likely to run up against a scenario where the AMI's author doesn't want you to be able to log into the VM via RDP.  You'll quickly discover this when you attempt to "Generate Windows Password":

If you see this after you've let an AMI-based VM "settle" for, oh, I don't know, an hour or so... you'll probably guess that something's awry.

You'd be correct... something is awry... the AMI's author decided to modify the "C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml" to set Ec2SetPassword from Enabled to Disabled.  AWS doesn't tell you this--you're just left to infer this on your own, after the Windows Administrator password fails to generate after a more-than-generous amount of time.

Figure 1: The AMI's author, Scott

A shame, really.  But there's a way around it.


Following the steps below may result in additional AWS usage bills, data loss or other unfortunate circumstances.  By following the instructions below, you hereby agree that I am not liable for losses of any type (data, financial, sanity, etc.).

Step 1
Shut down your hamstrung VM.

Step 2
Spin up a new t1.micro instance of Windows Server 2008 R2 x64 (not tested: Windows Server 2012, though I assume this process would be virtually identical):

Why pay if you don't have to?

Choose the same network as your exiting VM (if you don't do this, then you won't be able to detach/attach your volumes later on):

They won't let you have less than 30GB on the free tier for this AMI (I tried, don't bother):

Because #%$@ tags:

If you're feeling frisky, name the new Security Group something informative (to let Future You know that this is RDP only):


Set your AMI key (you had to do this when you set up the first VM) and launch it:

Go grab some coffee/tea/monster:

Step 3
Grab the Windows password from your new scratch VM:

Upload your previously-created PEM or paste it:

Save your Administrator password someplace safe... you'll need it in a sec:

Step 3
Detach the volume from the hamstrung instance, and attach it to your scratch instance by visiting the Volumes section:

Right-click on the volume associated with your hamstrung instance and choose Detach:

Click Yes, then Refresh the screen ( ) until the volume shows as "available":

Now that it's detached, let's attach it to the scratch VM:

Choose your scratch VM and attach the volume:

Step 4
RDP into the scratch VM (use the credentials and IP from Step 3).

You should see a new drive letter... this used to be the root volume of your hamstrung VM:

Let's edit that key file:

The one we care about is Ec2SetPassword... that needs to be changed to Enabled:

Step 5
Make the partitions bootable again, before you nuke your scratch machine!

Remember seeing that D:\ drive in your scratch machine, along with the E:\ drive which contains your actual OS?  On 64-bit versions of Windows, an additional "boot" partition is created (32-bit versions do not create this additional boot partition... these instructions assume you're using the x64 AMI mentioned earlier):

That said, we're going to modify our commands appropriately to ensure that the boot volume (D) is the one we're "fixing."

Why do we need to fix the volume?  If Windows sees more than one drive as bootable, it will mark the other drives that it didn't boot from as non-bootable:

You'll need a copy of the 32-bit (x86) bootsect.exe.  Feel free to Google for it, or download it here:  (Note: When your downloading using the Internet Explorer that's built in, you'll need to either add * as a trusted site -or- disable IE ESC in Server Manager):

Throw bootsect.exe in C:\Windows\System32 on your scratch machine (just so it's in %PATH%):

Fire up a Command Prompt on your scratch machine as Administrator:

Run the following commands, in order (this assumes that you've not switched processor architectures on me... these x64 commands assume a D:\ "boot" drive and E:\ "Windows" drive (as shown in your scratch machine), which would be the case assuming the above has been followed :-)):

bootsect /nt60 D: /mbr

bcdboot E:\Windows /s D:

bcdedit /store D:\Boot\BCD /set {default} device partition=E:

bcdedit /store D:\Boot\BCD /set {default} osdevice partition=E:

bcdedit /store D:\Boot\BCD /set {bootmgr} device partition=E:

SHUT DOWN (do not restart) the scratch VM:

Hopefully, you'll never need this scratch VM again.  This would be an appropriate occasion to thank it for its service:

Step 6
Confirm that both your scratch and production VMs are stopped:

Detach the volume from the scratch instance, and attach it to your now-hopefully-not-hamstrung instance by visiting the Volumes section:

Right-click on the 2nd volume (the one mounted as xvdf) associated with your scratch instance and choose Detach:

Click Yes, then Refresh the screen ( ) until the volume shows as "available":

Attach the volume...:

...and choose the original machine, but do not choose xvdf:

Instead, change this to /dev/sda1

Step 7
Fire up your production VM on the Instances tab:

I'm keeping my scratch machine around until I know this boots and I can recover the Windows password:

Step 8
Let's get that Windows password!

Finally!  We're in!

Time to nuke that scratch VM :-)

Credits & Attributions
It took me a while to parse all of the available information on this topic, and I couldn't have put together as comprehensive a guide without these folks: