NDS Migrations
So, you have finally decided to bite the bullet and embark on an NDS to AD migration. Whilst such as decision is not to be taken lightly the release of Windows 2003 and Exchange 2003 Microsoft has provided a number of very compelling reasons to go through this pain and a growing number of Enterprises are seeing the value in this move and embarking on the process.
Once you have made this choice the next question that very quickly springs to mind is “just where do I start?” However, remember the words of Lao Tzu, “the journey of a thousand miles begins with one step”, and all will be well.
Initial Considerations
A number of project paths should begin simultaneously; these include discovery of your NDS environment, translating NDS concepts and objects to AD concepts and objects, password migration problems, planning to deal with objects and processes that will need to migrated manually and planning your AD design, security and management.
Discovery: work out just what you have in your old NDS environment and work out what is useful and requires migrating and what is redundant and should be left behind. There are a few tools on the market that can help with NDS reporting (in addition to native NDS resources). Quest’s NDS Reporter is one such utility that can assist in the discovery phase. Such tools can provide, among other things, information on the last time that a User logged on (or if they ever have), whether or not the user has a Null password, Group membership and file and folder permissions (perhaps to be handed to the business to confirm that permission translation is appropriate).
NDS concept translation: certain NDS concepts do not translate perfectly to the AD world and require a degree of rethinking to establish the most appropriate method of translation. In NDS for example, Containers, Countries, Organisations and Organisational Roles can be used – in addition to Users and Groups - as security principles. In the AD world only Users and Groups can be security principles and Containers, Countries and Organisations must be translated into security groups if permissions are to be carried over from NDS to AD.
NDS also adheres to strict X500 naming conventions and an object must be unique only within its container (thus, for example, there can be a number of “Marketing” security groups in NDS). In AD the name of an object must be unique within the Domain and the UPN of the User object must be unique within the Forest. This can provide a number of issues that must be addressed prior to any migration if a User and Group migration is to be undertaken.
Another issue surrounding NDS to AD migrations is that of passwords. There are no tools available to migrate the user password from an NDS user to an AD user (either native or third-party) and a process must be put in place to deal with this issue. MSDSS (Microsoft’s NDS to AD migration tool) can synchronise passwords from AD to NDS but the password still needs to be set on the AD object in the first place. Quest’s NDS Migrator provides a web portal to capture NDS passwords (users are requested to authenticate to NDS through this portal and the password is captured and applied to the migrated AD user object prior to the user signing on to AD for the first time). In addition it is possible to script the process of applying a random password to the AD user objects and emailing this password to the user’s current email account (which they would access through their NDS account prior to a migration) ready for the cutover day. The user can then write this password down on a Post-It note and place it on their monitor.
Manual Processes: There are a number of objects and applications that cannot be migrated with tools and will require manual processing. These objects may be the rate limiting step for any migration. Printers must be manually created in the AD side and users must be mapped to them with a script or through another method. Web based applications running on Netware servers will be Java based and may need to be converted to .NET to run on a Windows based platform. ZenWorks will need to be replaced. In larger or more complex environments this may be with SMS and there are tools such as InstallShield’s AdminStudios that can take a ZenWorks object and repackage it as a Microsoft MSI but the rest of the process will have to be manual. BorderManager requires NDS for authentication and will need to be replaced with an equivalent product such as ISAS for this functionality to continue. All of the above will require a good deal of planning and time and should be embarked upon very early in the project.
NDS Migrations: A secure, robust and well planned Active Directory must be in place prior to the migration. AD must be designed to two, often conflicting, aims, delegation of permissions and Group Policy. Tools and Processes must be in place to secure and manage the AD domain and maintain the environment. Training will need to be conducted to ensure that the network administrators are happy with AD and can do day-to-day tasks and troubleshoot AD problems.
NDS Permissions Translation: The point of tools (Microsoft and third-Party) is to translate NDS file and folder permissions to AD thereby drastically reducing the workload of the Migration Project team. If the business examines the file and folder permissions and decides that they are very messy and require cleaning up and that this will be done by setting new permissions with new groups in AD then the requirement for a tool to translate permissions is removed. A few companies have chosen this path but in very large environments and when companies have extremely aggressive time constraints on their projects this approach becomes practically impossible and a permissions translation migration is necessary.
Backup, Backup and Backup. As with all infrastructure projects there should be functioning and tested backups in place at all stages. In addition, the test phase (in a test environment!) should be as extensive as possible and the Pilot phase should be with a representative set of users and should also allow a few weeks after pilot to iron out any small issues.
Planning for Coexistence and Data Migration
The next consideration is that of coexistence. The Holy Grail of NDS Migrations is to establish a closed group of Users, Groups, files and folders and to migrate these all as one chunk in one go. Such an approach negates the need for coexistence and the possible use of the Netware Client32 on the workstations. However, this is rarely possible in real life unless small numbers of users are confined to one server and one NDS Tree and this can be moved to one Domain. For the most part there will need to be some degree of coexistence and remapping of portions of data for the Users. If there is to be a desktop refresh as part of the User migration this may have an impact on the proposed migration path.
Client Focused Migration:
A migration can be triggered by repointing a client to AD (either by removing the NDS Client32 or by reducing the order within the network stack) which will point the client workstation to AD and through DFS or mapped drives to the appropriate network shares.
Server Focused Migration:
Using File and Print Services for Netware an administrator can emulate a Netware Server on a Windows Server and allow for a gradual transition. In addition, the use of the Netware Client32 will allow for gradual repointing of data by updating the NDS logon scripts and the AD logon scripts at the same time. This approach requires a good deal of planning.
Security Translation and File Migration: The key to both the Native approach (Microsoft tools) and Quest’s approach to a permissions translation migration is the initial step of creating the user objects in AD. Once this has occurred and a mapping of NDS object to AD object has been established it is then possible to start migrating the files and folders and setting the equivalent AD permissions on them. It is this process that is the core of an NDS to AD migration and we will outline both the Native approach and the Quest approach below:
How Native Tools work. Microsoft’s MSDSS is a directory synchronisation tool that sets up a one-way or two-way synchronisation between NDS and AD. This provides for ongoing coexistence in the medium term but requires that a number of issues are addressed prior to setting up the connection (Specifically the issue of duplicate names in NDS). Once the synchronisation has been established Microsoft’s File Migration Utility (FMU) can be used to migrate data from a Netware server to a Windows server and preserve permissions.
How Quest’s NDS Migrator works. NDS Migrator acts as a one time migration utility with a great degree of flexibility in creating accounts and migrating attributes. In addition, it is possible to map onto preexisting user and group objects (perhaps migrated from NT4 to AD to bring in Exchange 5.5) and translate permissions. A great degree of flexibility is possible and utilities are available to deal with intra-NDS name collisions and NDS to AD naming collisions. NDS Migrator will also create security groups in AD to represent Countries, Organisations and Containers that have been used for permissioning. File ACLs can also be directly permissioned with existing AD accounts. Once this mapping is in place the file migration can begin and the volume mapping utility can be used to schedule data migrations (and rerun migrations to take over volumes that are too large to move in one night), to check for problems (server permissions, free space) prior to the migration and to report on the data migrations.
Conclusions
A migration from NDS to AD is a difficult process that requires a great deal of planning and testing to accomplish with the minimum of impact on the end user. Such migrations in larger and more complex environments will require third-party tools and experienced consulting to reduce risk and bring the project in on time and within budget.
Comments
- Anonymous
January 01, 2003
Darren has written an article on some of the challenges and issues that you may encounter when migrating... - Anonymous
January 01, 2003
I wanted to pass on a good article that came up at a co-workers blogsite here on TechNet.com... The IT...