In this Chapter
When organizations begin a migration to Windows Server 2003, even though they have completed a detailed plan, each implementation task has been carefully considered. Often many unforeseen factors can arise that can have adverse effects on the migration, disrupting the flow of the progress and productivity of the migration project.
This chapter focuses on best practices and tips that can assist administrators with a migration by identifying common mistakes and best practices to avoid unforeseen issues. Some of these issues may include improper network designs, problemsome network communication links, improperly configured systems, or errors in site to site replication.
Besides avoiding these issues, other key factors covered in the chapter are the various migration strategies and best practices to avoid downtime and streamline the migration process.
When planning a migration to Windows Server 2003, one of the key components is to design and implement a new Windows 2003 Active Directory infrastructure and forest that is scalable and flexible enough to meet an organization’s existing and future business needs.
To meet this goal, it is important for organizations to understand the current Windows NT 4.0 environment beyond their basic Windows NT operating systems. Knowing and understanding all existing hardware and third-party applications in use can assist an organization in avoiding setbacks and disruptions when planning and migrating to Windows Server 2003 and Active Directory.
Understanding these components and how they can affect a migration and Windows Server 2003 will assist administrators and planners in ensuring that a new Active Directory infrastructure is fully functional and scalable to an organization’s future plans and needs.
Before planning a migration, it is important to know whether existing hardware currently in use in the network environment can support the various editions of Windows Server 2003 that will be implemented as part of the migration.
Begin planning your migration by assessing future hardware needs and conducting a detailed inventory of all existing server hardware that will be migrated to a new Windows 2003 Server family platform.
Planning Hardware Upgrades
Plan hardware upgrades according to server roles and installed applications that might require additional memory or faster processor speeds to ensure optimal server performance. Combine your software and hardware inventory to plan and deploy a scalable optimal performing server hardware environment.
Begin by creating a detailed and documented hardware inventory to assist in identifying existing server hardware. The inventory can be used to identify server hardware that does not meet the Microsoft Windows Server 2003 family minimum hardware requirements. Review the requirements in Table 14.1 to determine if your Windows NT 4.0 installations meet the minimum Microsoft hardware requirements for installing Windows Server 2003.
Another method to determine hardware compatibility is by using the Compatibility Check Tool available on the Windows Server 2003 installation CD-ROM. This tool can be run directly from the Windows Setup on the installation CD-ROM and does not require administrators to install Windows Server 2003.
Software Compatibility List
You can also review the Windows Server 2003 Family hardware and software compatibility list on the Microsoft Web site.
Processor Compatibility
Windows 2003 Server might not upgrade Windows NT systems with multiple Pentium Pro or Pentium II processors correctly. Windows Server 2003 setup and the Compatibility Check will identify if dual processors and multiple processor servers will only run with one processor after the upgrade is complete. More information on the subject can be found on the Microsoft System Requirements Web site at www.microsoft.com/windowsserver2003.
You can use the autorun feature built into your server systems to launch the Windows Server 2003 setup screen, which will enable you to navigate to the Compatibility Check Tool. If your server hardware does not support the autorun feature, or it has been disabled in the server bios, the compatibility check utility can be run from the command prompt or Windows run option. To run the compatibility check tool, at the prompt type: D:I386winnt32/checkupgradeonly (where D: represents the CD-ROM drive letter of the server you are checking).
One key component to a successful migration is identifying all applications currently installed and present in the existing Windows NT 4.0 environment. By identifying all applications in use as well as specific applications that might no longer be in use, administrators can have a full understanding of the application migration requirements they might be challenged with. Knowing what applications are to be migrated and what the specific requirements are for compatibility with Windows Server 2003 will assist you in avoiding any issues with application functionality after applications are migrated to Windows Server 2003 and Active Directory.
One challenge in identifying these applications is the method you should use to accomplish this large task. Organizations with Microsoft Systems Management Server (SMS) can produce a detailed inventory of applications using the collection of data obtained through the software inventory component of SMS.
Application Compatibility Tool Kit
Download the Application Compatibility Tool Kit from the Microsoft Windows Server 2003 Web site at http://www.Microsoft.com/windowsserver2003/compatible/appcompat.mspx.
For organizations that do not have Systems Management Server (SMS), another method to inventory software in a Windows NT 4.0 environment is to use the tools provided in the Application Compatibility Tool Kit for Windows Server 2003.
The Application Compatibility Tool Kit (ACT) is a deployment tool provided by Microsoft to assist IT staff in identifying and testing applications for compatibility with Windows Server 2003. There are three components to the ACT:
Microsoft Application Compatibility Analyzer is a tool used to remotely gather all installed programs within a Windows NT network. This tool automatically creates an inventory of all installed programs without requiring a management tool such as SMS.
Windows Application Verifier can be used to identify compatibility issues with existing and new application to be installed on Windows Server 2003.
Compatibility Administrator is a complete tool that can determine the necessary fixes required for application support with Windows Server 2003. The compatibility administrator can also be used to create packages of fixes stored in a database that can then be distributed to application servers or computers on the network.
After the discovery of hardware and software has been completed and documented, the next step is to design and implement a scalable Windows 2003 Active Directory environment. By designing and implementing a Forest Root that is scalable, organizations can leverage the flexibility and migrations options when migrating to Windows Server 2003.
Logging Tips
Use the command line tool Collector.exe to inventory systems applications and write information to a log file. By default, the Collector tool writes information and places the log file on the system desktop in which the tool is being run. Use the -o switch to specify an alternative location to write the collectors logs; for example, Collector.exe -o c:AppInfoCollect.log.
You can begin understanding how to implement scalability into a migration and Active Directory by understanding the different migration paths available when upgrading from Windows NT 4.0.
Advance Active Directory Design
To better understand options that can be applied to your Active Directory design, review Chapter 10, “Advanced Active Directory Design.”
The first option is an in-place domain upgrade. This method is the most restrictive of the three methods; however, it is best used for organizations that want to maintain the existing domain model.
The second option is a domain migration; this method is best implemented by organizations that want to migrate all existing domain objects to a single newly created Active Directory domain.
The most effective and flexible method is a domain consolidation. When performing a domain consolidation, a newly created Active Directory Root is implemented and connected to the existing NT domain using domain trust.
This option provides the most migration flexibility and a broader range of migration options. By leveraging all the functionality available in the first two migration paths a domain consolidation is ideal for organizations that want to implement change and maintain certain existing domain configurations (see Figure 14.1).
When planning a migration, how to migrate is not always the most import component to consider. Sometimes understanding the best approach and tasks involved to recover from a failed migration can be just as important as the migration tasks themselves.
The following sections review common areas to consider and tips that can allow administrators the capability to undo tasks in certain migration scenarios.
Test All Migration Scenarios
It is best practice to test all migration scenarios in an isolated lab environment prior to attempting a live migration.
When performing an in-place upgrade of a Windows NT 4.0 domain, or even when migrating domains, corruption of SAM databases or unrecoverable failures of the Windows NT Primary Domain Controller (PDC) and Backup Domain Controllers (BDCs) can occur. These cases require a full recovery of the original source domain’s SAM database.
One method to recovering the original NT source domain is to create a backup Domain Controller that can be isolated from the production domain for recovery purposes in case of an unrecoverable failure.
Installing an additional Windows NT Back Up Domain Controller on the source domain creates a copy of the SAM database, which can then be pulled of the network and shut down. To recover the SAM database in case of a failure, the recovery server can simply be turned on and promoted to the domain’s new primary domain controller, providing a complete copy of the original SAM database.
When migrating accounts such as desktops and user accounts, one challenge administrators face is how to recover if a migration were to fail. The simplest method is to understand and leverage the options available with the Active Directory Migration Tool (ADMT).
Using the Active Directory Migration Tool to migrate accounts enables you to preserve the original account in a disabled state within the source domain, while at the same time creating a new account in the new Active Directory target domain. In the case of a failed migration, administrators can simply enable the original account, providing immediate access to network resources for the user account that failed to migrate. Review the options and settings available for account migration in Figure 14.2 to determine the best method for migrating accounts based on the migration’s specific requirements.
As with most day-to-day administrative tasks, avoiding network downtime is a priority when migrating to Windows Server 2003 and Active Directory. Avoiding end user disruption and network downtime can be accomplished by carefully planning, documenting, and testing the method in which a migration is performed as well as implementing an effective failover plan.
To address network downtime, review the Windows Server 2003 Active Directory design and functionality available with Windows Server 2003.
One simple method you can use to leverage Windows Server 2003 functionality and redundancy is to implement redundant domain controllers and global catalog servers in a new active directory domain. You can rely on the secondary server to support the domain in the case of a domain controller failure.
Installing an additional domain controller to support redundancy on the Active Directory domain during a migration, even if the domain controller is temporary, can be the difference between an immediate recovery and a complete domain restore.
Domain Functional roles can be seized at any point of failure by the secondary domain controller to restore immediately domain functionality and user authentication.
By installing an additional domain controller, you can also configure this system easily to provide additional redundancy by replicating the Active Directory Global Catalog. Configuring this option on a second domain controller will dynamically create a complete redundant copy of the domain’s global catalog on the additional domain controller.
To configure this option on an additional domain controller, perform the following steps:
Begin by selecting Start, All Programs, Administrative Tools.
From the Administrative Tools program group, select Active Directory Sites and Services.
Select the Sites folder and navigate down to the server that you would like to configure as a Global Catalog server by choosing Sites, Default First Site Name, Servers, Server Name, NTDS Settings.
From the File menu, select Action and click Properties. This will open the Properties page on the server you want to configure.
Place a check in the Global Catalog check box as shown in Figure 14.3.
For More Information
This option can be created as a temporary solution or added into the Active Directory Design. For more information regarding design considerations, review Chapter 10.
During a migration or while maintaining coexistence during a domain consolidation, it is important to maintain effective and proper name resolution between the source Windows NT 4.0 domain and the destination Active Directory domain.
Planning and managing effective name resolution ensures that server-to-server communications and client server communication are not disrupted. Another area of importance is ensuring third-party applications that are dependent on server name resolution continue to function properly. Review the different name resolution options in the following section to meet your organization’s migration requirements.
The solution for managing this task is best determined by understanding the different method in which each of the Microsoft Windows operating systems perform name resolution when querying a host name lookup.
The Windows NT Server 4.0 operating system along with many legacy applications rely primarily on the Windows Internet Naming Services (WINS) built into Windows NT 4.0. When a Windows NT Server requests a host name lookup, NetBIOS name resolution is used to query the domain’s WINS. This is the primary means of resolving host names to network addresses with Windows NT 4.0 unless other methods of name resolution are configured to override this method. This method also works with Windows 95, Windows 98, and Windows NT client desktops.
Unlike Windows NT 4.0, Windows Server 2003 and Active Directory rely on the Domain Naming System (DNS) standard as their primary method of name resolutions. This functionality is mandatory and required for the installation of Active Directory. When implementing Windows Server 2003, this becomes the primary method of host name resolution for Windows Server 2003 and Active Directory.
To maintain effective server-to-server and client-server communications when migrating to Windows Server 2003, it is important to consider and design which domain will be responsible for providing name resolution and how name resolution will be affected when the source domain is decommissioned.
When integrating Windows Server 2003 and Windows NT Server environments, domain controllers must be able to communicate via their NetBIOS name as well as Fully Qualified Domain Name (FQDN). To implement effective name resolution, it is often a good decision to migrate the Windows NT 4.0 primary WINS services to the newly created destination Active Directory Domain. By migrating WINS services to the destination Active Directory domain, name resolution can be maintained during the migration as well as during the decommissioning of the source Windows NT domain and servers.
Implementing a New Installation of WINS Services in the Destination Domain
Implementing a new installation of WINS Services in the destination domain requires reconfiguring the TCP/IP WINS properties for all servers and clients in the source domain.
Disable the source domain’s WINS Service using the services Control Panel. Maintain one installation of WINS as a means of redundancy in case a problem were to appear requiring a fallback to the original WINS server.
To install WINS on the Windows 2003 Server platform, open the Control Panel and perform the following steps:
From the Windows 2003 Server, select Start, Control Panel, Add Remove Programs.
Select Add/Remove Windows Components.
Select Network Services and click the Details tab.
Select the Windows Internet Naming Services (WINS) and click OK. This installs WINS on the server. Management of the WINS can be completed through the Windows Administrative tools.
Incorporating the Installation and Configuration of Windows 2003 WINS into the Migration Project Plan
Incorporate the installation and configuration of Windows 2003 WINS into the migration project plan. Installing and configuring the service when building the domain controller to replicate information can allow the service to function properly for a period of time prior to beginning to migrate domain users and resources.
After all domain users and resources have been migrated to the destination Active Directory domain, you can begin to decommission unneeded WINS services previously required for coexistence with the Windows NT 4.0 source domain.
To begin, review the current state of the Windows Server 2003 domain controller’s Domain Name Systems logs in the server event viewer to identify any potential DNS name resolution issues. Address and resolve any errors prior to removing the WINS service.
To decommission WINS in an Active Directory environment, changes must take place on the Windows clients as well as all servers in the domain. In every scenario, servers and workstations must be modified to remove old WINS entries from the TCP/IP properties of the system and optimize configuration.
Best practice is to start with the modifications of network servers, choosing a server that has little to no impact on the network. Modify the TCP/IP properties of the server and test access to network resources. Then continue modifying WINS TCP/IP properties on the remaining servers in your network.
Modifying workstation TCP/IP properties can be much more difficult if an organization has not implemented Dynamic Host Configuration Protocol (DHCP) to distribute network addresses to client workstations.
If your organization is using DHCP, you can modify and remove WINS server entries in the client TCP/IP configuration by modifying the DHCP scope at the server level. This modification can be made at any time with little to no impact on the end user community.
After all WINS-dependant areas have been addressed, it is now time to uninstall WINS service from the Windows 2003 Server. To complete this task, follow these steps:
Open the Control Panel of the server and open the Add/Remove Programs tool.
Select the Add/Remove Windows Components and choose Networking Services from the Selections dialog box.
Click the Details button to review the networking services options and deselect the WINS component.
Select Finish and close Add/Remove Programs to complete the removal of WINS services.
Testing Name Resolution
Modify a workstation’s TCP/IP properties and test name resolution prior to implementing an enterprisewide DHCP configuration change.
Test all server-to-server communications and applications requiring name resolution to ensure that functionality will not be affected when decommissioning WINS services.
Use the Services Control Panel to stop the WINS Service and test name resolution functionality before removing the WINS service and database.
Often when Windows NT 4.0 Servers where installed without hardware fault-tolerant equipment such as RAID controllers, the Windows NT 4.0 disk manager was used to create volume sets, mirrored sets, stripe sets, and stripe sets with parity. Because the Windows Server 2003 operating system does not support Windows NT 4.0 disk manager configurations, you must modify software-based disk configurations before performing an in-place upgrade of a Windows NT Server to Windows Server 2003. Perform the following tasks for each server that meets this configuration before continuing to upgrade any Windows NT server to Windows Server 2003.
If Windows NT 4.0 disk administrator was used to create a mirrored set for redundancy prior to upgrading to Windows Server 2003, the Windows NT 4.0 mirrored set must be broken to install Windows Server 2003 successfully.
If you are performing an in-place upgrade of a server that has been configured using Windows NT 4.0 volume sets, stripe sets, or stripe sets with parity, the sets must be deleted and new fault-tolerant drive configurations will need to be configured before an upgrade to Windows Server 2003 can be completed successfully.
Don’t Delete All the Data from the Volume
Performing the task of deleting a volume set, stripe set, or stripe set with parity will delete all the data from the volume.
Back up all server data prior to deleting any type of volume or stripe sets.
Because any upgrade from Windows NT 4.0 to Windows Server 2003 using volume sets, stripe sets, or stripe sets with parity requires a reconfiguration of hardware, you should build a new Windows NT 4.0 domain controller, promote this system to the domain’s primary domain controller, and conduct the in-place upgrade on the new system.
Manually Synchronize All Domain Controllers in the Domain
When promoting a new Windows NT primary domain controller, it is good practice to manually synchronize all domain controllers in the domain.
Allow enough time for synchronization to occur and validate this by reviewing the domain controller’s system event logs.
By adding this new domain controller to the source domain without unsupported volume and stripe set disk configurations, you can conduct the in-place upgrade without being required to take any domain controllers offline during the upgrade.
When the new domain controller is promoted to become a Windows NT 4.0 primary domain controller, the old server will become a backup domain controller and a copy of the Windows NT 4.0 SAM database and its information will remain intact.
Commonly overlooked server hardware and operating system service packs can cause unrecoverable failures and lengthy downtime when upgrading servers. Understanding the hardware being used for upgrading and installing the proper service packs for compatibility will help you perform the migration and prepare for any physical failures or migration tasks that need to be repeated.
Whether upgrading existing server hardware to Windows Server 2003 or installing new server hardware, failures of physical hardware components can affect a migration timeline and schedule.
With a detailed hardware inventory, you can plan and purchase spare components such as hard drives, memory, and RAID controllers to ease recovery in case of a hardware failure. This is often a good practice especially when network availability is a priority. This can also be beneficial when upgrades are being performed on server hardware that has been in production for any length of time.
When preparing a network for upgrade, you must plan to upgrade all Windows NT Server operating systems, taking into account the operating system version. With many organizations supporting various versions of the Windows NT 4.0 Server operating system, you must determine whether the existing installations of Windows NT 4.0 meet the minimum Microsoft requirements for upgrading as well as minimum Service Pack revisions required for an upgrade to Windows Server 2003.
Not all Windows NT 4.0 server operating system platforms can be upgraded to just any Windows 2003 Server family platform. To understand the different upgrade paths and options available, look at Table 14.2. This will assist you in planning the best approach to implement your design and design needs.
The Windows NT 4.0 Server upgrade paths are only supported by Windows NT 4.0 Service Pack 5 or later. It is always best to install the latest service pack and allow time to evaluate the service pack installation by reviewing server logs and server performance before upgrading.
Conduct a detailed review of all servers being upgraded in the migration plan. Determine any required service pack installations needed and schedule a service pack upgrade for any existing Windows NT 4.0 servers not meeting the minimum requirements. As a good practice, allow these systems to run long enough to evaluate their performance and stability to ensure that they are not experiencing any issues prior to performing any upgrades to Windows Server 2003.
Installing a Clean Copy of Windows Server 2003
Whenever upgrading existing Windows NT Servers, Microsoft recommends installing a clean copy of Windows Server 2003 as a best practice whenever possible.
Further information about service packs requirements and server upgrade paths can be found at http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/supportedpaths.mspx.
After the Windows Server 2003 operating system is in production and functional. One challenge often overlooked in previous versions of Windows was maintaining server drivers to optimize performance. The time and effort required in the past to maintain servers with updates is no longer a factor with Windows Server 2003. Using the Windows Update services built into the Windows 2003 server operating systems has simplified the task of updating service packs, security fixes, critical updates, and Microsoft signed drivers.
After the upgrade or installation of Windows Server 2003 is complete, use Windows Update to install any required Windows updates and driver library updates to ensure server performance and optimal security.
Windows Update can only be run on server systems connected to the Internet with the proper TCP/IP properties configured to support Internet access.
To use Windows Update services to install the latest service packs, hot fixes, and security update, complete the following steps:
From the Start menu, select All Programs, Windows Update. This will launch the Windows Update service and connect the server being updated to the Microsoft Windows Update Web site.
Accept the Windows Update upgrade as required if you’re prompted.
Select Scan for Updates; this will automatically scan the server system for any required updates.
Select the updates to be installed and finalize the server installation by selecting Install Now.
While planning and implementing a migration, it important to review and determine the support requirements for domain clients. Ensuring effective Windows client network authentication and access to domain objects should be considered as important as upgrading domain servers.
When installing Windows Server 2003, the Windows Setup Manager prompts you that the Windows Server 2003 operating system does not support certain Windows clients. This is by design, because the Windows Server 2003 upgrades NTLM authentication from version 1 to NTLM version 2, thus disabling the ability for older Windows 95, Windows 98, and Windows NT 4.0 clients to access network resources without additional software to support connectivity to Active Directory.
There are two methods by which support for these clients can be enabled: installing the Active Directory Client and enabling support for NTLM V1 through the local server policies on the Windows 2003 domain controllers.
In addition to supporting legacy clients on the domain, another area to consider is authentication performance for existing clients during coexistence and domain controller upgrades.
As Windows Server 2003 domain controllers are implemented into a Windows NT domain, the first domain controller to be upgraded takes on the role of PDC emulator. Once upgraded, this single domain controller is now responsible for providing domain services to all domain controllers as well as the domain authentication to all existing Windows 2000 and Windows XP client systems accessing the domain.
Organizations with large numbers of Windows 2000 and Windows XP clients, as well as legacy clients such as Windows NT and Windows 98, can experience PDC locator overload in this configuration. PDC overload can affect performance of the PDC emulator and prevent proper network authentication to client systems as well as replication of network changes.
Avoiding PDC Emulator Overload
To avoid PDC emulator overload, install and configure additional Windows 2003 domain controllers and configure each to emulate Windows NT 4.0 domain services.
Also, upgrading client computers during a migration without adding additional domain controllers can affect PDC performance and load balancing.
To configure a Windows Server 2003 domain controller to emulate Windows NT domain controllers, change the Registry of the domain controller to the following settings:
After the Server Upgrade Is Complete...
modify the server Registry and configure the Windows 2003 Server to perform Windows NT domain PDC emulation before running the Active Directory Installation Wizard.
Modifying the Registry Setting
Modifying the Registry setting will also modify the method in which the new Domain controller performs Domain Name System Lookups. After the Registry setting is in place, Windows Server 2003 domain controllers use the Windows NT 4.0–compatible Locator process to performed Domain Name Systems lookups.
After all client upgrades are complete, modify the Registry setting on each domain controller to reverse the Registry setting change and enable the Windows Active Directory Internet Protocol Locator Process.
Before upgrading to Windows Server 2003, client support and compatibility with Active Directory must be considered for legacy Windows clients. The Windows Server 2003 family of operating systems do not support Windows 95, Windows 98, or Windows NT 4.0 client systems and will not authenticate these clients to the domain after the presence of Windows NT domain controllers are eliminated.
To enable the ability for these client systems to authenticate and access domain resources, additional client software must be installed or domain controller configurations completed to support authentication. Review the methods by which support can be enabled for these clients and the specific features that each method provides. Determine which method best meets your migration needs and test the configuration in a lab environment before implementing.
The most common method of enabling support for client systems running nonsupport versions of Windows is to install the Microsoft Active Directory Client software.
Available for free download from Microsoft, the Active Directory Client installs the Active Directory extensions enabling support for Windows 95, Windows 98, and Windows NT Service Pack 6a systems in a Windows 2003 Active Directory environment.
By installing the Active Directory Client extensions, client support is enabled in the following areas:
NTLM version 2 Authentication. Support for improved authentication using NTLM version 2.
Site Awareness Support. This functionary allows client systems to authenticate to the domain, logging onto the most available and physically closest Windows 2003 domain controller to the client system. Also, client systems can now change the password on any Active Directory domain controller in the domain.
Active Directory Service Interfaces (ADSI). ADSI support provides client scripting ability often used to manage and retrieve information in Active Directory.
Distributed File Systems Support DFS fault tolerance. This function enables support for access Distributed File System (DFS) shares configured on the Windows 2003 Active Directory domain.
Active Directory Windows Address Book (WAB) property pages. Enabling WAB support allows clients authenticated to the domain to search active directory for user object retrieving information, such as addresses and phone numbers.
One other method of enabling support for legacy clients is to use the local domain controller policy on the Windows Server 2003 domain controller. When organizations want to support legacy clients in an Active Directory environment, authentication can be accomplished through configuration changes to the local domain controller policy by doing the following:
Download the Windows NT 4.0 SP6a Active Directory Client Extensions
The Windows NT 4.0 SP6a Active Directory Client Extensions can be downloaded from the Microsoft Web site at http://www.microsoft.com/ntworkstation/downloads/Other/adclient.asp.
You can enable support by relaxing the NTLM version settings and modifying the Digitally Sign Communication Settings of the default policy as shown in Figure 14.4.
To modify the local server policy, open the Administrator Tools and click the Domain Controller Policy Management Console.
Expand the Local Policies and select Security Options in the left pane of the Policy Management Console.
Modify the following settings as shown in Figure 14.4:
Microsoft Network Server: Digitally Sign Communication (always)—Modify the setting to Disable.
Microsoft Network Server: Digitally Sign Communication (if Client Agrees)—Modify the setting to Enable.
Network Security: LAN Manager Authentication Level—Modify the setting to Send NM & NTLM—Use NTLM Version Session Security if Negotiated.
The Active Directory Migration Tool is a comprehensive tool for migrating user accounts, computer accounts, and groups. One area this tool does not complete without additional configuration is the migration of user passwords to the new Active Directory domain. This feature is important when organizations require users to maintain passwords for access to the source domain as well as migrating service accounts to active directory.
Implementing a secure Password Export Server (PES) into the migration design enables you to focus on migration tasks without spending excessive time supporting user password changes when migrating accounts. Also, with the password migration utility, single sign-on requirements can be maintained and supported by preserving Windows NT 4.0 account user passwords in the newly migrated Active Directory domain.
To migrate passwords, select or install a backup domain controller in the source Windows NT 4.0 domain to act as the Secure Password Export server. This server will communicate with the Active Directory Migration Tool (ADMT) Server in the Target Domain. To provide secure password migrations and ensure no issues with the installation of the Password DLL, a Password Export server should be added to the network during the migration process.
Password migrations are sensitive and information about user’s password are being sent over the network and are stored on the password server.
Enabling security and encryption on the Password Export server and Active Direction Migration Tool server in the target domain is a good practice. Ensure that the following requirements are met before installing the Password Export Server and migrating with ADMT:
The Password server encryption key is a key created on the ADMT server and is required to complete the installation of the Password Export Server. The encryption key can be created and stored in one or both of the following methods, by copying to the local floppy disk drive for transport to the password export server or by storing the encryption key in a folder on the local hard drive.
To create the Password Encryption key, begin by opening a command dialog box on the ADMT server in the target domain and do the following:
Storing the Key
Regardless of which methods are used to store the password encryption key, it must reside on the local server hard drive. Mapped network drives and shares cannot be used for this purpose and will prevent the installation of the Password Export server.
From the command line type the following to create a PES encryption key and create a password: ADMT.exe key Source Domain Name Folder: [Password]
(For example, C:ADMT.exe DunePoint A: Zip&Harley123)
After the encryption key has been created, copy the key to a floppy disk and insert the disk into the floppy drive of the PES server.
On the PES server, run the Password Migration installation from D:I386ADMTPWDMIG.exe where D: represents the drive of the CD-ROM. Type in the password and complete the setup process.
To enable password migrations the AllowPasswordExport Registry key value on the Password Export server must be set. Open the Registry editor on the PES server by typing regedit from the run command dialog box. Open the HKLMSYSTEMCurrentControlSetControlLsa key in the Registry. Modify the Registry key to allow password migrations by adding the value of 1 to the key. This enables password migration on the source domain’s backup domain controller.
After the installation of the PES is complete, the next step is to set domain permission to allow password migrations between the target domain and source domain. Perform the following steps:
Add the Everyone group to the Pre-Windows 2000 Compatible Access group in the target domain. This must be completed using the command line by typing the following: NET LOCALGROUP “Pre-Windows 2000 Compatible Access” Everyone /ADD.
Add anonymous access to domain controllers in the target domain. From the ADMT domain controller, open the group policy editor and choose Default Domain Controllers Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, Additional Restrictions for Anonymous Connections.
Ensure that Rely on Default Permissions or Not Defined is set. This setting must be present to allow password migration to complete.
Add Anonymous Logon user to the Pre-Windows 2000 Compatible Access group using the command line by typing the following: NET LOCALGROUP “Pre-Windows 2000 Compatible Access” Anonymous Logon /ADD.
Test Migration
Perform a test migration to ensure that proper rights have been configured and password migration functionality is present before performing migrations of domain users.
Additional information about password migrations and password server installations can be located on the Windows Server 2003 CD under I386ADMT eadme.doc.
Now that you understand migration concepts and options available using the Active Directory Migration Tool, let’s focus on desktop migration and options that can be implemented to ease the client experience during the migration.
Using the Active Directory Migration Tool, domain member desktop systems can be migrated from the source Windows NT domain to the target domain with little to no need for user intervention. By preparing and understanding the requirements needed to migrate desktops, you can install the ADMT agent easily and remotely.
The following sections review the key elements involved with migrating a desktop and common permissions you need to avoid a failed migration.
Before migrating desktops to Active Directory, the account being used to migrate will require administrative permission to the local desktop administrator group and domain administrator group. This is required to perform certain functions, including changing the domain membership of the desktop on the domain controller and installing the desktop migration agent on the local desktop.
A local group is a desktop system account that is strictly prohibited to the individual desktop and is used to grant permissions and rights to the local computer. The local administrative group is the most privileged of the local groups and allows members access to all function of the local desktop such as services, installing software, and access profiles.
Unlike domain and global groups, which are managed at the domain level by the domain network administrator, local groups can only be managed at the local desktop and require administrative privileges to be changed locally to grant an account membership to this group.
Local administrative groups can host memberships to local user accounts, local groups, domain user’s accounts, domain groups, and global groups.
Many times when migrating, the actual domain administrator account is used to perform all migration functions. Using this account, including adding it to the local administrative group of the desktop, can create network vulnerabilities and allow anyone with access to this account information on the local user’s desktop.
As a best practice, creating a separate account to migrate the desktops systems allows you the capability to control access to the local systems by simply disabling and enabling the account for migration or administrative purposes.
Create a desktop migration account on the target domain. This account will require membership to the domain administrative groups on the source and target domains in order for the administrator to be able to perform these migration functions.
Enhancing Security
To enhance security, the desktop migration account can be disabled when not migrating desktops.
Also the desktop administrative account password can be changed at any time without affecting any other domain administrator account functions.
Most importantly, this account can later be leveraged for administrative purposes. By enabling the desktop account, you can perform tasks at the local desktop level without requiring the domain administrator account to be used.
One thing that often stops administrators from creating and using a desktop migration account is the task of deploying the account to the local desktop administrator group. There are several tips and tricks that can be used to add the desktop migration account to the local desktop administrator group without requiring the administrator to visit each individual desktop system.
One way to create the proper administrative permission required for migrating desktops is to simply add the desktop migration account that resides in the source domain to the domain administrators group in the target domain. Using this method will allow the Active Directory Migration Tool to perform the required functions; however, this will not provide local administrative rights to the desktop after it has been migrated to the target domain.
The second method that can be leveraged to easily populate the desktop migration account to all domain desktops is to use the Net Add User command in the logon script in the Windows NT 4.0 source domain. By adding a single net add statement to the Windows NT 4.0 domain logon script, the desktop migration account can be added to the local administrators group on all desktops when users logon to the domain. Using this method will also leave the account membership intact even when the desktop has been migrated to active directory.
For most migration scenarios, it is unrealistic to think that the migration can be completed in a single upgrade. When this occurs, providing coexistence and functionality between Windows NT domains and Active Directory domains become a major component of the domain migration.
Because Windows Server 2003 is fully integrated with Windows NT security, networking and logon services, coexistence can be supported for a period of time with relative ease of management.
Understanding the migration time frame and logistics of how objects will be moved can better assist you in planning for domain coexistence. Knowing the key elements of the migration and implementing them into the migration plan can provide domain users a reliable level of service during the migration and avoid lengthy network disruptions.
One major benefit to implementing coexistence with Windows Server 2003 is its compatibility with Windows NT domain services. When managing and maintaining coexistence, you can plan to migrate domain services such as Dynamic Host Configuration Protocol (DHCP), Domain Name Service (DNS), and Windows Internet Naming Services (WINS) to Windows Server 2003 as a first step. By migrating these services up front, the ability to take advantage of the features and performance of Windows Server 2003 even when providing functionality of these services to a Windows NT 4.0 domain is greatly enhanced.
Because Windows Server 2003 provides increased performance and availability, migrating and consolidating network services to the new Active Directory domain can actually improve domain performance and client server response. Also, moving these domain services and consolidating to Windows Server 2003 will effectively eliminate Windows NT 4.0 domain servers and provide an increased level of reliability to clients still residing on the Windows NT 4.0 domain.
As users are migrated to the new target domain, maintaining and managing coexistence to ensure uninterrupted access to user resources can be difficult. Backward compatibility to objects such as Windows NT 4.0 file shares and network resources not yet migrated can be accomplished by leveraging and implementing features available in the Active Directory Migration Tool.
With the Windows Server 2003 Active Directory Migration Tool, network administrators can now migrate user accounts while also migrating users’ Windows NT 4.0 Secure Identifier (SID) information to maintain access to resources still residing in the source domain.
In Windows NT 4.0, all users, computers, and groups are associated with a unique domain SID. Windows NT 4.0 domains grant access to domain resources based on a user’s SID information stored in the Access Control List (ACLs). These can be viewed as permissions pages for principles such a file shares and domain resources. These user SIDs can be appended to the new Active Directory Account using the Active Directory Migration Tool. This enables users to maintain privileged access to resources still residing in the Windows NT 4.0 domain.
By choosing the option to migrate SID history, all account information of the domain user object in Windows NT 4.0 is migrated to the new account in Windows Server 2003 Active Directory domain. To migrate user SID history along with the domain user account, select Migrate User SIDs to Target Domain when using the Active Directory Migration Tool to migrate accounts as shown in Figure 14.5.
To migrate Windows NT 4.0 account SID history, select the Migrate SID History check box on the user migration options page of the Active Directory User Migration Wizard.
There are many tools and third-party utilities to assist your organization when migrating to Windows Server 2003. One of the most common and effective tools is the Microsoft Active Directory Connector (ADC). The ADC allows organizations to synchronize Windows Server 2003 and Active Directory with the Microsoft Exchange Server directories. The ADC can be implemented and used to support coexistence between mail systems and active directory while user’s accounts are being migrated.
For More Information
More information on the Active Directory Connector, directory synchronization, and additional tools can be found at www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/default.mspx.
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:
What are the best practices and order in which domain servers can be decommissioned?
How do I reduce risks that can affect the overall progress of the migration?
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.
When 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.
During 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:
Domain Services and Backup Domain Controllers (BDCs)—. Leveraging Windows 2003 performance enhancements by moving key domain services such as DHCP and DNS improves client server communications immediately and eases administration during the migration. This also allows your organization to begin downgrading immediately the total amount of Windows NT 4.0 Domain BDCs and reducing replication requirements and network traffic when changes are made.
File and Print Servers—. When hardware requirements are met, it is sometimes more effective to upgrade file servers using an Inplace upgrade scenario to Windows Server 2003. When this is not possible, migrating these files and print services can be done with relative ease allowing these larger capacity servers to be reallocated into the new active Directory Domain.
Application and Web Services—. With more organizations relying on Web services and server-based applications to support daily business needs, extensive testing and validation is required to ensure application compatibility and a successful migration. By migrating these services later rather than sooner, you have time to test and validate application upgrades and functionality before migrating.
Migration Support Servers—. Review the server roles that reside in the target domain that were used to support the migration such as the Active Directory Migration Tool and server services. Decommission these roles that were used for the migration.
Primary Domain Controllers—. At the very last point of the migration, the only system that should actually remain is the Windows NT 4.0 Primary Domain Controller. Remove this server and archive this system for a period of time acceptable to your organization. This system is the last remaining archive of the original Windows NT 4.0 domain state. Having this domain controller available can enables you to recover domain information if necessary at a later time.
When 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.
The 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:\SUPPORTTOOLS directory where D: represents your system’s CD-ROM drive.
Migrating from Windows NT 4.0 to Windows Server 2003 can be as simple as inserting the Windows Server 2003 CD into the Windows NT 4.0 PDC and allowing for an automated upgrade. However, there are several things that can be done to validate and test for a successful migration in a test environment prior to doing the migration in a live production environment.
Leveraging tools available for compatibility and migration testing and creating tested fallback plans can minimize the risk and the potential failure of a migration to Windows 2003. Planning can also minimize risk, as well as testing and validating procedures and processing times during a prototype or lab test to clarify how long it will take to initiate the migration.
With security enhancements built into Windows Server 2003, the migration process takes on a whole new test of tasks that require security testing and validation before proceeding. Testing security processes can minimize migration failure caused by a Windows service not starting automatically, or access to necessary administrative accounts are blocked by policy or rule.
By leveraging best practices and lessons learned in the migration process, an organization can improve the success factors that lead to a successful migration to Windows Server 2003.