Q178009: Renaming a Domain: Process and Side Effects
Article: Q178009
Product(s): Microsoft Windows NT
Version(s): winnt:3.51,4.0
Operating System(s):
Keyword(s):
Last Modified: 09-AUG-2001
-------------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows NT Server versions 3.51, 4.0
-------------------------------------------------------------------------------
WARNING: The information in this article has not been confirmed or tested
by Microsoft. ANY USE BY YOU OF THE INFORMAITON PROVIDED IN THIS ARTICLE IS
AT YOUR OWN RISK. Microsoft provides this information "as is" without
warranty of any kind, either express or implied, including but not limited
to the implied warranties of merchantability and/or fitness for a
particular purpose.
SUMMARY
=======
In Windows NT, a domain is uniquely identified by both a NetBIOS name and by a
Security Identifier (SID). Most Access Control Lists (ACLs) and other security
features of Windows NT identify the domain by a SID; therefore, it is possible
to change the name of the domain with little disruption to network services.
The following procedure describes how to safely rename a Windows NT domain. This
will work for a single domain, or for an accounts domain or resource domain in a
network using the master domain model.
Please read this article in its entirety before attempting to rename your domain.
Some BackOffice products are adversely affected by renaming a domain; these
products are detailed later in this article.
Microsoft cannot guarantee that any third-party software that is installed will
function after changing the domain name. You should work with third-party
application vendors to ensure you understand how their product will react to a
domain name change.
Microsoft strongly recommends that you thoroughly test, outside of a production
environment, the effects of renaming your domain, before you actually change the
domain name on your production computers. This article does not attempt to
address every issue that might arise as a consequence of renaming your domain.
Use this procedure at your own risk.
Important notes:
- Do not install any primary domain controller (PDC) or backup domain
controller (BDC) during this procedure, under either the old or new domain
name.
- Do not promote any BDC to PDC during this procedure.
- This procedure should only be undertaken during a time when ALL network
services related to this domain can be disrupted. All clients should log off
and remain logged off until the rename is complete and all computers involved
have been restarted.
- Perform a full backup on all computers involved immediately before beginning
this process.
- Create separate, updated Emergency Repair Disks for each computer involved
immediately before and after the update.
- Have a copy of the Windows NT Server compact disc, the latest service pack,
and Windows NT boot disks (appropriate to your version of Windows NT)
available during the procedure.
- The NETDOM utility in the Windows NT Server Resource Kit, Supplement 2, can
be used to change the domain name remotely on some computers, preventing a
visit to each computer involved.
MORE INFORMATION
================
To change a domain name, follow these steps:
1. Document and then break all trust relationships between the domain whose name
you will be changing and all other domains. Be sure to remove the trust entry
on both sides of the trust (in User Manager for Domains for both domains in
the trust).
2. Stop all BackOffice services such as Microsoft Exchange Server, SQL Server,
and Internet Information Server. Set startup to manual on all these services.
3. Change the domain name on the PDC.
4. Restart the PDC. This will cause the <1Bh> entry for the new domain to
appear in the WINS server.
5. If you are using WINS for NetBIOS over TCP/IP name resolution, force
replication from the PDC's primary WINS server to all other WINS servers to
propagate the <1Bh> entry for the new domain. Name resolution to the
PDC is necessary for each BDC to successfully change to the new domain name.
If you are using TCP/IP without using WINS, create an LMHOSTS file with a
<1Bh> entry for the new domain and put it on each BDC.
6. On each BDC, change the domain name and restart. The restart is necessary for
the BDC to correctly register its <1Ch> entry with WINS.
For additional information about what to do if the BDC refuses the domain name
change, please see the following article in the Microsoft Knowledge Base:
Q139471 Unable to Change Domain Name of Windows NT BDC
7. Force replication from all WINS servers to propagate the <1Ch> entry.
8. Re-establish the trust relationships. Using Server Manager, synchronize both
domains involved in each trust.
9. In the Services tool in Control Panel, re-enter the service account for each
of the BackOffice services that were stopped in step 2. Pick the account by
using the Startup button rather than typing in the account name. Set the
services back to Automatic startup, if appropriate. Restart the services in
the correct order.
10. Make any necessary service-specific changes, as detailed elsewhere in this
article.
11. Change the domain name on each member server or workstation. For downlevel
clients such as Windows 95 or Windows for Workgroups, change the workgroup
name to the new domain name.
12. Synchronize the entire domain.
Troubleshooting
---------------
If you encounter errors on any of the BDCs after the name change is completed,
the most likely causes will be either name resolution or accounts database
synchronization problems. The first thing you should do to troubleshoot is to
open Server Manager on the computer that has problems and synchronize it with
the PDC. For name resolution issues, make sure that WINS has replicated or that
your LMHOSTS files are correct.
You may encounter some errors in batch files and so on, with the old domain name
embedded. For this reason, you should check all such files. They are likely to
be found in the NETLOGON share on your domain controllers, referenced by the
Scheduler service where it is installed, and in any other scripting or
automation tools that you use.
You can find out more information about specific error events by searching the
Microsoft Knowledge Base for "event id XXXX" where XXXX is the event id number
of the error event. The Microsoft Knowledge Base is available on the World Wide
Web at:
http://msdn.microsoft.com/support
If you encounter any problems after the domain name change, they are likely
related to the name change, especially if you see any of the following errors:
Network name not found
-or-
Error 53
Typically, these are name resolution issues that are specific to one computer.
Check for the COMPUTERNAME<00h>, COMPUTERNAME<03h>, and
COMPUTERNAME<20h> entries in WINS, and replicate if necessary.
A domain controller for this domain could not be found.
-or-
Unable to contact the domain controller for this domain.
Typically, these are name resolution issues specific to the domain. Look for the
DOMAIN<1Bh> and DOMAIN<1Ch> entries in WINS, and replicate if
necessary.
The trust relationship failed.
Typically, this is either a trust relationship with another domain that was not
re-established, or an invalid machine account. Reestablish the trust, or delete
and re-create the machine account for the computer and remove and re-add the
computer to the domain.
Possible Side Effects of a Domain Name Change
---------------------------------------------
- Service accounts are stored textually, not as SIDs, in the Service Control
Manager database. Therefore, any services, on any computer, that use domain
user accounts as their service account will have to be manually adjusted. The
Sc.exe utility from the Windows NT Server Resource Kit may be useful for
making this change on remote computers.
- If you are using integrated security in SQL Server, you will need to reset
the "Default Domain" field in SQL Security Manager. Additionally, if the
users are not part of the "Default Domain" you may need to remove and re-add
users and groups from the renamed domain or local groups containing groups
from the renamed domain.
- Microsoft Exchange Server service accounts will need to be reassociated with
the new domain name, as described earlier. Additionally, in the Exchange
Administrator program, select Tools, select Options, and then click the
Permissions tab, you will need to change the default Windows NT domain name
to the new domain name.
- Security settings on all Exchange Server public folders will be lost. Before
renaming the domain, use the command line utility Pfadmin.exe to export the
public folder security settings to a text file to make reconstruction of the
permissions easier. This utility can be downloaded as part of the Microsoft
Exchange Server Resource Kit from the following Web site:
http://www.microsoft.com/servers
- If Systems Management Server primary or secondary sites exist in the domain
that is being renamed, Systems Management Server will have to be uninstalled
and then reinstalled with the new domain name. You will not be able to
restore the existing Systems Management Server database after reinstallation;
you will have to start with a clean database.
- If the domain being renamed is part of an Systems Management Server site but
has no primary or secondary sites located in it (only logon servers and
clients), the domain should be removed from the site prior to the name change
and added back into the site after the change. Please refer to the Systems
Management Server Installation and Configuration Manual, Chapter 3, "Adding
Domains, Servers, and Clients."
- If you are running Internet Information Server, you may need to change the
account specified in virtual paths.
Additional query words: ntfaqdom
======================================================================
Keywords :
Technology : kbWinNTsearch kbWinNT351search kbWinNT400search kbWinNTSsearch kbWinNTS400search kbWinNTS400 kbWinNTS351 kbWinNTS351search
Version : winnt:3.51,4.0
Issue type : kbinfo
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.