UPDATED 2010-10-03: Obviously the KB2276339 is not a Aug CU hotfix KB2352342 is the correct one.

The second Cumulative Update (CU) is out for SharePoint 2010. It contains two hotfixes; one for Foundation and one for Server. The Foundation fix contains the really important update that should fix the problem with LINQ to SharePoint and anonymous users. You can get the fixes here:

Caution when installing hotfixes (as usual), they are not that thoroughly tested as Service Packs and only install them if you experience the problems mentioned in the KB articles. Nevertheless since this SPF hotfix contains the above mentioned fix for LINQ to SharePoint - this one is pretty important!

After installing the CU’s you should have version 14.0.5123.5000.


So, what’s the problem I’m talking about?

UPDATE: The problem I and several others experienced is that the User Profile Service Application started generating errors. This was due to the fact that an incorrect hotfix for the August CU was floating around. So if you get these errors below, you know that you have installed the wrong hotfix.  (Question remains on what the KB2276339 does!)

CONTENT BELOW SHOULD BE CONSIDERED OBSOLETE As the title of this blog post implies I have (once again) discovered a really nasty bug in the hotfix that makes your User Profile Service Application (UPA) inaccessible. After installing the binaries and upgraded the farm (including reboot and a very long wait for the content databases to update) this is what is presented when going to the UPA administration web page (ManageUserProfileServiceApplication.aspx):


File not found, correlation id…yup, you know what to do next. Just search the ULS logs for the correlation id and discover this sweet little error message:

UserProfileServiceUserStatisticsWebPart:LoadControl failed, Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.ResourceManagement, Version=4.0.2450.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.  File name: 'Microsoft.ResourceManagement, Version=4.0.2450.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35'     at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.InitializeIlmClient(String ILMMachineName, Int32 FIMWebClientTimeOut)     at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)     at Microsoft.SharePoint.Portal.WebControls.UserProfileServiceStatisticsWebPartBase.LoadControl(Object sender, EventArgs e)

Ok, it cannot locate the Microsoft.ResourceManagement.dll assembly with this version number; 4.0.2450.11. And that’s correct, the GAC does not contain that version of the assembly:


So where did the 4.0.2450.11 version of this assembly go then, I have no idea! But, if you take a look at the KB2276339 you will see that the pplwfe-x-none.msp package should contain just that specific assembly and version (.11). A search amongst the local files on the server also discovered that the assembly is located in two different locations, but not in the GAC:

  • C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin
  • C:\Program Files\Microsoft Office Servers\14.0\Service

This assembly is required by the Microsoft.Office.Server.UserProfiles.dll, also present in the GAC.

UPDATE: Do not follow these steps, instead install the correct hotfix.

My first reaction was - just register the new assembly to the GAC and everything will be fine. But not! That really funks up the User Profile Service Application. You will see the user interface in Central Administration but the synchronization service will seriously fail and eventually refuse to start, with even more exceptions in the ULS and application logs.

So instead I decided to use some assembly redirection in Central Administration and forcing CA to use the older version of the assembly. This was done by editing the web.config of Central Administration and adding the following under the runtime/assemblyBinding element:

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">  <assemblyIdentity name="Microsoft.ResourceManagement"     publicKeyToken="31bf3856ad364e35" culture="neutral" />  <bindingRedirect oldVersion="4.0.2450.11" newVersion="4.0.2450.9" /></< span>dependentAssembly>

As you can see I’m forcing Central Administration to use 4.0.2450.9 instead of 4.0.2450.11.

Once the web.config is saved the CA app pool will automatically be recycled and SharePoint, UPA and the profile sync should run as usual.

Interesting note: Also, looks like there is a lot of updates to User Profile Service Application in the Server hotfix, but no clues about that (except the files) in the KB!!!!

WARNING! This is not a tested or validated solution for this problem. It is an intermediate solution for experienced SharePoint administrators to temporarily work around the issues. I expect that an updated CU hotfix will be released as soon as possible.