• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    In-Place Upgrade of an NT4 Domain

    At this point, you should have a clear roadmap of your deployment plans. You should know which classic domain controllers you are going to upgrade and in what order. All the prerequisites should be complete. You have brewed a big pot of coffee, and you're ready to begin.

    Figure 9.7 shows a classic NT multiple-master domain with a single resource domain. In a production network, there could be many resource domains with interlocking trusts to several account domains. The configuration in the diagram shows a user in the second account domain who accesses a shared resource on a server in the resource domain.

    Figure 9.7. Classic NT multiple master domain.


    The server cannot validate the user directly because there is no trust between the resource domain and the user's account domain. Classic NT domains are not transitive. The user must either log on using credentials from the first account domain or present an alternate set of credentials when mapping to the resource.

    The following examples describe how to upgrade this multiple master NT configuration to a single Windows Server 2003 forest. The administrators in this example have decided to retain the same domain structure in Active Directory as they now use in NT. The "Migrating from NT and Windows 2000 Domains to Windows Server 2003" section discusses how to collapse the classic domains into a single domain.

    Here is the order of events:

    1. Install a placeholder domain to act as the root domain of the forest.

    2. Upgrade the PDC of the first account domain.

    3. Upgrade the BDCs in the first account domain.

    4. Shift the functional level of the first account domain to Windows Server 2003.

    5. Upgrade the PDC and BDCs of the resource domains under the first account domain or migrate all the users and computers to the newly created Windows Server 2003 domain.

    6. Shift the functional level of any upgraded resource domains to Windows Server 2003.

    7. Upgrade the PDC and BDCs of the second and subsequent account domains and shift the functional level to Windows Server 2003.

    8. Shift the forest functional level to Windows Server 2003.

    Install a Placeholder Domain

    If you have several NT account domains that you plan on preserving after the upgrade to Windows Server 2003 and Active Directory, you should strongly consider installing a placeholder domain to act as the root domain of the forest. This is sometimes called an empty root because it has no production user accounts. Figure 9.8 shows an example.

    Figure 9.8. NT domain upgrade beginning with new Windows Server 2003 domain acting as placeholder above existing NT account domains.


    The empty root clearly defines who manages the forest you're building. Both the Configuration naming context and the Schema naming context are considered a part of the root domain even though all domain controllers have a replica of them.

    Domain Controller Promotion and the Local SAM

    When promoting Windows Server 2003 to a domain controller, the SAM hive in the Registry is deleted and replaced with a standard hive containing the Administrator account, a disabled Guest account, and the standard Builtin groups for a server, except that the Power Users group is included rather than the Server Operators group.

    If you have been using a server for file-and-print duties and it has local groups or user accounts, be sure to replace the access control list (ACL) entries for these accounts on the data files and printers prior to promoting the server to a domain controller.

    Domain administrators in the empty root have control over these forest-wide naming contexts, whereas domain administrators in the child domains are free to manage their own naming contexts but have no forest-wide authority. Without a placeholder root, the first account domain to be upgraded would become the root domain of the forest, and the administrators in that domain would have extensive authority.

    Because the placeholder domain has no preexisting NT4 or Windows 2000 domain controllers, it is simple to install. Obtain at least two servers that meet your specification for domain controllers and install Windows Server 2003 on them. These servers can also act as DNS servers with Active Directory integrated zones and DNS Application naming contexts. Later on, you can place these DNS naming contexts on selected domain controllers in other domains to create a separate DNS replication topology.

    Using a placeholder domain also simplifies initial installation. Creating the first domain controller in the placeholder domain, and the forest, requires simply running Dcpromo on Windows Server 2003. The domain functional level can be shifted to Windows Server 2003 as soon as the new domain controller is operational.

    Use the steps in Procedure 9.1 to promote a server running Windows Server 2003 to a domain controller and initialize the first domain in a forest. Make sure the server is configured to point at the DNS server you have designated to host the Active Directory zone.

    Procedure 9.1 Promoting the First Windows Server 2003 Domain Controller

    1. Launch Dcpromo from the Run window. The Active Directory Installation Wizard starts.

    2. Click Next. The Domain Controller Type window opens. Select Domain Controller For A New Domain. Keep in mind that this action will delete the existing SAM and Security hives in the Registry (see Figure 9.9).

      Figure 9.9. DcpromoDomain Controller Type window.


    3. Click Next. The Create New Domain window opens. Select Domain In A New Forest. This designates the new placeholder domain as the root domain in the forest.

    4. Click Next. The New Domain Name window opens. Enter the fully qualified DNS name you've selected for the placeholder domain (see Figure 9.10).

      Figure 9.10. DcpromoNew Domain Name window.


    5. Click Next. The wizard queries WINS and broadcasts to verify that no other domain or NetBIOS entity has registered the flat name that corresponds to the DNS name you entered.

    6. If no name collision occurs, the NetBIOS Domain Name window opens and displays the flat name for the new domain.

    7. Click Next. The Database and Log Folders window opens. Enter the path to the volume you've prepared to hold the Active Directory files (see Figure 9.11).

      Figure 9.11. DcpromoDatabase and Log Folders window.


    8. Click Next. The Shared System Volume window opens. Enter the path to the volume you've prepared to hold the Sysvol folder. This can be the same volume that holds the Active Directory database files.

    9. Click Next. The DNS Registration Diagnostics window opens (see Figure 9.12). The DNS analysis tool reports the results of a diagnostic check. If the DNS server is available and the zone is present and configured for dynamic update, the analysis tool reports a success. Otherwise, the error is reported and followup actions are suggested.

      Figure 9.12. DNS Registration Diagnostics window.


    10. Click Next. The Permissions window opens (see Figure 9.13). If you no longer have NT4 RAS servers on the network, select Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating System.

      Figure 9.13. DcpromoPermissions window.


    11. Click Next. The Directory Services Restore Mode Administrator Password window opens. Enter the password to be assigned to the Administrator account in the new SAM that will be installed on the server. This account provides access when Active Directory is not available.

    12. Click Next. A summary window opens.

    13. Click Next. The wizard begins installing the directory service. This takes between three and five minutes depending on the speed of your server. When installing new domain controllers in an existing domain, allow sufficient time for the Active Directory contents to replicate to the new domain controller.

    When the promotion has completed, the machine restarts. When you log on following the restart, use the Administrator account you defined during the promotion.

    Before proceeding, make sure that the SRV records for the domain were registered correctly in the DNS zone. This registration is performed by Netlogon. It takes a few minutes to complete, so check back with the DNS server five minutes after you are able to log on at the console of the server. If the SRV records fail to appear, resolve the problem immediately. If the problem were an incorrect DNS configuration at the domain controller, you can register the DNS records manually by starting and stopping Netlogon.

    Troubleshoot Promotion Problems

    The most common cause of promotion problems is improper DNS configuration. If you get an inexplicable failure during promotion, check your DNS setup carefully. There are many subtle ways that DNS can derail a promotion. Other potential sources of problems are the following:

    • Corrupt SAM or Security hives

    • Registry corruption or improper Registry settings involving critical services

    • Running out of memory or drive space during the promotion (could be due to massive fragmentation rather than actual drive space limitations)

    • Network connection problems

    • Driver or file corruption

    During Dcpromo, the Configuring Active Directory window gives a running report of the actions taken by the promotion wizard. The wizard writes a full report to Dcpromoui.log located in \Windows\Debug. Another log file, Dcpromo.log, describes the gory details of each API call and error reports, if any.

    Table 9.1 shows a typical sequence of events during a domain controller promotion as logged by the AD Installation Wizard in Dcpromo.log. Check this list if you have a failure and you want to see what a successful promotion looks like.

    Add More Domain Controllers

    You do not want to operate for an extended period with Active Directory files hosted on a single domain controller. This tempts Murphy. Promote a second domain controller as soon as the first one is operating satisfactorily.

    The only difference between promoting a second domain controller and promoting the first one is the selection of a domain type at the start of Dcpromo. The Select Additional Domain Controller For An Existing Domain option tells the wizard to replicate the contents of Active Directory from the existing domain controller.

    If you want to avoid the tedious replication of a large Active Directory database across a slow WAN link, you can opt to populate the database on the new domain controller from a restored copy of the database from another domain controller.

    To use this option, first run a system state backup at an existing domain controller then restore the backup tape or file to a temporary folder at the server you are going to promote. Be sure to give the temporary folder lots of elbow room. It needs to hold at least 300MB at a minimum, not including the size of the Ntds.dit file, because Ntbackup will only let you restore the entire system state, not just the Active Directory files inside the system state.

    Table 9.1. Dcpromo.log Entries for a Successful Domain Controller Promotion



    Path validation

    Paths to Active Directory database, logs, and Sysvol checked and created, if necessary.

    Domain creation

    Verifies that domain flat name is unique.

    Promotion begins

    Netlogon is stopped and target folders created. Sysvol configured for replication.

    Active Directory Installation

    Credentials verified to have sufficient privileges for domain creation. Active Directory files created. Schema naming context created and populated. Configuration naming context created and populated. Domain naming context created and populated.

    Account creation

    User, group, and computer accounts moved from SAM to Active Directory. Original domain SID assigned to new domain.

    Security settings

    LSA policies copied and prepared. Windows Time Service initialized. Netlogon configured. LSA policies initialized.

    Registry security

    Domain controller (DC) promotion security template applied to Registry.

    File security

    DC promotion security template applied to system files and folders.


    Upgrade temp files and old Netlogon information removed.


    Wizard is informed of the successful completion of the promotion.

    To get the option for using a local copy of the AD files, launch Dcpromo with the /adv switch: dcpromo /adv. In this advanced mode, when you elect to create an additional domain controller for an existing domain, the wizard presents an additional window called Copying Domain Information that permits you to point at a backup file. Figure 9.14 shows an example. Point the wizard at the temporary folder where you restored the system state files.

    Figure 9.14. Active Directory Installation WizardAdvanced OptionsCopying Domain Information window showing the option for using a backup file to populate the Active Directory database.


    If the AD source files came from a Global Catalog server, Dcpromo queries if you want the new domain controller to be a GC, as well. You can say No and the wizard will only import the naming context for the source domain plus the Configuration and Schema naming contexts.

    When the promotion is complete, verify that the Knowledge Consistency Checker (KCC) establishes connections to other domain controllers in the site. Use AD Sites and Services to view the Connection objects and verify replication. See Chapter 7, "Managing Active Directory Replication," for details.

    If you want, you can create an external trust to one or all of the NT account domains. This is not required for the forest deployment, but it can be reassuring to know that administrators in the account domains can view resources in the root domain. Any External trusts you create between the root domain and the NT domains will be converted to Domain trusts when the account domain is upgraded.

    Set Domain Controller Roles

    The first domain controller in a domain is a Global Catalog server, by default. When configuring an empty root domain, configure the second server to be a Global Catalog server, as well. This ensures fault tolerance. If you choose to leave one of the servers as a standard domain controller, it is very important to transfer the Infrastructure Master role to that server.

    Use the AD Sites and Services console to configure a domain controller as a GC. Open the Properties window for the NTDS Settings object under the server. Check the Global Catalog option. Figure 9.15 shows an example.

    Figure 9.15. NTDS Settings object for a newly promoted domain controller showing the Global Catalog setting.


    Give the server a while to replicate the contents of the Global Catalog from another GC server or to collect the partial naming context replicas from domain controllers in the various domains in the forest. You can follow the result of this replication in the Event log.

    You can verify the identity of the Global Catalog servers in a forest using Replmon. Right-click a server and select SHOW GLOBAL CATALOG SERVERS IN ENTERPRISE from the flyout menu. You can also configure the ADSI Editor (Adsiedit.msc) from the Support Tools to query just port 3268, the port used for handling LDAP queries sent to a GC. If the server responds to queries on this port, you know it is a GC server.

    You can leave the remaining FSMOs with the first domain controller unless you have some other reason to transfer them. For example, the second server might have a faster processor or dual processors, making it a better choice for PDC Emulator. You should transfer the RID Master along with the PDC Emulator. This is not strictly required, especially when operating at a Windows Server 2003 functional level, but it makes recovery a little less complicated when you do not split the PDC Emulator and RID Master roles between servers.

    If the server is the first server in a site, it will become the Inter-site Topology Generator (ISTG) and the bridgehead server to the connected sites. Use AD Sites and Services to ensure that the domain controller establishes connection to its fellow bridgeheads and that it replicates according to the schedule and frequency you have assigned to the site links.

    Shift Root Domain Functional Level to Windows Server 2003

    By default, the functional level of a new Windows Server 2003 domain is set to Windows 2000 Mixed. There is no need to retain a low functional level in the placeholder domain, so before proceeding to the upgrade of the NT domains, shift the root domain functional level to Windows Server 2003.

    Use the AD Users and Computers console to shift domain functional levels. Right-click the top of the tree and select RAISE DOMAIN FUNCTIONAL LEVEL from the flyout menu. This opens a window that permits you to select either Windows 2000 Native or Windows Server 2003 functional level. Figure 9.16 shows an example.

    Figure 9.16. Using the Raise Domain Functional Level window to set a domain to Windows Server 2003 functional level.


    After shifting the Domain functional level to Windows Server 2003, you must restart the domain controllers to gain full access to the new Windows Server 2003 features.

    Active Directory Integrated DNS Zones

    You can choose to move forward with the account domain upgrades, but you may want to pause for a while and reconfigure your DNS infrastructure. When you promoted the domain controllers in the root domain, they registered their SRV records with a preexisting DNS server. If you prefer to use Active Directory integrated zones, you can install DNS onto the new domain controllers and configure them to be the primary DNS servers for the Active Directory zone.

    Be careful to configure the TCP/IP settings for one DC to point at the other DC as its primary DNS server. This avoids problems where a failure of replication causes a failure to update DNS records when then solidifies the inability to replicate. See Chapter 5, "Managing DNS," for details on installing DNS and changing zone types.

    In Windows 2000 Mixed or Native functional level, the resource records for an Active Directory integrated DNS zone are stored in the Domain naming context. This is satisfactory if you have a single domain in your forest, but it can cause problems when you have multiple domains with domain controllers that reside in geographically remote locations. Clients need access to SRV records representing servers throughout the forest.

    In Windows 2000, you could provide local access to forest-wide SRV records by creating a separate primary zone for the forest-related SRV records in _msdcs and placing secondary copies of this zone on DNS servers in the various domains.

    Windows Server 2003 handles the problem more elegantly. When you shift a domain functional level to Windows Server 2003, you can put the DNS resource records in their own naming contexts rather than into the Domain naming context. Windows Server 2003 creates two naming contexts for this purpose, one for domain-related SRV records and one for forest-related records. You can see these new naming contexts using the Replication Monitor utility from the Support Tools. Figure 9.17 shows an example. You can view the contents of the naming contexts using the LDAP Browser, Ldp, which also comes in the Support Tools.

    Figure 9.17. Replication Monitor showing the new DNS naming contexts created when a domain is shifted to Windows Server 2003 functional level.


    Upgrade the PDC in the First Account Domain

    After the placeholder domain is in place, you're ready to upgrade the first account domain. Figure 9.18 shows the result of this stage. The first step is to upgrade the PDC. A domain controller upgrade has two stages. First, the operating system is upgraded, followed by an automatic launch of Dcpromo to create the Active Directory domain. During the promotion, you will join the domain to the forest root in the placeholder domain.

    Figure 9.18. NT domain following upgrade of first account domain PDC.


    If you do not use a master license or volume license copy of Windows Server 2003, you must activate the server following installation. You have thirty days to do the activation, but the system will kvetch at you regularly until you comply, so you might as well get it out of the way as soon as you upgrade.

    When the prerequisites have been met and your disaster recovery actions have been taken, follow Procedure 9.2.

    Procedure 9.2 Upgrading an Account Domain PDC

    1. Insert the Windows Server 2003 CD or initiate Winnt32 from a network drive. This launches the upgrade wizard.

    2. When prompted, accept the End User Licensing Agreement (EULA) and enter the 25-character Product Key. The remaining portions of the operating system upgrade proceed without further user input.

    3. Following the final restart after the network operating system upgrade, the Active Directory Installation Wizard, Dcpromo, launches automatically. At this point, the classic SAM and Security hives are still intact but the server does respond to logon requests. Users can still log on to the domain via the BDCs.

    4. Before commencing Dcpromo, open a command prompt and verify using Nslookup that the server can see its DNS server and that the DNS server hosts the zone that will form the Active Directory domain.

    5. In the Dcpromo wizard, click Next. The Create New Domain window opens. Select Child Domain In An Existing Tree. This prepares the domain to join the forest rooted at the placeholder domain.

    6. Click Next. The Network Credentials window opens. Enter the name and password of an account with administrator privileges in the root domain along with the fully qualified DNS name of the root domain.

    7. Click Next. The Child Domain Installation window opens. Under Parent Domain, enter the fully qualified DNS name of the parent. In this example, the parent is the root domain of the forest. Under Child Domain, enter the flat name of the NT domain you are upgrading.

    8. Click Next. The Database and Log Folders window opens. Enter the path to the Active Directory files and the log files. This should be a separate spindle than the operating system.

    9. Click Next. The Shared System Volume window opens. Enter the path for the Sysvol folder. This can be on the same spindle as the Active Directory files if the server will not be heavily loaded during morning logons. The volume must be formatted as NTFS.

    10. Click Next. The DNS Registration Diagnostics window opens. This presents a report of the DNS connectivity for the server. If it was able to find a DNS server that hosts the specified zone and the zone can be dynamically updated, the wizard reports a success. Otherwise, it points you in the direction of the problem and gives you a chance to fix it before proceeding.

    11. Click Next. The Permissions window opens. If you have no legacy NT4 RAS servers in production, select Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating Systems.

    12. Click Next. The Directory Services Restore Mode Administrator Password window opens. Enter the password that you will use to access the server when Active Directory is not available. This password is assigned to the Administrator account in a new SAM installed at the completion of the promotion.

    13. Click Next. A summary window opens.

    14. Click Finish. The wizard begins the promotion.

    Following the promotion, the server restarts to finalize the settings. The next section contains a set of verification checks you should perform to make sure everything went well.

    Post-Upgrade Verifications

    Following the upgrade and promotion of the PDC, perform a quick set of checks to make sure critical services installed during the upgrade work as expected. This includes the following:

    • Account Replication to BDCs. Make sure that the upgraded PDC, which is now a Windows Server 2003 PDC Emulator, is able to replicate to its downlevel BDCs. You cannot verify this directly by running User Manager from the BDCs because User Manager always points at the PDC. Verify replication by running Server Manager at the BDC, highlighting the BDC name on the list, and selecting COMPUTER | SYNCHRONIZE WITH PRIMARY DOMAIN CONTROLLER from the menu. This starts a replication cycle. Check the Event log to verify that the replication occurred.

    • DNS record verification. Make absolutely sure that the SRV records for the new domain are registered in DNS. This registration is performed by Netlogon. It takes a few minutes to complete, so check back with the DNS server five minutes after you are able to log on at the console of the server. If the SRV records fail to appear, resolve the problem immediately. You can stop and start Netlogon to reregister the SRV records. By default, the server will refresh its registration once per hour.

    • User authentication. Log on at a variety of client desktops to ensure that you can get authenticated. Some forms of SAM corruption cause a situation where Windows 98 users can logon but NT users cannot. This is due to a failure to import the NT password hash during the Active Directory promotion.

    • Group policies. Log on from XP and Windows 2000 desktops to verify that you get Kerberos authentication and that you get group policies from the newly upgraded PDC. This can be verified quickly using the Kerbtray utility from the Resource Kit.

    • Profile settings. Verify that users get their roaming profiles and home directories as specified in their user accounts.

    • Dial-in verification. Test at least one dial-in user to verify that the account works to permit dial-in and that the RAS server is able to check the user's credentials.

    • Computer authentication. Restart at least one of each type of NT-based client to ensure that computer accounts were copied successfully to Active Directory. If you have thousands of computers, you may want to check that the total number of computers present after the upgrade matches the total before the upgrade.

    • Trust authentication. Log on at a desktop in a resource domain using an account in the newly upgraded domain to ensure that the trust is still in place. If you have a two-way trust between account domains, do this for accounts in both domains. Also, use the AD Domains and Trusts console to check the presence of each trust.

    • Logon script and system policy verification. Check to make sure that the existing logon scripts and system policies were migrated to the \WINNT\Sysvol\Domain\Scripts folder. (The system folder is not renamed during an upgrade.) Put the alternate copy method in place to refresh the Netlogon share at the BDCs, and then log on at various clients to ensure that they get the logon scripts.

    • Share point verification. Verify that any pre-existing shares are still in place. This includes the administrative (dollar-sign) shares. The simplest way to do this is using the NET SHARE command.

    • Application verification. If the server was running special applications prior to the upgrade, make sure those applications are still functioning. This includes items such as backup agents (or the backup application itself), antivirus agents, web sites, and Simple Network Management Protocol (SNMP) agents.

    Upgrade Account Domain BDCs

    You can operate for a while in Windows 2000 Mixed, but to get the benefit of the new Active Directory features in Windows Server 2003, you need to shift the domain functional level to Windows Server 2003. This means getting the classic BDCs off the wire, either by upgrading them or decommissioning them. Figure 9.19 shows the configuration following this stage.

    Figure 9.19. Mixed NT and Windows Server 2003 domains following upgrade of remaining BDCs in first account domain.


    If the servers acting as BDCs have suitable hardware for Windows Server 2003 and are relatively free of legacy applications, you can upgrade them to Windows Server 2003 domain controllers in the same way that you did the PDC upgrade. The only real difference is the source of the files for creating the local replica of Active Directory. The BDCs do not convert their local SAM and Security hives. They copy the contents of Active Directory from an existing domain controller.

    If the BDC is in the same location as the PDC, the upgrade and promotion should not take long. The Active Directory database is not large or complex at this stage of the deployment because of the backwards compatibility with existing BDCs. If you have several thousand users, you can use backup files as described in the placeholder domain upgrade.

    You can also build new Windows Server 2003 domain controllers in the same site as the newly upgraded PDC then ship them out to the remote locations. When the domain controller arrives at the remote site, have a local administrator put the server on the wire and configure the TCP/IP settings. At that point, move the server to the correct site based on its new subnet.

    Following the BDC upgrade, ensure that the newly promoted Windows Server 2003 domain controller replicates correctly with the other domain controllers. If this is the first domain controller in its site, verify that it acts as the bridgehead server and consider configuring it as a Global Catalog server. Also verify that it has connections to bridgeheads in the other sites as defined by the site link objects.

    Upgrade Resource Domains

    You've now finished the first stage of the upgrade and you need to decide what to do with the resource domains, as shown in Figure 9.20. You can upgrade them, in which case they are controlled by domain admins similar to the management processes used by classic NT, or you can migrate the computer accounts to the newly upgraded Windows Server 2003 domain and leave the resource domains behind.

    Figure 9.20. Mixed NT and Windows Server 2003 domains following upgrade of domaincontrollers in the resource domain.


    If you decide to retain separate domains, it is important to shift the functional level to Windows 2000 Native as soon as possible. This permits downlevel clients to access resources in the other domains via transitive Kerberos trusts on the intervening domains.

    Upgrade Remaining Master Account Domains

    At this point, you've completed the migration of an entire classic NT domain, including the account domain and all resource domains. Now you need to upgrade the remaining account domains and join them to the Windows Server 2003 forest.

    Follow the same procedure for upgrading the remaining account domains as you did for upgrading the first one. The DNS domain name you select for the domain must be contiguous with the root domain. Be sure to verify user access to resources and replication between domain controllers, especially if the domain controllers are in different sites. Don't make the mistake of assuming that inter-site replication will just work all by itself. Sure, often it does, but you cannot be sure until you check.

    You should also be careful to verify the transitive trust relationships that are created between the domains (see Procedure 9.3). Use the Trust Wizard in the AD Domains and Trusts console for this purpose.

    Procedure 9.3 Verifying Transitive Trust Accessibility

    1. Open the AD Domains and Trusts console at one of the domain controllers.

    2. Open the Properties window for one of the domains. Select the Trusts tab (see Figure 9.21).

      Figure 9.21. Properties window for showing Tree Root trust.


    3. Highlight the trust and click Properties.

    4. In the Properties window, click Validate. You'll be prompted for credentials in the remote domain.

    If the validation is successful, it means the secret account that the two domains share is accessible and they both know the password. If it fails, you may need to reset the trust. When these checks show that you have full functionality in the resource domain, promote the remaining domain controllers.

    Shift the Forest Functional Level to Windows Server 2003

    When all downlevel domain controllers have been purged, you're ready to shift the forest functional level to Windows Server 2003. This opens up many additional features, primarily the ability to replicate discrete group members rather than the entire membership list. It also lets the Inter-Site Topology Generators (ISTG) and KCCs in each site use a streamlined spanning tree calculation to keep track of replication topology, increasing the scalability of the forest.

    Shift the forest functional level using the AD Domains and Trusts console. Right-click the top of the tree and select RAISE FOREST FUNCTIONAL LEVEL from the flyout menu. This opens the Raise Forest Functional Level window shown in Figure 9.22.

    Figure 9.22. Raise Forest Functional Level window showing selection of Windows Server 2003.


    Click Raise to implement the change. You will not be offered the option as long as any domains in the forest operate at any functional level other than Windows Server 2003. You must restart all domain controllers in all domains in the forest to implement the change completely.

    After you shift the forest functional level to Windows Server 2003, you are officially FINISHED with the deployment! The final step is to use your favorite search engine to look for a great vacation spot.

      Previous Section Next Section