Migrating SharePoint to a new domain--do it the right way
I recently worked a case where the customer was having issues with getting the Distributed Cache running. When attempting to run a Register-CacheHost commandlet, they would get the following error: "The requested name is valid but no data of the requested type was found."
To investigate further, we ultimately queried the Config database to check settings for the CacheConfigCluster:
SELECT * FROM dbo.CacheClusterConfig WHERE EntryType = 'hosts'
When we did this, we could see that servers with different domains than the current domain name were listed. It turns out the customer had attempted to migrate an existing farm to a new domain by changing account settings in SharePoint and SQL. While you might be able to get away with this for a single-server development environment (there are many blogs out there detailing how to do this), attempting to do this with a production and/or multi-server server farm is a very bad idea, and is in fact unsupported.
Simply "moving" a SharePoint farm from one domain to another is actually not possible. SharePoint hard-codes server and account names, including domains, in the Configuration database. This is done in multiple tables. There is no way to modify these settings in a supported manner.
Fundamentally, you must create a new farm in the target domain and move the existing content. At a high level, this involves the following steps:
- Disconnect and rejoin servers to a new farm with new config database
- Create new Service Applications using existing DBs when possible
- Create new web applications
- Deploy all the custom solutions and custom configuration
- Mount the databases to respected web applications
- Migrate the users from old domain to new domain