best practices for nt to active directory migration

®

NT

Best Practices for NT toActive Directory Migration

© Copyright Quest Software, Inc. 2004. All rights reserved.

This guide contains proprietary information, which is protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software, Inc.

WARRANTY

The information contained in this document is subject to change without notice. Quest Software makes no warranty of any kind with respect to this information. QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software shall not be liable for any direct, indirect, incidental, consequential, or other damage alleged in connection with the furnishing or use of this information.

TRADEMARKS

Quest Domain Migration Wizard is a trademark of Quest Software, Inc. Other trademarks and registered trademarks used in this guide are property of their respective owners.

World Headquarters 8001 Irvine Center Drive Irvine, CA 92618 www.quest.com e-mail: [email protected] U.S. and Canada: 949.754.8000

Please refer to our Web site for regional and international office information.

Quest Domain Migration Wizard Updated – January 18, 2005 Software version – 6.1

http://www.quest.com/

mailto:[email protected]

i

Contents ABOUT QUEST WINDOWS MANAGEMENT ...............................III ABOUT QUEST SOFTWARE, INC. .............................................III

CONTACTING QUEST SOFTWARE .......................................................III CONTACTING CUSTOMER SUPPORT .................................................... IV

PREFACE................................................................................... 5 MIGRATION PROCESS OVERVIEW .......................................................5 ABOUT THIS DOCUMENT .................................................................6

DISCOVERY, PLANNING, AND TESTING.................................... 7 DISCOVERY AND PLANNING..............................................................7

Active Directory Design...........................................................7 Active Directory Management (Delegation and Provisioning Model)7 Network and Site Topology......................................................8 Trusts ..................................................................................9 SID Filtering..........................................................................9 Domain Migration Wizard Console Placement ........................... 10 Migration Account and Required Permissions............................ 10 NT Directory Preparations ..................................................... 11 Decommissioning Activities.................................................... 12 Migration Cookbook.............................................................. 12 Import Lists ........................................................................ 13 Administration During the Migration........................................ 13 Exchange Migration .............................................................. 14

TESTING ................................................................................. 14 Creating a Test Environment.................................................. 14 Testing Third-party Applications ............................................. 14

ACCOUNT MIGRATION AND RESOURCE UPDATING ................ 15 MIGRATION PROJECTS AND SESSIONS ............................................... 15 PILOT MIGRATION ...................................................................... 15 MIGRATION SCENARIOS ............................................................... 15

Centralized Migration............................................................ 16 Delegated Migration ............................................................. 16

MIGRATION STEPS...................................................................... 17 Overview ............................................................................ 17 Step 1. Migrate the Directory................................................. 18 Step 2. Process Distributed Resources..................................... 19 Step 3. Move Distributed Resources to the Target Domains ........ 29 Step 4. Process BackOffice Servers......................................... 30 Step 5. Move BackOffice Servers to the Target Domain.............. 31 Step 6. Disable Source Accounts ............................................ 32

ii

Step 7. Clean Up SIDHistory Attributes ................................... 32 Step 8. Clean Up Legacy Account Permissions .......................... 32 Step 9. Demote or Decommission Legacy Domain Controllers..... 33

ROLLBACK ............................................................................... 33 Return to the Source Accounts ............................................... 33 Session Undo ...................................................................... 34 Restore from Backup ............................................................ 34

CONCLUSION.......................................................................... 35

iii

About Quest Windows Management Quest Software, Microsoft’s 2004 Global Independent Software Vendor Partner of the Year, provides solutions that simplify, automate and secure Active Directory, Exchange and Windows environments. The Quest Windows Management group delivers comprehensive capabilities for secure Windows management and migration. For more information on Quest Software’s Windows Management group, please visit www.quest.com/microsoft.

About Quest Software, Inc. Quest Software, Inc. provides software to simplify IT management for 18,000 customers worldwide, including 75 percent of the Fortune 500. Quest products for application, database and Windows management help customers develop, deploy, manage, and maintain the IT enterprise without expensive downtime or business interruption. Headquartered in Irvine, Calif., Quest Software can be found in offices around the globe and at www.quest.com.

Contacting Quest Software Phone 949.754.8000 (United States and Canada)

Email [email protected]

Mail Quest Software, Inc. 8001 Irvine Center Drive Irvine, CA 92618 USA

Web site www.quest.com

Please refer to our Web site for regional and international office information.

http://www.quest.com/microsoft




http://www.quest.com/microsoft

iv

Contacting Customer Support

Quest Software’s world-class support team is dedicated to ensuring successful product installation and use for all Quest Software solutions.

SupportLink www.quest.com/support

Email at [email protected].

You can use SupportLink to do the following:

• Create, update, or view support requests

• Search the knowledge base

• Access FAQs

• Download patches

http://www.quest.com/support


http://www.quest.com/support


5

Preface Often management, network administrators, and end users feel that migrating to Active Directory is an enormous and frightening task. Although all projects and environments are quite different and should be assessed independently, it is still possible to outline some common migration scenarios to provide guidance for moving to Active Directory.

This document provides best practices for migration from NT to Active Directory. Note that it is not a substitute for Quest Domain Migration Wizard’s User’s Guide and on-line help, which contain detailed information on the tool and its options.

The procedures listed in this document are relevant for Domain Migration Wizard version 6.1.

Before you start your migration, check for the latest product and documentation updates on the Quest web site: http://wm.quest.com/download/default.asp?product=domainmigrationwizard

Migration Process Overview

The migration process can be divided into two main parts:

1. Discovery, planning, and testing

2. Account migration and resource updating

Quest Migration Suite for Active Directory contains tools to help you migrate from Windows NT to Windows 2000/2003 and Active Directory. These tools are:

• Quest Reporter—Used to report on the current Windows NT environment and assist with planning migration activities to Active Directory. You can also use Quest Reporter to create reports on the Active Directory environment after migration is complete.

• Quest Domain Migration Wizard—Used to migrate user accounts, service accounts, computers, and global and local groups, as well as user properties, passwords, and group membership from Windows NT to Active Directory. Domain Migration Wizard provides ZeroIMPACT™ on end users.

http://wm.quest.com/download/default.asp?product=domainmigrationwizard

Best Practices for NT to Active Directory Migration

6

Quest Migration Suite for Active Directory also includes Enterprise Migration Manager (for Active Directory to Active Directory migration) and NDS Migrator (for NDS to Active Directory migration). Other related products are Quest Consolidator (for schedulable data migration and server consolidation) and Quest Migration Suite for Exchange. For more information about these products, see their documentation.

About This Document

This document outlines best practices for:

• Discovery of the current environment using Quest Reporter to gain a full view of the environment and properly plan for migration activities

• Migration of user accounts, groups, and computers from NT to Active Directory using Domain Migration Wizard


7

Discovery, Planning, and Testing Before you migrate to Active Directory, you should:

1. Plan your migration carefully, using a solid knowledge of your existing network environment.

2. Test your migration plan before using it in your production environment.

Each of these steps is discussed in further detail below.

Discovery and Planning

This section outlines decisions and tasks that must be planned for prior to migration and provides best practice recommendations. It also describes the information you need to collect to plan your migration, and the reports from Quest Reporter that provide this information.

Active Directory Design

It is recommended that your Active Directory design be certified by Microsoft or a certified partner with vast experience with Active Directory. Active Directory design (logical structure and site topology) must be completed prior to any migration.

Before the migration you should check that the DNS is functioning properly so that machine names can be successfully resolved into addresses. You should also check Active Directory replication to ensure that any changes to Active Directory (such as object creations and deletions) will be properly replicated between domain controllers (DCs) in different locations.

Active Directory Management (Delegation and Provisioning Model)

When planning a migration to Active Directory, it is recommended that your delegation model be engineered ahead of the project in order to identify all business rules that must be enforced. Quest ActiveRoles, including the product formerly known as Aelita Enterprise Directory Manager, is the most comprehensive delegation and provisioning product available. It is the best practice to install and configure ActiveRoles soon after implementing Active Directory and prior to migrating any accounts to ensure a pristine Active Directory from the start.


8

These tools can also help during the migration process itself. In particular, in the case of a distributed migration, you can easily delegate only the necessary rights to the persons performing various parts of migration. For more details, refer to the ActiveRoles documentation.

Network and Site Topology

It is essential to have a solid understanding of your infrastructure and know your bandwidth at every location. Site topology with inter-site connections speeds, Active Directory design, OU hierarchy, DC placement, FSMO placement, BackOffice server location, and other infrastructure diagrams help you see the whole picture and make good decisions.

Site topology and information about the number of users in each site, for example, help you decide whether to have a single migration project or to divide the migration into parts and allow some remote sites to be migrated locally (in other words, to delegate the migration activities). Site topology also helps you decide which DCs to use for migration. You should choose DCs located in the same site as the migration console to avoid traffic span across slow WAN links.

Also, if you want to migrate a large number of accounts (more than 500) to the target domain in one session, it is recommended that you select a target DC that owns the RID master role. Otherwise, the target DC may experience delays getting the next set of RIDs from the RID master when creating objects in Active Directory.

How It Works

When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal object created in a domain. Each Windows 2000 DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. There is one RID master per domain in a directory.


9

Reports

Use the “Location of BackOffice Servers” report to find the computers that have BackOffice service installed. Use the “FSMO Roles” report to determine FSMO placement.

Trusts

We recommend that you establish two-way trust relationships between each source and target domain that will participate in migration.

Trusts make it possible to resolve objects’ SIDs, which in turn helps to distinguish objects and check that everything is going right. Trusts also help provide co-existence of two environments, including uninterrupted access to the resources for both switched users and users not yet switched.

Remember that trusts between Windows NT domains and Active Directory domains are not transitive. You should establish trusts between each source Windows NT and target Active Directory domain individually.

SID Filtering

If your target DCs are running Windows 2000 SP4 or later or Windows 2003, you should turn off SID filtering for each source domain to be migrated. SID filtering is turned on by default.

To disable SID filtering, you must be a domain administrator. Use the Netdom.exe utility from Active Directory Support Tools Pack with the following syntax:

Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd

To enable SID filtering, set the /quarantine: command-line option to Yes.

For more information about external trusts, SID filtering, and the Netdom utility, refer to the following article:

http://www.microsoft.com/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/enterprise/proddocs/en-us/domadmin_concepts_explicit.asp






10

Domain Migration Wizard Console Placement

The Domain Migration Wizard console is the computer running Domain Migration Wizard. The console machine should be a member of either source or target domain.

Migration Account and Required Permissions

The best practice is to create a separate user account in the source domain for the migration activities instead of using an existing one.

This account must be a member of the domain local Administrators groups in both the source and target to ensure that it has enough permissions to perform the migration activities. You should also add this account to the local Administrators group on the Domain Migration Wizard console machine.

This powerful account must be maintained closely and should be deleted after the project is complete. It is recommended that this account be owned by one individual and one back-up individual (or as few individuals as possible).

If you cannot get administrative rights over the domains, because of the enterprise security policy, for example, Domain Migration Wizard will let you perform the migration, but with some restrictions:

• If you are not in the Administrators group on the source DCs, Domain Migration Wizard will not be able to get the passwords and privileges of the source users.

• The Add SIDHistory operation may not work.

If you did not establish a two-way trust between the source and target domain, you must log on to the console with the target domain administrator account and obtain administrative rights over the source domain: use the standard ‘net use’ command to connect to the source DCs, servers, and workstations with an account from the source domain created for migration. For example:

net use \\DC_name\Admin$ /u:Domain_name\Admin_Account

where Admin_Account is the account created to perform the migration activities.


11

NT Directory Preparations

Handling Accounts with Non-Standard Names

When creating a user in Active Directory, Domain Migration Wizard uses the corresponding source user’s Full Name (if present; otherwise, its Username) for the target user’s Common Name (CN) and Display Name.

However, naming standards in a Windows NT environment often do not meet naming standards for objects in Active Directory. For example, a source user’s Full Name might be in Firstname Lastname notation, but you want it to appear in Active Directory as Lastname, Firstname. Some users in Windows NT directory may also have middle initials inserted between the first and last names. In such cases, user accounts migrated from the source will have non-standard names in Active Directory.

One solution is to change the name’s form on the fly by adding an evaluation expression during the migration session. However, any source object names that do not meet one of the naming standards (either Firstname Lastname or Lastname, Firstname) must be changed to meet one of them prior to migration.

Another solution is to determine which NT names are non-standard and change them before migration. To list account names, estimate the number of non-standard names, and decide which ones must be changed, you can use the “General User Information” report in Quest Reporter or export the information from NT directory into a CSV file using third-party tools.

Handling Disabled and Inactive Accounts

Domain Migration Wizard can automatically filter out disabled accounts during migration. We recommend you to use this option and not bring disabled accounts to Active Directory.

You might also want to filter out user accounts that have not been logged on to for a long time and disable them prior to migration. To locate such accounts, use the following reports:

• “Accounts that have never logged on”—Displays user accounts that have never logged on

• “Inactive Accounts”—Shows all accounts that are disabled or deemed inactive during the time period you specify


12

Handling Accounts with Duplicate Names

There may be user accounts already created in Active Directory with names similar to source accounts. Domain Migration Wizard considers two objects to be duplicates if the source object’s SAMAccountName is equal to the target’s Pre-Windows 2000 Logon Name.

Although Domain Migration Wizard reports on duplicate accounts during the migration session and allows you to choose to rename, merge, or skip them on the fly, the best practice is to handle duplicates before migration. You should find duplicate user and group names and determine which accounts belong to the same person and what do not. If two accounts, source and target, have the same name and belong to the same person, they should be merged during migration. If not, you should either rename one of them or skip them during migration.

To find duplicate user and group names, use the “Duplicate Users” and “Duplicate Groups” reports from Quest Reporter.

Decommissioning Activities

During the planning phase of the project, servers and DCs to be decommissioned should be identified and a decommission plan outlined. The Domain Migration Wizard Resource Kit contains a tool called DC Demote that enables a DC to be demoted to a member server without requiring an OS reinstall.

Migration Cookbook

We recommend that you create a migration cookbook: a detailed, step-by-step guide of the migration activities specific to your environment that outlines a repeatable process that can be tested and then mirrored throughout the environment.

This is particularly useful in the case of delegated migration, which is when a number of independent administrators located in different sites migrate the accounts they are responsible for to the same Active Directory forest. The cookbook can be given to all of them to unify the tasks and ensure a solid target environment with a structure that meets your design and corporate standard.


13

Import Lists

An import list is a text file listing accounts to be migrated with Domain Migration Wizard. Import lists should be used when migrating large environments to Active Directory. It makes the migration process more manageable, more accurate, and much more efficient. If you are going to perform a one-time migration and plan to migrate all users and groups at once, an import list is not necessary. But for most large migrations (over 2,500 users), it is recommended that import lists be created for migration activities. Using import lists can help you easily track migration activities by site, region, location, or any other criteria set up during the planning phase.

To easily create an import list, run the “User List by OU” report in Quest Reporter against your source NT domain and save it in a plain text, comma-delimited format. Then open it in Excel and remove all columns except User Name and save it again. The resulting file can be used as an import list in Domain Migration Wizard.

Administration During the Migration

During long migration projects, source and target directories co-exist and thus both require administration. We recommend that during the migration, you make any necessary administrative changes on the source (NT) side and then synchronize them to the target (Active Directory) using Domain Migration Wizard. Domain Migration Wizard is designed to synchronize from source (NT) to target (Active Directory) and not from target to source.

If you make changes to the source Windows NT environment after you have migrated user accounts and groups to Active Directory (for example, changes to source group membership or to source user password), these changes can be replicated to the target Active Directory environment. Domain Migration Wizard Project Manager can help you accomplish the following tasks:

• Copy passwords from source to target

• Mirror global group membership to the target

• Copy local group membership to the target

However, for other changes (such as changes to other account attributes or creation of new user accounts), you have to run Domain Migration Wizard sessions to merge or create the accounts in Active Directory. Domain Migration Wizard automatic migration sessions can be used to synchronize changes made to source accounts’ properties or automatically migrate newly created accounts to Active Directory. Domain Migration Wizard automatic sessions can be scheduled to run using the standard Windows Scheduled Tasks interface. For more details on Domain Migration Wizard automation, refer to Domain Migration Wizard Scripting Reference.


14

Exchange Migration

The best practice is to first complete the migration to Active Directory and stabilize Active Directory before migrating to Exchange 2000/2003. Otherwise, you need to simultaneously support three separate directories, which is difficult and error-prone. Exchange migration is described in the Quest Migration Suite for Exchange documentation.

Testing

Creating a Test Environment

Migration strategies and activities should be tested in a lab that best reflects the current production environment, including resources, servers, applications, legacy design, and bandwidth. So that you can completely run through your migration scenarios, we recommend you create a copy of your live SAM database in the test lab. This can be done by doing any of the following:

• Move one of your live BDCs into the isolated network that will become a test lab and promote it to PDC. In this case, you may want to create an additional BDC in production and then use it for testing purposes in the lab.

• Create an image of your live PDC using third-party tools and restore the image to another box with a similar hardware configuration in the lab.

• Export the NT directory into a CSV file using third-party tools and import it into the test environment.

Testing Third-party Applications

All third-party applications running in Windows NT environment must be tested to prove that:

• The applications will function correctly in the Windows 2000/2003 and Active Directory environments if you move the server they are running on to the target domain and re-assign permissions for target user accounts.

• Migrated users will still be able to work with the applications after permissions have been processed for target user accounts.

Depending on the results, you will need to decide whether to move the server running the application to target or to re-deploy the application there. In either case, additional planning is needed.


15

Account Migration and Resource Updating

Migration Projects and Sessions

Migration should be completed as quickly as possible to limit the costs of administering both NT and Active Directory.

When Domain Migration Wizard is installed, a single Domain Migration Wizard project is created by default. Each migration project can have multiple sessions. We recommend using a single project.

Pilot Migration

Since most lab environments are not true mirror images of production, there may be some differences in behavior when you start migration in production. Therefore, the best practice is to begin your migration with a pilot migration: select a pilot group of accounts that includes a wide spectrum of groups, users, and service accounts, and migrate that group first. This limits the user impact if unexpected issues occur. Do not limit the pilot to just IT or the migration project team members as they generally have modified configurations and won’t represent a good cross-section of your users.

During the pilot migration, follow the procedures in the cookbook you prepared during the planning stage. If no problems occur, you can start migrating the rest of the environment. However, if you meet with a problem, you should resolve it first, perform additional testing, update the cookbook to include the correct procedures, and then repeat the pilot.

We recommend running a pilot migration using a separate session within your migration project.

Migration Scenarios

Migration from an NT environment to Active Directory using Domain Migration Wizard can occur either centrally or on a distributed basis. Each of these scenarios is outlined below.


16

Centralized Migration

In a centralized migration, the Domain Migration Wizard console is installed in central location and all migrations tasks, including post-migration resource updating, are performed from this console machine by one person. A single Domain Migration Wizard project is used.

The migration process is described in more details in the Migration Steps section below.

Delegated Migration

If it is not possible to perform the migration from one central location, certain migration tasks can be delegated to the administrators in other locations. Choose a delegated migration if any of the following applies:

• The administrator who is responsible for Active Directory administration cannot be granted administrative rights over the source domains and, therefore cannot migrate the accounts to Active Directory. In this case, delegate the account migration task to the administrators of the current source domains.

• The administrator who performed account migration to Active Directory cannot be granted administrative access to the resources in source domains and, therefore cannot update them. In this case, delegate the resource updating task to the individuals who have administrative rights over the resources.

• You need to avoid excessive traffic during resource updating across slow links. In this case, the resource updating task is also performed locally by the individuals who have administrative rights over the resources.

Overview of Delegated Account Migration

In delegated migration, account migration is directed from a central location by the individual who is responsible for Active Directory administration. This person grants the necessary rights in Active Directory to the source domain administrators who will perform the account migration from their domains, and coordinates and controls their activity.

Delegated administrators install and use their own Domain Migration Wizard consoles in their locations. Thus, each delegated administrator has a separate migration project in Domain Migration Wizard and should perform the steps described below in the Migration Steps section.


17

After the accounts from each source domain have been migrated to Active Directory, the separate migration projects are consolidated: each delegated administrator sends the data (Domain Migration Wizard session files) from the local Domain Migration Wizard project folder to the Active Directory administrator, who puts them in one single migration project. The consolidated data is later used for resource updating.

Overview of Delegated Resource Updating

Permissions to resources can be granted to users from multiple domains. Using the consolidated data for resource updating ensures that permissions, user rights, group membership, etc. will be updated for all users from all domains that have been migrated.

In the delegated migration scenario, resource updating is performed locally by the persons who have administrative rights over the resources in their locations. The updating procedure is the following:

1. The Active Directory administrator uses the central Domain Migration Wizard console to prepare special INI files from the consolidated project data.

2. The Active Directory administrator sends the INI files to the local administrators responsible for resource updating in their locations.

3. The local administrators run resource updating in a special mode using the INI files.

Refer to the Delegated Resource Updating section below for more details.

Migration Steps

Overview

The migration procedure below assumes that:

• Two-way trusts are established between each source Windows NT and target Active Directory domain.

• The SIDHistory attribute is added to the target accounts during migration.

It is highly recommended that SIDHistory is appended during the account migration process. However, if this is not possible due to your specific requirements, make sure that permissions on all resources are re-assigned to


18

target accounts before users are switched to the target domain. This also means that step 4 in the migration procedure below must precede the step 3.

To perform the migration, follow these steps. Best practices for each step are described in detail below.

1. Migrate the directory (domain user accounts and groups).

2. Process the distributed resources (end-user workstations and servers), adding permissions to the resources for the target users.

3. Move the distributed resources (end-user workstations and servers) to the target domain.

4. Process any BackOffice servers, adding permissions for the target users.

5. Move the BackOffice servers (Exchange 5.5, SQL, and SMS servers) to the target domain.

6. Disable the source accounts.

7. Clean up SIDHistory attributes.

8. Clean up legacy account permissions.

9. Demote or decommission legacy Windows NT domain controllers.

Step 1. Migrate the Directory

The information about each migration session is stored in a separate session file (SSN) in the current Domain Migration Wizard project folder. These files are later used for resource updating.

We recommend migrating user accounts and groups together in one session in order to transfer group membership to the target accounts during a session. However, if you plan to migrate user accounts and groups in portions, using multiple sessions, we recommend you use the following order to successfully transfer group membership information:

1. Migrate local and global groups to the target domain.

2. Migrate user accounts in subsequent sessions, selecting the global and local groups they belong to, and then merge groups.

If you migrate user accounts and groups in separate sessions without following this order, the project becomes much more complex. Specifically, additional steps are required after account migration, including mirroring global group membership, copying local group membership from source to target, re-


19

migrating, and merging accounts and local groups to update group membership on the target.

We also recommend that you always add the SIDHistory attribute to the target accounts. This greatly helps to ensure that there is no impact to end users during the co-existence period of two environments, making your migration smoother.

Step 2. Process Distributed Resources

Distributed resources are end-user workstations, file and print servers, servers running IIS, scheduled tasks, and other services and applications. To ensure that resources will still be available to users when they start using their target accounts and when you have cleaned up SIDHistory, permissions granted to source accounts to access the resources must be re-assigned to the target accounts.

Service accounts and accounts used to run scheduled tasks must also be changed to the corresponding target ones to ensure that services and scheduled tasks will run correctly after the source accounts are disabled.

Service accounts should be handled separately since the server must be restarted to use the new account. You must coordinate this activity before disabling the source account or the service may stop running. You can use the “Services not Running as System Account” report to determine which accounts are used to launch services other than local system on the selected computers.

In order to re-assign user rights and permissions set to the objects, update local group membership, and change service and scheduled tasks’ accounts, distributed resources must be updated. You can do this in either of two ways:

• Interactively, by using Agent Manager. In this case the updating agent is installed on each computer selected for processing and controlled from Agent Manager remotely.

• Locally, by using the command-line updating tool Vmover.exe and INI files. You can run the update on a computer directly, from a command line, or via a user logon script.

The following items can be updated:

• Local group membership

• User rights

• Services


20

• Scheduled tasks

• Registry

• Local profiles

• Roaming profiles

• Shares

• Printers

• File system

• IIS

• DCOM

• COM+

We strongly recommend selecting the “Leave source accounts’ permissions” option when updating the resources. This ensures that source users will still be able to access the resources after they have been processed. Then if you need to roll back and use your source accounts again, rollback will be immediate and therefore have no impact on source users. The permissions for these legacy accounts can be cleaned up after the migration is over (see Step 8 below).

Here are the factors to keep in mind when doing the resource updating:

• The more objects the computer has (in most cases, this means the more files and folders), the longer it will take to process it. Thus, it takes much longer to process a file server than a workstation.

• Updating NTFS permissions requires a lot of disk access (I/O operations) and may slow the server for a period of time.

• Each computer in a set is processed by its own agent. Thus, all the computers are processed in parallel and it takes approximately the same time to process a dozen of workstations as a thousand.

• Agent Manager will not let you reconfigure a set of computers until all of them are processed. Thus, you will not be able to add other computers and start their processing until the previous session is done.

• Expect about 10% (depending on the environment) of your workstations to require troubleshooting because they are offline, the Server service is not running, the domain administrators were removed from the local Administrators group, etc.

Accordingly, it is recommended that you create separate lists for end-user workstations and servers and process workstations first and then servers.


21

You may also want to perform server processing during non-business hours, such as late at night, to ensure that no users are affected by a possible server slowdown.

To create computer lists, you can use the CEnum utility from the Domain Migration Wizard Resource Kit. This utility creates a list of computers in a specified domain using the computer password age criterion. By default, all computers reset their passwords every 7 days, so computers with a large value for the password age have probably not been used for a long time.

This utility is helpful in two ways:

1. It creates the list of computers from the PDC, and therefore it will not be affected if there are problems with the Computer Browser service or WINS.

2. It helps you identify computer accounts that can be removed from your NT directory and do not need to be migrated.

The PDC’s password age never expires, so its password age may be greater than the threshold you specify.

Running the CEnum utility using the following command returns a list of computers with password age less than or equal to 45 days:

CEnum -d -s 45 DC_Name > list.txt

where the DC_Name is the name of the domain controller you want to get the computer list from.

Refer to the Domain Migration Wizard Resource Kit documentation for more details.

You can also create two different lists based on the “Computer Roles—Servers Only” and “Computer Roles—Workstations Only” reports from Quest Reporter to distinguish end-user workstations and server accounts and use them in Agent Manager.


22

Resource Updating Requirements

Administrative Rights

Administrative rights over the resources are required for successful resource updating. To obtain administrative rights you can:

• Add the account you are currently logged on to the console to the local Administrators group on each computer to be updated.

By default, the Domain Admins group of the domain the computer is a member of is a member of a computer’s local Administrators group. You will get administrative access to the computer if the account you are using is a member of the source Domain Admins group.

• Use another account that is a member of a computer’s local Administrators group to connect to the computer. Establish the connection to the machine’s administrative share using a standard ‘net use’ command, for example:

net use \\MachineName\Admin$ /u:DomainName\Admin_Account net use \\MachineName\C$ /u:DomainName\Admin_Account

You can also create a Connect.cmd file from Agent Manager that will contain a list of resources and credentials to be used for connection to each resource. Standard ‘net use’ command syntax is used in this file as well. It must be run each time before you start the resource updating to ensure that you have administrative access to the resources.

The “Administrator Access by Computer” report helps you check local Administrators group membership on each computer to be updated.


23

Server Service

Server service must be running on a computer in order for it to be updated from Agent Manager. If for some reason (for example, due to your corporate policy) it is not allowed to have Server service running on the computers, Agent Manager will not be able to install the agent on these machines and you will need to update them locally using the command-line updating tool.

The command-line updating tool VMover.exe is located in the Domain Migration Wizard installation folder. The update can be performed directly from the command-line interface or via a logon script. To perform the updates, VMover retrieves the source-target account pairs from the INI file. This file can be created by clicking Export INI File on the File menu of Domain Migration Wizard Project Manager. It will contain all the options you select in the Export INI File dialog box and a list of the accounts which were selected in Project Manager when the file was created. When using the INI file, VMover will perform the updates for the selected accounts. We recommend you select all user accounts and groups listed in Domain Migration Wizard Project Manager and all options listed in Export INI File dialog box at once.

Refer to the “Command-line Resource Updating” section of the Domain Migration Wizard User’s Guide for more details.

Resource Updating Scenarios

Centralized Resource Updating

To update the distributed resources centrally, follow these steps:

1. In Domain Migration Wizard Project Manager, select the accounts you want to update the resources for. Our recommendation is to select all user accounts and groups listed in Domain Migration Wizard Project Manager at once.

2. From Domain Migration Wizard Project Manager, start Domain Migration Wizard Agent Manager

3. Add resources (workstations or servers) to the Domain Migration Wizard Agent Manager Computer list. We recommend adding all workstations or all servers to be processed at once using import lists.

4. Obtain administrative rights over the resources.

5. Select the items you want to update permissions for. Our recommendation is to select and update all items at once.

6. Start resource updating.

7. To view the progress of an individual server or workstation, right-click it and select “View Progress.”


24

Delegated Resource Updating

Delegated resource updating is performed by delegated administrators using the INI files received from the Active Directory administrator.

The Active Directory administrator has to prepare the INI files by taking the following steps:

1. In Domain Migration Wizard Project Manager, select the accounts whose resources need to be updated. We recommend selecting all accounts that have been migrated.

2. From Domain Migration Wizard Project Manager, run the Export INI file command.

3. Make sure that the “Reassign local group membership, user rights and object permissions to Target users” option and the “Leave source accounts’ permissions” checkbox are selected.

4. Select the items to be updated. We recommend selecting and processing all items at once.

5. Leave the default path and filename: %ProgramFiles%\Quest Software\ Domain Migration Wizard\VMover.in_. It is recommended that you use the compressed format for INI files by selecting the “Create compressed” checkbox because the files are sent across the network during distributed resource updating.

6. Click OK. This creates a file, VMover.in_, that contains matching information for the source and target objects and information about which items should be updated.

7. Send the VMover.in_ file to each person who will perform the local resource updating.

Local administrators then do the following:

1. Put the Vmover.in_ file into the %ProgramFiles%\Quest Software\Domain Migration Wizard folder.

2. From the Windows Start menu, run Agent Manager. 3. Add resources (workstations or servers) to Agent Manager

Computer list. We recommend adding all workstations or all servers to be processed at once using import lists.

4. Obtain administrative rights over the local resources. 5. Start resource updating.

Only distributed resources and Exchange 5.5/2000/2003 servers can be updated via INI files. To update SQL and SMS servers, Domain Migration Wizard session files (SSN) are required.

When you start the Agent Manager from the Start Menu, you can process the resources only by using the INI file.


25

Updating User Profiles

User profiles get updated when you run distributed resource updating from Agent Manager. After processing, the profiles are shared between the source and target user accounts. As a result, target users will use the same profiles as the corresponding source users do.

You can use the ExportProfile utility from the Domain Migration Wizard Resource Kit to associate the current source user's profile with his or her future (migrated) account. However, this does not grant the new account the permissions needed to use the profile. This has to be done by running distributed resource updating. Refer to Domain Migration Wizard Resource Kit documentation for more details on the ExportProfile utility.

A user profile consists of two parts: the key in system registry and the folder on a hard disk that contains user-specific data, desktop settings, and a registry hive stored in NTUSER.DAT file. Depending on where user data is stored (on a local hard disk or server), user profiles can either be local or roaming.

When a user configured with a roaming profile logs on to a workstation for the first time, a local copy of the roaming profile is created on the workstation. NTUSER.DAT is copied from the roaming profile folder to the corresponding local one as well.

The updating process is slightly different for local and roaming profiles and depends on the version of Domain Migration Wizard you use.

• Domain Migration Wizard version 6.1: When you run distributed resource updating from Agent Manager, profile folders and registry keys for both local and roaming profiles get updated when you select both Local profiles and Roaming Profiles options. No additional steps are required.

• Domain Migration Wizard versions prior to 6.1: When you run distributed resource updating from Agent Manager, only local copies of profile folders and registry keys for both local and roaming profiles get updated. However, additional steps are required to update roaming profile folders.


26

Additional Steps for Updating Roaming User Profiles Folders

The procedure listed in this section is required if you run Domain Migration Wizard version prior to 6.1 only.

If users have been configured with roaming profiles, after processing the local copies of profile folders and registry keys with Agent Manager, take the following additional steps to update the ACLs stored inside NTUSER.DAT file in each roaming profile folder:

1. Make sure that the user accounts you want to update the profiles for are selected in Domain Migration Wizard Project Manager.

2. From the File menu, run the Export INI file.

3. Make sure that the “Reassign local group membership, user rights and object permissions to Target users” option and the “Leave source accounts’ permissions” checkbox are selected.

4. Type the INI file name and path.

5. Click OK. This will create an INI file in the folder you specified.

6. Copy Vmover.exe and the INI file to the server where the roaming profiles are stored. Vmover.exe is located in the %ProgramFiles%\Quest Software\Domain Migration Wizard folder by default.

7. On the server where the roaming profiles are stored, create and run the following batch file:

@FOR /d %%i IN ("AllProfiles_Path\*") DO vmover.exe /c /roaming="%%~fi"

where AllProfiles_Path can be either the UNC or the local path to the folder where user profiles are stored. For example: D:\Profiles, \\ServerName\Profiles. Note that the FOR command in the example above searches only for ntuser.dat in the first-level subfolders of the ALLProfiles_Path folder.


27

Enabling the “Cross-Forest User Policy and Roaming User Profiles” Policy

If the server where roaming user profiles are stored is running Windows 2000 SP4 or higher, you should enable the Allow Cross-Forest User Policy and Roaming User Profiles policy to allow users from trusted domains to use roaming profiles on that server. You can configure this policy either locally on the server or by using a domain or organizational unit-based Group Policy object (GPO). To do this locally on a server:

1. Log on to the computer as a user with administrator rights.

2. Click Start, click Run, type gpedit.msc, and then click OK.

3. Double-click Computer Configuration, double-click Administrative Templates, double-click System, and then click Group Policy.

4. In the right pane, double-click Allow Cross-Forest User Policy and Roaming User Profiles.

5. Click Enabled, click Apply, and then click OK.

6. Quit the Group Policy tool.

7. Allow sufficient time for the computer policy to be automatically updated, or update it yourself by running the following command in the command line:

secedit /refreshpolicy machine_policy

In Windows 2003, use the gpupdate command.

Refer to Microsoft Knowledge Base article 823862 for more details on user policies:

http://support.microsoft.com/default.aspx?scid=kb;en-us;823862

http://support.microsoft.com/default.aspx?scid=kb;en-us;823862


28

Resource Updating Troubleshooting

Workstations

After you run the updating session, some computers you specified may not be successfully updated. The computer may be turned off or inaccessible by the network from your location (network connectivity problems), or you may not have enough rights to connect to it, and so on. Domain Migration Wizard Agent Manager allows you to sort computer objects by last error status. If a computer was processed successfully, the last error field is empty and the computer can be removed from the list. Otherwise, you will see error descriptions. The typical errors are:

• Access is denied—You get this error when you do not have administrative rights over the server or workstation. Refer to the Resource Updating Requirements section above.

• The network path was not found—Probably, either the computer is turned off; it cannot be accessed by network from your location due to network connectivity problems; it cannot be found by name (NetBIOS computer name cannot be resolved into the address due to DNS/WINS issues); no computer with that name exists; or it is a laptop computer whose owner is currently out of the office. You need to diagnose each situation separately. Use the ping <ComputerName>, ping <Computer_IP_Address> and nslookup commands to determine whether you have a name-resolution problem or whether the computer is turned off and cannot be accessed by the network from your location.

• The Server service is not started—Start the Server service and try to process the computer once again or follow the command-line updating procedure to update the computer locally.

Servers

We recommend you update servers during non-business hours to ensure that end-users will not be affected by possible decrease of server performance.

After adding servers to the Agent Manager and starting the updating, wait for all computers to finish even if some have errors. Once the processing is finished, use the sort feature on the column headings to sort computers by problem, fix the problems, and start the updating once again for only those computers.


29

Step 3. Move Distributed Resources to the Target Domains

We recommend you to move end-user workstations to the target domain first after they have been processed and then move the servers.

Move End-user Workstations to the Target Domain

This step makes up the user switch. After a computer is moved to the target domain using Domain Migration Wizard, the default logon domain name is changed to the target domain name, so the user logs on to the target domain and starts working with the target account.

You should always make sure that user profiles were processed prior to moving their workstations to the target domain. If you selected the “Change default logon name” option when moving computer accounts, the default logon name will be changed to the target domain name on each computer that has been moved. If user names were not changed during the migration, most probably users will not notice the change and log on to the target domain. If their profiles were not updated yet, they will get brand new profiles.

The ChangeProfile utility from the Domain Migration Wizard Resource Kit associates the profile of users currently being migrated with their previous (source) accounts. It can help to link a target user account to the old profile. Refer to the Domain Migration Wizard Resource Kit documentation for more details.

Move Servers to the Target Domain

Next, move file and print servers and servers running scheduled tasks using Agent Manager.

For procedures for moving servers running IIS and other applications and services, refer to the product’s documentation. Be sure to test these procedures first in your test environment.


30

Step 4. Process BackOffice Servers

Microsoft BackOffice includes SQL, Exchange, and SMS server products. To update BackOffice server permissions for the target accounts, use the following Domain Migration Wizard wizards:

BACKOFFICE SERVER

WIZARD DESCRIPTION

Exchange 5.5 Exchange 5.5 Processing Wizard

Updates Exchange permissions to grant the migrated accounts in the target domain the permissions assigned to the source accounts.

Makes the target account the Primary Windows NT account on the 5.5 mailboxes and adds the source account to the permissions as an administrator.

Updates permissions on public folders and handles administrative and directory permissions on mailboxes and all other Exchange 5.5 objects.

Exchange 2000/ 2003

Exchange 2000 Processing Wizard

Updates client and administrative permissions on mailboxes, public folders, and all other Exchange 2000 objects.

SQL (6.5, 7.0, 2000)

SQL Processing Wizard

Automatically detects the SQL Server version (versions 7.0 and 2000 are supported) and performs the updates accordingly.

SMS servers (2.0) SMS Processing Wizard

Updates Microsoft Systems Management Server 2.0 permissions to reflect the migration.

Centralized BackOffice Server Updating

If you want to update BackOffice servers from a central location, the wizards listed above must be started from Domain Migration Wizard Project Manager, as described for distributed resource updating in Step 2.


31

Delegated BackOffice Server Updating

Only Exchange 5.5/2000/2003 servers can be updated via INI files. To do that, start the Exchange 5.5 and Exchange 2000 Processing Wizards from the Windows Start menu. Refer to the Domain Migration Wizard User’s Guide for more details.

To update SQL and SMS servers, Domain Migration Wizard session files (SSN) are required. To delegate SQL and SMS server updating to another person in a remote site, the SSN files must be sent to that person, who should put them in the Domain Migration Wizard project folder on the local console and then process the SQL and SMS servers as in the centralized updating scenario.

Step 5. Move BackOffice Servers to the Target Domain

Microsoft BackOffice includes SQL, Exchange, and SMS server products. The recommendations for them are different:

SQL Servers

SQL servers can be moved to the target domain easily after they have been processed. You can do this manually or from Agent Manager.

Exchange Servers

Instead of moving Exchange 5.5 servers to the target environment, we recommend using Exchange Migration Wizard to migrate Exchange 5.5 to Exchange 2000/2003 after the account migration from NT to Active Directory is completed. For more details on Exchange migration scenarios, refer to the Exchange Migration Wizard User’s Guide.

SMS Servers

Due to SMS implementation complexity, we recommend you re-deploy SMS in the target environment instead of moving the SMS servers.

If you do choose to move your BackOffice servers to another domain, refer to the procedures described in the Microsoft BackOffice documentation and Microsoft Knowledgebase for more information.


32

Step 6. Disable Source Accounts

It is good practice to disable source accounts at this stage and thus make sure that all users are logging on with their target accounts. We recommend that you wait some time to make sure that all users are already using their target accounts.

Bulk Disable and Enable operations can be done from Domain Migration Wizard Project Manager.

Step 7. Clean Up SIDHistory Attributes

After the distributed resources and BackOffice servers have been processed, we recommend you wait some time to ensure that everything is working right before cleaning up SIDHistory attributes from the target user accounts.

SIDHistory cleanup is done by Directory Processing Wizard, which is also started from Domain Migration Wizard Project Manager. If after SIDHistory cleanup some users cannot access the resources, SIDHistory can be re-applied back to the accounts that lost access. This will give you time to check whether the resources were processed correctly for these accounts, fix the problem, and clean up SIDHistory again.

After SIDHistory is cleaned up, wait some time to ensure that all target users can access the resources they used before the migration.

Step 8. Clean Up Legacy Account Permissions

Cleanup of legacy account permissions is performed by the same wizards used to update resources.

Cleanup is hard to undo, so it is recommended that you clean up permissions only when you are sure that all users are using their target accounts for all applications and have no problems accessing resources.


33

Step 9. Demote or Decommission Legacy Domain Controllers

This is the latest step of the migration process. If all previous steps were successfully done, you can switch off your Windows NT domain controllers.

Do not switch off or demote your source domain controllers if there are servers (Exchange, SQL, or other servers running specific applications and services) that are still members of the source domain. Perform decommissioning only when you are sure that there are no member servers or workstations currently accessed by users left in the source domain.

You can re-use the hardware freed up by source domain controller decommissioning. Domain Migration Wizard Resource Kit’s DCDemote utility makes it possible to demote a Windows NT domain controller to a stand-alone or member server without an OS reinstall.

Rollback

Domain Migration Wizard does not make changes to the source environment. During the account migration phase, it just reads data from source and applies it to target. That means that until you disable source accounts, if migration issues arise, users can log in back to source. We recommend that you keep source accounts for a period of time after the migration is finished.

Domain Migration Wizard is designed so you can roll back any changes made to the environment at any step of the migration process:

Return to the Source Accounts

The easiest way to roll back is to start using source accounts again. You can start using source accounts at any stage of the migration process as long as you leave the source accounts’ permissions while processing the resources.


34

Session Undo

You can also undo the corresponding session in Domain Migration Wizard Project Manager to roll back the account migration. This will delete the accounts created by the session on target. Merged accounts will be returned to the states they had before the migration.

When you undo a session from Domain Migration Wizard Project Manager, all migrated accounts are removed from Active Directory. But if you have already re-assigned permissions on the resources to the target accounts (that is, performed steps 2 and 4 described above in the Migration Steps section), each resource’s ACL after the session undo will contain unresolved SIDs of the deleted objects. Therefore, you should always return the target environment to its original state by performing a permissions revert before doing a Domain Migration Wizard session rollback.

Permissions Revert

Permissions revert is done by the same wizards that were used to re-assign permissions to the target accounts.

Although it is possible to use Exchange System Manager to install Quest Archive Manager on all nodes after the first installation, you must not do this. Only a local installation will complete properly.

Restore from Backup

If changes were made to the source environment that cannot be undone, use standard procedures to restore from backup. That’s why it is recommended that source and target environments be backed up with standard backup procedures. Ensure that you have the latest valid backup of your servers in both source and target.

We also encourage using Quest Recovery Manager for Active Directory during all migration and post-migration activities to back up Active Directory. This allows online granular restoration of objects down to the attribute level without a DC reboot if they are accidentally deleted or corrupted.


35

Conclusion Migration to Active Directory is a monumental task. This is especially true for large distributed and complex environments. It is essential that a solid discovery and analysis be completed on the entire enterprise prior to migration. All testing should be performed in an environment that mirrors the production environment as exactly as possible.

To make migration easier, first migrate to Active Directory, then ensure Active Directory is stabilized, and then go forward with the migration from Exchange 5.5 to Exchange 2000/2003.

Although no two projects are exactly the same, this document outlines some of the key factors for ensuring a successful migration to Active Directory.

best practices for nt to active directory migration

Documents