Introducing a new directory service to your network may be procedurally similar to installing a new application, but from an organizational and strategic standpoint, the process is far more complex. By definition, the directory service is an application that interacts with virtually all of your network’s resources - hardware, software, and human - and for it to function properly, you must plan judiciously and test carefully before you actually deploy the service on your production network.

A crucial part of deploying any hierarchical directory service is the design and construction of the directory services tree itself. While building a new tree from scratch can be a complex task, migrating existing directory information from another service presents its own set of challenges. Many networks are currently using Novell Directory Services (NDS) as their primary storehouse for directory service information, and with the release of Windows NT Server 5.0, there will be a need to migrate that NDS information to the new Active Directory service. Windows NT Server 5.0 includes a Directory Services Migration Tool (DS Migrate) that makes it possible to import NDS information across the network and model it as needed before committing the new data to the actual Active Directory tree. This paper examines the procedures involved in this migration process and the operation of the DS Migrate program.

DS Migrate is, in essence, a third directory service that functions as an interim step between NDS and Active Directory. The program runs on a Windows NT system and works by importing the NDS directory objects and their properties from NetWare servers into its own Microsoft Access database. This database is considered to be an offline directory, because it is not actually accessed by network users, but it maintains the same type of object hierarchy and provides many of the same control functions as both NDS and AD.

Once you have imported the directory information from NDS into the DS Migrate database, you can model the data in the offline directory by moving container and leaf objects around the tree, creating and deleting objects, and modifying the values of the objects' properties. It is only after you are satisfied with the directory design as it appears in the offline database that you write the imported objects to Active Directory. This method provides you with a safety buffer that lets you experiment with different tree designs and reconcile object and property conflicts before making any changes to your live Active Directory database.

After you have created your new tree structure and transferred the NDS objects to Active Directory, you can use DS Migrate to perform a file migration from your NetWare volumes, preserving the NetWare file system access control lists and converting them to NTFS permissions.

DS Migrate is not a part of Active Directory itself. It is a completely separate program that communicates with AD through ADSI (Active Directory Service Interfaces) and uses the Microsoft Management Console's snap-in architecture to host its user interface. This is an excellent example of how third-party developers can use these interfaces to create new applications that are tightly integrated with Active Directory.

ADSI is a high level API set that abstracts directory service functionality and makes it easy to create directory-enabled applications by using high-level tools such as Microsoft® Visual Basic® programming system, Java, C, or Microsoft Visual C++® development system, without having to worry about the underlying differences between the different namespaces. ADSI abstracts the capabilities of directory services from different network providers to present a single set of directory service interfaces for accessing and managing network resources. Administrators and developers can use ADSI services to enumerate and manage resources in a directory service, no matter which network environment contains the resource. This can be an LDAP-based, NDS-based, or NTDS-based directory; it doesn't matter, as long as a service provider is available for that directory service. This means that you will be able to build or buy applications that give you a single point of access to multiple directories in your network environment, whether those directories are LDAP, NDS, or NTDS-based directories.

Migrating directory service data is not a task to be taken lightly, and before you begin you should plan the entire process carefully. In addition to the data migration itself, you must consider all of the effects that migrating to Active Directory will have on your network, its users, and its support staff. First, you should create an inventory of the services provided by your existing directory services solution, and make sure that the new directory can perform the same services.

DS Migrate is designed to transfer user and group objects, as well as files and permissions, to Windows NT, but have to make other arrangements to implement your printing architecture in the new directory, as well as any other application services that use the NDS database. This means that you may have to evaluate new applications to provide services like network backups and faxing under Windows NT, before you can provide users with the same services that they had under NDS.

Whenever possible, you should make the transition to new network services with as few changes to standard user procedures as you can, but it still may be necessary to provide users with additional training. You will almost certainly have to expend a considerable amount of time and resources in training the network support staff to maintain the new directory. This is a process that should begin long before you actually perform the data migration.

When you are planning the actual NDS to AD migration itself, you should lay out a realistic schedule that suits your network's usage patterns. Don't expect to be able to migrate a 10,000 user network in a weekend, particularly if you have to upgrade client workstations as well. Divide and conquer can be a sensible rule for the migration process; even after considerable offline testing, you may run into situations that you didn't anticipate when running AD on your live network. Migrating your network one department or segment at a time can let you spread out the acclimatization process for both your users and your network administrators.

Finally, make sure that you have valid backups of both your Windows NT and your NetWare servers before you begin the migration process. This protects you in case unforeseen circumstances (such as a power outage) interrupt the procedure, or you want to restore your servers back to their original state.

DS Migrate takes the form of an snap-in module for the Windows NT 5 Microsoft Management Console (MMC). When you select Directory Services Migration Tool from the Start Menu, the system loads MMC with the appropriate snap-in.

DS Migrate must have access to both your network's NDS tree and to Active Directory in order to perform its functions. This means that the system must be running an NDS client, such as Windows NT's Client Services for NetWare. For access to the Active Directory database, it is recommended that you run DS Migrate on a domain controller. This saves having to transmit the directory information over the network when writing it to the AD database, which can increase the overall traffic burden considerably. It is possible to run the program on a Windows NT Server system that is not a domain controller, but Windows NT Workstation is not supported.

The first step in migrating NDS information into Active Directory is to import the NDS data into the DS Migrate database. DS Migrate access NDS through the system’s NetWare client (either Microsoft’s or Novell’s) on a read-only basis. The process makes no changes to the NDS database, and you can continue to use NDS alongside Active Directory for as long as is needed. The account that you use to log into NDS must have sufficient object rights to read the objects and properties that you intend to migrate. The use of the Admin account or an equivalent is recommended.

The DS Migrate database is organized into containers called projects, and each project is composed of one or more views. These are simply organizational structures that you can use to experiment with the data import and modeling processes. You can create multiple views of the same data within a single project, to try out various tree designs. The names that you assign to your views will not be part of your Active Directory tree. Although they appear to be part of the tree hierarchy in DS Migrate, the views exist only in DS Migrate's Access database, and are not written to AD.

In fact, DS Migrate does not write any data to Active Directory until you explicitly select a view and direct the program to do so. You can therefore import the same NDS data as many times as you wish, and experiment with different organizational structures before you commit your changes to a live environment.

Creating a project is a simple matter of selecting the appropriate option from DS Migrate’s Action/New menu. The project itself is not imported into Active Directory, only the data within its views, so you can give the project any name that you wish. Once you have a project, you can highlight it and select View from NetWare from the Action/New menu to begin the NDS importation process. This launches DS Migrate’s Discover Wizard, that leads you through the process of discovering the data in the NDS database and on bindery servers.

After you assign a name to the view, the wizard displays an expandable list of the NetWare binderies and NDS trees visible to your NetWare client (see screen 1). You can navigate to any context (that is, any container object) in any tree and select it for discovery by clicking the Add Context button. Binderies are not hierarchical, so you need only decide whether to import the entire bindery or not.

Once you have completed your selections, DS Migrate reads the context(s) you have chosen, parsing all of their subordinate contexts, and importing the discovered objects into its own proprietary database. During the discovery process, the program displays progress messages and copies them to a permanent log (see screen 2). If you are importing a large number of objects, the log is your best means of determining whether or not the process proceeded successfully.

There are four types of log entries generated by the NDS discovery process:

Every entry in the log contains an indicator of the entry type and a date stamp. The logs are stored as part of the project databases, and you can view them at various levels of detail by selecting an object in DS Migrate's source pane (on the left side of the screen) and choosing Browse Logs from the context menu. You can, for example, view the logs for an entire project, the logs for a specific view, or the logs for a particular discovery within a view, depending on the object that is highlighted when you open the log viewer. You can also apply filters to the log viewer in order to display only specific entries, making it easy to scan the logs for errors, for example.

Apart from the display of error messages, the most important function of the log is to document exactly which objects DS Migrate has discovered in the NDS contexts you selected. Active Directory and NDS are similar in many ways that are common to most directory services. Both use a hierarchical tree structure to organize a collection of objects that represent network resources. These resources can include the network hardware, like servers and printers, human resources like users and groups, and purely logical resources like organization and organizational unit objects.

The primary function of DS Migrate is to import the objects representing the human and organizational resources and their properties into Active Directory, and as a result, there are certain objects and properties in NDS trees that are deliberately not migrated. These include:

These objects are not migrated because they have no equivalent in the Active Directory schema and no purpose on a Windows NT network. You can, of course, continue to use these objects in the NDS tree as you always have, until you deploy equivalent services on Windows NT.

The user and group objects in the NDS contexts you selected for discovery are imported into DS Migrate, along with the container objects that define the directory hierarchy, such as organizations and organizational units. At the conclusion of the discovery process, you should see a replica of your NDS object hierarchy appended to the new view object that the Discovery Wizard created. If you have selected a context that is more than one layer removed from the root of the NDS tree, DS Migrate creates "phantom" objects to represent the superior containers.

DS Migrate can only discover objects that the NetWare client has permission to read. If you use an account that does not have full Read object rights to the context you select, then the discovery will be limited to the visible objects.

Bindery discoveries work the same way as with NDS. You must have supervisor rights on the NetWare server containing the bindery, and the discovery is subject to the same object type limitations. What is different, however, is that since the bindery is not hierarchical, there is no tree structure. DS Migrate creates a default hierarchy when it imports bindery data by creating an organization object in the chosen view, using the organization name specified in the Novell Environment Discover page of DS Migrate's Options dialog box, which you access by selecting Options from the Action menu (by default, the name is Organization). Beneath the organization object, the Discovery Wizard creates an organizational unit object named for each bindery server that you select for discovery. It is in this organizational unit object that the wizard creates the users and groups that it discovers in that bindery.

Importing NDS objects into Active Directory is, of course, pointless unless the objects' properties are imported as well. As with the object discovery process, DS Migrate imports only properties that are applicable to an Active Directory object. For example, NetWare login scripts, NDS templates, and any properties added by NDS schema extensions are not discovered, because they would not be usable when transported from the NDS context to the Windows NT directory services environment. However, the Discover Wizard does import most of the standard identification properties, converting them when necessary to the appropriate AD property names.

DS Migrate's primary emphasis is on discovering NDS objects' identification data and their object and property rights. There are quite a few other properties common to both NDS and Active Directory objects that the program does not discover or migrate. These include properties like allowed logon times, password restrictions such as expiration dates and required lengths, and disk quotas.

One property that is deliberately never imported from the NDS database is the user object password. Transmitting unencrypted passwords over the network and storing them in an unprotected form is not recommended. You must assign user passwords yourself with DS Migrate's password generation tool in order to secure your user objects .

Part of the planning process that precedes the actual migration should include discussion of how the functionality of the NetWare and NDS mechanisms that you use on your network can be realized in Windows NT and Active Directory. You may have to change your strategies for applying logon scripts, for example, in addition to modifying the NetWare scripts themselves. This is where DS Migrate's tree modeling capabilities can be most useful.

One of the most important properties of an NDS object that is migrated to Active Directory is its access control list (or ACL). Every object in an NDS tree has an ACL that lists its trustees and the rights that each trustee has to the object. A trustee is simply another object in the tree that has been granted object or property rights to the original object. These rights are needed to view, modify, rename, or delete the object and its properties. Each entry in the ACL consists of the following information:

Active Directory uses a system of rights that is similar to that of NDS, but the two are different enough for some special consideration to be needed during the conversion process. The AD equivalent to NDS object rights are called access control entries (ACEs), which are stored in each object’s security descriptor. An ACE consists of the following elements:

The specific rights granted by the two security systems are similar in function, but sometimes differ in their names. The following table lists the various NDS object and property rights, and the equivalents to which DS Migrate converts them during the discovery process.

During the NDS discovery process, DS Migrate converts the NDS ACLs into AD ACEs and adjusts the Active Directory settings to duplicate the NDS security model as closely as possible. This means that, since NDS rights all work from the perspective of granting (not denying) access, the new ACEs are configured to allow (and not deny) rights. Also, since NDS objects always inherit object and property rights from their parent objects, the ACE inheritance flags are automatically enabled, even though this is usually an optional feature in AD.

To counteract the automatic rights inheritance, NDS has a feature called an inherited rights filter (IRF) that prevents specific rights from being inherited by certain objects. Active Directory ACEs have a feature that can control the flow of rights into an object's security descriptor, but this controls the flow of all rights, not specific ones like an IRF. However, when DS Migrate encounters IRFs during the discovery process, it uses this feature, plus its ability to grant specific rights to individual objects to emulate the cumulative effect of an IRF.

There are, however, two other popular methods for assigning NDS object rights that are not supported by Active Directory and for which there are no workarounds. Because NDS rights are automatically inherited from superior objects, it is a common practice among administrators to assign trustee rights to container objects, in the expectation that the objects in the container will inherit those rights. Unfortunately, organizational unit (OU) objects in Active Directory do not have security credentials, and therefore cannot be trustees of other objects. When DS Migrate encounters trustees that are OU objects, it logs the fact that the new AD object has no security credentials and omits the object from the ACE. This means that any object rights that you have granted in NDS using this method are lost.

In the same way, Active Directory does not support the use of security equivalences as NDS does. In NDS, by granting one object the equivalent security of another object, the first object inherits all of the rights assigned to the second. Many NDS administrators use this as a quick and dirty method for granting certain users Admin privileges. Like OU trustees, the security equivalence property is also ignored by DS Migrate, which can result in Active Directory users that do not have the same rights that they did in NDS.

These are situations that are best dealt with in NDS, before you begin the directory service migration process, by using another means to assign objects the rights they would normally inherit from OUs or gain from security equivalences.

You can control the metrics that govern the structure of the DS Migrate directory tree from the Verify page of the Options Dialog box. DS Migrate checks the NDS data against these metrics as it is imported to prevent the Discovery Wizard from building tree structures that are not supported by Active Directory. The default tree metrics are as follows:

You can modify these metrics as needed and, on the same page, specify whether the DS Migrate should verify the object dependencies of user and group objects as they are discovered. This verification is a check to see that all of the object names listed in the property values of the imported users and groups actually exist in the new directory tree. You can also trigger a complete check of an entire view's object dependencies at any time by highlighting the view and selecting Task/Verify Object Dependencies from the Action menu.

Once the discovery of your NDS data is complete, you can work with the newly created objects in the DS Migrate view you have created in any way you wish. This is called the modeling process, and it is intended to be a period of experimentation in which you decide how you want these objects to appear in the Active Directory database. Because you are working with offline data, no actions you take here have any effect on your live AD database until you explicitly choose to write your changes to a Windows NT domain controller.

Before you start modeling, you may want to export your views to external files for protection, by highlighting a view in the source pane and selecting Task/Export View from the Action menu. This way you always have a backup of your NDS data in its original form. You can use the export file to create a new view with your original data, enabling you to start the modeling process over, if necessary.

Modeling your data can mean many things, depending on your needs. You may not want to make any changes at all, and simply import your NDS objects into Active Directory as is. However, DS Migrate provides the ability to modify the NDS objects and their properties in any way you wish, including the following:

The one factor that you must keep in mind while modeling the directory objects in DS Migrate is that you are working with only the data that you have imported from NDS. If you are building a brand new AD tree, then this might not be a problem, but if you have an existing AD tree, you must consider how the DS Migrate object hierarchy will dovetail with the AD structure.

Depending on the size of your network, your Active Directory tree design may differ substantially from that of your NDS tree. DS Migrate's modeling capabilities are intended to help you re-architect your NDS hierarchy to take advantage of Active Directory's ceilings and capabilities. Tree design is an extremely important element of any Active Directory rollout, especially on larger networks. Although this subject falls well outside of the scope of this paper, you should consider it to be an essential part of the migration planning process. There is a large collection of documents on Active Directory and tree design available on the Microsoft web site at http://www.microsoft.com/NTServer/Basics/TechPapers/default.asp. Fortunately, with a tool like DS Migrate, you can import your NDS data and experiment with various tree designs long before you are ready to commit the data to the Active Directory database.

DS Migrate can only discover data from NDS trees and NetWare binderies. You cannot discover the existing objects on your Windows NT domain controller in order to create a complete facsimile of the combined NDS/AD directories. If you plan on merging your NDS objects into an existing hierarchy, you must be careful to duplicate that hierarchy exactly in DS Migrate.

For example, in the following directory structure, in order to combine the NDS users in the Accounting organizational unit into the OU of the same name in the Active Directory tree, and add the three NDS Sales subdivisions, it is vital that the CorpNet, Accounting, and Sales objects in both directory structures be identically named and situated in the tree hierarchy.

Moving Objects

Although the NetWare discovery process duplicates the structure of your NDS tree, you need not leave it that way. DS Migrate enables you to move or copy objects using the standard Windows drag-and-drop or cut-and-paste procedures, both within a view and between views. You can therefore modify the tree structure directly within a discovered view, or create a new empty view and build a new tree from scratch using the discovered objects.

Using these techniques, you can move leaf objects like users and groups to another container, or move containers (with all of the objects they contain) to another location in the tree. When you move objects, DS Migrate enforces the superiority rules of the directory service object hierarchy, preventing you from moving an organization object to a position that is subordinate to an organizational unit, for example. This ensures that when you write your changes to the Active Directory database, the tree structure will not be improperly formatted.

In some cases, an important part of the directory modeling process is the merging of objects. If, for example, you discover NetWare data from multiple trees or binderies, you may have several objects representing the same person with property values that you want to combine. This ensures that all of the rights granted to the separate objects are combined into the single merged object. You can merge two objects manually by dropping one on another (called an object merge) or automatically by merging containers that have objects of the same name and type within them (called a container merge).

DS Migrate supports two forms of merging: the merging of two NDS (or bindery) objects and the merging of an NDS (or bindery) object into an Active Directory object. In both cases, the most important part of the merge operation is the treatment of property conflicts.

Directory service objects can have two types of properties: single-value and multiple-value (multi-value). When you combine two objects with different values for a single-value property (such as the password property), you must choose one of the two values and discard the other. When you combine multiple-value properties (such as the group members property), you have the option of combining all of the values from both objects or allowing the values of one object to take precedence over the other.

DS Migrate enables you to control the behavior of object merges from the Merge page of the Options dialog box. You can control how DS Migrate handles conflicting properties during a merge by selecting one of the following options:

If you fill the Replace Single-Value Properties check box, then the property value of the destination object is deleted in favor of the source object's property value.

It is also important to be aware of situations where you do not want objects to be merged. You may, for example, have users in different departments or divisions with the same logon names. In NDS, it is perfectly acceptable to have objects with the same name in different containers, but you should make sure that objects like these are not accidentally merged during the directory migration process.

The treatment of passwords is always a critical subject in any directory service migration, because of the dangers inherent in transmitting them over the network in clear text and in storing them in an interim directory like that of DS Migrate. The NDS databases on a NetWare server, for example, are located on the SYS volume, but they are not visible to the NetWare file system, and the passwords they contain are stored in an encrypted form.

DS Migrate, however, is simply an application, not an operating system or a file system, and it has no such elaborate security features. As a result, it was decided that that DS Migrate should not import user passwords at all during the NetWare discovery process. Thus, all of the newly created user objects in the DS Migrate database have no passwords, but the program provides with several options that can remedy this problem.

The simplest and most time-consuming method is simply to edit a user object's password property value manually and insert a password. This is obviously not a practical solution for large numbers of objects, but for Admin and other accounts with high-level access, this is a good way to protect them quickly and securely.

DS Migrate also provides a solution for generating user passwords en masse, either on demand, or as you merge and create objects. The Password Generation page in the Options dialog box enables you to select how you want the passwords of newly merged and created objects to be treated. You can also trigger an immediate password generation event for all of the objects in a particular view by highlighting the view and selecting Task/Generate User Password from the Action menu (see screen 3). Both dialog boxes provide the same options, which are as follows:

· Assign NO Password to Each User

· Assign a Unique Randomly Generated Password to Each User

· Set Each Password to the User’s Logon Name

· Assign Each User the Same Custom Password

When you elect to assign random passwords to the user objects in a view, DS Migrate assigns a 12-character alphabetical password to each user and records them in the log. This provides the maximum amount of security but also requires that you manually extract the passwords from the log and distribute them to the appropriate users in a secure fashion. Assigning the same custom password to all of the user objects is less secure, but you need not advertise the fact that everyone is using the same password. This option also greatly simplifies the task of providing the password to the users. Using logon names as passwords is even less secure, amounting to little more than a temporary obstacle to a potential intruder, and using no passwords, of course, leaves your user accounts wide open.

The password option you select should be based on your network’s need for security, keeping in mind that this need not be a permanent solution. You can force your users to change their passwords after the first AD logon or at any time thereafter, using the standard Windows NT password control properties.

In addition to modeling the directory tree structure, you can also use DS Migrate to modify the values of many object properties. By double-clicking on an object, you open its Properties dialog box, that displays all of the properties supported by the program, with the values discovered from NDS. Any changes that you make in this dialog box become part of the Active Directory objects you create later with DS Migrate.

You can also modify the names of objects in the database and references to those objects using DS Migrate’s Find and Replace feature. When you highlight a container object and select Task/Find and Replace Object Names from the Action menu, you see the dialog box shown in screen 4. From this dialog box you can search for object names in the container and modify them either by replacing the search string or adding a prefix or suffix to the existing object name.

This feature makes it east to modify objects names in order to distinguish newly imported NDS objects from existing objects in the Active Directory database. If, for example, you have objects with duplicate names in both directory services, you can rename the NDS objects to prevent them from being merged into the AD objects.

The Find and Replace References feature enables you to change specific object references in trustee lists and other properties. If, for example, you change the name of an object, you must also change any references to that object anywhere else in the directory. You can also use this tool to change trustee references from NDS accounts like Admin to equivalent AD accounts like Administrator.

Once you have modeled your directory tree to your specifications and modified the object properties as needed, you are ready to copy the objects to the Active Directory database, a process that DS Migrate calls configuration. When you configure the imported NDS objects to Active Directory, you can use one of two methods. Either you configure an entire view that you have designed to overlay the Active Directory tree structure (called a view-based configure), or you configure a container object to a specific location in the Active Directory tree (called a relative configure).

When you perform a view-based configure by highlighting a view in DS Migrate and selecting Task/Configure Objects to Active Directory from the Action menu, the program assumes that the tree structure in the view should be added to an NT domain at the top level of your Active Directory LDAP tree. For this to occur, you must duplicate the appropriate domain object and tree hierarchy in DS Migrate.

While view-based configures assume that you have constructed an entire tree structure and want to import the entire thing into Active Directory at one time, relative configures are intended for writing smaller parts, or sub-branches, to the AD tree. Procedurally, a relative configure differs in that you highlight a container object (instead of a view) before selecting Task/Configure Objects to Active Directory from the Action menu. DS Migrate then presents a dialog box (see screen 5) that enables you to navigate Active Directory’s LDAP hierarchy and select the location where you want to place the container you are configuring. All of the objects subordinate to the selected container will be configured to the location that you select.

Before the configuration process begins, DS Migrate verifies the object relationships in the view or container you've selected, displaying the results and saving them to the log. You have the option of proceeding with the configuration or aborting the process, based on these results. If the verification detects a large number of broken object references, it is recommended that you do not proceed with the configuration until you have corrected the problems using DS Migrate's search and replace feature.

As in the modeling process, DS Migrate can merge property values when it encounters identically-named objects during the configuration process. You control the merge process on a separate page of DS Migrate’s Options dialog box, although the available options are fundamentally the same. The Active Directory Configure page contains two checkboxes: filling the Replace Single Valued Properties checkbox causes DS Migrate to replace single valued properties in Active Directory objects with the values from the equivalent properties in the NDS objects being migrated. Leaving the checkbox unfilled causes the program to discard the NDS property values. The Replace Multi-Valued Properties checkbox causes the NDS property values to overwrite the existing Active Directory values for multi-valued properties. If you leave this box blank, DS Migrate appends the NDS property values to the existing Active Directory values.

Once you have migrated your NDS objects to Active Directory, you can migrate the files from your NetWare volumes, along with their trustee rights. In NetWare, file system access rights are completely separate from NDS object rights, although in both cases the objects to which you grant rights are referred to as trustees. Every file and directory in the NetWare file system has an access control list (ACL) identifying the users, groups, and other objects that have been granted access to that file or directory. The access control list, however, is stored as part of the file system, not in the NDS database.

NetWare maintains separate objects in NDS for its servers and for the volumes on those servers. DS Migrate can discover the volume objects, but not the servers. When you use the NetWare Administrator to open an NDS volume object, you can see the directories and files stored on that volume, but they are not part of NDS. Since the file system ACLs contain references to NDS objects, however, those objects must be imported into the Active Directory database before you can migrate the NetWare files and directories. Otherwise, it is not possible to convert the NetWare file system trustee rights to Windows NT permissions, because the users and groups receiving the permissions do not yet exist in Active Directory.

It is recommended that the target for a file migration be an NTFS drive on a Windows NT server, because the FAT16 and FAT32 file systems do not support the permissions that will be created from the NDS trustee rights. Also, DS Migrate does not support the Macintosh name space that you can add to NetWare volumes. If you have Macintosh files stored on your NetWare servers, they will not be usable by Mac systems after migration to NTFS.

When you select Task/File System Migrate from the Action menu, you are presented with the File Migrate Wizard that walks you through the steps of migrating volumes, files, and trustee rights from your NetWare servers to Windows NT shares. You can elect to migrate only the NetWare files, only the NetWare security rights (if you have already migrated the files), or both simultaneously. The wizard enables you to navigate the NDS tree and your Windows NT share hierarchy to select the sources and destinations for your volume migrations (see screen 6).

By default, DS Migrate creates a directory on the target Windows NT drive with the same name as the NetWare volume you are migrating. You can also create a new Windows NT share for the migrated files. The wizard also displays the rights that the new files and directories will inherit from its Windows NT parent container (see screen 7).

As with any file migration, you must be certain that you have sufficient disk space on the target drives to hold the migrated files and directories. As the migration process proceeds, the results are logged in the same way as any other DS Migrate procedure, so that you can check for error and warning messages afterwards.

From a procedural standpoint, DS Migrate is a simple program to use, but this does not mean that the process of migrating from NDS to Active Directory is always a simple one. Depending on the size of your directory, a migration of this type can be minimal or monumental. If you are dealing with thousands of objects and many gigabytes of files, the process may take a very long time and a great deal of prior planning. If you have a well-planned NDS tree and you simply want to move the entire structure to Active Directory, the planning phases of the procedure may be relatively simple, although you do have to take into account the differences between the two directory services, as mentioned in this paper.

If, however, you are deploying an enterprise-wide directory service for the first time, by importing NetWare binderies or relatively small NDS trees, you should carefully consider the needs of your network users and design an appropriate tree structure before you even begin to work with DS Migrate.