Just in time for summer break here in the US the SharePoint product team has released a good number of fixes for SharePoint 2010. Service Pack 1 and the June Cumulative Update (CU) is now available for download. These are fairly substantial updates when you consider the number of bugs that have been fixed and in the case of SP1 the new improvements which have been made. To put it another way, SharePoint Server 2010 is about 1.47 GB and the Uber Package for the June CU (Foundation+Server) has a size of just about 1 GB.
In the march to continually push up the quality of SharePoint 2010 sometimes we may encounter a speed bump along the way and this is what happened to me today when installing the June 2011 CU on a SharePoint 2010 Server. This is a massive product and the sustained engineer teams have a huge task and frankly are doing a good job to keep things together. They make really tough choices every day around what gets in as a fix and what doesnâ€™t. The team works really hard to ensure regressions do not occur however sometimes these things slip through.
My lab server was running the April CU so I installed the SharePoint Foundation SP1 and the SharePoint Server SP1 binaries and ran psconfig. I confirmed the operation completed successfully by going through the logs and using Central Administration. I then installed the June 2011 June CU Uber package and ran psconfig. I have included the text of that command here:
C:\>psconfig -cmd upgrade -inplace b2b -force -wait
Performing configuration task 1 of 4
Waiting to get a lock to upgrade the farm.
Successfully initialized SharePoint Products upgrade.
Performing configuration task 2 of 4
Successfully initiated the upgrade sequence.
Performing configuration task 3 of 4
Successfully upgraded SharePoint Products.
Performing configuration task 4 of 4
Successfully completed the SharePoint Products configuration.
Total number of configuration settings run: 4
As you can see I hit a small issue. The upgrade completed however the UPS service failed to start. I confirmed as much when I took a look at my event log and found this event.
And finally, taking a look in Central Admin Services on Server I can see the User Profile Synchronization Service is â€œStoppedâ€ (services.msc confirmed this too).
The error is pretty clear, the FIM service is not a fan of the DB schema on the Sync DB so I decided to reset the sync DB. Now at this point I am about to lose all my UPA settings however I cannot touch the DB and with its schema not in a good spot I really have no other choice. Fortunately we have an article on TechNet that tells you how to go about Resetting your Sync DB. http://technet.microsoft.com/en-us/library/ff681014.aspx#resetSync After running through this article I found I could still not get the UPA sync service to start. Looking in the ULS logs I found this error:
|UserProfileApplication.SynchronizeMIIS: Failed to configure MIIS pre database, will attempt during next rerun. Exception: System.Configuration.ConfigurationErrorsException: ERR_INVALID_GROUPS
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ValidateConfigurationResult(UInt32 result)
at Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance).
So clearly there is something wrong with the group membership for the UPA service. Knowing I have not changed anything in Active directory or on the machine; and knowing the TechNet article previously wanted me to add the service account (Farm Account) back to the db_owner group I suspect there was something missing in SQL. Looking back at the backup I took of my SyncDB before I blew it away I found a missing group, FIM_SynchronizationService. which my service account (Farm Account) was not a member of. So I created the group with this command and added my account to this group:
CREATE ROLE [FIM_SynchronizationService] AUTHORIZATION [dbo]
So my DB, although empty of tables, views, stored procs, and most importantly data did have a configuration that looked much like my previous DB however I just did something really bad and unsupported â€“ I just edited the DB! The DB is empty and sans of any data so I do run some supportability risk however its probably small but I am not endorsing this approach. So after starting my UPA sync service and waiting it finally started and I was back up and read to start the configuration process againâ€¦or at least I thoughtâ€¦
When navigating to the UPA service to configure my synchronization connections I found I was getting a very strange error that I could not connect to SQL. So with UPA somewhat working from SharePointâ€™s perspective I decided to focus on FIM.
The service binary for FIM is miiserver.exe and its located in %ProgramFiles%\Microsoft Office Servers\14.0\Synchronization Service\bin. It also has a configuration file named miiserver.exe.config. Using the magic of snapshots I reverted back to before I installed the June CU and made note of the contents of this file as captured here:
See the difference? A new supportedRuntime element was added for the 4.0 version of the .Net framework.I just so happen to have the .Net 4.0 framework installed on my Windows 2008 R2 host OS so the FIM service is now attempting to use that version of the framework.
I commented out the v4 element and restarted both FIM services within services.msc. I then did an IISReset and went back into CAâ€™s UPA configuration for sync connections and all the errors were gone. I then configured a sync connection and did a FULL sync and everything seems to be working again.