Migrating Windows 2008 SQL Cluster to New Windows Domain

This procedure is unsupported and Microsoft recommends deleting the cluster and rebuilding it from scratch if you want to migrate it from one Windows Domain to another Windows Domain. However, I have had some success migrating a clustered SQL 2008 R2 server running on Windows 2008 R2 Failover Cluster. The instructions are at a high level and assume that you know who to configure Windows Failover Cluster, edit the registry and manage Active Directory Object. If you do not know how to do these things then you probably should not be attempting to follow these instructions in the first place. If I get the time I will update the instructions with more detail and some screenshots. YOU USE THESE INSTRUCTIONS AT YOUR OWN RISK.

1. Set the cluster IP address to the correct network and the new IP address
2. Add the cluster name to DNS with the new IP address
3. Create a new Computer Account in the new domain for the cluster
4. Update registry on each cluster node with the new GUID of the computer account created in the new domain (see below)
5. Right click on the Cluster Name resource and select More Actions….Repair Active Directory Object
6. For each clustered SQL instance
   1. Set the SQL Instance IP address to the correct network and new IP address
   2. Add the SQL instance name to DNS with the new IP address
   3. Create a new computer account in the new domain for the SQL instance
   4. Set permissions on the SQL instance computer account
   5. Update registry on each cluster node with the new GUID of the SQL instance computer account created in the new domain (see below)
7. Restart the Cluster Service
8. If you have done all of the above correctly then the cluster core services should successfully start and each of the SQL instances should start

Updating the registry with the new GUID of the computer account created in the new domain

The GUID of the new computer account will be in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. You can find this from the Attribute Editor as ObjectGUID

These are pairs of hexadecimal numbers, e.g. 11223344-5566-7788-9900-aabbccddeeff.

In the registry the first 3 sets of hexadecimal numbers have the pairs reversed e.g. 12345678 becomes 78563412, i..e the pairs are 12 34 56 78, so take 78 then 56 then 34 then 12. In addition the hyphens are not stored in the registry, so for a GUID of 5e6ff387-e531-4ee6-9bf0-6245aa54d31e it would be stored in the registry as 87f36f5e31e5e64e9bf06245aa54d31e.

In the registry under HKLM\Cluster\Resources each of the resources are listed in separate subkeys, to find the correct subkey for the cluster name, find the subkey which contains CoreCurrentName, below this look at Paramaters and edit ObjectGUID to match the translated GUID for the computer account that has been created in the new AD.

Permissions to set on the computer account created for the SQL instance

Give the cluster computer account the following permissions to the SQL instance computer account

• Read
• Allow to authenticate
• Change password
• Receive as
• Reset password
• Send as
• Validated write to DNS Host Name
• Validate write to service principle name
• Read account restrictions
• Write account restrictions
• Read DNS host name attributes
• Read MS TS gateway access
• Read personal information
• Read public information

 Updating the registry with the new GUID of the SQL instance account created in the new domain

The GUID of the SQL instance computer accounts needs to be translated in the same way as the computer account GUID was translated to be stored in the registry.

Again look in the registry under HKLM\Cluster\Resources and find the resource for the SQL instance name the Name key will be set to SQL Network Name (SQL-INSTANCE-NAME), e.g. SQL Network Name (SQLSERVER01), again under here open up Parameters and set ObjectGUID to the translated GUID for the instance computer account you have created.