Wednesday, February 16, 2011

Amazon EC2 instance not accessible via RDP after Windows Update and reboot

For the last couple of days, I have been running into a problem where my Amazon EC2 instance is no longer accessible via remote desktop after a Windows Update and a reboot.

My process for setting up these servers is pretty straightforward: Install SQL 2008, Install SharePoint 2010 Prerequisites, Install SharePoint 2010, run Windows Update. I have done this a couple of dozen times now without any problems. Just a couple of days ago, I was finding that after the Windows Update and ensuing reboot, the server comes up, status is active, but it is not accessible via RDP or HTTP (just times out).

My first thought was that one of the more recent Windows Updates is incompatible Amazon EC2. Comparing my last successful installation with the latest Windows Update packages, I found that the following might be the culprit:


  • Cumulative Security Update for Internet Explorer 8 for Windows Server 2008 x64 Edition (KB2482017)
  • Platform Update Supplement for Windows Server 2008 x64 Edition (KB2117917)
  • Security Update for Windows Server 2008 x64 Edition (KB2393802)
  • Security Update for Windows Server 2008 x64 Edition (KB2479628)
  • Security Update for Windows Server 2008 x64 Edition (KB2483185)
  • Security Update for Windows Server 2008 x64 Edition (KB2485376)
  • Update for Windows Server 2008 x64 Edition (KB971029)
  • Windows Malicious Software Remove Tool x64 - February 2011 (KB890830)

So, I'd figure I would try again and leave out these specific updates, but upon reboot, my new instance would also be unaccessible via RDP or HTTP.

Perplexed and after a lot of searching, swearing, hair pulling, I came across this post: Avoiding RDP connectivity issues when running SharePoint 2010 on Amazon EC2. In particular, it mentions the Microsoft Article KB2379016: A computer that is running Windows Vista or Windows Server 2008 stops responding at the "Applying User Settings" stage of the logon process which describes the problem as being a deadlock in the Service Control Manager database. To break the deadlock, it is just a matter of forcing HTTP.sys depend on CryptSvc. This can be accomplished as follows:
  1. Run regedit
  2. Locate and the registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP
  3. Create a New, Multi-string Value: DependOnService
  4. Set a single value CRYPTSVC
So far so good. Maybe I'll get some sleep tonight.
 




No comments:

Post a Comment