Changing Windows Domain

I have a 2 node Windows 2000 Active/Passive Cluster running SQL Server 2000
Enterprise Edition. The cluster supports a 24x365, mission critical
application.
The nodes are currently members of a Windows NT4 domain which trusts a
Windows 2003 Active Directory Domain. All user and service accounts
(including SQLServer and SQLServer Agent accounts) are "ADDomain" accounts.
I am planning on using the procedure described in KBs 269196 and 319016 to
move the cluster from "NT4Domain" to the trusted "ADDomain". The TCP/IP
names and addresses will not change, and to reiterate, the user and service
accounts are already logging into the trusted domain "ADDomain", not
"NT4Domain".
When I look at 319016, however, I get the impression that that KB was
written more to address a changed TCP/IP domain as opposed to a changed
Windows domain. My questions are:
1) Does 319016 even apply in this situation?
For example, step 1 of 319016 calls for a rerun of SQLServer setup. Since
1) the TCP/IP address is not changing and 2) the SQL service account is not
changing, do I need to perform step 1? I'm not sure what all setup might be
doing there.
Also, step 2 of 319016 calls for the new TCP/IP address to be entered for
each instance. Again, the IP address is not changing. As info, there is
only the default instance.
2) I think that I need to move both nodes into the new domain and restart
the cluster service on both (with SQLServer resources kept offline) before
any SQL changes. Is that correct?
3) Assuming there are no GP changes, are there other concerns I'm
overlooking? I saw a similar question in which the admin was leaning toward
rebuilding from scratch instead of moving the cluster. That seems like a lot
more work (rebuilding systems, cluster resources, and
reinstalling/configuring applications) than moving as described above.
Thanks for any feedback
There are two major considerations involved in changing domains. First is
the security issue. The SQL Setup program rewrites the account login
information on each node. If that is not changing, you should be OK without
having to go through setup. Worst case, you can manually change the service
account information on each node. DO NOT attempt to start the service
manually on any particular node. Make sure the service accounts have the
same permissions on the host nodes after changing domains. Be aware that
the machines will now be subject to Group Policies which may change things
in unexpected ways.
The second is changing the FQDN of the system. If the IP domain is
different after the change, you may run into problems with client
connections. A DNS alias record can fix this faster than any other method.
If the actual host names change, then a cluster rebuild may actually be
faster. The other way to handle node renaming is to kick out each node one
at a time, change the host name, add it back to the cluster, reinstall SQL,
reapply hotfixes.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
news:CB00A57B-A0E5-450D-9C83-9818B7883595@.microsoft.com...
>I have a 2 node Windows 2000 Active/Passive Cluster running SQL Server 2000
> Enterprise Edition. The cluster supports a 24x365, mission critical
> application.
> The nodes are currently members of a Windows NT4 domain which trusts a
> Windows 2003 Active Directory Domain. All user and service accounts
> (including SQLServer and SQLServer Agent accounts) are "ADDomain"
> accounts.
> I am planning on using the procedure described in KBs 269196 and 319016 to
> move the cluster from "NT4Domain" to the trusted "ADDomain". The TCP/IP
> names and addresses will not change, and to reiterate, the user and
> service
> accounts are already logging into the trusted domain "ADDomain", not
> "NT4Domain".
> When I look at 319016, however, I get the impression that that KB was
> written more to address a changed TCP/IP domain as opposed to a changed
> Windows domain. My questions are:
> 1) Does 319016 even apply in this situation?
> For example, step 1 of 319016 calls for a rerun of SQLServer setup. Since
> 1) the TCP/IP address is not changing and 2) the SQL service account is
> not
> changing, do I need to perform step 1? I'm not sure what all setup might
> be
> doing there.
> Also, step 2 of 319016 calls for the new TCP/IP address to be entered for
> each instance. Again, the IP address is not changing. As info, there is
> only the default instance.
>

> 2) I think that I need to move both nodes into the new domain and restart
> the cluster service on both (with SQLServer resources kept offline) before
> any SQL changes. Is that correct?
> 3) Assuming there are no GP changes, are there other concerns I'm
> overlooking? I saw a similar question in which the admin was leaning
> toward
> rebuilding from scratch instead of moving the cluster. That seems like a
> lot
> more work (rebuilding systems, cluster resources, and
> reinstalling/configuring applications) than moving as described above.
> Thanks for any feedback
>
|||I just did this last night for a customer. If you are already using the new
domain's service account, it's pretty easy. I take it your cluster & SQL
service accounts are already in the local administrators group on each node.
Take all cluster groups offline. Join one node at a time to the new domain,
reboot, when both are back up in and in the new domain start the groups.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
http://msmvps.com/clustering/archive.../20/58233.aspx NYC Clustering
class
"CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
news:CB00A57B-A0E5-450D-9C83-9818B7883595@.microsoft.com...
>I have a 2 node Windows 2000 Active/Passive Cluster running SQL Server 2000
> Enterprise Edition. The cluster supports a 24x365, mission critical
> application.
> The nodes are currently members of a Windows NT4 domain which trusts a
> Windows 2003 Active Directory Domain. All user and service accounts
> (including SQLServer and SQLServer Agent accounts) are "ADDomain"
> accounts.
> I am planning on using the procedure described in KBs 269196 and 319016 to
> move the cluster from "NT4Domain" to the trusted "ADDomain". The TCP/IP
> names and addresses will not change, and to reiterate, the user and
> service
> accounts are already logging into the trusted domain "ADDomain", not
> "NT4Domain".
> When I look at 319016, however, I get the impression that that KB was
> written more to address a changed TCP/IP domain as opposed to a changed
> Windows domain. My questions are:
> 1) Does 319016 even apply in this situation?
> For example, step 1 of 319016 calls for a rerun of SQLServer setup. Since
> 1) the TCP/IP address is not changing and 2) the SQL service account is
> not
> changing, do I need to perform step 1? I'm not sure what all setup might
> be
> doing there.
> Also, step 2 of 319016 calls for the new TCP/IP address to be entered for
> each instance. Again, the IP address is not changing. As info, there is
> only the default instance.
> 2) I think that I need to move both nodes into the new domain and restart
> the cluster service on both (with SQLServer resources kept offline) before
> any SQL changes. Is that correct?
> 3) Assuming there are no GP changes, are there other concerns I'm
> overlooking? I saw a similar question in which the admin was leaning
> toward
> rebuilding from scratch instead of moving the cluster. That seems like a
> lot
> more work (rebuilding systems, cluster resources, and
> reinstalling/configuring applications) than moving as described above.
> Thanks for any feedback
>
|||I think we should be okay. The IP address will not change (domains, subnets
all remain exactly the same), I'M TOLD that there are no GP changes, and the
same service account is already being used.
Also, you wrote,
> DO NOT attempt to start the service manually on any particular node.
By this, are you saying to not start SQL through the Services applet as
opposed to starting it through Cluster Administrator after completing the
migration? Just looking for clarification of the above statement.
"Geoff N. Hiten" wrote:

> There are two major considerations involved in changing domains. First is
> the security issue. The SQL Setup program rewrites the account login
> information on each node. If that is not changing, you should be OK without
> having to go through setup. Worst case, you can manually change the service
> account information on each node. DO NOT attempt to start the service
> manually on any particular node. Make sure the service accounts have the
> same permissions on the host nodes after changing domains. Be aware that
> the machines will now be subject to Group Policies which may change things
> in unexpected ways.
> The second is changing the FQDN of the system. If the IP domain is
> different after the change, you may run into problems with client
> connections. A DNS alias record can fix this faster than any other method.
> If the actual host names change, then a cluster rebuild may actually be
> faster. The other way to handle node renaming is to kick out each node one
> at a time, change the host name, add it back to the cluster, reinstall SQL,
> reapply hotfixes.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
> news:CB00A57B-A0E5-450D-9C83-9818B7883595@.microsoft.com...
>
>
>
|||Great news; thanks. Like you said, the account is already in Administrators
so that's already done.
"Rodney R. Fournier [MVP]" wrote:

> I just did this last night for a customer. If you are already using the new
> domain's service account, it's pretty easy. I take it your cluster & SQL
> service accounts are already in the local administrators group on each node.
> Take all cluster groups offline. Join one node at a time to the new domain,
> reboot, when both are back up in and in the new domain start the groups.
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering Website
> http://msmvps.com/clustering - Blog
> http://www.clusterhelp.com - Cluster Training
> http://msmvps.com/clustering/archive.../20/58233.aspx NYC Clustering
> class
> "CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
> news:CB00A57B-A0E5-450D-9C83-9818B7883595@.microsoft.com...
>
>
|||Piece of cake then! Good Luck!
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
http://msmvps.com/clustering/archive.../20/58233.aspx NYC Clustering
class
"CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
news:769D2D4F-D9D4-4209-8E88-356FDD592842@.microsoft.com...[vbcol=seagreen]
> Great news; thanks. Like you said, the account is already in
> Administrators
> so that's already done.
> "Rodney R. Fournier [MVP]" wrote:
|||Do not start SQL through the Services applet. Let the Cluster service
manage the SQL service startup. You can use Enterprise Mangler or the SQL
Server Service Manager tool to stop/start SQL clustered instances but I
prefer to use the Cluster admin tool.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"CarolinaKB" <CarolinaKB@.discussions.microsoft.com> wrote in message
news:7E8687AC-02C3-467E-8226-846B657BBCDD@.microsoft.com...[vbcol=seagreen]
>I think we should be okay. The IP address will not change (domains,
>subnets
> all remain exactly the same), I'M TOLD that there are no GP changes, and
> the
> same service account is already being used.
> Also, you wrote,
> By this, are you saying to not start SQL through the Services applet as
> opposed to starting it through Cluster Administrator after completing the
> migration? Just looking for clarification of the above statement.
> "Geoff N. Hiten" wrote: