The company I work for is undergoing a very long Active Directory migration project.
The result of which has included duplicate users in multiple domains, issues with Sid History, users not showing up in SharePoint, etc…
We’ve tried lots of things to work around the state of AD and one article was pretty critical for us:
The true gem of the article isn’t the article itself, it’s in the comments from Brandon on the 17th of May 2013:
This is covered in the August 2012 CU (Note, this is also part of 2010SP2) … when you run this command: STSADM -o setproperty -pn HideInactiveProfiles -pv true it will bypass disabled accounts and query the active domain.
(Interestingly, that propertyname doesn’t show up when you invoke help on STSADM -o getproperty)
For some more background on what we did,
Our AD team made copies of all user accounts from “OLDDOMAIN” to “NEWDOMAIN” these copies also included “SidHistory” When this happened what we observed was it became impossible on SP2013 to pick an “OLDDOMAIN\user” – they would only show under “NEWDOMAIN\user” – since our accounts were migrated, but the users themselves were not yet using the migrated accounts (they were still logging on as “OLDDOMAIN\user”) this created a huge problem for the SharePoint team, and thousands of SharePoint users.
Part of the solution was that article, and the other part, was that the AD Team moved the duplicated accounts In “NEWDOMAIN” to a “Holding” Organizational Unit (OU) within AD (that OU was still in NEWDOMAIN), they then asked us for the service accounts we use for SharePoint and Denied access to that OU for those accounts.
The net effect of all of this work is that SharePoint 2013 now behaves as it would if there were not duplicated accounts on our domain. When we search a user, they only show up once, and from the “correct” users domain.
Now eventually, the AD team is going to ask users to start using the accounts in the “NEWDOMAIN” -when this happens, they will pull the account OUT of the “Holding” OU, making them visible to SharePoint, and they will also deactivate the old account in “OLDDOMAIN” which would prevent duplicates from showing up.
All the credit for this solution goes to the AD team I work with for the “Holding” OU and related permissions work, and also to Craig Forester for the Blog post with the original workaround and to Brandon Ryan for posting the property name. I’ve documented it here because it’s been so impactful for us, and wanted to be sure I had a permanent reference in case the original article is ever moved.