Solution Accelerator for Domain Server Consolidation and Migration: Windows NT 4.0 to Windows Server 2003

On This Page

	Introduction
	Pre-process Testing
	Process Testing
	Post-process Testing
	Test Results
	Summary

Introduction

This document describes the testing that was performed to validate the guidance for migrating and consolidating from a Windows NT® 4.0 flat domain environment to a Windows Server™ 2003 Active Directory® environment. The document consists of the following three sections:

Top of page

Pre-process Testing

Pre-process testing consisted of a suite of build verification tests (BVTs) in order to establish that the lab conformed to the specifications for testing the defined scenarios. In addition, basic functionality and configuration of networking, server, and client resources were also confirmed. Both source and target computers were closely inspected to ensure that all prerequisites to the consolidation and migration process were in place and ready.

Domain migration and consolidation processes were performed in the same lab environment using shared resources. Therefore, pre-process testing of non-service specific areas was shared between both test efforts to prevent duplication of efforts.

Network Topology Testing

Auditing of the computer resources provided by the lab for the domain migration and consolidation process was conducted prior to any service level testing. The items validated during the audit were physical computer inventory, visual computer identification, network connectivity capabilities, and proper assignment of role per computer resource.

For more details, refer to test case IDs: 161-166 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Figure 1. Woodgrove National Bank’s Windows NT 4.0 Domain Model (StartState)
See full-sized image

Network Services Testing

An extensive suite of tests confirmed network connectivity as well as the configuration of domain and network services for each client and server in the environment. To ensure the correct configuration of the test environment, every computer was tested for the following:

Client and server settings were audited against the Woodgrove Bank’s Windows NT Server 4.0 Domain Infrastructure (StartState) figure displayed in the “Test Lab Environment” chapter in this Test Guide and the Configuration Matrix worksheet included in the Test Kit. Any noted discrepancies were resolved.

Using quick command-line ping tests, basic network connectivity and appropriate IP address assignments were confirmed for each computer and supporting hardware (router). Any uncovered issues were identified and resolved.

All servers received additional auditing to confirm that the correct network services were in place and operating as expected. Servers hosting DHCP, DNS, or WINS services were inspected for service configuration and successful replication. Each server was then shut down and restarted. After start-up, the services list and logs were inspected for any errors or issues needing resolution.

For more details, refer to test case IDs: 167-169, 173, 176, 177, 181, 186-190, and 282 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Microsoft® Exchange Server 5.5

The scope of our project did not include the migration and consolidation of the domain that hosts our messaging services. However, testing was conducted in order to validate the existence, functionality, and appropriate configuration of the Exchange Server 5.5 service.

For more details, refer to test case ID: 170 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

File and Print Services Testing

File and print services testing verified the functionality of file and print services on all appropriate servers and from all clients. It also validated the security settings for each file and print system resource.

Security Tests

File and print services security testing verified folder, file, printer port, and network resource access (shares) privileges to confirm that all file and print objects had the appropriate permissions prior to beginning the domain migration and consolidation process.

To verify that the designated account groups had proper access to perform tasks appropriate to their security levels, various actions were performed while logged on with a local administrator, a domain user, and a domain administrator account. Account security tests verified the following:

For more details, refer to test case IDs: 172, 175, 204, 212, 213, and 216 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Client Testing

Client file and print tests were performed using Windows® 98, Windows NT 4.0 Workstation, Windows® 2000 Professional, and Windows® XP Professional clients, to establish that all network resources were visible to each client type in each location. Additional testing validated connectivity and accessibility to applicable file and print servers and their respective resources.

Security testing of clients verified that designated account groups properly accessed and manipulated file and print resources from each client type. Folder, file, and printer access and change actions were performed on each of the three client types while logged on with a local administrator, a domain user, and a domain administrator account.

Client messaging tests were performed on each client type to validate connectivity to their respective Exchange 5.5 Server and to ensure messaging capabilities were present.

For more details, refer to test case IDs: 178-180 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Domain Testing

Domain testing consisted of validating the domain objects present within the organization prior to any processes being performed. Four object classifications were verified: groups, users, computers, and group membership.

On each domain controller, the domain tests verified that global groups, user accounts, computer accounts, and group memberships were consistent with the functional requirements provided by our development team.

For more details, refer to test case IDs: 182-185 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Top of page

Process Testing

Process testing primarily focused on verifying that the guidance provided in the specified chapters of the Implementation Guide worked correctly, and did not cause any undocumented lapses in operational availability or breaks in security. These chapters included:

Each stage of the process was performed according to the provided guidance to ensure both accuracy and completeness. Bugs were filed against the guidance if documentation discrepancies were found or process steps were unclear.

The first phase, pre-migration tasks, prepared the environment for the migration process.

The second phase covered the upgrade of the primary account domain from the Windows NT 4.0 Server operating system to the Windows Server 2003 operating system. It also involved a proposed domain upgrade fallback scenario.

The third phase focused on migrating essential networking services (DHCP and WINS) to the newly created Windows Server 2003 environment, as DNS had already been migrated in the previous phase.

The fourth and fifth phases were responsible for the bulk of the domain migration and consolidation processes and involved primarily the migration of the domain objects from the Windows NT 4.0 flat domain space to the Windows Server 2003 Active Directory.

The final phase was to decommission the unnecessary Windows NT 4.0 account domain and re-provision the domain controllers.

Pre-Migration Tasks

Prior to upgrading or restructuring the Windows NT 4.0 domains in the lab environment, the test team performed certain tasks to ensure that the environment was ready for migration. The overall pre-migration tasks performed were to accomplish the following:

Account Domain Upgrade

When performing an in-place upgrade of a Windows NT 4.0 domain, the first server that must be upgraded is the Primary Domain Controller (PDC). Prior to upgrading the PDC to Windows Server 2003, the Bank’s migration plan required the test team to configure a new PDC with hardware capable of supporting the Windows Server 2003 operating system. The test team was also required to reconfigure the DNS infrastructure to support dynamic updates for the Active Directory installation.

Introducing New Hardware and Configuring the DNS Namespace

During the upgrade of the Windows NT 4.0 PDC to Windows Server 2003, the Active Directory Installation Wizard looks for a DNS server. Providing a Windows Server 2003 DNS server during this process is not completely necessary, however, it is a good idea as it supports all the necessary DNS services, such as SRV records and dynamic updates, which are required to run Active Directory efficiently. The test team recognized that the PDC had to be able to write to the DNS database during the upgrade so it could create the zones necessary for Active Directory.

For more details, refer to test case IDs: 225-227 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Promoting the New Primary Domain Controller

The assessment of the domain controllers within the WNB-ACCT-A domain found that the PDC hardware was not able to support the upgrade to the Windows Server 2003 operating system. The test team decided to promote the newly introduced Backup Domain Controller (BDC), with hardware that was more capable of running Windows Server 2003, to be the new PDC.

For more details, refer to test case IDs: 228-232 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Configuring for Domain Upgrade Fallback

The test team performed a full, or “system state,” backup of the PDC and the target offline BDC (fallback BDC) prior to beginning the upgrade of the PDC. For a Windows NT 4.0 domain controller a “system state” backup involves backing up the Registry, the Operating System files, the NETLOGON share, and the Security Accounts Manager (SAM) database. As part of the fallback plan, the test team chose one of the BDCs as the fallback server. This server was removed from the network after the full synchronization had taken place, and placed in a secure location.

For more details, refer to test case IDs: 233 and 241-245 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Upgrading the Primary Domain Controller

After the preparation of the DNS environment and the comprehensive testing of the fallback plan, the next step is the actual in-place upgrade on the Windows NT 4.0 PDC.

For more details, refer to test case IDs: 234-240 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Configuring Replication of Windows Server 2003 DNS Zone

To ensure that any existing Windows 2000 and upward clients located in the WNB-ACCT-A domain could resolve DNS names for the corp.woodgrovebank.com domain and domain controllers, the DNS servers had to be configured so that they all had the corp.woodgrovebank.com DNS zone. The DNS servers located on Windows NT 4.0 (NYC-WR-DHCP-01 and NYC-WR-DHCP-02) were configured as secondary DNS servers to the newly upgraded PDC, which was acting as the primary DNS server.

The test team verified that the name server records for the Windows NT 4.0 DNS servers in the corp.woodgrovebank.com DNS zone. They also verified that the name server records for the Windows NT 4.0 DNS servers were configured in DNS on the Windows Server 2003 PDC, to ensure that replication of the DNS zones worked correctly.

For more details, refer to test case IDs: 246-247 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Scheduling Lbridge Replication

During the migration period for the WNB-ACCT-A domain, there was a mix of Windows Server 2003 domain controllers and Windows NT 4.0 BDCs. As the Windows NT 4.0 LAN Manager Replication Service (LMRepl) is not supported on a Windows Server 2003 domain controller, a bridge was created between LMRepl service and Windows Server 2003 File Replication Service (FRS). The demoted PDC (NYC-WA-DC-01) was selected to be the last Windows NT 4.0 domain controller in the domain; as the PDC (and then BDC), it hosted the Windows NT 4.0 LMRepl export directory. The data copying between LMRepl and FRS was achieved by regularly scheduling the Lbridge.cmd script. The frequency of the scheduled job on the Windows Server 2003 domain controller was set at every two hours.

The test team used the Lbridge.cmd script and the xcopy.exe utility so that the files created in Windows Server 2003 in the NETLOGON share were replicated to the Windows NT 4.0 export server. For step-by-step instructions on how to create the service account for this task, refer to the “Synchronize File Replication Services” section in the Windows Server 2003 Resource Kit Deployment Guide, available at the following URL:

http://www.microsoft.com /resources/Documentation/windowsserv/2003/all/deployguide/en-us/default.asp

The procedure ensures that a scheduled task is set up to copy the files from the Windows Server 2003 domain controller’s NETLOGON share.

For more details, refer to test case ID: 248 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Extending the Active Directory Schema

As Woodgrove Bank planned to upgrade to Exchange Server 2003, the Active Directory schema was extended as soon as the first Active Directory domain controller was installed.

For more details, refer to test case ID: 249 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Upgrading the Remaining Backup Domain Controllers

The migration plan required Security ID (SID) history to be maintained during the migration of security principals from the second accounts domain. To achieve this, the domain must be switched to the Windows Server 2003 Functional Level. The transition to Windows Server 2003 Functional Level requires all domain controllers to be running Windows Server 2003. As a result, the migration plan called for a rapid deployment or upgrade of all remaining Windows NT 4.0 BDCs in the WNB-ACCT-A domain.

The test team had identified that due to hardware restrictions, some BDCs would have to be replaced, instead of being upgraded in-place. For those domain controllers, the replacement domain controller was built in a staging site and immediately shipped to the destination. The old BDC for that location was taken offline, and disposed of securely.

At this point, the offline BDC was no longer required and was disposed of securely. (The fallback BDC was the BDC that had been taken offline and stored securely. See “Configuring for Domain Upgrade Fallback” section earlier in this chapter.) As every domain controller in the WNB-ACCT-A domain was now running Windows Server 2003, the test team removed the scheduled FRS script from the domain controller, which provided the daily export of scripts to the LMRepl export server.

For more details, refer to test case IDs: 250-252 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Raising the Forest and Domain Functional Levels

As all domain controllers in the Active Directory domain and forest were now Windows Server 2003, the Functional Level was raised to Windows Server 2003. The test team used Active Directory Domains and Trusts to change the domain and the forest Functional Level to Windows Server 2003.

For more details, refer to test case ID: 253 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating Network Services

Valid IP addresses and name resolution are a core requirement of any client/server infrastructure using TCP/IP networks. While DNS is the primary method of name resolution in Windows Server 2003, Woodgrove Bank still had a number of applications that required NetBIOS name resolution through WINS. DNS had already been migrated to Windows Server 2003, while DHCP and WINS services were still hosted on Windows NT 4.0. This phase details the process the test team used to migrate DHCP and WINS services to Windows Server 2003.

Reducing the DHCP Lease Duration

To allow the Woodgrove Bank administrators to decommission the existing DHCP servers more rapidly, the lease durations of the DHCP scopes were reduced. Clients received the new DHCP lease durations at their next DHCP renewal.

For more details, refer to test case ID: 254 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Configuring the Windows Server 2003 Cluster

The Bank’s plan was to deploy DHCP and WINS in a clustered configuration to increase availability. Both the DHCP and WINS service would use Windows Clustering on a 2-node active/passive configuration. Figure 2 shows the Woodgrove Bank clustered DHCP and WINS servers. NYC-WA-MSP-01 would be the active DHCP and WINS server, and NYC-WA-MSP-02 would be the backup server.

Figure 2. Woodgrove Bank DHCP/WINS Cluster
See full-sized image

For more details, refer to test case IDs: 255-257 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Adding the New DHCP Scopes

The test team enabled DHCP conflict resolution as a means of migrating the DHCP scopes to the new Windows Server 2003 DHCP server. While the scope information from the Windows NT 4.0 DHCP servers could have been exported using the DHCPExIm tool, the manual process was deemed sufficient.

For more details, refer to test case ID: 258 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Authorizing the DHCP Scopes

DHCP servers in an Active Directory domain must be authorized to prevent rogue DHCP servers from coming online and authorizing a DHCP server.

For more details, refer to test case ID: 259 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Activating Scopes

The scopes had to be activated before they could provide DHCP addresses to clients.

For more details, refer to test case ID: 260 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Deactivating Windows NT 4.0 DHCP Scopes

Once the scopes on the DHCP cluster server had been activated, the Windows NT 4.0 DHCP scopes were deactivated.

For more details, refer to test case IDs: 261-262 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating WINS to Windows Server 2003

WINS push/pull replication was the most simple and effective way to migrate the WINS database to the new Windows Server 2003 cluster.

For more details, refer to test case ID: 263 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Restructuring Additional Account Domains

At the completion of the in-place upgrade and when the corp.woodgrovebank.com domain had been switched to Windows Server 2003 Functional Level, additional Windows NT 4.0 master user domains could be restructured into the Active Directory domain.

As security principals from the WNB-ACCT-ROW domain were referenced in multiple resource domains, it would not be possible to decommission this user domain until all resources had been migrated, and their security references translated. It was also expected that changes to non-migrated user objects would continue to be made in the WNB-ACCT-ROW domain during the migration process. To ensure that the WNB-ACCT-ROW domain and the corp.woodgrovebank.com Active Directory domain both had a consistent representation of user and group objects, Active Directory Migration Tool version 2.0 (ADMT v2) would be scheduled to update the Active Directory domain nightly with any changes.

Creating the Target OU Structure and Delegation

A temporary Organizational Unit (OU) structure was created in the corp.woodgrovebank.com domain as a repository for the migrated objects. Objects were migrated to a temporary OU so that Woodgrove User Account Managers and Desktop Configuration Administrators could easily resolve any naming conflicts that arose during migration. Once those conflicts were resolved, the objects were moved to their correct OU by the User Account Managers.

The temporary OU structure for the migrated objects was delegated to the User Account Managers and Desktop Configuration Administrators at this point in the migration process. The group <Source domain> Data Admins was granted full control over computer objects in the Migrated Objects\<Source Domain>\Computer and Migrated Objects\<Source Domain>\Server OU structure. Full control to group objects was also granted to the Migrated Objects\<Source Domain>\Groups OU. The User Account Managers were made members of the <Source domain> Data Admins group.

For more details, refer to test case IDs: 264 and 272 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Identifying Service Accounts

To assist in the computer migrations later, it was important to identify applications that used a service account on member servers and domain controllers. A service account is a user account that had been created explicitly to provide a security context for those applications and had been granted ‘log on as a service’ rights. The migration plan detailed a list of servers that had applications that were run as services and that ran in the security context of a service account.

For more details, refer to test case ID: 265 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating Global Groups

The global groups from the account domain WNB-ACCT-ROW had to be the first security principals to be migrated so that the groups retained their membership when the user accounts were migrated in the next step. The Woodgrove Bank migration plan called for the migration of all of the groups defined in the WNB-ACCT-ROW domain rather than risk losing business access to data which was to be migrated.

Performing a Pilot Group Migration

A pilot migration was performed to ensure that the selected migration options produced the required final state; these options included the naming of the groups, the target OU, conflict resolution, and sidHistory migration. The migration involved selecting fifty global groups and migrating them from the WNB-ACCT-ROW to the corp.woodgrovebank.com Active Directory. A thorough evaluation of the pilot migration was performed to ensure that the migration was successful and performed as expected. These groups would be included in the final group migration, that is, they would be re-migrated during the next group migration phase.

For more details, refer to test case ID: 266 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

ADMT v2 Command Line Group Migration

As the group migration involved such a large number of group objects, it made sense for the test team to use the ADMT v2 command line and scripting options to migrate the group accounts.

For more details, refer to test case ID: 267 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating User Accounts

After the groups were migrated from the WNB-ACCT-ROW domain, the users of the domain could be migrated, using ADMT v2. The test team migrated the user accounts immediately after the group migration had been successfully completed.

Performing a Pilot User Account Migration

A pilot migration was performed to ensure that the selected migration options produced the required final state; these options included the naming of the users, the target OU, conflict resolution, and sidHistory migration. The migration involved selecting fifty users and migrating them from the WNB-ACCT-ROW to the corp.woodgrovebank.com Active Directory. A thorough evaluation of the pilot migration was performed to ensure that the migration was successful and the results were expected. These users were excluded from the final user account migration.

For more details, refer to test case ID: 268 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

ADMT v2 Command Line User Account Migration

As the user account migration involved such a large number of user objects, it made sense for the test team to use the ADMT v2 command line and scripting options to migrate the user accounts.

For more details, refer to test case ID: 269 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Merging Accounts

User Account Managers might have needed to merge multiple accounts from the source domain to a single target user account. The merging of accounts would be required if a Woodgrove Bank employee had a separate user account in each of the WNB-ACCT-A and WNB-ACCT-ROW domains. To consolidate the user accounts into a single Active Directory user object, an additional sidHistory attribute would be added to the object.

For more details, refer to test case ID: 270 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Restructuring Resource Domains

The goal for the Woodgrove Bank resource domain restructure was to reduce the number of resource domains in the Windows Server 2003 forest. This meant that the resources in the Windows NT 4.0 resource domains were to be consolidated into Active Directory OU in the corp.woodgrovebank.com domain. Typically, the Woodgrove Bank resource domains contained workstation computer accounts, server computer accounts and a limited number of service accounts. In the Woodgrove Bank scenario, the WNB-RES-A and WNB-RES-SYD domains were consolidated into the corp.woodgrovebank.com domain. The Exchange 5.5 domain, WNB-MESSAGING was retained and plans called for it to be consolidated into the Active Directory forest during a future Exchange Server 2003 deployment project.

Establishing Trust Relationships

In order to migrate objects between a Windows NT 4.0 resource domain and the Windows Server 2003 Active Directory domain, external trusts had to be in place. As the migration user account existed in the resource domain, a two-way trust was established to allow resource OU delegation in the corp.woodgrovebank.com domain. It was acceptable to establish the two-way trust relationships in the Woodgrove Bank environment for the purpose of the resource domain migration as the domains were being decommissioned once the objects were migrated. An alternative to establishing the two-way trust between the resource domain and the corp.woodgrovebank.com domain, would have been to perform the migration with a user account in the corp.woodgrovebank.com domain that had administrative privileges in the resource domain and all computers in the resource domain that are being migrated.

For more details, refer to test case ID: 271 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating Workstations

The process of migrating workstations to the corp.woodgrovebank.com domain was performed by Desktop Configuration Administrators onsite where possible. The migration process involved creating a new computer account in the corp.woodgrovebank.com domain, transforming security principals on the workstation and changing the domain membership of the computer. ADMT v2 was installed on a migration workstation located onsite and the ADMT v2 agents were remotely deployed to each computer. While ADMT v2 did not have any limitations in the number of machines that could be migrated at once, the test team chose to limit the computer migration batch to 500 computers. This allowed them to adequately support the migrated workstations should a fallback procedure have been required. The Agent Monitor dialog in ADMT v2 was used to verify the successful migration of each workstation.

If no Desktop Configuration Administrators were present at a Woodgrove Bank site, then the workstations could be migrated remotely. The sites where a remote workstation migration was performed typically contained fewer that 20 workstations.

Generating a SID Mapping File

When security was translated, ADMT v2 used its internal information about migrated accounts stored in the protar.mdb file to decide which Access Control Lists (ACLs) needed to be translated and how. A SID mapping file could have been used to overwrite this information. The test team used SID mapping files to translate security principals in the resource domain to the new security principals in the corp.woodgrovebank.com domain.

For more details, refer to test case ID: 273 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Performing the Pilot Workstation Security Translation

A pilot migration of approximately ten workstations was performed at each site prior to the actual migration. The standard workstation migration process had to be followed by the pilot migration.

For more details, refer to test case ID: 274 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

ADMT v2 Command Line Workstation Security Translation

As the security translation involved such a large number of workstations, it made sense for the test team to use the ADMT v2 command line and scripting options to translate the security on the workstations.

For more details, refer to test case ID: 275 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Changing the Workstations Domain Membership

Workstations and member servers have their own SAM account database. If they are moved between domains, they always take this database with them. If accounts that live in the local SAM database (like local groups) were used to grant access to resources, they would always move with the computer. Therefore, migrating these accounts was unnecessary. This second phase of the workstation migration changed the domain membership of the workstation to corp.woodgrovebank.com. The workstation domain change required a reboot to complete and was scheduled one minute after the completion of the migration.

Performing the Pilot Computer Migration on Workstations

A pilot migration of approximately five workstations was performed at each site prior to the actual migration. The standard workstation migration process had to be followed by the pilot migration.

For more details, refer to test case ID: 276 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

ADMT v2 Command Line Computer Migration

As the computer migration involved such a large number of workstations, it made sense for the test team to use the ADMT v2 command line and scripting options to migrate the workstations.

For more details, refer to test case ID: 277 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Migrating Member Servers

The process and tools used to migrate a member server, such as a file and print server, were identical to the workstation migration process. The migration plan detailed some additional precautions to the security translation process of the Woodgrove Bank member server migration process, to ease fallback procedures. Additionally, some extra change control processes and user communications were required as the member servers would also require a reboot to complete the change to of their domain membership.

Performing the Pilot Member Server Security Translation

A security translation of a single member server was selected for the pilot. This allowed the test team to examine the impact of the security translation before continuing to other member servers in the domain.

For more details, refer to test case ID: 278 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Performing the Member Server Security Translation

Security translation was required to be performed on all member servers in Woodgrove Bank. This ensured that any references to migrated security principals were updated, such as the print queues and file system ACLs. The security translation did not require a reboot to complete, so this was performed directly prior to the member server domain membership change. As Woodgrove Bank member servers resided in a resource domain, a SID mapping file was used to identify migrated account references on the member server. The SID mapping file contained all migrated user accounts and groups in the corp.woodgrovebank.com domain.

For more details, refer to test case ID: 279 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Changing the Member Servers Domain Membership

Member servers also have their own SAM account database. If they are moved between domains, they always take this database with them. If accounts that live in the local SAM database (like local groups) were used to grant access to resources, they would always move with the computer. Therefore, migrating these accounts was not necessary.

This second phase of the member server migration changed the domain membership of the member server to corp.woodgrovebank.com. The member server domain change required a reboot to complete and was scheduled one minute after the completion of the migration.

Performing the Pilot Member Server Computer Migration

A pilot migration of a single member server was performed at each site prior to the actual migration. The standard member server migration process had to be followed by the pilot migration.

For more details, refer to test case ID: 280 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Performing the Member Server Computer Migration

The computer migration was required to be performed on all workstations in Woodgrove Bank. This ensured that the computer accounts for the workstation were created in the corp.woodgrovebank.com domain and that the domain membership on the workstation was also updated.

For more details, refer to test case ID: 281 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Decommissioning the Additional Account Domain

The final goal after migrating all of the accounts and resources from the additional account domain (WNB-ACCT-ROW) and decommissioning the resource domains was to decommission the account domain WNB-ACCT-ROW and re-provision the domain controllers. The prerequisites to begin the process of decommissioning the WNB-ACCT-ROW domain were:

Top of page

Post-process Testing

Post-process testing validated the success of the applied consolidation and migration guidance by confirming the operational functionality of the consolidated and migrated servers, clients, and network resources.

Figure 3. Woodgrove National Bank’s Windows Server 2003 Active Directory Domain Model (End State)

Network Services Testing

A subset of our pre-process tests confirmed network connectivity as well as the configuration of domain and network services for each client and server in the environment. To ensure the correct configuration of the post-process test environment, every computer was tested for the following:

Using quick command-line ping tests, basic network connectivity and appropriate IP address assignments were confirmed for each computer.

For more details, refer to test case IDs: 173, 176, 177, 181, and 186-190 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Exchange Server 5.5

Testing was conducted in order to validate the continued existence, functionality, and maintained configuration of the Exchange Server 5.5 service.

For more details, refer to test case ID: 170 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

File and Print Services Testing

After completing the domain migration and consolidation process, file, folder, printer port, and network resource access privileges were tested again to ensure that the process did not cause any breaks in security. All file and print objects were checked for appropriate permissions. Testing confirmed that no security issues were introduced by the migration and consolidation process.

Account security testing verified that all designated account groups had the proper access levels, and that they could perform tasks appropriate to their security levels but none beyond it. Various file and printer access and change actions were performed while logged on with a local administrator, a domain user, and a domain administrator account. Tests were performed to verify that the security translation that was performed during the migration and consolidation process was successful and that user and group accounts could access the same resources that they could prior to said process.

For more details, refer to test case IDs: 172, 175, 213, and 216 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Client Testing

Client messaging tests were performed on each client type to validate connectivity to their respective Exchange 5.5 Server and to ensure messaging capabilities were present.

For more details, refer to test case ID: 178 in the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Top of page

Test Results

Three test passes were performed to validate the domain migration and consolidation process. All test passes were run against the same configuration with changes only to our processes based upon bugs encountered within the previous test pass.

Throughout the testing cycle, process documentation quality was increased through document reviews and resolution of bugs filed during testing. Additional test passes were performed for each major process change until the quality could be confirmed. The final test pass for the domain migration and consolidation was performed without encountering any additional process related errors.

For more details on the final test pass, refer to the Domain Migration and Consolidation Test Cases and Results worksheet included in the Test Kit.

Top of page

Summary

This chapter described testing that was performed to validate the guidance provided in chapters 6 - 11 in the Implementation Guide for consolidating and migrating a Windows NT 4.0 flat domain environment to a Windows Server 2003 Active Directory environment. The testing consisted of: pre-process testing, process testing for consolidation and migration of domains and domain objects, and post-process testing.

First, pre-process testing was performed to ensure that the lab environment met the requirements for the Windows NT 4.0 domain consolidation and migration process. Then, using the guidance documented in the specified chapters of the Implementation Guide, process testing was completed. Finally, post-process testing validated the success of the applied process. Multiple test passes were performed until the required process quality was achieved.

Top of page

7 of 7