I was installing SharePoint prerequisites and it seemed to hang at the first step "Configuring application server role, Web Server (IIS) Role". The PrerequisiteInstaller process seems to stall there forever. Looking at the installation log at \AppData\Local\Temp\2 under my profile, I saw over 2500 instances of the message: "Request for install time of Application Server Role, Web Server (IIS) Role". In the System event log, there are thousands of events "Windows Servicing successfully set package <some-package>(<some-status>) to <some-status>(<some-status>). There are also many repeats of the same package and status (eg: update, installed, staged).
I don't really know why it took so long. However, the simple solution was to just wait it out and eventually the task succeeded. In the end, the prerequisite installation took 1h 15min.
Wednesday, March 30, 2011
Wednesday, March 9, 2011
I run SharePoint 2010 in my Amazon EC2 instances. As a result, I do not want my machines automatically renamed by the EC2Config service when I stop / start them. This would totally screw up SharePoint as it does not behave well with machine name changes. Fortunately, Amazon EC2 has a way to do this via the EC2Config Service Settings executable or by directly editing C:\Program Files\Amazon\Ec2ConfigSetup\config.xml and changing the Ec2SetComputerName value to Disabled. The latter is quite handy as I had to stop and restart instances recently due to some deadlock issues.
Tuesday, March 8, 2011
In a recent post, I had to troubleshoot an issue with an Amazon EC2 instance not accessible via RDP after Windows Update and reboot. Back then, I didn't realize that I could have edited the registry of the unresponsive instance. Here is how to do it (Thanks to Nick Greising at Amazon for providing me with the steps). You will first need a repair instance in the same zone.
- Note down instance information such as instance ID, attached block devices (volumes), private IP address, associated elastic IP address
- Stop the instance
- Detach the root volume
- Attach the volume to repair instance
- Login to the repair instance
- Bring the disk online (eg: drive E)
- Run regedit
- Go to HKLM
- Select File->Load Hive
- Browse to E:\Windows\System32\config
- Open the hive you want (eg: SYSTEM)
- Pick a Key Name (eg: System_old)
- Make whatever changes you need
- Select the root of the hive you just loaded and modified (eg: HKLM\System_old)
- Select File->Unload Hive
- [Optional: Note if you are running SharePoint you may need to set Ec2SetComputerName to Disabled so the machine does not change names on restart]
- Take the disk offline
- You can now logoff or close the connection to the repair instance
- Detach the volume from the repair instance
- Attach volume to original instance
- Start instance
- You will also need reconfigure your security groups as the internal IP address would have changed and to reassociate the Elastic IP Address.
Now, I could just plop in the steps from Amazon EC2 instance not accessible via RDP after Windows Update and reboot into step 13 and I can repair those unresponsive instances. Note that when the hive is loaded, there won't be a CurrentControlSet. However, you can look at the value of HKLM\System_old\Select\Current to determine which ControlSet to use. See the knowledgebase article What are Control Sets? What is CurrentControlSet? for details.