You’ve just been given the daunting task of migrating from Novell NetWare to Windows 2000. You have hundreds (maybe thousands) of users in your Novell Directory Services (NDS) tree, and the thought of recreating all those accounts manually is enough to give you nightmares. You need a solution, but management won’t approve the purchase of a third-party migration tool. In this article, I’ll give an overview of Microsoft’s proprietary synchronization tool, explain how it works, and then describe lessons I learned during a NetWare-to-Windows migration that provided for the continued existence of NetWare.
MSDSS: What it is and how it works
MSDSS is an acronym for Microsoft Directory Synchronization Services, and it is part of a larger package called Services for NetWare v5.0 (SFN). The other major component of SFN is File and Print Services for NetWare (FPNW), which allows a Windows 2000 server to essentially imitate a NetWare server. MSDSS does just what it says: It synchronizes directories. It synchronizes user, group, and container objects between Novell’s NetWare Directory Services (NDS) and Microsoft’s Active Directory (AD).
MSDSS communicates with AD and NDS using Lightweight Directory Access Protocol (LDAP). A session is created that maps a container in AD to a container in NDS. An initial reverse-synchronization occurs, which reads the entire NDS tree and copies user, group, and organizational unit (OU) objects into AD. (Printer, application, and other objects in NDS do not get synchronized.) If a long-term migration or coexistence is planned, a schedule is then set up to perform reverse synchronization (NDS to AD), forward synchronization (AD to NDS), or both.
Cutover migration vs. long-term migration or coexistence
A cutover migration is quite simple. The initial reverse synchronization is the main task needed for this kind of project. File and print services, client configuration, and other issues will play a much bigger role in this type of migration. MSDSS performs virtually flawlessly in this type of migration.
With a long-term migration or coexistence, you have to take more care and do more planning. You will have to consider issues such as how you will be doing your future administration—from AD, NDS, or both—and how passwords are changed and synchronized.
Synchronization: One-way vs. two-way
Once the initial reverse synchronization has been completed, and objects exist in both directories, you must decide in what direction synchronization will occur. A reverse synchronization reads all the objects from NDS, filters out the objects that haven’t changed, and then writes changed objects to AD. A forward synchronization is much more efficient, in that it reads only the changed objects from AD and writes only the changed attributes back to NDS.
While forward synchronization is more efficient and allows synchronization of passwords (see section below), there are situations in which reverse synchronization or two-way synchronization is a better choice. Let's look at three scenarios that describe situations in which one synchronization method is most appropriate.
Company A is primarily a Novell shop and plans to stay that way. A Windows 2000 domain was created to centralize accounts for a terminal server farm. There are no plans to migrate to Windows 2000 as the primary network operating system (NOS). In this situation, reverse synchronization would be ideal. All resource administration would be done using NetWare Administrator or other NetWare tools. Any changes made in the Microsoft Management Console (MMC) would not be synchronized to NDS.
Company B is planning a full migration to Windows 2000 and wants to force administrators to use the MMC for administration as soon as possible. Forward synchronization is best here. Any changes made in NetWare Administrator would not be synchronized to AD. All administration would be done with the MMC and would utilize the most efficient synchronization method.
Company C is implementing a long-term, coexistence strategy. Novell ZENworks is used for application deployment, and Microsoft Exchange 2000 has been deployed for e-mail. Administrators need access to both NetWare Administrator and the MMC for administration. In this situation, two-way synchronization is necessary, as it allows changes made in either directory to be synchronized with the other.
When you create a synchronization session, you have four options for setting passwords in AD as users are created:
- Set blank passwords.
- Set passwords to be the same as the username.
- Set passwords to a random value (password assignments are stored in a file).
- Set all passwords to a static value.
If you are moving from NDS to AD, remember these facts about passwords in AD. AD cannot read the password value from NDS. If a user or administrator changes an account password in NDS, that password won’t be synchronized.
AD can set the value of the password in NDS. When synchronization occurs, NDS views the password change as an administrative password change (whether it was done by the user or by an administrator is irrelevant). When an administrative password change is performed in NDS, NDS will automatically expire the account.
Because of the first two considerations in the list above, the only successful way to synchronize passwords is to make all password changes in AD and to turn off password expiration on the NDS accounts.
A password change will take time to complete because you have to wait for synchronization to occur before the password is the same in both directories. Microsoft includes a Web-based password reset utility, which bypasses the synchronization wait time, but only administrators can use it.
Lessons learned from a recent project
One of my clients (I’ll call them XYZ Corporation) has a fairly large network consisting of a corporate hub, approximately 50 remote locations, and approximately 1,500 users/workstations. The network operating system was primarily Novell NetWare 5.0/4.11, with a small (50 users) NT domain for the Citrix farm. The goal was to create a new Windows 2000 AD structure, which synchronized with the NDS tree. Since NetWare was going to continue to exist (at least for the foreseeable future), long-term coexistence was needed.
Since Windows 2000 domains still require unique account names, my first task was to eradicate duplicate account names from the NDS structure. Incidentally, MSDSS handles duplicate account names by creating account names with a number after it; multiple JSmith NDS accounts become JSmith, JSmith1, JSmith2, etc. in AD. Once that was completed, I set about building the domain controllers for the new domain. According to Microsoft, MSDSS should be installed on a domain controller with the Novell client.
Next, I began creating synchronization sessions. This was a pristine, nonproduction domain, so I could take my time and determine the best way to perform the production synchronization. The biggest lesson learned in this phase is that I needed to synchronize the directories at the highest level possible in the tree. If I created multiple sessions (one for each major OU, for example), any group membership or permissions that crossed OUs would not be saved.
Let’s look at XYZ Corporation as an example. In the NDS structure, XYZCORP is the primary organization, and NE, CO, and IA are OUs. Now let’s assume that a separate synchronization session is created for each OU. Let’s also assume that the user JSmith exists in the CO OU and is a member of the ApplicationX group in the IA OU. After reverse synchronization occurs for all the sessions, the JSmith user exists in the appropriate OU in AD, and the ApplicationX group exists in the appropriate OU in AD, but JSmith is no longer a member of that group. Further, if forward synchronization then occurs, that change is written back to NDS. So, my recommendation here is to create one session, which maps the AD domain with the NDS organization.
About a month after two-way synchronization was established in production, and everything had been running smoothly, something odd happened. All of the user objects under the CO OU suddenly reverted back to the settings they had a month prior. All changes that had been made in the last month (group memberships, password changes, etc.) were gone. Then, as I was investigating the cause, all of those same user objects disappeared from AD. I immediately shut off synchronization so that a forward sync wouldn’t delete the accounts in NDS as well. I spent the next few days on the phone with Microsoft’s Product Support Services, to no avail.
I found out that the problem was with NDS. Another month later, when MSDSS was no longer in the picture, the same thing happened again in NDS; all the NDS objects reverted back to what they were a month prior. It turned out that NDS had become corrupt from all the different versions of DS.NLM running throughout the enterprise. Obviously, it’s crucial to make sure NDS is in good health before attempting to synchronize another DS with it.
The other big lesson I learned from this project was that there is no way to manually map individual objects between the two directories. By the time I figured out that the problem was with NDS, too many changes had been made in the directories to turn the synchronization session back on. Creating a new session would have just created all new users. Once the system was broken, there was no realistic way to fix it.
Is it worth it?
All in all, I think MSDSS is a far cry better than any of Microsoft’s previous attempts at directory synchronization. I would definitely recommend this product as an inexpensive alternative for a short-term migration strategy. However, the lack of customization features and the inability to fix something when it’s broken make this tool unsuitable for a long-term migration or coexistence strategy. For more information on MSDSS, visit Microsoft’s MSDSS home page.
Have you managed a migration?
Whether it’s a straight cutover or a long-term coexistence, migrating from one system to another is a huge undertaking. Have you participated in or managed such a project? Send us your migration experiences and recommendations.