In-Depth

Mix It Up with NetWare

Naturally, Microsoft wants to woo your company away from its reliance on NDS. Windows Services for NetWare is crucial to that goal. Here’s how it works.

• By John M. Gunson II
• 05/01/2001

Windows 2000 probably isn’t the first directory product you’ve ever worked with. In fact, because of the product’s relative maturity, your organization could very well be a Novell Directory Services (NDS) shop. But now that your company is considering a move to Win2K Professional and those Win2K servers are coming on board, you may be inclined to start looking at the benefits of an AD infrastructure, including IntelliMirror and RIS. In this article I discuss two methods for migrating from Novell’s NetWare to Win2K; explain how to work with Microsoft’s migration tool of choice, MSDSS; and go through how to move data from your NetWare servers to your new Win2K servers. Along the way I share insights about moving from ZENworks to IntelliMirror and from GroupWise to Exchange 2000. I also share some troubleshooting tips that could come in handy if the work doesn’t go the way you expect.

Migration Methodologies
You have two methods for moving from NetWare to Win2K: direct migration and gradual. Direct migration implies that you intend to move all of your NetWare resources to Win2K over a very short period of time, say, a weekend. The gradual migration is, of course, a slower process. This method assumes you’ll be moving groups of users from NetWare to Win2K, and the entire process might last from a few weeks to a few months. During the gradual migration, you’ll have resources being managed in NDS as well as from AD.

If you’re in a simple environment, you’ll probably want to perform the direct migration approach. You’ll save money by doing it quickly, but also face greater risk. With the direct migration, there is no easy fallback path to NDS. If you’ve spent years perfecting your NDS tree and have branches spread over the globe, you’ll most likely go the route of gradual migration. In this scenario NDS and AD co-exist for a period of time. The risk is less but the cost more.

That Synching Feeling
Microsoft Directory Synchronization Service (MSDSS) provides synchronization between AD and NDS or Bindery Services. This tool lets you manage both directories from one management console (AD Users and Computers), thereby letting you provide access to NetWare resources through NDS and begin assimilating AD into your environment. I believe this will be the route most companies follow on the road from NetWare and NDS to Win2K and AD. The risk of trying to pull off the direct migration strongly outweighs the benefits of having a one-directory shop after a weekend’s worth of work.

MSDSS is a component of Windows Services for NetWare version 5 (SFNv5), available from Microsoft for $149 for an unlimited license. SFNv5 contains three main utilities for Win2K and NetWare integration: MSDSS, the File Migration Utility, and File and Print Services for NetWare. The File Migration Utility (FMU) uses log files from MSDSS to facilitate the migration of files from NetWare file servers to Win2K while maintaining the user’s permissions on the files. More on this later.

File and Print Services for NetWare allows your Win2K or Windows NT Server to “act” like a NetWare server for clients who use the IPX/SPX protocol. This lets you replace a NetWare server with a Win2K serve, and is transparent to clients.

MSDSS—the star of the SFNv5 package—provides either one-way or bi-directional synchronization between AD and NDS or one-way synchronization between AD and bindery services. One-way synchronization is the movement of directory data from AD to NDS—that is, when you make a change to a user object in AD, the change is synchronized to the user object in NDS. Bi-directional synchronization takes this one step further. Changes in AD are synchronized to NDS, and changes to objects in NDS are also synchronized back to AD.

You’d primarily use the one-way synchronization in migration scenarios—when transferring management of the directory data to AD while continuing to keep NDS updated for the clients who are still dependent on NetWare resources. Bi-directional synchronization is used when you intend to have a dual-directory environment. If you’re keeping NDS and AD around simultaneously for a long time and you’ll be managing each directory from its respective application, then you’ll need to synch changes between the two.

There are a few prerequisites for using MSDSS. You must run it on a Win2K domain controller. You must also install Novell’s Client for Win2K on this server. You should have at least 256MB of RAM, plus an additional 30MB to accommodate MSDSS. If you’re going to host multiple synchronization sessions on the server, you should consider going to 512MB or even higher.

Using MSDSS to foster the move from NDS to AD provides several benefits. First, it can allow you to quickly model your NDS tree in AD. This is done through a reverse-synchronization, where MSDSS allows NDS to push the objects in its directory over to a container in AD.

A second benefit is the ability to manage all of your objects from one interface. Once you’ve set up a synch session between AD and NDS, you can use AD Users and Computers to manage the objects. Changes made here will synch with their NDS equivalents.

Last, you get a form of single sign-on and password synchronization. Once you’ve done reverse-synchronization from NDS, you can perform one-way password synchronization. Figure 1 shows how this happens. The process involves passing passwords from NDS to AD, authenticating on AD, then synching changes back to NDS.

Figure 1. 1) The NDS user objects are copied into AD through reverse synchronization. The passwords are set to one of several possible values via the password scheme—password equals the username, set to blank and so on. 2) The original password in NDS doesn’t change yet. 3) The user authenticates through AD from his or her workstation and is asked to change the password. 4) Once that’s been done in AD, the new password is synchronized back to NDS. 5) At this point, the password for the user object changes to reflect the new password from AD.

Shazam! Password synchronization between AD and NDS! This doesn’t really change much for users who still need to access NetWare resources. They’ll still log on using the NetWare Client and again for the Win2K AD. (By using NetWare’s Client, this all gets wrapped into one GUI. However, since the passwords have been synched between AD and NDS, users only have to type passwords once.)

Now that you’re more familiar with MSDSS, let’s look at the mechanics of the migrations.

Migration Mechanics
Whether it’s direct or gradual, both kinds of migration are fairly complex projects. However, both approaches also share a number of elements.

First, they need a lot of planning. This should consist of a thorough documentation of your existing environment, including number and types of servers, OS versions, network addressing and so on. The purpose of this detailed inventory is to eliminate any surprises when you actually begin the migration. There’s nothing worse when planning to replace an aging CD-ROM tower than to learn that it was actually a 100-disk jukebox—and you only ordered a 30GB CD-ROM server to replace it. Also, this alerts you to any potential problems, such as mismatched frame types, outdated service pack revisions, and so on. You should be intimately familiar with your network before attempting to pull off a major network OS migration.

Second, you need to determine how to conduct the migration. Here you’ll want to choose the order in which your sites will be migrated. There are two schools of thought when choosing which goes first. Some admins recommend migrating the largest environments first—naturally, they’re probably the heaviest users of the network, and getting a lot of users moved quickly is easily accomplished in this scenario. Others recommend starting with the outlying small offices. By migrating these users first, you can identify problems with the migration planning; it will only affect a small number of users, rather than a large office (which usually houses the CEO, CIO and other upper management). I would choose to go with the smaller offices first—maybe if only to test the process on one office—and then move on to a larger office. Less risk is better.

Third, you need to build a test environment. There’s no substitute for working out the kinks of a complex migration in a non-production environment. Your test environment should realistically model your production environment. Anything that will be affected by the migration should be in this test environment.

Once you’ve solidified your plan, run a pilot migration for a small representative sample of users to verify that everything works against production machines. Once these tests confirm that everything is working smoothly, proceed to your master plan and start the production migration.

The complexity of the gradual migration comes from the migration’s phased nature. You won’t have a one-directory environment until the very end. At first, you’ll continue to have NDS as your primary directory, with a small number of users being authenticated by AD. As time goes on, AD will take precedence, with the number of NDS users dwindling. You’ll probably uncover problems in maintaining connectivity with NetWare-centric services, such as ZENworks and GroupWise. You shouldn’t see an interruption in service for those users who are still being primarily managed by NDS. Testing should uncover those problems long before your migration affects the production environment.

Configuring MSDSS
Now let’s look at how you can install and configure MSDSS for a one-way synchronization session or a migration. You’ll use the one-way synchronization for gradual migrations and MSDSS’ migration feature for a direct migration. Installing MSDSS is simple via the MSDSS.MSI program, which is on the SFNv5 CD under the MSDSS folder. Then it’s time to set up a synchronization session (Figure 2).

Figure 2. You’ll find the option to install Microsoft Directory Synchronization Services under the MSDSS folder on the Windows Services for NetWare CD.

Figure 3. The New Session wizard lets you designate the type of synchronization session to perform.

When you start MSDSS, it looks like any other MMC console. To start the wizard for configuration of a one-way synchronization session (Figure 3), choose Action from the top menu, then New Session. Choose Novell Directory Services from the drop-down list and the radio button for one-way synchronization (from AD to NDS or Bindery). Choose Next.

Next, select the AD container where you’ll sync the NDS data. Figure 4 shows this location stored in LDAP format after you navigate the directory from the Browse button. Depending on how many domain controllers you have, you may need to type in the name of the DC that will be running the sync session. (MSDSS fills in the name of the server hosting the current instance of MSDSS by default.)

Figure 4. The next step is to select the AD container for synching to NDS.

Figure 5. Now choose the NDS container to be synchronized.

Now choose the NDS container to synchronize (Figure 5). Just browse the NDS tree to find the correct location. I recommend choosing a container high in the tree, as opposed to creating numerous sessions at the lower organizational unit level. This will make things easier from a management perspective. You’ll have a more complete tree structure being modeled in AD, as opposed to numerous OUs being synched in parallel with each other. It also increases performance, since the server isn’t trying to manage multiple sessions when it could be managing just one or two.

MSDSS has a limit of 50 synchronization sessions per server. This is a soft limitation. From a performance standpoint, more than 50 sessions would overwhelm a reasonably configured server. So it’s best to balance your sessions across multiple servers when you get near that 50-session limit. (You probably won’t need to have 50 sessions unless you’re synching with bindery-based servers, each of which requires a unique session.)

Notice in Figure 5 that the user name is written in long notation. If you don’t write the user name in this format, you can’t proceed. MSDSS gives an error stating that it can’t authenticate because the network path wasn’t found.

After choosing the AD and NDS containers to synchronize, you’ll be asked if you want to perform an initial reverse synchronization. Remember, this is where NDS becomes the “publisher” and pushes its data into AD. I recommend doing this for the one-way synchronization.

The Password Options box gives you a number of choices for managing your passwords during the sessions. You can set the passwords to blank, the user name, a random value, or a custom value. This change affects the account when it gets reverse-synched; it doesn’t affect the original NDS data until you start forward-synching after the migration.

Next, choose how to map directory objects as they’re synchronized between NDS and AD. This feature comes in handy if you’re renaming containers in AD. Otherwise, the default object mapping will work fine (Figure 6).

Figure 6. The Object Mapping Scheme lets you specify what objects get synched.

Now it’s time to finalize the one-way synchronization session. You’ll be asked to provide a descriptive name and then to confirm all of your settings. Then the initial reverse synchronization session takes place. A progress dialog box shows the status of the reverse synchronization. When this is complete, you’re ready to go. Figures 7 and 8 show the original NDS tree from within NDS Admin, and the synchronized data within AD. As you can see, the data structure looks identical.

Figure 7. The original NDS tree...

Figure 8. ...compared to the NDS tree within Active Directory.

Once the one-way session is created, you can begin managing the objects being synchronized from within the AD Users and Computers console. Any changes will be synchronized back to NDS. As you migrate users and their NetWare resources to Win2K and AD, you can choose to delete their objects from NDS or wait until everyone has been migrated and then decommission NDS and all the NetWare servers. From a fallback perspective, it’s prudent to allow MSDSS to continue to synchronize the two directories (with all user objects intact) in case something arises that forces you to return to the NetWare environment.

Configuring MSDSS for a migration is similar to creating the one-way synchronization session, with a few differences. First, you’d choose to do a migration instead of a one-way synchronization (see Figure 3). Second, you’d select the Migrate Files option. You aren’t given the option to perform an initial reverse synchronization (because the migration is a reverse synch all by itself). This operation copies the NDS objects to the container you specify. If you select the Migrate Files option, the wizard creates a text file that maps the NDS user accounts with the new AD user accounts. This text file will be used by the File Migration Utility to “know” how to translate file permissions from NetWare to Win2K.

Fast File Moves
Once users move over to Win2K, their files should follow, right? The File Migration Utility (FMU) is just the tool to make this process as painless as possible. This utility copies both files and trustee rights over to the new Win2K home and converts those trustee rights to Access Control Lists (ACLs).

The FMU uses the text file generated by MSDSS to determine who gets access to the files copied to the Win2K server. If you move users around once they’ve migrated to AD, this process will likely fail, as the trustee right-to-ACL map won’t know how to match up users. The moral of this story? Don’t re-arrange users in AD until you migrate the files! Another gotcha is that you must move the users to AD before you move the files. Obviously, you can’t assign rights to a file if the user doesn’t exist first.

Using the FMU is pretty straightforward. When you start the program (Start | Programs | Administrative Tools | File Migration Utility), you must provide the location of the migration log generated by MSDSS (Figure 9). MSDSS tells you where it’s located just prior to ending the migration session. By default, the migration logs are stored in C:\WINNT\system32\Directory Synchronization\Session Logs. Next, click on the Load Data button to read the mappings into the FMU. If you’re curious to see the user mappings, click on the View Maps button. Then click Next.

Figure 9. The file migration process begins when you designate the location of the migration log. MSDSS tells you where it’s located just prior to ending the migration session.

Figure 10. Next, you must log into NDS.

Next, you’re asked to log in to NDS (Figure 10). Click on the Log On to Novell button. It’s best to just do this, even if you’ve logged in before. Then choose Next. Now it’s time to choose how the NetWare volumes and folders will map over to Win2K (Figure 11). From the left side you choose which folder in NetWare you wish to migrate. On the right side, you specify a Win2K server share for the files to be copied to. Click the Map button in the center to create the mapping, which is displayed in the bottom window.

Figure 11. Then you choose how the NetWare volumes and folders will map over to Win2K.

The fourth wizard step lets you set various logging options for the migration. These logs are optional (and turned off by default). I recommend leaving them off, unless you experience errors during a migration. Next, you can conduct a “trial” copy of files from the NetWare server to the Win2K server (Figure 12). This is called a “Scan.” You must complete the scan in order to proceed to the actual migration. Click on the button marked “Scan” and wait for the Status on the right side to show “Scan completed successfully.” Then you’ll be permitted to finish the job.

Figure 12. The next step is to do a trial copy of files.

Figure 13. When the migration of files is done, the Status indicator shows, “Migration completed successfully.”

In the final step you conduct the migration. The wizard shows the status of the file migration and a progress meter.

Be careful about permissions when working with the File Migration Utility. When you initially migrate the files over to Win2K, they’ll have retained their NetWare trustee rights. In most cases you won’t be logged into AD with one of the NetWare accounts when you migrate the files. Thus, when you go into Windows Explorer to check the results of the file migration, you’ll be denied access to the migrated NetWare data. Don’t panic! Log in using one of the migrated NetWare accounts that had Supervisor rights to the migrated files, then assign rights to the correct Win2K users and groups. This alleviates access problems.

If you don’t plan on keeping the old Admin account around after the migration, you can remove it from the ACL on the migrated files once you’ve assigned new users and groups to the files.

Do you have to use the FMU to migrate files? Absolutely not. You can manually copy the files from the NetWare volumes to Win2K and then reassign the access rights. You might find this more efficient than using the FMU, especially if you don’t have elaborate trustee rights on your NetWare files. And you can always write a batch program or script to do the copying for you.

Odds and Ends
Well, we’ve migrated users from NDS to AD using MSDSS and migrated files using the File Migration Utility. There are only a few odds and ends left before we can decommission our NetWare environment.

Let’s look at the client environment. You’re likely running a mix of desktop OSs, from Windows 95 to Win2K. Once your users are being managed from AD and no longer need to access files on NetWare servers, you can remove the NetWare clients from their systems. This might also be the perfect opportunity to upgrade their machines to Win2K, if necessary.

Next, you’ll need to re-create your login scripts in Win2K. Most NetWare users are used to having drives automatically mapped for them when they log on. You should probably keep this tradition alive (for the time being) until your users become used to the new environment.

Are you using ZENworks? You’ll need to spend time thinking about the conversion of packages from ZENworks to IntelliMirror. There isn’t a direct migration path from .AOT files to .MSI packages. You’ll probably have to repackage your applications using an .MSI packager, like Wise Solutions’ Wise for Windows Installer (www.wisesolutions.com) or WinInstall LE (found in the valueadd\3rdparty\mgmt\ winstle directory of the Win2K Server CD). Other features of ZENworks, like Remote Control, Asset Management, and the like aren’t reproduced in IntelliMirror. You’ll need to consider another product like SMS to accomplish those tasks.

If you’re using Novell’s GroupWise for messaging and intend to migrate to Exchange 2000, Microsoft has a nifty utility that comes with Exchange 2000 for migrating accounts from various mail systems: Exchange Server Migration Wizard. It works well for GroupWise 4.x and 5.x to move calendar and task information (albeit, in Schedule Plus Interchange format). The one big issue with migrating messaging information (and this isn’t confined to a GroupWise-to-Exchange migration) is that every user must give proxy access to the migration account in order for the migration to succeed. Unfortunately, there’s no easy way to do this—every user must perform this step to his or her account. Once that’s done, the migration will perform flawlessly. You’ll even get a report listing who hasn’t granted the proper rights. Users will be able to use Outlook Web Access to check e-mail on the new Exchange 2000 server.

Troubleshooting the Migration
What kind of problems can you expect to encounter doing this migration? Let’s cover a few that have surfaced in my experience.

• Can’t install MSDSS? Make sure you’re trying to install on a Win2K domain controller with Service Pack 1 installed. Also make sure you’ve installed the Novell Client for Win2K.
• Can’t authenticate into NDS when creating a synchronization session? Make sure you’re entering the username in the proper format: CN={username}.OU=XXX.O=XXX. Also confirm that you have connectivity to the NetWare server or NDS tree.
• Lost group members after performing an MSDSS migration? You might want to create your session higher up in the tree. It seems that groups migrate best when all of the members migrate at the same time. By starting higher up in the NDS tree, you’ll increase the odds of getting more users in the session.
• Can’t access the folder you’ve just migrated files into? This is probably an ACL issue. Make sure the NetWare account with Supervisor rights has been given the right to log in locally to the server. Then log in to AD using this account. You should now have rights to view the migrated data. Add the appropriate Win2K users and groups to the ACL (preferably at the folder level), set the appropriate inheritance flags, and then log out. Log in with an account that has administrator rights and check for access.
• Users complaining that they can’t use an application formerly provided from ZENworks? You’ll need to repackage the application and use IntelliMirror and Group Policy to publish or assign the application to users running Win2K Professional; you’ll need SMS to provide the same functionality to legacy clients.

A Great Way To Go
As Win2K becomes more pervasive in our environments, the need to reduce the number of directories has become more important. NDS is the biggest competitor of AD in the corporate directory space. That means it’s in Microsoft’s sight. If you’ve chosen to go with Win2K Professional, it should be in your site too, as it makes sense to standardize on Microsoft’s directory product.

MSDSS provides a great way to manage a migration from NDS to AD. By providing one-way and bi-directional synchronization between the two directory products, you can move your NDS data to AD. Whether you’re conducting a direct or gradual migration, MSDSS will safely move and synchronize your directory data.