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.

PROCEED AT YOUR OWN RISK


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):


Launch!


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: https://dl.dropboxusercontent.com/u/22121/_BrianDagan.com/bootsect.exe  (Note: When your downloading using the Internet Explorer that's built in, you'll need to either add *.dropboxusercontent.com 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:

Warning: Don't use 4.2.2.2 for public DNS, use 8.8.8.8 or 8.8.4.4 instead

If you’re up for some light reading: http://www.tummy.com/Community/Articles/famous-dns-server/

If you’re not the “reading type,” here’s the key part of the article:  Should I Use 4.2.2.2?  Unless you are a Level-3 customer, absolutely not.

Essentially, 4.2.2.2 belongs to Level 3, and they have no obligation to ensure that this service is reliable or accurate.  As of late, a number of DNS queries made against 4.2.2.2 have been timing out, which makes it a bad choice to verify DNS name resolution.

8.8.8.8 and 8.8.4.4, please.

https://developers.google.com/speed/public-dns/docs/using

To add to this, Allied Telecom (and my independent tests) have noted that 4.2.2.2 is having some major issues today, which is manifesting itself as many of their customers calling them for Internet connectivity issues when the issue actually lies with the DNS provider that the IT Engineer chose to put in the firewall/DNS settings long before 4.2.2.2 started going downhill.

How To: Create Files Of A Specific Size

No, not rodents of unusual size…

…a file of a specific size.  Where would you use this?

·         Testing e-mail attachment size limits

·         Testing file transfer speeds

·         Deliberately filling a counterfeit Chinese flash drive to examine the file write “looping” behavior

It’s quick & easy to do this… just fire up an Administrative Command Prompt and type in the following:

fsutil file createnew [Filename] [Size in Bytes]

Example:

Happy testing!

How To: Install Entrust Certificates On A HP Thin Client For Citrix

If you’ve just installed a shiny new Entrust certificate on your Citrix server and you find out that your HP Thin Client machines can’t connect to published applications with a SSL Error:

“You have not chosen to trust ‘Entrust.net Certification Authority (2048)’, the issuer of the server’s security certificate (SSL Error 61).”

…then there’s a two-phase process to get this fixed.  The first phase, done on your workstation, requires that you have a USB thumb drive.

Phase 1: Done once on your workstation

1) Plug in the USB thumb drive

2) Open a web browser and download all eight of these files with their original filenames to the root directory of your USB thumb drive:

     2.1) https://www.entrust.net/downloads/binary/entrust_ssl_ca.cer

     2.2) https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

     2.3) https://www.entrust.net/downloads/binary/entrust_ev_ca.cer

     2.4) https://www.entrust.net/downloads/binary/entrust_g2_ca.cer

     2.5) https://www.entrust.net/downloads/binary/entrust_l1e.cer

     2.6) https://www.entrust.net/downloads/binary/entrust_l1e_chain_root.cer

     2.7) https://www.entrust.net/downloads/binary/entrust_l1c.cer

     2.8) https://www.entrust.net/downloads/binary/entrust_2048_chain_root.cer

3) Safely eject the USB thumb drive, and go find yourself some thin clients

Phase 2: Done on every HP Thin Client

1) Hop on the Thin Client, and plug in your USB drive from earlier

2) Click on the lower left corner (HP Menu)

3) Click on Administrator/User Mode Switch

4) On the Switch To Admin Mode login screen, type in “root” (without quotes) as the password (this is the default value) and hit Enter

5) In the “Thin Pro Control Center (Administrative Mode)” application, double-click “Control Panel”

6) Choose the “Advanced” tab

7) Double-click on “X Terminal”

NOTE: All commands going forward are case-sensitive!

8) Type “su” (without quotes) and hit Enter

9) Type “fsunlock” (without quotes) and hit Enter

10) Type “cd /media” (without quotes) and hit Enter

11) Type “ls” (without quotes) and hit Enter to list the drives… the names are case-sensitive in the next step

12) Type “cd [First few case-sensitive letters of your USB drive]” (without quotes or []s) followed by the Tab key, and it will auto-complete the name, then hit Enter:

   

13) Type “cp *.cer /usr/lib/ICAClient/keystore/cacerts/”  (without quotes) and hit Enter

    (No result is a good result, i.e. a blank line after the command means the files were successfully copied)

14) Type “fslock” (without quotes) and hit Enter

15) Type “reboot” (without quotes) and hit Enter

At this point, the HP Thin Client should connect to Citrix without issue.