I have been updating a couple of SharePoint 2010 servers and farms to the latest June 2010 Cumulative Update (CU) as well as installing a slipstreamed package. The slipstreamed install worked flawless using the same technique as with SharePoint 2007. But patching some of my servers seriously failed on both Windows Server 2008 R2 and Windows 7 with both SharePoint Foundation 2010 and SharePoint Server 2010. Here are some of my experiences of the patching.
Even though all June 2010 CU knowledge base articles says that a reboot is not required after applying the patches I indeed was required to boot after applying KB2028568 and KB983497 respectively. This doesn’t bother me more than that it should have been told in the KB article. I don’t know why I had to reboot and have not either tried to figure out why. It can have something to do with my configurations (even though I tried it on several different ones). Just reboot before running the SharePoint Configuration Wizard or psconfig and you will fine (almost - continue reading..).
Configuration Wizard fails
After rebooting the machines the troubles really started for me. I started the Configuration Wizard and it let me know that I needed to update so I went ahead. It starts going through the steps and on the final step where it usually takes some time it failed after a while. I opened up the PSCONFIG log files and found the following errors noted:
The exclusive inplace upgrader timer job failed.
An exception of type System.InvalidOperationException was thrown. Additional exception information: Cannot open SPTimerV4 service on computer ‘.’. System.InvalidOperationException: Cannot open SPTimerV4 service on computer ‘.’. —> System.ComponentModel.Win32Exception: Access is denied — End of inner exception stack trace — at System.ServiceProcess.ServiceController.GetServiceHandle(Int32 desiredAccess) at System.ServiceProcess.ServiceController.Stop() at Microsoft.SharePoint.PostSetupConfiguration.ServiceHelper.Stop(String serviceName)
I can’t say I hate error messages, contrary it gives me a challenge :-). Thankfully I had taken backups and even made snapshots just before updating the servers. The first thing I that came to my mind was that I was using a Farm administrators account to do this - but it was not the account that actually installed SharePoint 2010. As you know it is recommended to always have a separate account that you use for installation, patching and updating - and for nothing else. So I rolled back to where my snapshot was taken and used my install account instead - same error! Hmmm. Then I fired up another virtual machine - which also is a “least privilege” install of SharePoint and tried updating it - same error! Ok, now this is getting annoying! Tried updating SharePoint Foundation on my laptop - same error! @$$80!3 (censored)
After a lot of retries, Binging and chatting with some of the brightest. I run the Configuration Wizard again and even psconfig using the force argument (to see if I could see any difference). For one of the servers the Configuration Wizard actually completed. Yes! I went to Central Administration and unfortunately it reported that the server needed an upgrade. Back to square one! I also noticed the following in the PSCONFIG log file:
An exception of type System.InvalidOperationException was thrown. Additional exception information: Cannot open SPTimerV4 service on computer ‘.’. System.InvalidOperationException: Cannot open SPTimerV4 service on computer ‘.’. —> System.ComponentModel.Win32Exception: Access is denied — End of inner exception stack trace — at System.ServiceProcess.ServiceController.GetServiceHandle(Int32 desiredAccess) at System.ServiceProcess.ServiceController.Stop() at Microsoft.SharePoint.PostSetupConfiguration.ServiceHelper.Stop(String serviceName) at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.StopServicesListedInRegistry(RegistryHelper registry, Boolean disableService) at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.StopAllServices() at Microsoft.SharePoint.PostSetupConfiguration.InitializeTask.Validate(Int32 nextExecutionOrder) at Microsoft.SharePoint.PostSetupConfiguration.TasksQueue.Validate(Boolean useDefaultExecutionOrder)
By the looks of the error messages this must have something to do with security. I verified that all accounts had the correct permissions, was correctly configured etc.
User Account Control is the culprit!
Finally I installed the CU on a server where I did not use a plethora of service accounts but instead used the domain admin to run SharePoint and that update worked like a charm. In Windows Server 2008 R2 the built-in Administrators account by default have User Account Control (UAC) disabled.
I went back to the other servers, disabled the UAC and repeated the update procedure using the installation account - and it worked flawlessly! Did the same procedure on another machine, and it worked there to.
Without to must investigation I assume that the account running the timer jobs is performing tasks that fires up the UAC. But since that is a non-interactive session you are not able to allow the operation.
So in order to get your CU (or other updates for that matter) for SharePoint 2010 to install correctly I recommend you to disable the User Account Control for you service accounts.
Anyone with similar experiences or comments to this?