Repeated "Request for install time of Application Server Role, Web Server (IIS) Role" messages

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.

Disabling automatic naming of machines in Amazon EC2

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.

Loading and modifying the registry of a dead Amazon EC2 instance

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.

1. Note down instance information such as instance ID, attached block devices (volumes), private IP address, associated elastic IP address
2. Stop the instance
3. Detach the root volume
4. Attach the volume to repair instance 
5. Login to the repair instance
6. Bring the disk online (eg: drive E)
7. Run regedit
8. Go to HKLM
9. Select File->Load Hive
10. Browse to E:\Windows\System32\config
11. Open the hive you want (eg: SYSTEM)
12. Pick a Key Name (eg: System_old)
13. Make whatever changes you need
14. Select the root of the hive you just loaded and modified (eg: HKLM\System_old)
15. Select File->Unload Hive
16. [Optional: Note if you are running SharePoint you may need to set Ec2SetComputerName to Disabled so the machine does not change names on restart]
17. Take the disk offline
18. You can now logoff or close the connection to the repair instance
19. Detach the volume from the repair instance
20. Attach volume to original instance
21. Start instance
22. 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.

Limiting the People Picker in SharePoint

We have multiple SharePoint environments that share the same Active Directory. However, there are cases where we need to keep the various groups of users separated. Normally the People Picker will return results from the entire Active Directory.

Doing some quick research I found that some settings available through stsadm that control how the People Picker behaves. This is described in the Microsoft TechNet article on Configure the People Picker. In particular we were interested in 2 properties

• peoplepicker-Peopleeditoronlyresolvewithinsitecollection - To force People Picker to only return users who have permissions in the site collection when the Check Names button is clicked
• peoplepicker-onlysearchwithinsitecollection - To force People Picker to only return users who have permissions in the site collection when the Select People and Groups dialog box is used

It appears that the phrase "have permissions in the site collection" did not mean what I expected. I would have expected that this would include anybody who has security permissions to the site. Instead, it means that a permission is set. That is the user is in the SPWeb.AllUsers collection (ie: has accessed the system).

Furthermore, the Check Names button has more than one function. If you enter an exact match, then Check Names verifies the name you entered. If you enter a partial match, it actually does a search which is controlled by the peoplepicker-onlysearchwithinsitecollection property.

Clear as mud? 

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.

 

Visual Studio 2010 setup

I had been working with Visual Studio 2003 / 2005 / 2008 and now have 2010. As usual there are some little things to do with the initial setup so that I can be functional again.

Running without a local SharePoint environment
When I try to create a new solution using any of the SharePoint templates, I got the error: A sharepoint server is not installed on this computer is not installed on this computer
It seems like in order to do SharePoint development on VS 2010 I need to have a local SharePoint environment. Unfortunately, I don't have enough horsepower to run SharePoint on my local machine so I have to go with a workaround. I know that this is not ideal, but I don't have a choice at the moment. Searching around, I came across this thread: A SharePoint server is not installed on this computer. One of the posts describes a workaround which is to essentially copy the whole registry tree of the 14 hive. So I went to my SharePoint 2010 server and exported the following [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0] and imported into my development machine. I then restarted Visual Studio and magically I am now able to create SharePoint solutions.

Adding assemblies
Another consequence of not having SharePoint on my local machine, I don't have all the assemblies in the right place. The easy workaround is as follows:

1. Copy C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI from your SharePoint Server
2. Paste it into your local machine keeping the same folder hierarchy to be consistent
3. Run regedit
4. Add the key [HKLM]\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\SharePoint 2010 Assemblies. (Not sure if it's a Windows 7 change, but I now need to add this key instead: [HKLM]\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\SharePoint 2010 Assemblies).
5. Set the default value to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

References: How to display an assembly in the "Add Reference" dialog box, How to display your assembly "Add References" dialog.

Adding Create GUID
One of the tools I find useful is a GUID generator. For some reason this is not installed by default in VS 2010. The good thing is that it is very easy to do as described in the article: How to enable "Create GUID" option in Visual Studio 2010. The steps are as follows:

1. Go to Tools->External Tools
2. Click Add
3. Enter a title (such as Create GUID)
4. In the command box, browse to C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\guidgen.exe
5. Click OK

SharePoint PrerequisiteInstaller log file location

After running the PrerequisiteInstaller you sometimes want to check the log file. At first it wasn't obvious to me where this would be stored. However, with a bit of searching I found out that it's simply stored in the %temp% directory. (duh!)

So just cd %temp% and look for the PrerequisiteInstaller.*.log files.