In-Depth

Tough Migration Moves

Migrating from Novell Directory Services to Active Directory is hard work. This article explains how to assess your current situation, formulate an action plan and specify features for third-party help.

• By Jeff Bennion
• 11/01/2002

WHILE THE DECADE-OLD Novell Directory Services (NDS) remains a proven and highly capable network operating system for many IT shops, other organizations have decided that now is the time to upgrade their network infrastructure from NDS to Active Directory. Moving up from one version of a vendor’s operating system to another is hard enough. It’s even more difficult migrating from one network system to another. Adding to the challenge is the fact that the IT team assigned to this task hardly ever has extensive experience with both NDS and AD.

I’ve assisted many NDS migration teams over the years. They often find themselves under extreme time pressure and with limited budgets and experience. While every organization is unique, this article should aid you in assessing your current situation, give you ideas on formulating the optimal plan for your migration, and help you build your required features list if you decide to select a third-party migration tool. Keeping in mind Murphy’s Law—everything that can go wrong will—good planning and a firm grasp of your NDS implementation will help you to avoid making Murphy an unwitting member of your migration team.

Significant Risks
Any migration involves significant risks. A botched migration could damage your company’s business, inconvenience users, and imperil your career prospects. For these reasons, before beginning, carefully consider the following:

• Involve IT professionals in your migration team from a wide variety of company departments, and obtain senior management buy-in.
• Assess your current environment. Later in this article you’ll see that your choice of migration techniques hinges critically on the composition of your existing network.
• Clear out the junk. Over time, networks accumulate junk. Migration time is a great opportunity to clear away the useless parts. Use reporting and auditing tools to determine which parts of your network should be preserved and which should be discarded. You may elect to clear out this stuff before you migrate, or you may simply avoid migrating it to your new environment. (If your migration is going to take longer than nine months, it’s usually worth cleaning up first.)
• Once you’ve drawn up your plan, validate it in a lab setting that mimics your production environment. Carefully document the steps you take to achieve the desired outcome.
• Consider having your plan validated by experienced third-party consultants and think about purchasing third-party tools to simplify and accelerate your migration. Yes, I work for one of those third-party companies, so although you might consider my suggestion biased, I also know up close that a fresh pair of eyes on the lookout can really help—and speed up the work.
• Make sure your plan includes a back-out strategy so that if things go horribly wrong, you can at least get back to the point where you started.
• Confused or disabled users generate help desk calls, which adds to the expense and stress, so do all you can to minimize user impact. Communicate with your user community early and often.
• Keep your goals modest. A migration project can be become the IT department Christmas tree, with team members each hanging their own pet projects on it. Certainly, migration can (and should) play a large role in your long-term plans. But if successful completion of your migration project depends on finalizing a new corporate naming scheme, deploying a metadirectory solution or rolling out a new suite of desktop applications, your migration could drag out for years. Try to design the project so you can achieve modest, incremental improvements with each milestone, rather than one that depends on attaining complete IT nirvana before gaining any benefit.
• When investigating third-party tools to help with migrations, many people make the mistake of letting a specific vendor’s capabilities decide their migration plan. This is backward. Decide where you need to go and then pick tools that can best get you there. Don’t bring vendors in until you’ve at least settled on the broad outlines of your migration plan, so you can be an educated buyer. Of course, you’ll have to tweak your plan to work around software limitations and logistical considerations, but the starting point should be your needs—not the vendor’s features.

What and How to Migrate to NDS
Once you have a good idea of the state of your network and how you want to design your upcoming AD structure, you need to know what elements of your NDS structure you need to reproduce and how you’ll do it. In this section I list the major components of an NDS migration, and point out hazards you should avoid as well as suggest successful routes others have taken.

User Accounts The most obvious element of any migration is giving the users a new account so they can authenticate to the new directory. But you may already have NT or AD accounts for many users (if you have Exchange, then anyone with a mailbox perforce has an NT account). In this case, you can skip ahead to the discussion about group accounts.

You may also be looking at a three- or four-way migration, migrating from Windows NT to AD and GroupWise or Exchange 5.5 to Exchange 2000, in addition to your NDS migration. In some cases, it’s best to do one thing at a time: Migrate your NDS accounts to NT to get rid of NDS completely and then commence your NT-to-AD migration. If you have a fragmented directory with different communities having NT and AD accounts, but all sharing a single Exchange organization, it can make sense to have AD Connector take the lead. If you keep clearly in mind the IT goals driving your migration, the choices usually become clear. If you need to migrate user accounts from NDS, remember the following points.

Dormant Accounts User accounts that haven’t been logged into for the past four months probably don’t need to be migrated. Identify these accounts and disable them. Then delete the accounts or just avoid migrating them.

Duplicate Usernames NDS only requires that objects’ common names be unique within the same container. That means an object in one OU can have the same name as an object in a different OU. But in AD, object names must be unique within the domain, regardless of which OU it resides in. You can also have a problem with duplicate object names if you’re migrating from more than one tree into a single domain. In migration terms, these are called collisions. You can either associate the accounts (what you’d do if it were the same individual with two different accounts) or modify the usernames during migration (what you’d do if the two IDs correspond to different individuals, usually by appending a numeric suffix). Duplicate usernames are usually rare, but reporting tools can tell you how extensive they are.

NDS Password Tip If you’re set on users keeping NDS passwords, there are a couple of alternatives. If you have a dual NT/NDS environment where your users have identical IDs and passwords in both (and if you have Exchange, you probably do), then you can migrate the user from NDS and copy the password from the user’s corresponding NT account. There are also third-party password synchronization tools, but these can’t copy existing passwords. They intercept password changes as they happen in one directory and copy the same password to the other directory. You can set this solution up, and the next time the users change their passwords, they’re copied to the other directory. Once the users have gone through one password change cycle, their passwords in the new directory will match their NDS ones.

Passwords Unlike an NT-to-AD migration, users can’t use their old passwords on the new network. The most common solution to this is to give each batch of users you’re migrating the same password and then require them to change the password on their first AD login. Blank passwords or passwords matching the user ID can also be used, but these are less secure. A third way is to use random passwords but distributing them securely can be time-consuming.

Home Directories While the home directory location is part of both the NDS and AD user property, it wouldn’t make sense simply to copy this attribute straight across, since the home directory would then point to an inaccessible NDS volume. The home drive letter is part of the NT user attribute, whereas in NDS this is assigned through a login script. Some third-party migration software will move the home directory to a specified NTFS share and update the new AD account’s home directory attribute in one step. Don’t forget: If you change the username during the migration, you’ll also want to rename the user’s home directory on the destination server.

Login Scripts NDS login scripts have a slightly different syntax than NT login scripts, so you probably won’t be able to copy them directly. In NDS a user account can have a login script assigned directly and inherit login scripts through any of its parent containers. With NT you could only have one login script per user; but in AD if you implement GPOs, you can assign login scripts to containers in much the same fashion you could in NDS. GPOs also allow user logout and computer startup and shutdown scripts at any OU as well. If you have elaborate login scripts in NDS and want to keep them, then you’ll probably want to look at KiXtart (www.kixtart.org), a logon script processor and enhanced batch scripting language. GPOs, however, may be an even better option. A lot of tasks previously performed through a login script can be better accomplished through GPOs. Ultimately, login scripts are probably something you’ll need to re-implement from scratch on AD.

Mirror Directory Administration Often, you need to mirror directory administration across outgoing and incoming directories. For example, you might have a new user join the NYC-Finance team before you’ve completed the migration in NYC. If so, you’ll probably need to create accounts for this user in both NDS and AD and put the user in both the NDS and AD NYC-Finance groups. And, it’s easier if the groups and users have the same IDs in both directories.

Schema Extensions Both NDS and AD support schema extensions. If you have populated attributes in your extended schema for NDS, then you need to figure out how to bring those attributes over if you want to preserve them. No third-party tools handle this out of the box, so you’ll probably have to script some sort of solution (LDIFDE, a command-line tool, or ADSI scripts can help with this).

Group Accounts Group accounts are commonly used for granting access to files in NDS. NDS is used for nothing if it’s not used for file and print, so even if you don’t have to migrate user accounts, you’ll almost certainly have to migrate group accounts. Remember these hints when migrating groups.

Identify Empty or Unused Groups Over time, many redundant or unused groups can accumulate. With the help of reporting tools or command-line scripts, determine which groups don’t need to be migrated (or can even be deleted). Empty groups can usually be safely skipped. And while it’ll be harder for you to identify, there’s no sense migrating groups if they aren’t used for access permissions anymore.

Duplicate Group Names Duplicate group names are much more common than duplicate usernames in NDS, but they’re not allowed in AD either. Groups can be renamed during migration, but this can create further complications because it becomes harder to maintain the memberships of the groups when the name is changed, and doubly so if the username is also changed. This is one more reason for paring down the list of groups you’re migrating, but you’ll undoubtedly still have some duplicates. The best way to deal with group names is to tie the existing group name with the OU name. If you have Finance groups in both your New York and Boston OUs, rename New York’s group NYC-Finance and the Boston one BOS-Finance. You might even want to rename the original NDS groups with this scheme to simplify co-administration of your directories during the transition period.

Group Type NDS only has one group type, whereas NT has two and AD, seven. The question of group scope and type is understandably confusing for NDS administrators new to Microsoft. AD has four group scopes. From broadest to narrowest scope, they are: universal, global, domain local and local. The first three can be security-enabled (which allows them to be used to mediate access to resources) or simply remain distribution groups (which are purely for e-mail). I recommend migrating your NDS groups over as domain local groups if you’re in native mode. If you’re still in mixed mode, then you have no choice but to migrate your NDS groups over as global groups. You can change these groups to domain local groups as soon as you make the switch to native mode.

Organizational Units NDS has OUs. AD has OUs. So why not carry your old OU structure forward to AD? There are subtle but important differences to take into account before automatically reproducing your NDS hierarchy in AD.

Design Your Hierarchy for Today Your current IT needs should dictate your AD OU structure, not your legacy NDS OUs. Companies often suffer from poorly designed or obsolete OU structures for NDS. Even if your current structure suits you perfectly, your AD implementation may favor a different hierarchy than the one you had in NDS. Especially when considering GPO performance, AD favors a shallow and broad OU hierarchy (usually no more than three to five levels deep); it doesn’t matter to NDS. On the other hand, NDS best practices dictate designing OUs so none of them contains more than a thousand objects; AD doesn’t care. The main consideration with AD is the size of the domain. NDS, however, had a partitioned directory store that was divided according to OUs. OUs containing less than a thousand objects made for optimal partitioning and replication performance in NDS. (Ironically, with .NET Server, Microsoft is resurrecting a partitioned directory.)

Most migration tools allow you to reproduce your OU hierarchy in AD, but as you can see, this might not be the best AD hierarchy for you. Migration tools permit you to rework your OU hierarchy (or flatten it entirely) on the fly during the move. Worst case, you can reorganize your objects once they’re in AD, but this will lengthen the time it takes to put your domain into production. In any case, these questions are best resolved well in advance of your migration, so you might look at software tools to help model your OU hierarchy.

OUs Aren’t Security Principals In NDS, you can assign file permissions to an OU that gives any user access to the files. When the account is moved out of the OU, the user no longer has access. OUs work differently in AD. The only security principals in AD are users and security-enabled groups. Most third-party migration software can create a secondary hierarchy with a series of nested groups that mirrors your NDS OU hierarchy and then grant permissions to the files based on those AD groups.

You need to determine how extensively OU-based permissions are used in your organization. If they’re not common, you should probably not bother with this. OUs often tend to have duplicate common names (New York and Boston tend to each have a Sales OU, for instance), which isn’t a problem in either NDS or AD; but if they’re also turned into groups, you’ll have group name collisions all over the place.

Also, reproducing your OU structure in nested groups is only a short-term solution, as this parallel structure isn’t maintained automatically. If you move an account out of an OU in AD, it won’t automatically be moved out of the corresponding AD group. Over time, your OU hierarchy and your group hierarchy that shadows it will gradually diverge. It might be better to deploy a permissions model fully compatible with AD from the start.

Files and Folders Critical data must be relocated safely and securely from NetWare to Windows servers, so this is the most important part of the migration. Users who had access to files in NetWare will need the same level of access on AD. To make this as smooth as possible, consider these ideas.

Run VREPAIR Over time, errors can accumulate on disk, and NetWare’s file system with certain configurations can permit filenames that aren’t allowed on NTFS, which will cause problems during data transfer; the file could even fail to copy altogether. Novell’s utility VREPAIR is like SCANDISK for Novell servers. Running it on the file server with just the LONG file namespace loaded will make your filenames NTFS-ready as well as fix other problems. (Load other namespace support if you’re still using them, of course).

Table 1. A comparison of features between Microsoft and Novell directories

Feature NDS Active Directory Computer accounts Non-server computers don’t authenticate to the tree and don’t figure in NDS security. ZenWorks workstation objects aren’t the same as NT-style computer accounts. Workstation objects are more comparable to computer group policy settings and will have to be duplicated manually if at all NT, Windows 2000 and XP computers must have a computer account in the same or a trusting domain of the user, or the domain user can’t log in at the computer. Through a mechanism known as passthrough security, computers participate in domain security Directory type Extensible, object-oriented, self-describing schema Extensible, object-oriented, self-describing schema File permissions NDS permissions: • Stored in directory • Inheritance calculated bottom to top • Permissions inheritance can be blocked for specific security principals and permissions (IRFs) NTFS permissions: • Stored in file system • Inheritance calculated top-to-bottom • Inheritance, when blocked, is blocked for everyone File sharing NDS volume NT file share Group accounts One group type Global Group Universal Group Domain Local Group (each of these three group types can be either a distribution or security group) Local Group Login scripts Can have several, for individual user as well as for OUs of which the user belongs Can only be assigned one through the user attribute; but through GPOs, login scripts can be assigned at OUs, and also permit logout scripts and computer startup and shutdown scripts Object uniqueness Stricter X.500 compliance means objects only need to be unique in the same container. When a trustee is renamed or moved, the resources that refer to them are updated through backlinks Object names must be unique in the domain. (Universal groups must be unique in the forest) Objects have a GUID which is the basis for assigning permissions, rights, and group membership, so objects can be moved or renamed without losing access Printers Printer device Print queue Print server Printer driver and device port (local or remote) Shared printer Servers Security equivalence Any object can be made equivalent to any other object and automatically gain access to any resources the equivalent object has access to Security equivalence doesn’t exist in AD. SID history is a similar concept, but isn’t applicable to NDS migrations Trustees (security principals) Groups Users OUs Organizational role Security-enabled Groups: Local, Domain Local, Global, Universal Users Computers User account Several dozen attributes Two dozen attributes—and the most important ones— are comparable

Copy Smart Most migration software reapplies permissions to the data during the copy, but that’s hardly ever the most efficient way to do it. To ensure the integrity of your data, you have to remove access to it while you’re copying, which means you’ll be doing it after business hours. Since many NDS volumes are quite large, copying can take hours or even days, which means a lot of sleepless nights for you. Consider using other ways to get the data to Windows other than slow over-the-network copies, like restoring from a backup tape. Identify large files that haven’t been accessed in years that can safely be deleted (after backing up, of course). With the files left, use a two-pass copy scheme. During business hours, copy your files from the NetWare source to the NTFS destination. At the close of business, remove user access to the volume, and sync up the changed data (The NT Resource Kit utility ROBOCOPY’s /MIR switch will do this, for example). In the course of a day, very few files will have changed, so this will take just a few minutes. Then you can proceed to the next step.

Repermission Add permissions to the destination files so that the migrated accounts have the same access the original NDS accounts did. If your group or user account names have changed, most third-party migration software has the ability to map the accounts to each other even if the names have changed. Just make sure you save these mappings when you do the account migrations in the beginning. If you have OUs as security principals in NDS, check to see if your tool can map NDS OUs to the AD groups that mirror them for permissioning as well. Some migration tools allow you to skip adding permissions to files and just permission directories. This can speed up the process by an order or two of magnitude. NDS reporting tools or command-line scripts can tell you how common file-based permissions are on your NDS volumes, so you can decide if you can safely apply permissions only to the directories.

If you plan on using disk quotas in AD, then make sure you can retain file ownership during file and folder migration. If you simply copy the files from NetWare volumes, then you will become the new owner of NTFS volume.

Save All Your Logs When a file access problem shows up, it’s easy to fix it: Grant the user the new permission and relocate the missing file. But a minor problem, like the proverbial iceberg, might be a symptom of a deeper one lurking beneath. If someone should have had access to a file but doesn’t, check the logs to see how it was missed and you’ll probably find other things that were missed too. You can’t do these kinds of postmortems if all your logs aren’t centrally preserved.

Printers
While some migration software can reproduce the permissions of your NDS printers on NT print queues, most printers aren’t secured tightly, so this is rarely useful. The way NDS and NT/AD handle printers is too different to automate effectively, so you’ll probably need to create new print queues on Windows manually. But once you’ve got the print queues set up, you can use Group Policy and login scripts to help push out the new printer assignments to the users’ desktops.

The Closed Set Problem Before your users can begin logging in exclusively to AD, they must have access to all the data they had in NDS. The trick is to break up your migration into small, manageable chunks of user and group accounts and the data they access. These "chunks" of accounts and data is called "closed sets" in migration terminology. If you have a distributed company with very little cross-site collaboration, your closed sets can be easily broken out into each geographical site. But it's not always so easy. Sometimes you just can't specify a closed set smaller than your entire NDS network—so much for manageable chunks! One solution to this is to change the access permissions on the NDS data. The users left behind will have read-only access, while the users caught up into the AD rapture will have full access. Services for NetWare version 5 (available from Microsoft for a nominal charge) can figure in your transition strategy as well. It has both Gateway Services for NetWare, which allows Windows networking-only clients access to NetWare volumes, and File and Print Services for NetWare, which allows NetWare-only clients access to NTFS shares.

Desktop Updates
Until the release of version 6, NetWare required a proprietary network client to be installed on each machine expected to access NetWare files and printers. At some point you’ll need to remove the Novell client from the migrated users’ desktops. It’s possible—though difficult—to do this remotely. This might be one case where you disregard my earlier warning about piling too much onto a migration project. If convenient, you could consider timing the user’s migration with a desktop client update (such as a hardware or OS upgrade) so that technicians only have to visit the user’s workstation once.

No Dragons Here
The greatest challenge in an NDS to AD migration is your own lack of knowledge. Trying to plan a migration can be daunting, like the superstitious sailors of old who, upon reaching the end of their maps, labeled the lands beyond with the warning: “Here there be dragons.” Rest assured, with good planning and knowledge, just like many others before you, you can successfully chart a course from NDS to AD.