Chapter 4: Migrating - Prototyping the Migration to Windows Server 2003

  • Article
On This Page

Introduction and Goals Introduction and Goals
Validating Test Lab Components Validating Test Lab Components
Testing the Design and Migration Process Testing the Design and Migration Process

Introduction and Goals

The purpose of the Developing Phase (or Migrating Phase in this document) is to build, validate, and test the design and migration process in an isolated nonproduction environment. This phase is a critical step in an effective migration strategy, as the majority of problems can be uncovered when testing the migration process. It is much better to uncover issues in this phase than when they affect production users and business processes.

Major Tasks and Deliverables

The Developing Phase tasks that are relevant to migration projects are:

  • Testing the design and migration process

  • Resolving issues that are identified during the testing process

The content of this section provides the technical information needed to enable teams to accomplish these tasks. Refer to the UMPG for general project guidance on how team members and work processes should be organized to complete this phase.

Migrating Phase Major Milestone: Scope Complete

The phase formally ends with the Scope Complete Milestone. At this major milestone, the team gains formal approval from the sponsor and/or key stakeholders that all solution elements are built and the solution features and functionality are complete according to the functional specifications agreed upon during Planning.

Validating Test Lab Components

In the Planning Phase the lab was set up to include replicas of existing environment infrastructure such as NDS servers and files and Active Directory components per the information from the design. In the Migrating Phase, the lab is built up based upon both the existing environment and the new environment. When the complete lab has been established, the migration process can be tested.

Testing the Design and Migration Process

In the Planning Phase, the team developed a design, migration strategy, and a test plan. The Migrating Phase uses the parameters outlined the Test Plan to test and validate the design configuration and migration processes in the isolated test environment.

Validation testing should include the following steps:

  • Synchronize directory information by using MSDSS or Quest NDS Migrator.

  • Migrate files and file security on sample data by using the File Migration Utility or the Quest Tools.

  • Configure and test printing in the lab (create of new Printers in Active Directory to replace NetWare Print Queues)

  • Review and adjust your migration plans as appropriate based on the results of the test lab. It is expected that problems will arise in the test lab.

  • Repeat the test migration process to hone the process until you are comfortable with the results. This process leads into the next phase of the migration, the Stabilizing phase, where the process is perfected.

Design

Before you can test the migration process, you must first test the design by building the new infrastructure and configuring the environment to meet the design specifications.

Build New Windows Server 2003 Infrastructure

Regardless of whether you have chosen to build a new Active Directory from scratch or to do an in-place upgrade from an existing Windows NT 4 or 2000 environment, a set of new Windows 2003 servers and a new Active Directory forest must be deployed through the architectural design chosen during the Planning Phase. This forest will serve as the future host for the migrated NetWare resources.

Initially you should deploy only the hardware and operating system, and then create the Active Directory forest after the build process is complete. Use the procedures developed in the lab with the latest release of the operating system to build the Active Directory servers—domain controllers, file servers, and utility servers—and update the servers with all available critical updates.

Build or Migrate to Active Directory

After the servers have been deployed and updated, the Active Directory forest can be implemented according to the design. For environments that have never had a Windows domain, this is a nonimpactful process, as new Active Directory servers can be brought online in tandem with other servers. Because no one will be using the infrastructure initially, you will have more flexibility to make design modifications, restart servers, and perform initial pilot testing before the Active Directory domain components become part of the production infrastructure.

For environments which will be upgrading from an existing Windows NT 4.0 domain structure or Windows 2000 Active Directory forest, the process is more involved and potentially impactful to end users. This type of migration process should be carefully designed, documented, prototyped, piloted, and implemented on its own before it will be a fully developed Windows Server 2003 Active Directory environment. For more information on upgrading to Active Directory see Windows Server 2003 Deployment Kit: Designing and Deploying Directory and Security Services (https://www.microsoft.com/downloads/details.aspx?FamilyID=6CDE6EE7-5DF1-4394-92ED-2147C3A9EBBE&displaylang=en#filelist).

Direct Migration

Now that you have established the new platform, you can test the migration process to the new environment. The steps for the direct migration process are:

  1. Build new Windows 2003 Server infrastructure

  2. Build Active Directory

  3. Install MSDSS

  4. Migrate users, groups, and files

  5. Migrate printers

  6. Migrate workstations.

Phased Migration

Manual Migration

If your team selected a manual migration process during the Planning Phase, you have removed a certain degree of complexity from the process, because a manual approach does not migrate existing users, groups, and file permission structures.

Setting up a prototype using the manual migration process consists of the following key steps:

  • Identify the sample data that will be migrated. This may consist of a server or a single NetWare volume.

  • Create test users and necessary accounts.

  • Create equivalent users and groups in Active Directory to match the old Users and Groups in NetWare.

  • Migrate a specific set of File data from NetWare file servers to Active Directory file servers, using simple copy techniques.

  • Apply NTFS security to the migrated data, either manually or with a utility such as XCACLS, which will allow for a scripted application of file permissions.

  • Migrate client functionality for the test users, either through a manual removal of the Client32 software, or a modification of the existing login scripts to map the migrated volume or server to its new location in Active Directory. In addition, the clients must be configured to login using their new Active Directory user names.

Automated Migration by Using Services for NetWare 5.03

If your organization chooses or requires an automated approach, the Microsoft Services for NetWare 5.03 (SfN) or the Quest NDS Migrator tools can be helpful. There are several key concepts that are similar in the way that both tools work, and it is important to understand how to deploy and use them.

Note: When deploying SfN on Small Business Server (SBS 2003), you need to stop Exchange services before installing SfN or it will fail.

Set Up Directory Synchronization

After deploying Microsoft Services for NetWare 5.03 on the appropriate server in accordance with the design specifications, Microsoft Directory Synchronization Service (MSDSS) can be used to set up directory replication between Active Directory and NDS/Bindery as well as prepare for file migration.

MSDSS requires the use of Novell Client for Windows. If you performed a clean installation the Windows Server 2003 operating system, you must download and install Novell Client for Windows before you install Services for NetWare 5.03. In addition, the user account that runs the install process must have Schema Admin rights to the forest, as the MSDSS install process will extend the AD schema.

To install MSDSS:

  1. In My Computer, right-click the drive where the Services for NetWare CD-ROM is located, click Explore, and then double-click the MSDSS folder.

  2. In the details pane, double-click msdss.msi. (You need to have Schema Admin rights to the Active Directory forest to install the product.)

Note: To manage MSDSS after you have installed it, open Administrative Tools, and then click Directory Synchronization.

The next step is to create sessions for each Novell Organizational Unit (OU) that is to be migrated or synchronized. In addition to selecting the appropriate OUs in each directory for the session, you must select the migration type (NDS or Bindery) of the session.

After the sessions are defined according to the design criteria, you can schedule regular updates for the appropriate directories. At this time, you can perform an initial manual synchronization as well. It is highly recommended that you set up all objects to be synchronized between NetWare and Active Directory from the moment of the Pilot setup, through the implementation, and all the way to the end of the project, as this will ensure that all changes that are made to both directories are reflected in both places.

To set up an MSDSS Synchronization session, perform the following tasks on the server where MSDSS was installed:

  1. In Administrative Tools, click Directory Synchronization.

  2. In the console tree, right-click MSDSS, and then start the New Session Wizard.

  3. Choose whether objects will be copied from NDS or Bindery.

  4. Select the Migration (from NDS or Bindery to Active Directory) task.

    If files will be migrated with directory objects, you need to select the Migrate Files check box. This will create the file migration log that is required by File Migration Utility.

  5. On the Active Directory Container and Domain Controller page, type the path to the Active Directory container in which you want to copy items, or browse to it.

    Type the path, using the syntax in the following example:

    LDAP://OU=Sales,DC=Server1,DC=Wingtip,DC=com

    All subcontainers in the selected containers will be copied.

  6. Under Domain Controller, accept the default domain controller in which you want to store the migration log, or click Find to locate a different domain controller.

  7. On the NDS Container and Password or Bindery Container and Password page, type the appropriate NDS or Bindery syntax as indicated, or browse to the container or server:

    NDS://Tree1/O=Wingtip/OU=Sales

    NWCOMPAT://Server

  8. Type the administrative account and the password for that account.

    You must type the NDS administrative account by using the full NDS context, such as "Admin.wingtip". Do not include the NDS tree name.

  9. On the Initial Reverse Synchronization page, click Password Options, and then choose one of the following password schemes:

    • Set passwords to blank

    • Set passwords to the user name

    • Set passwords to a random value

    • Set all passwords to the following value

    If you do not select a scheme, the default scheme (Set passwords to the user name) is applied.

Migrate Sample Data with the File Migration Utility (FMU)

In addition to performing the migration of users and groups, MSDSS also creates a file migration log which is then used by the File Migration Utility for migrating files. The users and groups that you create in Active Directory using MSDSS are then used to apply security to the data that is migrated with the FMU tool.

As part of the prototype, a sample set of data must be migrated from NetWare to the new Windows Server 2003 File servers. This sample set of data can consist of the data from a single NetWare server or a single volume of NetWare data from the server. The data should then be migrated by using the File Migration Utility, which will preserve the file security structure from the NetWare side and recreate it using the users and groups that were synchronized with the MSDSS tool.

To set up a File Migration Utility session to migrate the sample data, perform the following high-level steps on the server where FMU is installed:

  1. Start the File Migration Utility (Start, All Programs, Administrative Tools, File Migration Utility)

  2. Browse for the migration log that was created by using MSDSS with the Migration option selected.

  3. Click Load Data.

  4. Verify the Security Accounts.

  5. Select the source volume and target location.

  6. Enable logging.

  7. Click Scan to check whether the target source and roots are valid.

  8. On the last screen, click Migrate. The logs will be displayed as the file data and permissions are migrated.

Automated Migration by Using Quest

The Quest NDS Migrator tools allow for the same type of directory synchronization and file and security migration as the Services for NetWare tools. In addition, Quest has included advanced logging, more migration options, and additional flexibility to perform phased migrations. It is recommended that you test both sets of tools to determine which set is the best fit for your organization.

Installing Quest NDS Migrator

Before you install Quest NDS Migrator, make sure that your environment meets the hardware and software requirements as outlined in the Quest NDS Migrator - Quick Start Guide or the Quest NDS Migrator - User's Guide. These documents can be downloaded from https://www.microsoft.com/windowsserver2003/migrate/novell/default.mspx

  1. Download Quest NDS Migrator from https://www.microsoft.com/windowsserver2003/migrate/novell/default.mspx

  2. Install Quest NDS Migrator by double-clicking NDS Migrator Setup.msi. This will lead you through the installation process.

For more information on installing Quest NDS Migrator please see the Quest NDS Migrator - Quick Start Guide or the Quest NDS Migrator - User's Guide.

Using Quest NDS Migrator

The steps for migrating are as follows:

  1. Set up a new project (establish the project name and set the project options). Project options include:

    • User options

    • Group options

    • Access rights mapping options

    • Conflict rules

    • Script options

    • Object migration options

    • File migration options

    See the Quest NDS Migrator User’s Guide for detailed information on configuring the project options.

  2. Map objects from NDS to Active Directory using the Migration Guide.

  3. Detect Intra-NDS name conflicts.

  4. Detect NDS to Active Directory collisions. Quest NDS Migrator can determine if accounts that are to be migrated will collide with an Active Directory account.

  5. Migrate objects.

Note: The steps to migrate from a pure Novell environment versus a mixed Novell and Windows environment are the same. However, configuration settings will differ. See the Quest NDS Migrator User's Guide for configuration settings.

Password Synchronization

After the test users have been migrated, their passwords need to be synchronized from NDS to Active Directory. During the installation of Quest NDS Migrator, one of the options was to install the Password Synchronization Kit. The Password Synchronization Kit is a Web page where users will be able to supply their Novell logon and password. If the information is correct and they have been selected to have their password synchronized, their password will be updated in Active Directory. Please refer to the Quest NDS Migrator User’s Guide for more information on installing the Password Synchronization Kit. To prepare the Password Synchronization Kit, the migration data must be imported per the instructions in the Quest NDS Migrator User's Guide.

File Migration

Now you are ready to migrate file and folder data to the target environment.

The high-level steps to perform the file migration using the NDS Migrator are as follows:

  1. Establish volume mappings.

  2. Set the Files Migration Options.

  3. Migrate files.

  4. Check logs for file migration errors.

  5. Resolve migration errors.

Printer Migration

A printer “Migration,” between NetWare and Windows Server 2003, is more of a manual process than a migration. The process involves recreating printers in Active Directory to correspond to the old NetWare Print Queues. When setting up these printer objects, take into account these important factors:

  • Printers must be physically checked to ensure that they can be printed to using protocols other than IPX (Ideally TCP/IP). While it is possible to enable IPX/SPX support on Windows servers, it should be avoided. This may involve retiring older printers or loading new firmware onto existing printers.

  • There are significant driver differences between NetWare and Windows print queues. It is important to download and install the latest drivers from the printer OEM.

  • The clients must be redirected to the new printers in Active Directory either through login scripts or Group Policy Objects in Active Directory.

  • Printers which were manually set up in workstation profiles must be reconfigured to point to the new Windows locations.