Systems Engineering and RDBMS

Archive for February 8th, 2007

Microsoft Cluster Service Will Not Start After Migrating to a Different Domain

Posted by decipherinfosys on February 8, 2007

Moving a Microsoft Cluster Service (MSCS) environment from one domain to another may not be common practice, but it does occur. Since this type of migration is rarely performed, and officially discouraged by Microsoft, there are allot of unknowns that come along with the process. Microsoft recommends completely rebuilding an MSCS cluster when migrating between domains, but there are steps that can be taken so that you can avoid completely destroying your cluster and starting from scratch in the new domain.

Why Switch Domains?

As previously mentioned, moving clusters between domains does not happen often, especially in a production environment. However, in development and pre-production environments, this may be a little more common. For example, say you have two clustered database servers connected to a SAN, and these servers are performing back-end database duties to a pre-production environment that was originally only intended to be accessed from internal clients. Then, at some point the requirements for the environment changes, and suddenly external clients need access from the outside world. Well, this automatically makes this pre-production environment a candidate to be moved to a DMZ, which is exactly what happened in this case.

Into the DMZ

Since MSCS clustering and SQL Server clustering have dependencies on an Active Directoy infrastructure, a new domain needed to be created in the DMZ to service the cluster. The cluster administrator, for example, is almost always a domain user. If nodes in an existing cluster are moved from one domain to another, that cluster administrator account will no longer be recognized by the Cluster Service on the nodes and will refuse to start, stating something along the lines of ‘the user does not have sufficient permissions to perform this function’.

Manually Re-Creating the Cluster Service Account

With the Cluster Service account no longer accessible from the old domain, one would assume that simply creating a new domain user on the new (in this case DMZ) domain, and configuring that user to start the cluster service, will allow the cluster service to successfully start. Unfortunately there is a little more to it than that, but let’s begin at the beginning. We are already on the right track by adding the cluster nodes to the new domain, and configuring a new domain user to have ‘logon as service’ rights for the cluster service on each node. For those of you unfamiliar with how to do this, you begin by going to Computer Management -> Services and Applications -> Services. Highlight the desired services (in this case the Cluster service), right-click and select Properties. From there you add the domain user from the Log On tab similar to what is shown below:

Log On Service Screenshot

Modify Local Policies

The final step to get the Cluster service to work with the new domain user is to clean up the Local Group Policies on all of the cluster nodes. To function correctly, the Cluster service account requires the following rights:

  • Act as part of the operating system
  • Adjust memory quotas for a process
  • Back up files and directories
  • Increase scheduling priorities
  • Log on as a service
  • Restore files and directories

If, as in this scenario, the cluster nodes have been migrated from another domain, identifying the rights that need to be modified is relatively easy. The old domain user account will be easy to spot because they be displayed in a cryptic alpha-numeric fashion, like “S-1-52-234-58287738359889-823487858” for example. The rights are modified by going to Start -> Programs -> Administrative Tools -> Local Security Policy, which will take you to the following screen:

Local Group Policies Screenshot

Once all of these user issues have been resolved, the Cluster service will start successfully. However, this is only the tip of the iceberg. At this point, only the Cluster service is running. If the IP addresses for the cluster have also changed, which is quite likely if you migrated to a new domain, accessing the actual cluster via Cluster Administrator will still require more work. This IP address portion will be covered separately.

This should give you some good insight as to what is involved in migrating previously configured clusters between domains. It is not a trivial task, and it is not easy, but it is possible.

Posted in Windows | 1 Comment »