Upgrading your domains from Microsoft® Windows NT® 4.0 to Windows® Server 2003 Active Directory® directory service enables your organization to improve the security and scalability of your network infrastructure while reducing administrative overhead. As an alternative to restructuring Windows NT 4.0 domains, the in-place upgrade is an efficient, time-saving process that minimizes the effect on the Windows NT 4.0 production environment.
In This Chapter
Overview of Upgrading Windows NT 4.0 Domains... 288 Collecting Design Information ... 295 Completing Pre-Upgrade Tasks ... 310 Upgrading Domains from Windows NT 4.0 to Windows Server 2003
Active Directory... 312 Completing Post-Upgrade Tasks... 349 Additional Resources... 353 Related Information
u For more information about restructuring domains when upgrading from Windows NT 4.0 to Windows Server 2003, see “Restructuring Windows NT 4.0 Domains to an Active Directory Forest” in this book.
u For more information about the Active Directory logical structure, see "Designing the Active Directory Logical Structure" in this book.
u For more information about Windows Server 2003 Active Directory Functional Levels, see
“Enabling Advanced Windows Server 2003 Active Directory Features” in this book.
u For more information about Active Directory site topology, see "Designing the Site Topology" in this book.
Upgrading
Windows NT 4.0 Domains
to Windows Server 2003
Active Directory
Overview of Upgrading Windows NT 4.0 Domains
Upgrading your Windows NT 4.0 domains to the Microsoft® Windows® Server 2003, Standard Edition and Windows® Server 2003, Enterprise Edition operating systems enables you to simplify and reduce network administration. Windows Server 2003 Active Directory integrates with other applications and services and allows you to delegate administrative responsibility at the appropriate level when you have multiple organizations existing in a single domain structure.
When you upgrade your Windows NT 4.0 domains to Windows Server 2003 Active Directory, you improve scalability because Active Directory domains can scale to meet the needs of your organization. You also gain new capabilities by using Group Policy, and you gain more flexibility for business units.
In addition, performing an in-place upgrade of Windows NT 4.0 domains to Windows Server 2003 Active Directory has no adverse effect on your Windows NT 4.0 production environment. There are fewer administrative complexities than with restructuring your environment, such as maintaining access to shared directories, files, and printers. Groups and group memberships are retained. You do not need to migrate local profiles, and you retain the existing passwords and profiles for domain users.
Before planning and implementing Windows NT 4.0 in-place upgrades, ensure that your organization has already:
u Designed the Active Directory logical structure of the forest and Domain Name System (DNS) for your Active Directory environment.
u Designed a site topology to efficiently locate domain controllers.
u Deployed a Windows Server 2003 forest root domain if that is the upgrade path that your organization has decided on. For more information about the paths for in-place upgrading a Windows NT 4.0 environment, see “Upgrading Domains from Windows NT 4.0 to Windows Server 2003 Active Directory” later in this chapter.
After completing the in-place upgrade process, you can perform an in-place upgrade for any remaining Windows NT domains or restructure them into your new Windows Server 2003 forest.
For information about restructuring Windows NT 4.0 domains to a Windows Server 2003 forest, see "Restructuring Windows NT 4.0 Domains to an Active Directory Forest" in this book.
Note
For a list of the job aids that are available to assist you in upgrading your Windows NT 4.0 domains to Windows Server 2003 Active Directory, see
“Additional Resources” later in this chapter.
Process for Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory
Upgrading your Windows NT 4.0 domains to Windows Server 2003 Active Directory involves first completing the necessary preparation tasks and then following the steps to complete the upgrade. Figure 8.1 shows the process for upgrading Windows NT 4.0 domains to Windows Server 2003 Active Directory.
Figure 8.1 Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory
Complete pre- upgrade tasks
Upgrade domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Complete post- upgrade tasks
Collect design information
Background Information for Upgrading to Windows Server 2003 Active Directory
Before you begin the Windows NT 4.0 in-place domain upgrade, become familiar with some important issues that affect the upgrade process.
PDC Offline Operations
During the process of upgrading the operating system on the primary domain controller (PDC) from Windows NT 4.0 to Windows Server 2003 and installing Active Directory, client operations such as logon and resource access will continue to function because these services are provided by backup domain controllers. However, because the PDC will be offline during most phases of the upgrade process, typically between one and three hours, operations that require data to be written to the domain will not succeed. For example, users will not be able to change their passwords and administrators will not be able to create, delete, or unlock user accounts.
Administrative tools, such as User Manager for Domains or Server Manager, can be used only in read-only mode on backup domain controllers in the domain. In addition, you will not be able to create new objects, such as users and groups, while the PDC is offline.
Full Synchronization of the Local Security Authority Database
After upgrading a Windows NT 4.0 PDC, or after transferring the PDC role to another domain controller, the LSA will perform a single full synchronization of all objects in the database. This synchronization causes events to be logged in Event Viewer; specifically, Event Viewer in Windows Server 2003 will log Event ID 5713 and Event Viewer in Windows NT 4.0 will log Event ID 5717. However, the LSA database contains relatively few objects and the full synchronization does not affect network performance.
Do not confuse the full synchronization of the LSA database with a backup domain controller (BDC) full synchronization. A BDC full synchronization typically happens when too many changes occur on a PDC before the PDC can replicate the changes to a BDC. The number of objects that are replicated during a BDC full synchronization and the amount of network traffic that is generated depends on the number of users, groups, and workstations in the domain.
Domain Users and Client Workstation Operating Systems
When Microsoft® Windows® 2000, Microsoft® Windows® XP, and Windows Server 2003 clients attempt to authenticate with a domain controller, they first retrieve a list of domain controllers from either DNS or WINS, and will then authenticate with the first domain controller that responds to their authentication request. The first domain controller to respond is usually a domain controller located closest to the client. The client and the domain controller will then negotiate which authentication protocol to use.
When Windows 2000, Windows XP, and Windows Server 2003 clients are members of a Windows NT 4.0 domain, they will only use the NTLM protocol to authenticate because that is the only authentication protocol supported by Windows NT 4.0. Windows 2000 and Windows Server 2003 domain controllers are capable of using either the NTLM or the more secure Kerberos authentication protocol.
When performing an in-place upgrade of a Windows NT 4.0 domain to Windows Server 2003, the first domain controller upgraded is the Windows NT 4.0 PDC. If clients in the domain running Windows 2000, Windows XP, and Windows Server 2003 select the new Active
Directory domain controller for authentication, the negotiation of the authentication protocol will reveal that there are now domain controllers in the domain that support the Kerberos protocol.
These clients will then upgrade their secure channel to exclusively use the Kerberos protocol for authentication requests and will no longer attempt to authenticate using the NTLM protocol, potentially causing the new Active Directory domain controller to become overloaded with authentication requests.
To prevent Windows Server 2003–based domain controllers from being overloaded with authentication requests, configure each Windows Server 2003–based domain controller to emulate a Windows NT 4.0–based domain controller during the upgrade process. Configuring a newly upgraded Windows Server 2003–based domain controller to emulate a Windows NT 4.0–
based domain controller by using the NT4Emulator registry entry shields the new domain controller from getting too many authentication requests from Active Directory clients. Shielding the Active Directory domain controller takes place before the operating system is upgraded to Windows Server 2003 to prevent clients running Windows 2000, Windows XP, and Windows Server 2003 from ever establishing exclusive communications with a Windows Server 2003–
based domain controller.
When upgrading additional Windows NT 4.0–based domain controllers after the PDC has been configured to emulate a Windows NT 4.0–based domain controller, you must remember to configure the computer you are upgrading with the NeutralizeNT4Emulator registry entry. This is so that the additional domain controller will recognize the upgraded PDC that is emulating a Windows NT 4.0–based domain controller as an Active Directory domain controller. If the computer is not configured to neutralize emulation, you will not be able to install Active Directory because the additional domain controller will not be able to authenticate to an Active Directory domain controller.
For each site in which clients are running Windows 2000, Windows XP, and Windows Server 2003, ensure that you have enough Windows Server 2003–based domain controllers deployed in that site before removing Windows NT 4.0 emulation.
For more information about emulating Windows NT 4.0–based domain controllers, see
“Configure Protection Against Domain Controller Overload” later in this chapter.
For more information about domain controller placement, see “Designing the Site Topology” in this book. For more information about domain controller capacity planning and determining the number of domain controllers needed in each site to service Active Directory clients, see
“Planning Domain Controller Capacity” in this book.
Service Compatibility
In Windows NT 4.0 and earlier server operating systems, services running in the context of the Local System account communicate with other services over the network by using null sessions (a session in which a user name or password is not provided). In Windows 2000 and later operating systems, services running in the context of the Local System account on the local computer use the local computer account to authenticate to other servers. By default, Active Directory does not accept null session queries.
Of all the services that run in the context of the Local System account, Remote Access Services (RAS) is the most prominent. You cannot use null sessions to access network resources by using NTLM authentication unless the remote computer allows access with null credentials.
In an Active Directory environment containing both Windows NT 4.0–based and Windows Server 2003–based domain controllers, a member server that is running Windows NT 4.0 and is configured as a RAS server cannot retrieve information from a Windows Server 2003–based domain controller. For example, if a caller tries to dial into your network and accesses a
Windows NT 4.0 member server that is configured as a RAS server, the RAS server must query a domain controller first to verify whether the caller has permission to dial into the network.
Therefore, RAS operates correctly only if the domain controller responding to the RAS authentication request is a Windows NT 4.0–based BDC or the Active Directory domain has been configured to allow resources to be accessed by using null credentials. By upgrading the operating system on Windows NT 4.0 member servers that are configured as RAS servers to Windows Server 2003, you ensure that RAS callers are successfully authenticated by a Windows Server 2003 Active Directory–based domain controller.
The recommended solution is to upgrade the RAS servers to Windows Server 2003. However, if this cannot be done, the alternatives are:
u While installing Active Directory on the upgraded Windows NT 4.0 PDC, on the Permissions page of the Active Directory Installation wizard, select Permissions compatible with pre-Windows 2000 Server operating systems.
– or –
Add the Everyone group and the Anonymous Logon group to the Pre-Windows 2000 Compatible Access built-in group by using Active Directory Users and Computers or the command line.
To add the Everyone group to the Pre-Windows 2000 Compatible Access Group by using the command line
u At the command line, type:
net localgroup "Pre-Windows 2000 Compatible Access" Everyone /add
To add the Anonymous Logon group to the Pre-Windows 2000 Compatible Access Group by using the command line
u At the command line, type:
net localgroup "Pre-Windows 2000 Compatible Access" “Anonymous Logon”
/add
Both of these methods combined allow null sessions to read information out of the directory.
After you upgrade all RAS servers, and when you no longer need backward compatibility with operating systems earlier than Windows 2000, remove the Everyone group and the Anonymous Logon group from the Pre-Windows 2000 Compatible Access built-in group. For more
information about removing the Everyone group and the Anonymous Logon group from the Pre- Windows 2000 Compatible Access group, see “Eliminate Anonymous Connections to Domain Controllers” later in this chapter.
LAN Manager Replication Service and the File Replication Service
In Windows NT 4.0, the LAN Manager Replication (LMRepl) service provides single master replication of logon scripts and other database information located in the NETLOGON share on a Windows NT 4.0–based domain controller that is designated as an export server to all other Windows NT 4.0–based domain controllers in the domain. LMRepl can be configured only on Windows NT 4.0–based domain controllers. In Windows 2000 and Windows Server 2003, logon scripts and profile information are stored in the NETLOGON shared folder (which contains policies and scripts for non-Active Directory clients) and the SYSVOL shared folder (which contains Group Policy files and scripts for Active Directory clients). The File Replication service (FRS), a multimaster replication engine that runs automatically on all Windows Server 2003–
based domain controllers, replaces the LMRepl service and replicates the NETLOGON and SYSVOL shared folders between domain controllers in a Windows Server 2003 domain.
During the in-place domain upgrade process, your environment includes Windows NT 4.0–based BDCs operating with Windows Server 2003–based domain controllers. FRS and LMRepl are not backward compatible. Therefore, to provide support for the LMRepl service in the Active Directory environment, you need to create a bridge between LMRepl and FRS to replicated new files created in the NETLOGON folder on Windows Server 2003 domain controllers to the Windows NT 4.0 export server. The bridge is created by using the Lbridge.cmd script and the Robocopy.exe tool so that both services can operate autonomously. Do this by selecting one Windows Server 2003–based domain controller to copy the SYSVOL shared folder to the Windows NT 4.0 export directory of the Windows NT 4.0 export server. You can use a regularly scheduled script to copy the shared folder. For more information about creating this script, see
“Synchronize File Replication Services” later in this chapter.
Note
After this update to the Pre-Windows 2000 Compatible Access group replicates, you must restart the Server service on all domain controllers.
Security Policy Considerations when Upgrading from Windows NT 4.0 to Windows Server 2003
Server message block (SMB) packet signing and secure channel signing are security policies that are enabled by default on Windows Server 2003–based domain controllers. To allow clients running earlier versions of Windows to communicate with domain controllers running Windows Server 2003, you might need to temporarily disable these security policies during the upgrade process.
SMB packet signing
SMB packet signing is a security mechanism that protects the data integrity of SMB traffic between client computers and servers, and prevents man-in-the-middle attacks by providing a form of mutual authentication. This is done by placing a digital security signature into each SMB packet, which is then verified by the receiving party. Server-side SMB signing is required by default on Windows Server 2003–based domain controllers, which means that all clients are required to have SMB packet signing enabled.
Clients running Windows NT 4.0 with Service Pack 2 or earlier, and clients running Microsoft®
Windows® 95 without the Directory Service Client Pack, do not support SMB packet signing.
These clients will not be able to authenticate to a Windows Server 2003–based domain controller.
To ensure successful authentication, upgrade these clients to a later version of the operating system or Service Pack. However, if you cannot upgrade your clients, you can allow them to be authenticated by configuring SMB packet signing on all Windows Server 2003–based domain controllers so that SMB packet signing is preferred but not required.
For more information about SMB packet signing, see “Microsoft network server: Digitally sign communications (always)” in Help and Support Center for Windows Server 2003.
For more information about configuring SMB packet signing on Windows Server 2003–based domain controllers, see “Modify Security Policies” later in this chapter.
For more information about the Directory Services Client Pack, see article 323466, “Availability of the Directory Services Client Update for Windows 95 and Windows 98” in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Secure channel signing and encryption
When a computer becomes a member of a domain, a computer account is created. Each time the computer starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to ensure secure communications between a domain member and a domain controller for its domain. Secure channel signing is required by default on Windows Server 2003–based domain controllers, which means that all clients must enable secure channel signing and encryption.
Clients running Windows NT 4.0 with Service Pack 3 or earlier installed do not support secure channel signing. These clients will not be able to establish communications with a Windows Server 2003–based domain controller. To ensure successful communication, upgrade these clients to a later version of the operating system or Service Pack. However, if you cannot upgrade your clients, you must disable secure channel signing on all Windows Server 2003–based domain controllers so that the traffic passing through the secure channel is not required to be signed or encrypted.
For more information about secure channel signing, see “Domain member: Digitally encrypt or sign secure channel data (always)” in Help and Support Center for Windows Server 2003.
For more information about configuring secure channel signing on Windows Server 2003–based domain controllers, see “Modify Security Policies” later in this chapter.
Collecting Design Information
In preparation for deployment, the forest owner in your organization is responsible for working with the deployment team to acquire the following information:
u Documentation of your current Windows NT 4.0 environment.
u Names of the Windows NT 4.0 domains that will be upgraded and the order in which to upgrade them.
u Supported operating system upgrade paths for your Windows NT 4.0–based domain controllers.
Information such as domain diagrams, network services, and trust relationships might have been documented as part of the design process, and collecting it will be a matter of querying the design team. However, information such as the existing network and hardware configuration of each domain controller might have to be collected or documented by the forest owner during the deployment phase of the project.
In addition, the forest owner is responsible for developing a test plan and for developing a recovery plan in the event that the deployment does not complete successfully.
Note
Unlike SMB packet signing, secure channel signing does not affect Windows 95 clients.
Figure 8.2 shows the steps involved in collecting the design information that will be used to upgrade Windows NT 4.0 domains to Windows Server 2003 Active Directory.
Figure 8.2 Collecting Design Information
Complete pre- upgrade tasks
Upgrade domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Complete post- upgrade tasks
Collect design information Document the existing environment
Determine the domain upgrade order
Determine supported operating system upgrades
Develop a test plan
Develop a recovery plan
Document the Existing Environment
Before upgrading a Windows NT 4.0 domain to Windows Server 2003 Active Directory, document the existing Windows NT 4.0 domain structure.
Create a diagram that includes the following information:
u The names of all account and resource domains.
u The inbound and outbound trust relationships that each domain shares.
If documentation already exists for your domain, review the existing documentation for accuracy and clarity.
Figure 8.3 shows an example of the existing Windows NT 4.0 domain structure for a fictitious company, Trey Research.
Figure 8.3 Example of a Windows NT 4.0 Domain Diagram
Boston East
Mail-Apps Prod-Apps Office-Apps
In addition to documenting the existing domain structure, document the following:
u The domain controllers and the services that each provides in the domain.
u The existing hardware configuration on all domain controllers in the domain.
u The existing network configuration, including IP address and network adapter information for each domain controller.
u The current domain controller assignments and the role that you plan to assign to each domain controller after the in-place domain upgrade.
Document Domain Controllers and Services
Identify and document the domain controllers in the existing Windows NT 4.0 domain. Include in your documentation the role that each domain controller assumes in the domain and the services that each domain controller provides. Identify domain controllers that provide Remote Access Service and the LAN Manager Replication (LMRepl) service, because upgrading to Windows Server 2003 Active Directory affects these services.
For a worksheet to assist you in documenting domain controllers and services see
“Windows NT 4.0 Domain Controllers and Services” (DSSUPNT_1.doc) or “Windows NT 4.0 Domain Controller Documentation” (DSSUPNT_5.xls) on the Microsoft® Windows®
Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Domain Controllers and Services” or “Windows NT 4.0 Domain Controller Documentation” on the Web at
http://www.microsoft.com/reskit). “Windows NT 4.0 Domain Controller Documentation” is a master worksheet combining the information from all four individual worksheets in this section.
Example: Documenting Windows NT 4.0 Domain Controllers and Services
Trey Research has a Windows NT 4.0 account domain that includes nine domain controllers running Windows NT 4.0. Because the resource domains hold all of the application servers, the account domain does not include member servers. The PDC, SEA-EAST-DC01, is also a Windows Internet Name Service (WINS) server, as are two BDCs, BOS-EAST-DC01 and BOS- EAST-DC02.
Trey Research documented the domain controllers and services in their Windows NT 4.0 domain, as shown in Figure 8.4.
Figure 8.4 Example of Windows NT 4.0 Domain Controllers and Services Worksheet
For more information about the effect of upgrading to Windows Server 2003 Active Directory on the RAS service and the LMRepl service, see “Background Information for Upgrading to Windows Server 2003 Active Directory” earlier in this chapter.
Document the Existing Hardware Configuration
Review and document the existing hardware configuration of each domain controller that you plan to upgrade to Windows Server 2003. Use this information to identify the domain controllers in your environment that you can upgrade to Windows Server 2003 and the domain controllers that do not meet the hardware requirements for Windows Server 2003. Retain at least one domain controller that does not meet Windows Server 2003 hardware requirements to serve as a rollback server in the event that you must roll back your deployment.
If the PDC does not meet the hardware requirements, you can transfer the PDC role to a backup domain controller (BDC) that does meet the hardware requirements and upgrade it. If none of your Windows NT 4.0 domain controllers meet Windows Server 2003 hardware requirements, install a Windows NT 4.0 BDC on a computer that does meet the hardware requirements for a domain controller that is running Windows Server 2003 and transfer the PDC role to it.
You can also add a Windows Server 2003–based member server to a Windows NT 4.0 domain at any time before you upgrade to Windows Server 2003 Active Directory because Windows Server 2003–based member servers can operate within a Windows NT 4.0 environment. You can install Active Directory on the member server after you upgrade the PDC.
For more information about the hardware requirements of domain controllers in a Windows Server 2003 domain, see “Planning Domain Controller Capacity” in this book. To determine whether your hardware configuration is compatible with Windows Server 2003, see the Windows Server Catalog link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
For a worksheet to assist you in documenting your existing domain controller hardware configuration, see “Windows NT 4.0 Hardware Configuration” (DSSUPNT_2.doc) or
“Windows NT 4.0 Domain Controller Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Hardware Configuration”
or “Windows NT 4.0 Domain Controller Documentation” on the Web at http://www.microsft.com/reskit).
Example: Documenting the Windows NT 4.0 Hardware Configuration
Figure 8.5 shows an example of a Hardware Configuration worksheet for the Windows NT 4.0–
based domain controllers in the EAST domain for Trey Research.
Figure 8.5 Example of a Windows NT 4.0 Hardware Configuration Worksheet
Domain controllers BOS-EAST-DC02 and WDC-EAST-DC02 do not meet the minimum memory requirements for a Windows Server 2003–based domain controller. Therefore, Trey Research has determined that BOS-EAST-DC02 will be used as the Windows NT 4.0 rollback server if a problem occurs during the in-place upgrade process and WDC-EAST-DC02 will be assigned as a member server in the Windows Server 2003 forest. All other Windows NT 4.0–
based domain controllers are capable of supporting Windows Server 2003 Active Directory.
Document the Existing Network Configuration
Document the existing network configuration for your Windows NT 4.0 domain. Some network adapter drivers that are included with earlier versions of the operating system are not distributed with Windows Server 2003. If you attempt to upgrade a Windows NT 4.0–based domain controller to Windows Server 2003 and a network adapter is installed for which a driver is not provided, your network information might be lost or detected incorrectly during the upgrade.
Create a network configuration table listing the type of network adapter that each domain controller uses. Also include the TCP/IP configuration information for each domain controller, including IP address, subnet mask, and default gateway. You can run the ipconfig command at the command line to determine IP address, subnet mask, and default gateway. For more information about the ipconfig command, type ipconfig /? at the command line.
To determine whether the network card is supported by Windows Server 2003, see the Windows Server Catalog link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
For a worksheet to assist you in documenting your existing Windows NT 4.0 network configuration, see “Windows NT 4.0 Network Configuration” (DSSUPNT_3.doc) or
“Windows NT 4.0 Domain Controller Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Network Configuration”
or “Windows NT 4.0 Domain Controller Documentation” on the Web at http://www.microsoft.com/reskit).
Figure 8.6 shows an example of a network configuration worksheet for the EAST domain for Trey Research.
Note
You can install device drivers that are not included on the Windows Server 2003 operating system CD from the vendor’s Web site.
Figure 8.6 Example of a Windows NT 4.0 Network Configuration Worksheet
Document Domain Controller Role Assignments
As part of your in-place domain upgrade plan, assign the existing Windows NT 4.0–based domain controllers roles that they will assume in the Windows Server 2003 domain after the upgrade is complete. Assign one of the following three roles to Windows NT 4.0–based domain controllers in a Windows Server 2003 domain:
u Windows Server 2003–based domain controller. Assign the role of Windows Server 2003–based domain controller to any Windows NT 4.0 PDCs and other
Windows NT 4.0–based domain controllers that meet the appropriate hardware and software requirements.
u Rollback server. Assign the role of rollback server in the Windows Server 2003 domain to a Windows NT 4.0 BDC that does not meet the Windows Server 2003 domain controller hardware requirements.
u Windows Server 2003–based member server. Assign the role of member server in the Windows Server 2003 domain to a Windows NT 4.0–based BDC that does not meet the Windows Server 2003 domain controller hardware requirements.
For more information about the software and hardware requirements for Windows Server 2003–
based domain controllers, see “Determine Supported Operating System Upgrades” later in this chapter and “Document the Existing Hardware Configuration” earlier in this chapter.
Create a domain controller assignment table that outlines the roles that you plan to assign to your Windows NT 4.0–based domain controllers in the Windows Server 2003 domain. In this table, list the Windows NT 4.0–based domain controllers in your domain, indicate whether they meet the hardware requirements for Windows Server 2003, and list the role for each domain controller before and after you upgrade the domain, as shown in Figure 8.7.
For a worksheet to assist you in documenting Windows NT 4.0–based domain controller roles, see “Windows NT 4.0 Domain Controller Role Assignment” (DSSUPNT_4.doc) or
“Windows NT 4.0 Domain Controller Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Domain Controller Role Assignment” or “Windows NT 4.0 Domain Controller Documentation” on the Web at
http://www.microsoft.com/reskit).
Figure 8.7 Example of a Windows NT 4.0 Domain Controller Role Assignment Worksheet
Determine the Domain Upgrade Order
Before you begin the in-place domain upgrade process, determine the order in which you plan to upgrade your Windows NT 4.0 domains. Because account domains generally contain more objects than resource domains, upgrade your account domains before upgrading your resource domains. This allows your organization to take advantage of Windows Server 2003 security and administration features early in the upgrade process.
The order in which you upgrade account domains in your organization can affect the efficiency of your in-place domain upgrade process. Use the following guidelines to determine the order in which to upgrade multiple account domains:
u Upgrade domains that will become targets for restructuring first. After upgrading these domains, you can restructure remaining domain objects into the restructuring target. Target domains must be set at the Windows 2000 native domain functional level before
restructuring objects into them.
u Upgrade domains over which you have direct control and to which you have easy access.
This allows convenient access to these domains in the event that you must roll back your deployment if the upgrade does not go as planned.
For more information about restructuring Windows NT domains, see “Restructuring Windows NT 4.0 Domains to an Active Directory Forest” in this book.
Determine Supported Operating System Upgrades
Identify the Windows NT 4.0 platforms that are running in your environment and determine whether an operating system upgrade to Windows Server 2003 is supported, or whether you must perform a clean operating system installation.
Table 8.1 lists the Windows NT 4.0 platforms and indicates which platforms you can upgrade directly to each edition of Windows Server 2003. You do not need to reinstall applications on platforms that you can upgrade directly to Windows Server 2003.
Table 8.1 Supported Upgrade Paths to Windows Server 2003
Platform
Upgrade to Windows Server 2003, Standard Edition
Upgrade to Windows Server 2003, Enterprise Edition
Upgrade to Windows Server 2003, Datacenter Edition Windows NT 4.0 Server, Standard
Edition
Windows NT 4.0 Terminal Server Windows NT 4.0 Server, Enterprise Edition
If you have computers in your environment that are running operating systems that you cannot upgrade directly to a version of Windows Server 2003, such as Windows NT 3.51, you must do one of the following:
u If you need to retain applications that are located on those computers, upgrade the computers to run an operating system that you can upgrade to Windows Server 2003 after verifying that those applications will function on and are supported by Windows Server 2003.
u If you do not need to retain applications that are located on those computers, perform a clean installation of Windows Server 2003 on those computers.
Important
All versions of Windows NT 4.0 must have Service Pack 5 or later installed before upgrading to Windows Server 2003.
Develop a Test Plan
Develop a plan for testing your in-place domain upgrade procedures throughout the in-place domain upgrade process to ensure that they have completed successfully and to determine whether the process of upgrading Windows NT 4.0 domains to Windows Server 2003 Active Directory was successful.
Table 8.2 lists the Active Directory configurations that you must test and the tools that you can use to test each configuration. For more information about the options that are available for these tools, see “Active Directory support tools” in Help and Support Center for Windows
Server 2003. For more information about specific configuration and functionality tests that you can perform before and after the Active Directory installation, see the Active Directory link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Search under “Administration and Configuration Guides” and download the Active Directory Operations Guide.
Table 8.2 Active Directory Configuration Test Components
Configuration Tool Purpose
Dcdiag.exe Tests for successful Active Directory connectivity and functionality. Confirms that the domain controller has passed the diagnostic tests (such as connectivity and replicated objects). Each test must return a "passed" result.
Active Directory service
Netdiag.exe Diagnoses networking and connectivity problems by performing a series of tests to determine the state of your network client and whether it is functional.
Active Directory replication
Repadmin.exe /replsum Returns all replication events taking place between the forest root domain and other Active Directory domain controllers.
This must return a successful replication event with all inbound and outbound replication partners.
BDC replication status
Nltest.exe
/bdc_query:domainname
Shows connection status for all the BDCs. This must show
"status = success" for each domain controller within the domain.
After you confirm that the Active Directory configuration is correct, you need to verify that Active Directory is functioning correctly.
Table 8.3 lists the Active Directory functions that you need to test and the methods that you can use to perform the tests.
Table 8.3 Active Directory Functionality Test Components
Function Test Method
Trust relationships Verify the transitive trusts with the parent domain and the one- way trusts with Windows NT 4.0 domains.
Use the verify feature in Active Directory Domains and Trusts on the upgraded PDC to validate the trust relationships that are in place.
New user creation Create a new user on the Windows Server 2003–based domain controller.
Log on with administrator credentials and use Active Directory Users and Computers to verify that the new user was created successfully.
New user object replication
After replication to BDCs takes place, determine whether new user is replicated to BDCs.
1. Type Net User at a command prompt on a Windows NT 4.0–based domain controller, and then verify that the new user account exists.
2. Modify a property of an existing user and verify that the modified property replicates with the user.
Successful logon request
Verify that users can log on successfully.
1. Disconnect the Windows Server 2003–based domain controller to confirm that the Windows NT 4.0–based domain controller is validating the user logon request.
2. Verify that you can log on successfully by using the new user account credentials from each client machine.
3. Verify that all client operating systems in the upgraded domain and the domains that it trusts can log on successfully.
4. Repeat step number two over trust relationships where the trusting domain controller has a secure channel with the Windows NT 4.0–based and Windows Server 2003–based domain controllers in the trusted domain.
Successful resource access
Verify that the user can access important resources.
1. Access e-mail resources.
2. Access roaming profiles.
3. Access printers.
4. Resource permissions belonging to the user and a group.
Develop a Recovery Plan
Create a recovery plan for use if the in-place domain upgrade process does not go as planned.
Select a Windows NT 4.0 BDC to be used as a rollback server. Synchronize the BDC with the PDC and take the rollback server offline in the event that it must be promoted to a PDC to restore the domain to its original state. Although you are unlikely to need the offline domain controller, it is recommended that you take one offline as a precautionary step if the Security Accounts Manager (SAM) account database on all domain controllers becomes corrupt.
Include the following in your recovery plan:
u The steps needed for recovery. Be sure to provide clear instructions so that the deployment team can restore normal operations to the organization if necessary.
u The estimated time that can elapse before recovery must take place. When elements of the upgrade process test unsuccessfully, you might spend unanticipated amounts of time identifying and correcting errors. Establish clear guidelines for the time period after which the deployment team must restore operations for end users.
u Team review and sign-off. All members of the deployment team must sign off on the recovery plan. This signifies consensus about the recovery plan and reduces the chances that misunderstandings occur when the upgrade process does not go as planned.
Restoring the Domain to its Original State
If your in-place upgrade process fails, you can roll back a Windows Server 2003 Active Directory domain to its original state as a Windows NT 4.0 domain. There are two ways to roll back the deployment to its original state:
1. Remove (either by disconnecting the network cable or turning off) any Windows Server 2003–based domain controllers from the domain.
2. Promote a Windows NT 4.0 BDC to become the PDC.
3. Synchronize all Windows NT 4.0–based domain controllers.
Note
The first recovery method is preferred for restoring a domain to its original state. The second recovery method should only be used if the SAM database on all domain controllers becomes corrupt.
4. Test Windows NT 4.0 server operations and domain validation.
5. Document the reasons for the unsuccessful domain upgrade and communicate them to your design team.
6. Restart the design phase for the in-place domain upgrade. Be sure to include steps to mitigate the factors that caused the first in-place domain upgrade to fail.
– Or –
If a failure occurs after performing the steps above, remove all Windows Server 2003–based domain controllers from the network and promote the Windows NT 4.0 BDC that has been designated as the rollback server to become the PDC.
7. Perform a full synchronization of all Windows NT 4.0 BDCs.
8. Test Windows NT 4.0 server operations and domain validation.
9. Document the reasons for the unsuccessful domain upgrade and communicate them to your design team.
10. Restart the design phase for the in-place domain upgrade. Be sure to include steps to mitigate the factors that caused the first in-place domain upgrade to fail.
Important
You must take all Windows Server 2003–based domain controllers offline before you promote the rollback server to become the new PDC. If any Windows Server 2003–based domain controllers remain online in the domain, the promotion of the BDC to a PDC will not work.
Completing Pre-Upgrade Tasks
After you create your plan for upgrading your Windows NT 4.0 domains to Windows Server 2003 Active Directory, you must complete the pre-upgrade tasks shown in Figure 8.8 before beginning the in-place upgrade process for your domain.
Figure 8.8 Completing Pre-Upgrade Tasks
Complete pre- upgrade tasks
Upgrade domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Complete post- upgrade tasks
Collect design information
Relocate the LMRepl file replication service
Ensure remote access service compatibility
Enable the Windows NT 4.0 environment change freeze
Relocate the LMRepl File Replication Service
To maintain the replication of files in the NETLOGON shared folder from the Windows NT 4.0 export server to all other Windows NT 4.0 BDCs running the LMRepl replication engine during the in-place domain upgrade process, upgrade all servers that are hosting import directories before you upgrade the server that is hosting the export directory.
If the server hosting the export directory is the PDC, you can do one of the following:
u Promote a BDC that meets the Windows Server 2003 domain controller hardware requirements to become the new PDC and demote the existing PDC to serve as a BDC hosting the export server.
– Or –
Reconfigure the LMRepl export server on a BDC and remove it from the PDC.
To test the new configuration to ensure that LMRepl continues to work correctly, place an empty file on the export server and verify that the file is replicated to the import directories during replication. Next, delete the replicated file from the import directory, and then verify that the file is deleted during the next replication.
Ensure Remote Access Service Compatibility
To ensure remote access compatibility in a mixed Windows NT 4.0 and Windows Server 2003 environment, upgrade the operating system on all remote access servers in the domain to Windows Server 2003 before you begin the in-place domain upgrade process. If RAS is running on a domain controller, upgrade that domain controller early in the in-place domain upgrade process to minimize security risks.
Enable the Windows NT 4.0 Environment Change Freeze
Before you upgrade the PDC in your Windows NT 4.0 domain to Windows Server 2003 Active Directory, you must freeze the Windows NT 4.0 environment to ensure that no other domain changes occur until after the PDC is upgraded. Freeze the Windows NT 4.0 environment when:
u You have completed all of the updates to the Windows NT 4.0 domain and have replicated them to all domain controllers.
u You have synchronized a BDC and have taken it offline for recovery purposes.
When you freeze the Windows NT 4.0 environment, no additional domain changes can take place until you upgrade the Windows NT 4.0 PDC to Windows Server 2003. Communicate to all appropriate individuals that changes to the environment, such as password updates, will not be accepted after a specific date.
Upgrading Domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Before you begin the Windows NT 4.0 in-place upgrade process, determine the upgrade path that your Active Directory design specifies. The Active Directory design will specify one of two possible in-place upgrade paths:
u Upgrade to a regional domain in an existing forest.
Before upgrading a Windows NT 4.0 domain and joining an existing forest as a regional domain, you must first deploy a Windows Server 2003 forest root domain. Complete the planning and design phases of your Active Directory deployment and then complete the process for deploying the forest root domain. After the forest root domain is deployed, complete the in-place domain upgrade process by following the steps outlined in “Upgrade to a Regional Domain in an Existing Forest” later in this chapter. For more information about deploying the Windows Server 2003 forest root domain, see “Deploying the Windows Server 2003 Forest Root Domain” in this book.
To help illustrate the process for upgrading to a regional domain in an existing forest, sample data for Trey Research, is provided within the context of the tasks that must be performed.
u Upgrade to a single domain forest.
To create a new single domain forest, complete the in-place domain upgrade process by following the steps outlined in “Upgrading to a Single Domain Forest” later in this chapter.
To help illustrate the process for upgrading to a single domain forest, sample data for a fictitious company, Fabrikam, Inc, is provided within the context of the tasks that must be performed.
For more information about designing an Active Directory logical structure and determining what forest design model best suits your organization, see “Designing the Active Directory Logical Structure” in this book.
Note
If your organization already has a Windows 2000 or Windows Server 2003 Active Directory infrastructure in place, complete the in-place upgrade process by upgrading to a regional domain in an existing forest.
Figure 8.9 shows the two paths available for upgrading domains from Windows NT 4.0 to Windows Server 2003 Active Directory and additional tasks that all organizations must perform regardless of which option is specified by the Active Directory design. The additional tasks, including modifying security policies, synchronizing file replication services, recreating trusts, using DNS registration to decrease the workload on the PDC emulator, and upgrading additional domain controllers, are performed after the PDC is upgraded.
Figure 8.9 Upgrading Domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Complete pre- upgrade tasks
Upgrade domains from Windows NT 4.0 to Windows Server 2003 Active Directory
Complete post- upgrade tasks
Collect design information
Modify security policies
Synchronize file replication services Recreate trusts
Use DNS registration to decrease the workload on the PDC emulator Upgrade additional domain controllers Are you joining an existing forest?
Upgrade to a regional domain in an existing forest
Upgrade to a single domain forest
Yes No
After the in-place domain upgrade is complete, you can upgrade additional Windows NT 4.0 domains in-place or restructure the remaining Windows NT 4.0 domains into your Windows Server 2003 Active Directory environment. For more information about restructuring
Windows NT 4 domains, see “Restructuring Windows NT 4.0 Domains to an Active Directory Forest” in this book.
Upgrade to a Regional Domain in an Existing Forest
To complete the process for upgrading to a regional domain in an existing forest, perform the following tasks:
1. Back up all domain data.
2. Enable the Windows Server 2003 interim forest functional level in the existing forest.
3. Delegate the DNS zone in the forest root domain.
4. Configure protection against domain controller overload.
5. Upgrade the operating system of the Windows NT 4.0 PDC.
6. Install Active Directory.
7. Perform post-upgrade tests.
Back Up the Domain Data
Back up your Windows NT 4.0 domain data before you begin the upgrade. This task varies according to the operations and procedures that already exist in your environment. At minimum, complete the following steps:
u Back up the PDC.
u Back up the BDC that you designated as the rollback server.
u Test all backup media to ensure that the data can be restored successfully.
Important
Store backup media in a secure offsite location designated by and accessible to the deployment team before you begin the upgrade process.
Enable the Windows Server 2003 Interim Forest Functional Level
If all domain controllers in the existing forest are running Windows Server 2003, the functional level of the forest is set at Windows 2000, and the functional level of the forest root domain is set at Windows 2000 mixed, you can raise the forest functional level to Windows Server 2003 interim. Raising the forest functional level to Windows Server 2003 interim is recommended in order to take advantage of the Windows Server 2003 Active Directory features available at that level. However, if you are considering adding Windows 2000–based domain controllers to your environment at any time, you can maintain the Windows 2000 forest functional level and still upgrade your Windows NT 4.0 domains.
Raise the forest functional level in the existing forest to Windows Server 2003 interim before upgrading the PDC and joining the existing forest during the Active Directory installation. By raising the forest functional level in the existing forest before you upgrade the PDC, any additional domains that you upgrade as regional domains will automatically join the Windows Server 2003 forest at the Windows Server 2003 interim domain functional level.
You cannot use Active Directory administrative consoles to raise the forest functional level to Windows Server 2003 interim. Instead, use a Lightweight Directory Access Protocol (LDAP) application such as ADSI Edit or LDP in Windows Support Tools to edit the value of the msDS- Behavior-Version attribute. You must be a member of the Enterprise Admins group to raise the forest functional level, and you must do this on the domain controller that holds the schema master role.
To raise the forest functional level to Windows Server 2003 interim by using ADSI Edit 1. In ADSI Edit, expand the Configuration partition, expand
CN=Configuration,DC=forestname,DC=domainname,DC=com 2. Right-click CN=Partitions, and then click Properties.
3. Select the msDS-Behavior-Version attribute, and then click Edit.
4. In the Value field, type 1 to raise the forest functional level to Windows Server 2003 interim, and then click OK.
For more information about raising functional levels, see “Enabling Advanced Windows Server 2003 Active Directory Features” in this book.
Important
If you raise the forest and domain functional level to Windows Server 2003 interim, you cannot return to the Windows 2000 mixed domain functional level or to the Windows 2000 forest functional level. After you raise the functional level to Windows Server 2003 interim, the environment only supports Windows NT 4.0– and Windows Server 2003–based domain controllers. You can no longer add Windows 2000–based domain controllers into this environment.
Delegate the DNS Zone for the New Regional Domain
The Active Directory DNS owner in your organization is responsible for delegating the zone that matches the name of the regional domain to the DNS servers that are running on the domain controllers in the regional domain.
Before you create the new regional domain, delegate the DNS zone for the new Windows Server 2003 regional domain on any domain controller in the forest root domain DNS zone.
To delegate the DNS zone for the new regional domain
1. Open the DNS snap-in from any domain controller in the forest root domain.
2. In the console tree, right-click the forest root domain zone, and then click New Delegation.
3. Table 8.4 lists information to complete the New Delegation Wizard, as well as sample data for delegating the DNS domain for the first two regional domain controllers in the
east.trccorp.treyresearch.net domain, SEA-EAST-DC01 and SEA-EAST-DC02. Accept the default settings when no information is supplied.
Table 8.4 Delegating the DNS Domain for the New Regional Domain
Wizard Page Action Example
Delegated Domain Name
In the Delegated Domain box, type the name of the regional domain.
East
Name Servers 1. Click Add. In the New Resource Record dialog box, in the Server name box, type the name of the first domain controller you plan to deploy.
2. In the New Resource Record dialog box, in the IP address box, type the corresponding IP address of the domain controller, click Add, and then click OK.
3. Click Add, and in the New Resource Record dialog box, in the Server name box, type the name of another domain controller you plan to deploy in the regional domain.
4. In the New Resource Record dialog box, in the IP address box, type the corresponding IP address of the other domain controller, click Add, and then click OK.
SEA-EAST-
DC01.trccorp.treyres earch.net
172.16.16.10
SEA-EAST-
DC02.trccorp.treyres earch.net
172.16.16.11
Configure Protection Against Domain Controller Overload
Before installing Windows Server 2003 on the Windows NT 4.0 PDC, shield the domain controller by configuring it to emulate a Windows NT 4.0–based domain controller. By shielding the domain controller, clients running Windows 2000, Windows XP, and Windows Server 2003 will not recognize it as an Active Directory domain controller. Clients will authenticate with the new Windows Server 2003–based domain controller as if it were a Windows NT 4.0–based domain controller. This step protects the domain controller from being overloaded with authentication requests from Active Directory clients.
Maintain the emulation setting until enough Windows Server 2003–based domain controllers are in each site to service all Active Directory clients.
If no Windows 2000, Windows XP, or Windows Server 2003 clients are running in a particular site, or if a Windows Server 2003–based domain controller has the capacity to support the number of clients that are present in the site, you do not need this configuration.
To configure emulation on a Windows NT 4.0–based domain controller before upgrade 1. In the Run dialog box, type regedit, and then press ENTER.
2. In the registry editor, navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD Value.
4. For the new entry name, type NT4Emulator, and then press ENTER.
5. Double-click the entry name that you typed in the previous step.
6. In the Edit DWORD Value dialog box, type 1 in the Value data: box, and then click OK.
7. Click Registry, and then click Exit to close the registry editor.
Repeat this procedure as needed on each Windows NT 4.0–based domain controller that you plan to upgrade to Windows Server 2003.
Note
After removing the NT4Emulator registry entry, Windows 2000, Windows XP, and Windows Server 2003 clients will not immediately begin to use the Kerberos authentication protocol. This will be delayed until each client resets its secure channel or is restarted.
Caution
The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Deployment Kit companion CD or on the Web at http://www.microsoft.com/reskit.
After you protect the PDC from becoming overloaded, you must be sure to neutralize the emulation on any additional domain controllers you upgrade. Additional domain controllers in the same domain must be able to contact an Active Directory domain controller in their domain for the Active Directory installation to succeed.
On Windows NT 4.0 BDCs, setting the NT4Emulator registry entry before the operating system upgrade will protect the domain controller from overload. Setting the NeutralizeNT4Emulator registry entry immediately afterward allows the BDC to contact an Active Directory domain controller that has the NT4Emulator registry entry set and successfully install Active Directory.
For more information about neutralizing Windows NT 4.0 emulation, see “Neutralize Windows NT 4.0 Domain Controller Emulation” later in this chapter.
After you upgrade all domain controllers, or you have enough Windows Server 2003–based domain controllers to authenticate the clients in your domain that are running Windows 2000, Windows XP, and Windows Server 2003, you can reverse this configuration by editing the registry again and removing the NT4Emulator registry entry.
Upgrade the Operating System of the Windows NT 4.0 PDC
Before upgrading the operating system to Windows Server 2003, use the Winnt32.exe command- line tool to detect any upgrade problems you might have to resolve. This tool reports potential upgrade problems, such as inadequate hardware resources or compatibility problems.
To determine potential upgrade problems
u At the command line, connect to the I386 directory located at your installation source and type the following command:
winnt32 /checkupgradeonly
Resolve any reported problems before performing the upgrade.
To install the operating system on the computer, insert the Windows Server 2003 operating system CD in the CD-ROM drive of the domain controller and select the option to install the operating system, or use an automated installation method. If the Windows Server 2003 media is shared on the network, run the Winnt32.exe command from the installation source.
Complete the operating system installation by doing the following:
u Select Upgrade for the Installation type.
u Use the NTFS file system to convert the partitions. The installation of Active Directory will not succeed if you do not have at least one NTFS partition available on which to locate the SYSVOL shared folder.
u Verify that you are using a static IP address.
u Configure DNS client settings by using the IP address of the closest DNS server for the Preferred DNS server setting and either leave the Alternate DNS server setting blank or use the IP address of the closest DNS server. These DNS client settings are temporary and will be changed during the installation of Active Directory.
u Install Windows Support Tools, which are available in the \Support\Tools folder on the Windows Server 2003 operating system CD.
During the operating system upgrade the computer will restart three times. After you upgrade the operating system on a Windows NT 4.0 domain controller to Windows Server 2003, the
computer is in an intermediate state, meaning that the computer is no longer a Windows NT 4.0–
based domain controller, and it is not a Windows Server 2003–based member server or domain controller until Active Directory is installed. After the computer restarts for the last time, the Welcome to the Active Directory Installation Wizard appears.
Install Active Directory
The Active Directory Installation Wizard creates the Active Directory database and moves objects from the Windows NT 4.0 Security Accounts Manager (SAM) to the Active Directory database.
In addition, on the first domain controller in a new regional domain in an existing forest, the wizard does the following:
u Prompts the administrator to verify the installation and configuration of the DNS Server service.
u Configures DNS recursive name resolution forwarding by adding the IP addresses of the existing entries for Preferred DNS server and Alternate DNS server to the list of DNS servers on the Forwarders tab of the Properties sheet for the domain controller.
u Configures DNS recursive name resolution by root hints, by adding the root hints that are configured on the Preferred DNS server to the list of DNS servers on the Root Hints tab of the Properties sheet for the domain controller.
Note
When you are upgrading to a regional domain in an existing Active Directory forest, ensure that the domain naming master in the forest root domain is running Windows Server 2003 before installing Active Directory on the newly upgraded PDC. This ensures that application directory partitions are created on the first domain controller in the new regional domain.
u Configures the Preferred DNS server to point to the DNS server that is running locally on the domain controller, and configures the Alternate DNS server to point to the closest DNS server.
u Creates the DomainDnsZones application directory partition that is used by DNS to hold domain-wide DNS data.
Table 8.5 lists information to install Active Directory on an upgraded Windows NT 4.0 PDC and sample data for installing Active Directory on the first domain controller in a new regional domain in the trccorp.treyresearch.net forest, SEA-EAST-DC01.
Table 8.5 Information to Install Active Directory on a Windows NT 4.0 PDC Wizard Page or
Dialog Box Action Example
Create New Domain
Select Child Domain in an existing domain tree
Network Credentials
Type the user name and password of an account with sufficient privileges to install Active Directory on this computer, and the fully qualified domain name of the parent domain.
Child Domain Installation
Enter the full DNS name of the parent domain and the single label name of the new regional domain.
trccorp.treyresearch.net east
Database and Log Folders
Type the folder locations specified by your design The design for Trey Research specifies that the database folder remain in the default location: C:\Winnt\Ntds, and that the log folder is placed on a separate partition: D:\Logs Shared System
Volume
Confirm or type the location specified by your design C:\Winnt\Sysvol
DNS Registration Diagnostics
DNS Registration Diagnostics will indicate that it cannot find the name and address of the DNS server with which this domain controller will be registered.
This is because the pre-created delegation record points to the local computer and DNS has not been installed on the domain controller at this point.
Select the option to Install and configure the DNS server on this computer and set this computer to use this DNS server as its preferred DNS server.
(continued)
Table 8.5 Information to Install Active Directory on a Windows NT 4.0 PDC (continued) Wizard Page or
Dialog Box Action Example
Permissions Select the security level specified by your design:
Permissions compatible with pre- Windows 2000 server operating systems
Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems
Because Trey Research currently has services running on Windows NT 4.0–
based servers under the context of the Local System account, they selected Permissions compatible with pre-Windows 2000 server operating systems.
Directory Service Restore Mode Administration Password
In the Password and Confirm password boxes, type any strong password
Verify that all information on the Summary page is accurate, and then click Finish. After the Active Directory Installation Wizard finishes, you will be prompted to restart the computer. The installation will not be complete until the computer restarts.
For more information about installing and removing Active Directory, see the Directory Services Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Directory Services Guide on the Web at http://www.microsoft.com/reskit).
After you install Windows Server 2003 Active Directory, enable Remote Desktop for
Administration, formerly known as Terminal Services in Remote Administration mode, to enable administrators to log on remotely if necessary. To enable Remote Desktop for Administration, in Control Panel, double-click System, select the Remote tab, and then select Allow users to connect remotely to this computer.
Verify DNS Server Recursive Name Resolution
DNS server recursive name resolution is configured automatically during the Active Directory installation process. If your design specifies a different configuration, you can use the DNS snap- in or Dnscmd.exe to modify these settings. Use the DNS snap-in to verify DNS server recursive name resolution based on the information in Table 8.6.
Table 8.6 Information to Verify DNS Server Recursive Name Resolution
Method Configuration
Recursive name resolution by root hints
No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is correctly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in:
1. In the console tree, right-click the domain controller name, and then click Properties.
2. In the Properties sheet for the domain controller, view the root hints on the Root Hints tab.
Root hints are the recommended method to use for recursive name resolution in a Windows Server 2003 environment.
Recursive name resolution by forwarding
Forward unresolved queries to specified DNS servers. To verify forwarding by using the DNS snap-in:
1. In the console tree, right-click the domain controller name, and then click Properties.
2. On the Forwarders tab, in the selected domain’s Forwarders list, verify that the IP addresses match those specified by your design.
Forwarders should be used only if that is what your organization’s design specifies.
Root hints are the recommended method to use for recursive name resolution in a Windows Server 2003 environment.
No existing DNS infrastructure
No additional configuration is necessary.
In this environment, if you want to configure internal DNS servers to resolve queries for external names, configure this DNS server to forward unresolved queries to an external server, such as one in your perimeter network, or one hosted by an Internet service provider.
