3

I have a customer with an interesting issue. They are currently synchronizing about 12k user accounts from their domain. They have a selection of accounts that are coming over incorrectly.

Lets say the domain is listed as *CompanyRes*

There are some that are a selection of profiles listed as *Res* even though this domain doesn't exist and the domain connection does not contain that connection info.

One of the side effects of this is that the org chart is askew for users with bad manager references. What is strange is that if you edit a user whose manager is listed with a Res\ domain, it provides the lookup dropdown that resolves to the correct person on the correct domain. This allows the field to be reset, but then the manager disapears from the org chart because their profile only exists with the non-existent Res\ domain.

Aside from clearing out all user profiles, is there some other way to resolve this? They have done a number of subsequent synchronizations and the problem has not corrected itself, I assume because the underlying SIDs would be the same.

2
  • Are they using an AD migration tool like Quest or have they gone through a recent AD migration? Sep 21, 2011 at 14:03
  • No recent AD migration. They did a migration 5 years ago when they split off from another company and the new domains were created at that time. Its hard to tell how widespread the problem is, but from the browsing I've done it looks like it is a small percentage of accounts. Sep 21, 2011 at 15:06

2 Answers 2

2

We ended up figuring it out after finding this link:

http://social.technet.microsoft.com/forums/en-us/sharepoint2010setup/thread/39FB47DF-4489-4217-98F7-90192B8689CA

If your NetBIOS name is different from your domain name, at least Replicate Directory Changes permission is also needed on the cn=configuration container and you must enable NetBIOS domain names on the corresponding User Profile service application. For more information about enabling NetBIOS names on a User Profile service application, see Get-SPServiceApplication.

The UPA property NetBIOSDomainNamesEnabled is used to control whether the CNC partition is included in the AD MA or not. By default it is false (not enabled) and the CNC and associated run steps are not included in the AD MA configuration. If it is enabled, then the CNC partition and run steps are included.

When editing a connection, the flag is ignored. If the CNC was included in the AD MA when it was created, then it will continue to be included in the AD MA. If the CNC was not included when the AD MA was created then it will never be included in the AD MA.

To "enable" NetBIOS domain names once a connection is created requires the connection to be deleted and a new connection created with the flag turned on (set to 1 or true). For users that unintentionally import users with the flag turned off and later turn it on, this will delete all the users which had their SAMAccountNames incorrectly formed due to the NetBIOS domain name being incorrect.

How To: Enable import of NetBIOS Domain Names

Using the 2010 SharePoint Management Shell:

Get-SPServiceApplication <lists the Service Applications and their GUIDs>
$UPA = Get-SPServiceApplication –Id <GUID of User Profile Service Application>
$UPA.NetBIOSDomainNamesEnabled=1
$UPA.Update()

Additional Steps:

  1. Grant Replicate Directory Changes permission on a domain http://technet.microsoft.com/en-gb/library/ee721049.aspx#RDCDomain

  2. Grant Replicate Directory Changes permission on the cn=configuration container http://technet.microsoft.com/en-gb/library/ee721049.aspx#RDCconfig

  3. The one Clayton Cobb posted above.

  4. Delete the exsiting connection and "Create New Connection" on "Synchronization Connections" page.

  5. Perform "Start Profile Synchronization"

1
  • Thanks a billion for figuring all this out! This has solved problems with multiple fields involved in user synchronization.
    – skeletank
    Jun 8, 2012 at 19:14
1

I would use adsiedit to check the manager field and that the sid. First compare that sid to the sid stored for the actual user. If they are the same, next check the value of the sid except for the number after the last dash ( http://en.wikipedia.org/wiki/Security_Identifier ), and compare that to another user's manager where the manager worked correctly. Are the numbers the same?? Also, on a user who's manager is not working correctly, what happens if you remove the manager, save, and then readd it? Does the sync work correctly then?

I think the issue is in what's stored in AD itself, but if you wanted to do some SP troubleshooting I would check the following:

  1. I would run C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe and poke around in there. You can search the metaverse for the user and see the data. You can also view the updates and see the projected changes.

  2. Try running migrateuser to fix the names. I don't think this would work because i think that command only updates the user information list and also since it's a wss/foundation command, i doubt it changes the user profile database.

2
  • I just looked in adsiedit and I think that the manager property uses distinguishedName and not sid. Sorry, my mistake. Sep 22, 2011 at 19:19
  • Also, it seems that the quest tool is supposed to keep the same sid through a domain migration. So that could also make sense with what you are seeing in the user profile store. Sep 22, 2011 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.