Last week I was able to upgrade BB&D’s internal intranet site from SharePoint 2007 to SharePoint 2010! So you can properly understand what happened let me cover a little bit about the intranet first. Our intranet is a small deployment, just a single server deployment however it is kept up to date with technology so it is running on SQL Server 2008 with SP1, Windows 2008 R2 on a 64bit virtual machine. We have also not gone with heavy customisation, rather focusing on small tweaks and adjustments. A good example is we do not have a customised master page but rather use the theme options to get the colour scheme we want.
The first step I did was to download the pre-requisites for SharePoint 2010, and using the option on the installer this was a breeze. I’ve seen this before with Dynamics CRM and once again I am impressed by how a very simple feature makes such a big difference. Next step was the install, which was pain less and quick.
Once installed the configuration manager had to run and this is where I had two issues. The first problem was that I got stuck on task 1! The cause here is that a dialog box had appeared behind the main window (telling me to do the same to all servers in the farm) and won’t go until I clicked OK. This annoying little bug cost me a few minutes.
The second issue was that the SharePoint 2010 install needs to do some Active Directory queries and this meant my user account was not good enough. Not having a good enough user means that the installer produces a very unhelpful error at step 3:
System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at Microsoft.SharePoint.Utilities.SPUtility.GetUserPropertyFromAD(SPWebApplication webApplicaiton, String loginName, String propertyName)
at Microsoft.SharePoint.Administration.SPManagedAccount.GetUserAccountControl(String username)
at Microsoft.SharePoint.Administration.SPManagedAccount.Update()
at Microsoft.SharePoint.Administration.SPProcessIdentity.Update()
at Microsoft.SharePoint.Administration.SPApplicationPool.Update()
at Microsoft.SharePoint.Administration.SPProcessIdentity.UpgradeToV4ManagedAccount()
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.ResolveObjectAndClassVersions(SPLog log)
at Microsoft.SharePoint.Upgrade.SPConfigurationDatabaseSequence2.Upgrade()
at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse)
It took ages to figure this out, mostly because it is not a documented requirement. To get the correct permissions you need to get a domain admin to do the following on the domain controller:
- Open up Active Directory Users and Computer.
- Select Advanced Features from the View menu. Failing to do this means that the tab in step four won’t be visible.
- Right-click the your AD account and select Properties.
- Select the Securities Tab.
- Select Authenticated Users in the Group or user names field.
- Allow Full permissions in the Permissions for Account Operators.
- Repeat this process for any SharePoint service accounts you may have created.
- Next make sure this change replicates to all domain controllers.
- Now connect to your SharePoint server, and open the command prompt (cmd.exe) and type gpupdate /force. This will force the changes to the machine as it may have a cached version.
- Finally reboot the SharePoint server and start the configuration wizard again.
After all that was done the configuration wizard completed and the upgrade process started in central admin. The upgrade process also took a while to do, but once done everything just worked.
Lastly we applied some theme tweaks and a quick run through of testing it and it was done. One thing that is important to remember about this process is that the entire time it was happening the current intranet was done so plan your deployment accordingly. This is easily the best experience I’ve ever had installing or upgrading SharePoint and shows that the product is maturing.