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.
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.
Additional
Information |
Microsoft makes several NetWare
migration-related technical
documents available on its Web
site. These are probably the
most helpful ones:
|
|
|
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.