Hello World,

You have probably noticed that I do not post a lot of information lately. The funny thing is that I have plenty of ideas or situation that I could describe in this blog.  Because I’m currently working on multiple projects (in multiple locations around the world), I do not have much time left to write some useful tips & tricks.

I’m currently busy with an Active Directory migration project.  The current infrastructure is based on a single forest and multiple domains.  The project consist of consolidating this infrastructure into a single Forest/Single Domain model.  The Intraforest migration will be performed using ADMT Tool  (see my previous post about the the latest version of the tool).  The migration process/strategy is quite clear and not too difficult. Good planning and preparation is the key.

The Challenge

 However, the customer came to us and asked if it was an issue to migrate the SQL 2005 Clustered server from a child domain to a root domain.  The migration of such servers are included in the project. So, yes, we had to come up with a scenario to migrate this Cluster.

This might be challenging. Indeed, you have to be aware that as far as I know  Microsoft does not  support the move of a cluster from one domain to another domain. The recommended approach is to rebuild a cluster in target infrastructure and move your data to the new Cluster.  Taking that information into acount, we decided to investigate and check if it was an option to move (using ADMT tool) the SQL Computer accounts (and the Cluster) between domains.

To come up with a valid strategy, we first googled a little bit and found basically 3 links that provided us some help

• http://nyc-dba.blogspot.com/2007/01/changing-domain-for-sql-2005-cluster.html
• http://zhefeng.wordpress.com/2010/03/17/how-to-migrate-sql-cluster-between-domains/
• http://support.microsoft.com/kb/915846

Move a Clustered SQL 2005 – How To

Note :

Perform this operation at your own risk !  There is no support if you perform a move from one domain to another if something goes wrong. Again, if you need to perform such action, please test it first and remember I’m providing the info “as is“. This approach might be working for you or might not

Step 1 :

Bring all the Cluster resources Offline

Step 2 :

Stop the Cluster Service

Step 3 :

Set the Startup mode of the Cluster service from automatic to manual

Step 4 :

Using the ADMT Tool, we have migrated the service accounts used by SQL

Step 5 : 

Using the ADMT tool, we have migrated the sql groups uses by SQL

Step 6 :

Using ADMT, we have migrated the computer accounts (one at a time )

Step 7 :

ADMT tool will reboot automatically the SQL Nodes

Step 8 :

Check that Cluster service account has still the correct NT rights in the target Domain  

• Act as part of the operating system
• Adjust memory quotas for a process
• Debug programs
• Increase scheduling priority
• Manage auditing and security log
• Restore files and directories

Step 9 :

Check that SQL Service account has still the correct NT rights in the target Domain 

• Adjust memory quotas for a process
• Lock pages in memory
• Log on as a batch job
• Log on as a service
• Replace a process level token

Step 9 :

Add Cluster service account and SQL Service Account in the Local Administrators Groups. I encountered some issues if these two accounts are not member of the loca administrators group.

Step 10 :

Update information about SQL Groups through Registry. When you perform the installation of SQL, the setup program will ask you to assign one or multiple groups to the following services (mainly)

• SQL Agent
• SQL Full Index
• SQL Server

Apparently, information about these groups are stored in the registry.  The registry information is not using their display name but the SID.  I do not know if using the SIDHistory, the information in the registry is still valid (for SQL) or not.  At the end of the project, we have to perform a cleanup of the SIDHistory attribute, so we decided to modify directly the SID information in the registry.

Note : Perform this operation on both SQL NODES

We have to browse to the followign location : HKLM\Software\Microsoft\Microsoft SQL server\MSSQL.X\setup (where x is the SQL instance to be modified). Under this key you will find 3 registry keys that need to be updated :

• AGTGroup (SQL Agent Group)
• SQLGroup (SQL Server Group)
• FTSGroup (Full Text Index Group)

           

The Microsoft knowlege base also mention information about updating the following registry entry HKLM\Software\Microsoft\Microsoft SQL server\MSSQL.X\setup\Resume. Set the value of the Resume registry entry to 1 . 

When you have performed the operation on both nodes,  simply reboot them (not at the same time, give some delays between them), you will need to check that your resource come effectively online and that you are able to perform a failover operation between both nodes . 

Final Words

Using this step by step procedure, we are able to move the SQL 2005 server from one domain to another.  Something I might have forgotten to tell and that might be important : the SQL 2005 server has been patched with the Service Pack 3.  Before performing this procedure, you should check that both nodes have been patched accordingly and that they have exactly the same patches or service pack

That’s it for Tonight !  I hope this can help some of you.

Till next time

See ya