When User Profile Service Explodes
When User Profile Service Explodes

When User Profile Service Explodes

Posted by on Monday, July 8th, 2013  

 

Hey folks! I know, it’s been a while since I’ve blogged. Sorry about that. I’ve been UNBELIEVABLY busy on something. I’m not even sure what.

Anyway, I thought I’d pop up to talk for just a moment about a bug that I ran across in SharePoint 2010. I have a customer that is running SharePoint 2010 SP1 plus some cumulative updates. I believe they’re on the June 2012 cumulative update. This customer has a basic User Profile Service deployment. A few months ago it exploded.

This company started using the Active Directory attribute “employeeType” to put a string of text to identify the job code of the employee. They wanted this attribute to show up in the User Profiles of SharePoint alongside the normal Job Title, which was in the AD attribute of “title.”

They did what any of us might do. They visited the User Profile Service and clicked on “Manage User Properties.” As you’ll see in a default install of SharePoint 2010 and a User Profile Service, the “title” field doesn’t appear to be mapped to anything. Surprise! Actually, it is mapped to AD’s “title” field. You won’t see that unless you look in the FIM client itself.

The Forefront Identity Management client can be viewed by opening up:

C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

This client can be used to look at the operations of the User Profile Synchronization service (that’s under the “Operations” tab, by the way). In our case, this was definitely exploding with plenty of errors in the DeltaSync runs. It shouldn’t be doing that.

Back to what the client wanted to do. They had used Central Administration to map “Job Title” to “employeeType.” Then, they mapped “Title” to “title.” The end result looked like this:

When User Profile Service Explodes

That might look pretty good. However, surprise! FIM has now misunderstood your intention and double-mapped the “title” field. You won’t know about this though… until your users start complaining that their attributes aren’t being updated or you see the error in the FIM client:

The server encountered an unexpected error in the synchronization engine:
 
 “BAIL: MMS(3540): eafam.cpp(1298): 0x80230304 (The image or dimage already has an attribute with that name.)

There’s actually quite a bit of the “image or dimage already has an attribute with that name.”

The actual buggy mappings look like this:

When User Profile Service Explodes

See what FIM did? It double-mapped the destination “Title” attribute. That’s the issue. As a result most of your sync jobs will fail for an increasing number of users until you fix this.

Speaking of that… how do you fix this? Well, no matter what I did in Central Administration it would absolutely not resolve this by itself.

The RIGHT FIX:

Call Microsoft Support.

The WRONG FIX:

Remove the double-mapping of “Title” in the FIM client directly. I’m reasonably certain this is completely unsupported and I am NOT recommending this. I am only recommending the RIGHT FIX.

I just happen to know what’s wrong with it.

There you have it. Enjoy.

Subscribe to RSS Feed

Sign Up for Newsletter