Updated: September 15, 2010

Applies To: Windows Server 2008 R2

Planning is one of the most important functions you can fulfill as a technical professional. The first step in planning how to use MSDSS with an NDS-based or Bindery-based network is to gain an understanding of what migration is and how you can use MSDSS to implement it. The first sections of this document provide an overview of MSDSS, list important MSDSS concepts, and describe common scenarios in which MSDSS is useful. Later sections include step-by-step guides for installing Novell Client for Windows®, using MSDSS, and migrating accounts, groups, files and their associated directories and permissions.

NetWare 4.x, 5.x, and 6.x Environments

Migrating NDS, the directory service included with NetWare versions 4.x, 5.x, and 6.x, requires more planning than a Bindery migration does. You can map the NDS hierarchical directory namespace to the namespace used in Windows Server 2008 R2 Active Directory. However, in most circumstances, the optimum Active Directory namespace is not the namespace used by NDS. This disjointed mapping is due to differences between the basic methods of partitioning and replication.

NDS namespace mappings that are similar to an optimal Active Directory namespace might occur if a geographic namespace model is used for Active Directory. It is common for NDS implementations to follow this model to accommodate partitioning at the organizational unit (OU) level.

Active Directory and NDS provide a certain level of interoperability due to a common implementation of standards. However, namespace management is not the only network standard that is handled differently by NDS and Active Directory. Keep the following similarities and differences in mind when you plan a migration:

  • Replication

    NDS and Active Directory both provide replication services for the directory within each partition.

  • DNS

    NDS provides support for basic Domain Name System (DNS) services while Windows Server 2008 R2 DNS provides enhanced DNS services, including dynamic updates. The Windows Server 2008 R2 DNS offering is extremely robust and provides greater unification of name services and Windows® operating system service offerings.

  • DHCP

    The primary difference between NetWare and Windows Server 2008 R2 Dynamic Host Configuration Protocol (DHCP) relates to their integration with the DNS dynamic update protocol. However, both DNS services are capable of interoperating through standard zone transfers.

  • LDAP Services

    Both NDS and Active Directory support Lightweight Directory Access Protocol (LDAP) version 3. With a few exceptions, the implementations are interoperable even though not all NDS services are made available through LDAP.

  • Internet Services

    From a high level, both NetWare and Windows Server 2008 R2 provide similar Internet services, such as Web services. The specific implementations vary significantly and you should take great care when you swap Web servers. NetWare assumes a Java-oriented platform, and Windows Server 2008 R2 focuses on the Microsoft® .NET Framework.

  • Authentication

    NetWare and Windows Server 2008 R2 use completely different methods and protocols for authenticating client computers. Windows Server 2008 R2 uses Kerberos authentication over IP only. NDS authenticates using NetWare Core Protocol over either IP (for NetWare 5.x and later versions) or more commonly IPX.

  • Network Security

    From a high level, NetWare 5.x and NetWare 6.X versions provide a set of network services that is similar to Active Directory. These include support for Secure Sockets Layer (SSL), X.509 digital certificates, and security policies. If strategic interoperability is desired, you should focus on the use of SSL and public key infrastructure (PKI) to ensure a good level of interoperability. Both NetWare and Windows Server 2008 R2 support many similar security policies such as account lockout, access control, and password policies.

With a few exceptions, do not attempt to make a direct correlation between NDS partitions (which are disassociated with namespace) and partitions in Active Directory that map to DNS domains and namespace.

With the help of the utilities included with Services for NetWare, you can migrate NDS to Active Directory with little difficulty. However, some environments might benefit from using third-party utilities to perform advanced migration tasks or migrating object types other than users, OUs, and groups. These topics are addressed later in this document.

User and Group Object Migration

If you do not want to maintain multiple network operating system directories, the best choice is to use MSDSS to help convert quickly to a Windows Server 2008 R2 environment. MSDSS migration makes it possible for you to move directory objects to the Windows Server 2008 R2 platform.

If you have not deployed complex NDS-dependent applications, a quick, complete, one-time migration is often the best choice. Immediate migration is also feasible if you are setting up a large number of new computers or you have an older Bindery or NDS network and need to move to a more sophisticated operating system. For example, environments that only provide limited services such as account information and file and print services are relatively simple migration projects.

If your organization has a complex hardware and software environment, choosing to make the transition from Bindery or NDS to Active Directory could require a migration that proceeds in stages, running both systems concurrently for an extended period. This option is described in the Staged (Phased) Migration Requires Synchronization section of this document.

MSDSS is designed to migrate those directory objects that typically store the largest amount of information and the most important information. An immediate, one-time migration moves these Bindery or NDS objects to Active Directory, specifically: user accounts, groups, and distribution lists (for both Bindery and NDS), and (for NDS only) OUs. Detailed instructions for migration steps are provided later in this document. Keep in mind that object classes other than accounts, groups, OUs, files, and directories must be manually migrated. Objects that must be manually migrated include: computer accounts, printer objects, and application objects. You must also manually migrate security permissions for objects that you manually migrate.


Because Active Directory does not support a container equivalent to the NDS organization, this document sometimes uses the term “container” to refer generally to NDS OUs and organizations.

You can use third-party utilities to migrate directory objects other than NetWare users, groups, distribution lists, and OUs. These vendors deliver accessory products for migrating to Windows Server 2008 R2 and Active Directory. For information regarding GroupWise migrations, see the “Mail Systems” section of this document.

MSDSS migration creates a structure of Active Directory objects that mirrors the migrated Bindery or NDS objects. This makes it possible for you to retain existing Novell structures and use them immediately after you migrate to Active Directory. MSDSS migration maps Novell user and group objects to Active Directory user and group objects, and it maps Novell containers to Active Directory OUs.

However, because Active Directory does not support a container comparable to the NDS organization and because Active Directory handles security differently than Novell does, MSDSS—in migration mode only—creates a corresponding domain local security group in Active Directory for each NDS OU and organization. MSDSS then maps each Novell OU or organization to the corresponding Active Directory domain local security group.

File and File Access Rights Migration

You can use the File Migration Utility, part of Services for NetWare, in conjunction with MSDSS to migrate all or part of your NetWare folders and files to one or more file servers running Windows Server 2008 R2. If you migrate files in groups rather than all files at once, File Migration Utility helps you track the current status by providing an interim status report that shows which files have and have not been migrated.

File Migration Utility maintains the NetWare structure and carries existing rights and permissions for NetWare files into the Windows Server 2008 R2 NTFS file system. To migrate file-system permissions, you must migrate the users before you migrate the file system. That is, to be able to migrate files with their access rights, you must first use MSDSS to migrate NDS directory or Bindery objects to Active Directory and you must select the optional Migrate Files check box when you do so. This creates a migration log that File Migration Utility can use. You then use File Migration Utility to migrate the files and their access rights to a Windows Server 2008 R2 NTFS share. Detailed instructions for migrating the different versions of NetWare are provided later in this document.

The Windows Server 2008 R2 NTFS file system governs which users and groups can access individual files and directories, and NTFS can provide varying levels of access for different users. This file-level security is then enforced by the core operating system. File Migration Utility translates the NetWare file system rights and permissions to the equivalent rights and permissions in the NTFS file system.

NetWare file security is similar to NTFS security in that both file systems allow you to control the ability of users and groups to access files by applying permissions to objects. For a table showing exactly how Novell NDS or Bindery rights are converted to Windows Server 2008 R2 NTFS permissions, in MSDSS Help, see Understanding how rights are converted. The NDS Modify right, which does not have an equivalent NTFS right, is translated by default to Read, but during the migration process you have the option to select the Write check box to allow Read/Write access. See the step-by-step installation instructions in this document for more information.


You can also migrate files to a FAT file system on computers running Windows Server 2008 R2. However, the FAT file system does not support NTFS rights, and this process migrates only the directory structure and files, not the associated rights.

You map individual NDS or Bindery directories to Windows Server 2008 R2–based directories or shares (“directories” here refers to file-system directories or folders, not to network directories such as NDS, Bindery, or Active Directory). You can map multiple volumes to a single share or directory by creating more than one mapping. Multiple mapping entries are used to create one-to-one, many-to-one, and one-to-many relationships.

Typically, when you perform a migration in stages, there is a period during which client workstations have been migrated to the Windows Server 2008 R2 platform but some files that those client workstations might need to access are still on NetWare servers. (For details, see Staged (Phased) Migration Requires Synchronization later in this document.) To help overcome this problem, you could migrate some of the files to servers running Windows Server 2008 R2 prior to user migration. However, this option is generally not preferred for two reasons: First, this method does not migrate file-system permissions, and second, some NetWare clients that need those files might not yet be migrated. File and Print Services for NetWare (available on the same Services for NetWare CD-ROM that contains MSDSS and File Migration Utility) make it possible for NetWare client computers to access a Windows Server 2008 R2–based file and print server.