Active Directory Migration and SharePoint

Everyone should have to go through an Active Directory migration at least once in their career – you really learn how much you don’t know!

Recommendation

Create a test farm in the old domain that mimics your production farm as much as possible. Pay special attention to the service accounts. Create new accounts for each service account in the production farm, and use them in the test farm. Bring at least one content database over (backup / restore to the testfarm, then attach). Hopefully, you can do this with virtual machines, so that once you get your testfarm up and running you can snapshot it. Run the migration tools and move the testfarm servers to the new domain. Much better to try to figure things out in a testfarm than at 2 AM in a production environment!

Details

We migrated a small SharePoint 2007 farm (1 WFE/App server, 1 DB server). We used the Quest Migration Manager for Active Directory to do the heavy lifting. NOTE – every environment is different. As the saying goes, your mileage may vary.

Migrating Users

For many reasons, we moved users in phases. We also migrated the users and their machines first, and then migrated the servers (this is a debatable decision – things might have been smoother doing the servers first).

When a set of users is migrated, they are now logging in as newdomain\username, but their permissions / ownership / mysite etc. are still olddomain\username. To SharePoint these are two different users.  So, as users are migrated, you must run this STSADM command

stsadm.exe -o migrateuser -oldlogin olddomain\username -newlogin newdomain\username

This replaces the old account SID in the SharePoint databases with the new account SID – everything works. However, we did have the joy of having some ‘roaming’ users who used workstations in different locations. We did not identify them as we should have, and had all sorts of trouble when only one of their workstations was migrated. When they used the other non-migrated workstation they had no SharePoint access (other than Authenticated User). For these people, we manually added their olddomain\username to sites for which they needed access. After the migration was complete, we reran the migrateuser command on their accounts to fix things up.

Migrating SharePoint Servers

SharePoint sites worked correctly after Quest tool processing and migration of the server to the new domain. The tool did a great job creating newdomain\serviceaccounts in SQL Server, and giving them the proper roles and rights. However, the tool does not change the dbo for the SharePoint content databases to the newdomain accounts – this must be done manually.

One thing to note – the Quest tools allows you to do processing before the server is migrated. However, do not do the IIS processing on the WFE before you intend to migrate the server because the AppPool accounts will get changed to the new domain accounts – which will break SharePoint because they will not have DB access.

Running the recommended processing in the Quest tool and migrating the server worked pretty well. SharePoint sites were accessible and functional. However, these issues needed addressing (same ones we found when we tested) –

• Search did not return any results.
• Accessing the Central Admin site pages “Manage Applications” and “Operations” returned an Access Denied error.

Fixes were very easy and straightforward.

To fix the Access Denied errors

Logon to a Web Front End server. Open a command prompt, and navigate to the SharePoint 14 hive, bin directory. Run this command –

stsadm -o updatefarmcredentials -identitytype configurableid -userlogin <new domain>\admin_account –password *******

iisreset /noforce

To fix the search problem

Use the Central Admin web site to navigate to the Search Administration page (in the Shared Service Provider). Select “Default content access account” and change the domain on the account listed to the new domain. Start a new crawl (incremental is OK).