Using MSDSS to Support Migration

Updated: September 15, 2010

Applies To: Windows Server 2008 R2

When you have an existing Novell NetWare–based network, you can use the MSDSS directory synchronization and object migration utility and the related File Migration Utility in several ways. You can migrate a legacy NetWare environment to the Windows Server 2008 R2 platform, replacing the NDS or Bindery directory with the Windows Server 2008 R2 Active Directory and migrating files and file access permissions.

Alternatively, in larger or more complex network environments, you can (temporarily or for the long term) maintain NDS or Bindery at the same time that you introduce and take advantage of Active Directory functionality. Do this by using one-way (for either Bindery or NDS) or two-way (for NDS only) directory synchronization to establish interoperability between the directory services. Both types of synchronization make it possible for you to continue to use existing directory-enabled services and applications. The following bullet points summarize these options:

• Immediate (Direct) migration

  You can use MSDSS to perform a quick, one-time migration of NDS or Bindery objects and files to Active Directory. See the User and Group Object Migration and File and File Access Rights Migration sections of this article for more information.

• Synchronization

  MSDSS provides a variety of options for managing synchronization as part of a migration strategy, including:

  • One-way synchronization

    This option makes it possible for you to manage objects in both directories from Active Directory.

  • Two-way synchronization

    This option makes it possible for you to manage shared data, such as user account information, from either directory.

  • Staged (Phased) migration

    You can use MSDSS to implement synchronization as a temporary strategy, which makes it possible for you to access either directory while you perform the full migration in convenient stages. By gradually moving from a Novell directory to an Active Directory–based network, you can minimize disruption to your users.

The “Synchronization” section of this article explains each of the synchronization options noted earlier, but it primarily focuses on using synchronization to support full migrations. The strategy that you choose depends on the size, complexity, current infrastructure, and goals of your organization. Whichever migration or synchronization option you implement initially, you can easily change to a different configuration to adapt to changing circumstances or goals.

Microsoft designed MSDSS to provide transparency for complicated tasks such as handling class definitions that vary between different directories and handling the particular communication protocols used by different directories. MSDSS uses Novell NetWare Client for Windows and supports all protocols that NetWare supports, including IPX/SPX and TCP/IP. File Migration Utility supports both the TCP/IP and the IPX/SPX transport protocols. Available MSDSS features differ depending on whether you are establishing directory interoperability between Active Directory and NDS or between Active Directory and Bindery.

Synchronization

Microsoft designed Windows Server 2008 R2 and Services for NetWare to support both ongoing mixed deployments and a complete conversion to the new operating system. With Services for NetWare, you can use MSDSS synchronization to establish a long-term or permanent coexistence between Active Directory and a Novell directory. When you establish a mixed environment, you can take advantage of many Active Directory features—such as its enhanced search functions, improved user management, and delegation capability—without converting the entire network to Windows Server 2008 R2. Therefore, using directory synchronization makes it possible for you to protect existing investments in hardware, NDS-dependent software, and organizational logistics.

If you are preparing to migrate to Active Directory and decommission NetWare, you can use synchronization to implement a temporary mixed network environment. See the Staged (Phased) Migration Requires Synchronization section of this article for more information.

By default, MSDSS synchronization duplicates the Bindery or NDS structure in Active Directory. Also like migration, synchronization maps Novell user, group, and distribution list objects to Active Directory user, group, and distribution list objects, and (for NDS only) it maps Novell OUs and organizations to Active Directory OUs. In addition, MSDSS synchronization optionally provides custom object mapping (for NDS only) that makes it possible for you to map objects in dissimilar directory structures to each other. For more information, see the “User and Group Object Migration” section of this article.

The following sections explain more about how MSDSS synchronizes the NetWare and Windows Server 2008 R2 directories.

One-Way Synchronization

As discussed earlier in this article, the easiest choice for some organizations is to preserve their existing investment by implementing directory interoperability rather than migrating all systems to Windows Server 2008 R2. MSDSS synchronization makes it possible for directories to coexist, which means that users can share and access information in either directory and continue to use existing directory-enabled services and applications.

However, directory coexistence comes at the cost of partially duplicated administration of separate directories. MSDSS one-way synchronization makes it possible for you to retain an existing NDS tree or Bindery while it helps simplify network management by letting you to perform object administration solely from Active Directory. In addition to helping you to eliminate most of the cost of managing two separate directories, one-way synchronization is the best solution when the long-term goal is to migrate. (You must still manage security administration and non-synchronized object administration, such as computer account objects, from each directory separately.)

Initial Reverse Synchronization

To configure synchronization between Active Directory and NDS or Active Directory and Bindery, first you perform an initial reverse synchronization, which is a one-time process that copies existing NDS or Bindery objects to the Active Directory database. To perform an initial reverse synchronization, you create an MSDSS session, specify the NDS container or Bindery server from which objects are copied, and then specify the Active Directory OU into which these NDS or Bindery objects are copied. Before you can perform this synchronization, you first must create a target Active Directory OU container.

Regular Forward Synchronization

After the initial reverse synchronization has taken place, you schedule MSDSS to perform forward synchronizations (from Active Directory to NDS or Bindery) on a regular basis. Forward synchronization queries Active Directory for any new objects or for changes to existing objects and ensures that these changes are propagated to NDS or Bindery. By default, forward synchronization occurs every 15 minutes. Alternatively, you can schedule synchronization to occur at another specified interval. For example, you can schedule a forward synchronization from the Accounting OU in Active Directory to the Acct OU in the NDS tree to occur at 30-minute intervals. Note that the target container “Acct” in this example has a different name than the source container “Accounting.” Although the OUs being synchronized could have the same name, the name given to the target OU does not have to be the same as the source.

After you have established one-way synchronization, any future changes that you make to NDS or Bindery are not synchronized to Active Directory. Therefore, if you chose one-way synchronization, you must make all future changes to user, group, distribution list, or OU objects in Active Directory, not in NDS or Bindery. If you chose to perform a one-way synchronization where you copy only part of the NDS tree or Bindery to Active Directory, then you must continue to use NetWare NDS or Bindery to manage directory objects that exist only in the NetWare directory.

One-way synchronization from Active Directory to Bindery or NDS requires no Bindery modification or schema changes to NDS.

Two-Way Synchronization

Some organizations that choose to implement directory interoperability need the ability to enter new data or modify existing data in either directory and have that directory then update its partner directory. For NDS-based networks, MSDSS two-way synchronization provides this functionality. Two-way synchronization enables you to propagate changes made to objects in either Active Directory or NDS to the other directory.

Initial Reverse Synchronization Followed by Forward and Reverse Synchronizations

You begin establishing two-way synchronization just as you would one-way synchronization: by using MSDSS to perform an initial reverse synchronization that duplicates NDS objects in Active Directory. You then establish a schedule for both forward synchronization from Active Directory to NDS and reverse synchronization from NDS to Active Directory. Reverse synchronization copies new or changed objects from NDS to Active Directory.

Unlike one-way synchronization, two-way synchronization does require extending the NDS schema. Extending the NDS schema is required to stamp a globally unique identifier (GUID) on those directory objects that are involved in synchronization. In Windows Server 2008 R2, Active Directory objects must have a GUID, which is a unique 128-bit number assigned as an attribute of the object.

If your strategy is long-term directory interoperability and coexistence, you might find two-way synchronization more convenient than one-way synchronization. However, the cost is that reverse synchronization requires additional server and network traffic overhead and requires duplicated administration.

One-Way vs. Two-Way Synchronization

Choose either one-way or two-way synchronization when you initially set up a synchronization session for a pair of containers. When you evaluate which configuration is best for the given circumstances, consider the following factors:

Staged (Phased) Migration Requires Synchronization

If your organization is complex and you want to migrate from a Bindery-based or NDS-based network to Windows Server 2008 R2 Active Directory–based network, a staged migration is typically the best choice. A staged migration entails running the two systems in parallel for a period. During this time, you can perform migration tasks that are independent of MSDSS object migration and File Migration Utility file migration, such as replacing programs that are dependent on Novell services with Active Directory–compatible programs.

Using MSDSS to synchronize the Windows and Novell directories during the changeover period makes the transition easier for both administrators and users. A phased migration reduces risk because you proceed in easily managed stages and can reverse the process easily if necessary. For many organizations, this advantage of reduced risk outweighs the costs in administrative effort and additional resources.

In a staged migration, you use MSDSS to copy all Bindery or NDS user accounts, groups, and distribution lists, and (for NDS only) OUs and organizations to Active Directory, while you maintain these objects—now synchronized with their Active Directory counterparts—in NDS or Bindery. Then, while you gradually move resources to the Windows Server 2008 R2–based environment, the MSDSS-provided directory synchronization allows users to continue to access those resources that remain on NetWare servers. As the changeover continues, users begin to access resources on servers running Windows Server 2008 R2.

If you plan to perform the migration within a relatively short time, one-way synchronization is the preferred configuration. If your organization is complex and the migration will take several months or longer, you might prefer two-way synchronization.

When you establish directory synchronization over an extended period, you can reduce migration impact costs. As the existing NetWare technologies age, you can replace them with the latest comparable Microsoft technologies. Larger, more complex environments usually involve longer transition periods than small environments require.

After you have moved all resources to Windows Server 2008 R2, converted all Novell services and applications to Active Directory–based counterparts, and moved object security permissions and objects that MSDSS does not migrate (such as computer accounts, printer objects, and application objects), synchronization of the two directory services is no longer necessary. This allows you to delete the synchronization sessions and decommission remaining NetWare servers.

For a detailed discussion of factors that you need to consider when you determine whether a phased migration or permanent mixed network synchronization is the appropriate strategy for your organization, see the IT Infrastructure Analysis section of this article.

Schema Extensions for Migration

The directory schema provides a description of what can be placed in the directory—that is, a description of its object classes (the various types of objects) and their associated attributes. For each class of object, the schema defines the attributes that the object class must have, the additional attributes that it might have, and the object class that can be its parent. Schema extensions are done only once and are irreversible.

Migration, one-way synchronization, and two-way synchronization all require extensions to the Active Directory schema. Two-way synchronization also requires extending NDS.

Active Directory Schema

MSDSS automatically updates the Active Directory schema during the setup process. The schema update is required only once for each Active Directory forest. If the user who is installing MSDSS does not have the necessary permissions to extend the schema, the schema can be updated manually. To manually update the schema, log on to the schema master in the Active Directory forest in which MSDSS is to be installed with the appropriate schema credentials, then open a Command Prompt and type:

msiexec /I Path \msdss.msi SCHEMAONLY=1

To support two-way synchronization, you must extend the NDS schema. If you are required to extend the NDS schema when you create a new session, the wizard prompts you. Extending the NDS schema requires the following:

• Installation of Novell NetWare Client for Windows (also required by MSDSS)

• Supervisor permission to access the root object of the NDS tree

• Access to the server that holds the master replica of the root partition (this server propagates the changes to all the servers in the NDS tree)

You can also extend the NDS schema manually by using the MSDSS command-line NDS schema extension tool NDSext.exe (available in the “%systemroot%\System32\Directory Synchronization\Client” folder). Use the following syntax:

ndsext extend TreenameUsername.Context Password

This command makes it possible for you to extend the NDS schema of a specified tree.

MSDSS Password Management

Passwords are encrypted and stored in different formats in the Windows and Novell operating system directories. Because MSDSS cannot retrieve the encrypted passwords that are stored in an NDS or Bindery directory, MSDSS creates new passwords for each user who is migrated to Active Directory or whose account is synchronized between Active Directory and NetWare.

You must have administrator privileges to the NDS or Bindery directory to be able to specify the password scheme that MSDSS uses. MSDSS handles the mapping of passwords between Active Directory and NDS or Bindery without compromising security by providing several options for creating new passwords. You can specify the following password options either when you create a new MSDSS session or by modifying existing session properties:

• Set passwords to blank

  Clears all passwords so that users logging on to Active Directory for the first time do not need to specify a password.

• Set passwords to the user name

  Sets passwords to the user name after migration or initial reverse synchronization has taken place. This is the default option.

• Set passwords to a random value

  Creates random passwords for each user who is migrated to or synchronized with Active Directory. The password assignments are listed in a log file. The default location of this log is in the “%systemroot%\System32\Directory Synchronization\Session Logs” folder. A text file with a .pwd extension is created for each session that uses this option.

• Set all passwords to the following value

  Provides an option to specify the password value for all users migrating to Active Directory or for all users whose accounts will be synchronized between Active Directory and NDS or Bindery.

For example, assume that you accept the default option: Set passwords to the user name. After users are copied from NDS or Bindery to Active Directory through initial reverse synchronization, they are each prompted to change their password the next time they log on. The new password is then synchronized with the password attribute in NDS or Bindery during the next scheduled forward synchronization—that is, the new password overwrites the existing NDS or Bindery password.

The preferred method is to control passwords from Active Directory (you can control passwords from Active Directory in both one-way and two-way synchronization). This requires that clients log on to Active Directory.