> bashing mode on
Apparently this ought to be a relative easy task, right? Wrong! I don’t know if Amazon is to blame. Or Microsoft. Or both. Really don’t care. The annoying thing is the large pile of fail that destroys the productivity for the most basic tasks. However, besides cookies, we, the sysadmins of the Dark Side, also have solutions. We have to.
Some that know me better may think that I hate MS/Windows. I don’t, as long I don’t have to administer those machines. I do have a Windows 7 Pro box at home. While the Windows soft-RAID implementation blows for certain reasons, otherwise than this and some of the small quirks that every OS has, is a pretty dandy setup. Therefore no, I am not a pure Windows hater. Don’t get started with the wrong impression.
The first thing that’s really annoying is the long period that takes for the instance to be ready. In order to get the ‘Administrator’ password it takes ages. Amazon says it takes between 15-30 minutes. Come on EC2, you take a AMI off the S3 and spin up a new instance, then setup a new password. How hard can it be? A Linux instances is ready almost instantly after the console says it’s running. Even more, after the password is available via the console or the API (sometimes one of these gets it faster) the RDP still takes a few minutes before being available. Since Amazon & Microsoft don’t provide this for free, even more, we pay by the hour, STOP WASTING OUR TIME. Sincerely, the EC2 Windows Server users.
The second really annoying thing is the fact that Amazon recommends you to change the default password that they provide. While the recommendation is good, if you do this, you get locked out the instance. If you don’t have a second account with RDP access, you have one option: terminate the instance. The almost useless AWS Premium support probably will be able to do something about this. But if you’re in a hurry, going back to square one is probably the best option.
You have a workaround though that I discovered during my time boxing with EC2 and Windows Server: add the Administrator to the RDP allowed list, although the window says that ‘Administrator already has access’. If you change the password, the Administrator loses the RDP access, even though the password is valid. The welcome screen will tell you rubbish about using the wrong password, when clearly the input is good. I tried to reproduce this few times. Each time I got locked out. I even validated the new password by running something with runas. What? Wrong password? Listen a’holes, I asked you to change the f’ing password, not make me French fries. How hard is not to screw up such a basic task? Initially I though my Terminal Server Client is dumb, but the *nix guys don’t have any screw ups here. Using a Windows 7 client did the same.
If you want to create a new AMI off the existing instance, boy, more gotchas are waiting around the corner. Even if the Administrator password is successfully changed, the RDP access is preserved, the ‘Set Password’ options of the ‘Ec2 Service Properties’ application are unchecked, sysprep manages to tank the instance and the new AMI. Administrator completely loses the access on both instances, the existing and new new one. Tried with the ‘Set a random password’ option. Didn’t work as expected. Didn’t try the ‘SetPassword’ feature after sysprep, but I had enough anyway. I read somewhere around the Interwebs that sysprep somewhat affects the Administrator user, but I didn’t get any relevant information. Searching for it is a mess.
My workaround: create a new user part of the Administrators group. Set a strong password for that user. Amazon sets a joke anyway. I wouldn’t call that strong. Disable the Administrator account:
net user Administrator /active:no
Enjoy your newly created AMIs without surprises. Didn’t have any issues with other Administrators besides Administrator. Plus it is available as soon as the RDP service is available, unlike the ‘Amazon way’ of keeping you waiting 15 to 30 minutes, for nothing.
The third really annoying thing is the fact that the AMIs are awfully outdated. Since there’s an official partnership between Amazon and Microsoft I would expect a higher level of support. I know, there’s Windows Update, but even after all those years, it still doesn’t manage to do it into a brain dead-free way. I know I’m biased as I’m used to Debian and friends, but the OS upgrade could be a little bit faster. OK, a lot more faster. Downloading and installing 54 updates that have around 200MiB takes around a hour and half, on a c1.medium instance which is the best specs you can get from a x86 instance. It takes 3 reboots. It takes 4 times to click the ‘Check for updates’ link in order to actually be up to date in the end. I get that there are dependencies, but an OS that claims is ‘Datacenter’ grade should handle this properly: download all your junk, deal with it later. Even more, I used c1.medium because m1.small is even slower for the Windows Update part. Even when the update manager claims that it’s only downloading updates, the CPU usage won’t go under 50%. What? A download that takes a lot of CPU time? WTF? The actual update doesn’t do it nicer or faster anyway.
A fellow sysadmin suggested vbscript + AutoIt. Now why the hell should I write a script to fix issues that should not exist in the first place? Don’t know why, but Windows Server under EC2 still feels like a second class citizen, despite the fact that you pay extra for the privilege of running Windows. Anyway, in the end I managed to bake my own AMI that’s ready for spinning up new instances for our HA setup. But the experience wasn’t even remotely close to the advertised level.
> bashing mode off