During the planning processes outlined in this and previous chapters, you should have defined the phases of the restructure process. You will have identified the order in which the domains are to be restructured and the users and resources are to be migrated. You will also have decided how resources are to be cloned (an inter-forest restructure) or moved (an intra-forest restructure). In this lesson, you'll focus on the actual sequence of events for the implementation of the restructure.
After this lesson, you will be able to
- Plan the restructure process for a specific Active Directory configuration.
- Understand each of the actions to be performed and their sequence.
Estimated lesson time: 20 minutes
The basis of a restructure is to take objects from source domains, which might be Windows NT domains or mixed-mode domains, and move them into a native-mode Windows 2000 domain. The actual restructure process must contain the following steps:
- Establish a destination environment. The initial phase of the restructure must be to set up a native-mode Windows 2000 configuration into which the objects from the source environments are to be placed. The destination of the restructure must be a native-mode domain if SIDhistory is to be used to allow migrated objects to access resources in the source domains. The native-mode configuration will be achieved by either upgrading an existing domain and switching it to native mode after all the servers have been upgraded or by installing a pristine environment and switching it to native mode.
- Establish a source environment. If you're performing an intra-forest restructure, you can use the migration tools only if the source domain is operating in mixed or native mode. Hence, before a restructure can occur, the PDC in the source domain must be upgraded to Windows 2000 and the domain added to the forest containing the destination. BDCs in the domain might also be upgraded, but this isn't mandatory. If part of the migration plan is to protect existing domain controllers until verification of the parallel environment, you should consider installing a BDC that will be promoted to the PDC for the domain and then be upgraded.
If you plan to use universal groups to ease the movement of groups from the source domain into the destination, you'll need to convert the source domain to native-mode operation. Also, if you will be moving objects from the domain source (intra-forest) into the destination, the source and destination of the objects must be in the same forest.
If you will be cloning objects from the source domain (inter-forest), they cannot already exist in the destination forest.
- Build OUs in the destination. The final Active Directory design might use OUs to delegate management. These units must be set up and any GPOs associated with them must be created and assigned. When the source objects are moved or cloned, they can then be placed into the appropriate OUs.
There might be changes in how groups and policies behave after the migration, which you'll need to investigate in a test environment.
- Set up any new groups in the destination. When the restructure takes place, a number of groups from source domains might be consolidated into groups in the destination. Some of these groups will be in OUs in the destination. These will all need to be created and permissions set as appropriate on resources in the destination domain.
- Consolidate or remove any unused objects in the source. You can ease the burden of a restructure by cleaning up the source domain prior to migration. Over time, many Windows NT domains have collected a variety of unused groups and users, especially when users have left or projects have been completed and the administrator has been away during that period. Utilities such as Usrstat from the Microsoft Windows NT Server Resource Kit can indicate when user accounts were last used. You might also want to consolidate resource domains prior to a restructure into an OU configuration.
- Establish trusts. In an inter-forest restructure, you'll have to set up explicit trusts between the source and destination domains to retain resource access by migrated user accounts. However, both restructure methodologies might require you to duplicate the trust relationships associated with the source domain to the destination domain. Duplicating the trust relationships will ensure that any resources being accessed by trusted domains to migrated servers are kept intact. Trust relationships are also required by the migration tools.
- Establish access in the source domain. If you've created any new groups in the destination domain, you might have to give them permissions on resources in the source domain, once any required trust relationships have been set up.
- Perform the migration of the objects.The objects can now be moved (intra-domain restructure) or cloned (inter-domain restructure) into their preferred positions. The issue of whether resources are to be moved or cloned will have been addressed at the restructure planning stage.
- Image all servers. Once your system is running smoothly, take backups or image all servers in the pristine environment after every successful restructure. This procedure will ensure that you will always have a recovery position should a further restructure from another domain cause dramatic problems in the pristine environment. Bear in mind that it's easier to manage and store CDs or images stored on hard disks than it is to manage tapes.
- Delete objects in the source domain as appropriate. Once you've verified that all operations are running smoothly after a restructure, you can begin to delete the original source objects that were cloned in the source environment.
- Decommission and redeploy servers. Once all components of a domain have been successfully migrated, you can begin to decommission and redeploy servers. Before decommissioning, ensure that you take appropriate backups or images as a final fallback position.
Note that the previous list considers only the issues directly concerned with migrating user accounts and the resources that they use. Issues such as preserving network facilities and DNS are covered in Chapter 12, "Business Continuity."
Prior to migration, you must perform these steps on the test environment. Once the test results have been shown to be successful, the next step is to rebuild your pristine forest and begin a pilot restructure. Upon successful completion of the pilot, the restructure can then go ahead until, at some point, the pristine forest will become the production environment.
Practice: Create and Configure a Windows NT Source Environment
In this practice, you'll set up the source domain that will be used for an inter-forest migration in the next chapter. You will need to reformat PC2 and install Windows NT as a PDC in a domain called MIGRATE.
To create the Windows NT MIGRATE domain on PC2
- Install Windows NT on PC2, following the general instructions provided in "Getting Started."
- Refer specifically to the subsection "Standard Instructions" and start with step 1.
- Perform each step from step 1 through step 32, but when you encounter steps 5, 16, 21, and 26, use the modified versions of those steps as listed next.
- Give the machine the name MIGRATE1.
- When the Microsoft TCP/IP Properties dialog box appears, make the following settings on the IP Address tab:
IP Address: 192.168.0.106 Subnet Mask: 255.255.255.0 Gateway: Leave the gateway address empty.
- Leave the computer name as MIGRATE and set the domain name to MIGRATE.
- When the machine has booted, log on to the MIGRATE domain as Administrator with the password secret.
Be certain to complete step 31 in which you install Service Pack 5; several of the migration practices in the next chapters will fail otherwise.
In the next chapter, you'll be copying users from the MIGRATE Windows NT domain into the TRAINKIT Windows 2000 domain. Each user has a particular configuration and group membership. A batch file has been provided that will create the users and configure the system for them to work correctly.
To set up the user accounts in the MIGRATE domain
- Boot up MIGRATE1 (PC2) and log on as Administrator with the password secret.
- Open a command prompt, switch to the C:\Tools folder, and type setmigrate.bat.
The batch file setmigrate.bat will run and create the users and give them all the password secret. It also creates two shared directories to hold the users' files and profiles.
- Open the User Manager For Domains administrative tool on MIGRATE1.
- Select the users mig1, mig2, intra1, and intra2 by holding down the Ctrl key and clicking on each. Press Enter to open the Properties dialog box for these users.
- Verify that the User Must Change Password At Next Logon check box is not set, and click OK to save the settings.
Now you must also verify that the MIGRATE1 server allows users to log on locally to the server.
- From the Policies menu, select User Rights.
The User Rights Policy dialog box appears.
- Select Log On Locally from the Right list. Verify that the group Everyone is listed in the Grant To box. If it isn't, complete steps 8 and 9; otherwise skip to step 10.
- Click the Add button to open the Add Users And Groups dialog box.
- Select the Everyone group and click the Add button. Click OK.
- Click OK in the User Rights Policy dialog box to close it.
- Close the User Manager program.
In this lesson, you learned about several phases to be performed as domains are restructured. The source and destination domains must be set up in the correct modes. OUs, policies, trust relationships, and groups must be set up to allow migrated accounts to access resources in the source domains. You prepared PC2 for an inter-forest migration by installing Windows NT Server, creating the MIGRATE domain, and configuring user and group accounts.