As the migration of user objects and domain resources continues, administrators find that key design decisions have become clear and the implementation is well in progress. The remaining focus now turns to how and what is the most effective method to remove the Windows NT 4.0 source domain and domain servers. Questions often asked by network administrators when beginning to consider the removal of a Windows NT 4.0 domain or server are:
Key to decommissioning a Windows NT 4.0 source domain involves removing the Windows configuration that existed to support coexistence. The following sections describe common areas often overlooked, methods that ensure that domain communication and Windows 2003 performance is not compromised by residuals remaining from the migration, the methods in which to identify potential issues, and the tools used to resolve them. Decommissioning Windows NT 4.0 Domain ServersWhen migration of network file and print services begin, administrators often focus on the migration of resources and not how this is directly related to decommissioning the servers on which services resided. When domain servers are not directly upgraded to Windows Server 2003, roles must be migrated to the target domain, leaving servers in the source domain ready for removal. By understanding the best practices for migrating server roles, administrators can also systematically begin decommissioning server resources simultaneously , which would normally be removed at the end of the migration. Prioritizing Server Roles During a MigrationsDuring a migration, there are certain servers that can or should be migrated before or after others. The various server roles that should be prioritized during the migration process are as follows :
Removing PermissionsWhen establishing connectivity between domains for migration purposes and to support the migration tools, many configuration changes and group membership entries are created. These changes are just as important to review and remove after a migration is complete as they were to implement and provide functionality for the actual migration. By ensuring that permissions and group membership are removed after the migration is complete, ghost entries in Active Directory referencing Windows NT 4.0 administrative accounts are avoided and administrative cleanup requiring lengthy review and manual cleanup tasks at later time can be avoided. Review the administrative changes created to support the migration and remove these accounts from the Active Directory administrative groups before removing the last Windows NT 4.0 server from the Active Directory domain. Using the Active Directory System Editor ADSIThe Active Directory Services Interface editor (ADSI Edit) is an Active Directory Service tool that gives you the capability to use an alternative editor to manage the Active Directory domain and schema objects. ADSI enables you to add, remove, and modify all directory objects viewing the schema from a low level perspective. This tool can be used with many of the same features provided in Active Directory Users and Computers but without the restrictions sometimes experienced when trying to delete directory objects. Use the ADSI editors to remove objects such as legacy server objects remaining from the Windows NT 4.0 source domain created during coexistence. ADSI editors can sometimes be the only option for removing these objects. Using ADSI Edit Can Cause Irreversible Effects Using ADSI Edit can cause irreversible effects with no option to recover from mistakes. Before deleting objects using ADSI Edit, ensure that you understand the full repercussions and have backed up the Active Directory completely. The ADSI editor can be installed from the Windows 2003 Server CD-ROM by installing the SupTools.msi installation package. To install ADSI Edit, install the installation file located in the D:\\SUPPORT\TOOLS directory where D: represents your system's CD-ROM drive. |