Active Directory Migration Woes (Part 1)

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.


4 thoughts on “Active Directory Migration Woes (Part 1)

  1. I tried to deny access to the OU for all our service accunts, but the people-picker still shows the account of the new domain.
    Any suggestions ?

    1. We had the same problem, and it turns out that the people picker looks both internally and externally.

      What this means, is that after the AD query fails, people picker looks to the web to see if the user is in the user list of that web.

      The solution to that, is to remove-spuser the old accounts.

      It was a little unnerving to run that command against thousands of users across thousands of websites, but it seemed to work.

      In the case a live we had a tracking database of which users had migrated so we were able to ensure we only removed users old accounts, and only those who had completed the migration process.

      1. I removed the entries from the user-list.Still getting the new account. Also with completly new added users in the AD, the picker shows the account with “NEW_DOMAIN\userlogin”. I tested an AD-query with the web-app-account. The entries of the OU are hidden.

Leave a Reply