Migrating from a Novell NetWare environment to the Windows Server System

In my last job, I managed the migration of a major fashion design, marketing and retail company’s European business from Novell NetWare and GroupWise to a Microsoft platform. With a limited budget (none) for migration tools, only free utilities could be used and it worked, but was restrictive. This post discussed some of the alternatives that are available, based on a presentation from Microsoft’s Steve Plank at the IT Forum highlights event back in January.

NetWare has always been good at file and print, directory services, and management but traditionally it has lacked an application platform (although that is changing with Novell’s adoption of SuSE Linux) so many organisations have implemented Microsoft applications such as Exchange Server and SQL Server. Depending on the application, this may lead to a requirement for Active Directory (AD), and once the Windows servers for AD are in place, then it seems logical to provide file and print, or web services from the same infrastructure (IT Week recently reported that even Novell concedes that it has been losing between 12 and 15% of NetWare users every year for the last 4-5 years). This leads to a number of challenges around migration and interoperability. For many organisations, there is simply too big an investment in the existing environment to dump it all and move to a new platform, and so interoperability is a must; however by moving away from a mixed environment, support (and licensing) costs can be reduced, and the existing NetWare Directory Services (NDS)/eDirectory experience can even be used in planning the AD design.

There are a number of tools available to assist organisations with a migration to the Windows server system, the first of which is Microsoft Services for NetWare (SFN). Formerly chargeable, but now available as a free download, SFN provides:

  • File migration utility, which migrates files, preserving access controls (with some limitations as NetWare file attributes do not map directly onto the NTFS file system).
  • File and Print Services for NetWare, making a Windows server appear as a NetWare box (although only supporting the IPX transport and NetWare 3.x bindery mode – from v5.03 of SFN onwards, file and print services for NetWare, have been removed and are now available as a separate download).
  • Microsoft directory synchronisation services for NetWare (MSDSS), which provides 1- or 2-way synchronisation between NDS versions 4.x-6.x and AD; however there are some schema extensions required (which may or may not be desirable) and the Novell NetWare 32-bit client (v4.9 SP2) must also be installed (on a domain controller).

Third-party tools are also available (e.g. from Quest Software, who bought the previous Fastlane product set) and Microsoft is said to be producing solution accelerators to assist organisations in the transition.

It is important to bear in mind that data can co-exist in the two environments and that a migration is really a file copy. Therefore it is important to decommission old copies of data, to prevent two copies from being altered from users on different systems.

On the interoperability front, besides the gateway services for NetWare (GSNW) Windows server component (and client services for NetWare in Windows client operating systems), there is Microsoft Identity Integration Server (MIIS), which provides directory synchronisation, password management and user provisioning, or SFN can be used as a short term fix.

Implementing MSDSS for one way synchronisation from AD to NDS is good if AD is the focal point for management (e.g. as a short term, strategy until a move to AD can be completed), but is probably not sustainable in the long term. Two-way synchronisation allows both directories to be managed. There are some “gotchas” though:

  • Synchronisation is not real time – it works on a schedule, with an agent on the Windows side performing a push/pull operation.
  • More significantly, whilst AD does allow MSDSS to store passwords using reversible encryption, using a key which is only known by MSDSS, passwords cannot be passed from AD back to NDS as there is no reversible encryption option.

The file migration utility is actually a cut-down version of the Fastlane product, supporting NetWare versions 4.x, 5.x and 6.x as well as eDirectory 8.7.3. It preserves user permissions and provides some limited logging capabilities (although for reporting, the full product is required). Some considerations when using the tool include:

  • Data volumes (i.e. can all the data be physically migrated in the time available) – consequently, it may be appropriate to perform a trial run, then to actually migrated users and data in small volumes (scheduled for quiet times). One advantages of the migration may be the opportunity to consolidate server smaller servers into one.
  • Drive letters in document links – many Office applications, convert drive letters to UNC paths when saving documents. If the server location changes, then the link will be broken, although tools are available to assist in modifying this.
  • Encryption – encrypted files will need to be de-encrypted before they can be migrated.

There may also be migration considerations such as directory restructuring, removing the NetWare client from workstations and changes to login scripts, so whilst the free tools will be of use to many organisations, those enterprises with more than about 2000 users may wish to make use of third party tools. Quest Software’s NDS Migrator handles both object and data migration (together or as separate operations), with a central console for management which makes use of a mapping database to store metadata (either SQL Server or MSDE – although MSDE is limited to 2Gb in size).

NDS MigratorNDS Migrator is able to deal with a number of complex scenarios, as well as supporting the saving of configuration options (for a repeatable migration). Security principles are examined first, before attempting file migration, based on a file scan (during which information is written to the mapping database) and then finally a migration which uses the information from the database.

In NDS, a container is a security principle; whereas in AD, it is well known that security permissions cannot be applied to an OU. Instead, NDS Migrator creates global groups in AD called container permission equivalent groups (CPEGs), which correspond to an NDS container and are always named with a $ prefix.

NDS allows common names to be duplicated in different parts of the whereas AD common names must be unique. NDS Migrator handles this with pre-migration mapping and planning (identifying intra-NDS naming conflicts and remapping accordingly), as well as allowing for flexible migration (e.g. moving files to a new location), with a pre-migration file scan, Macintosh file support and a multi-threaded copy engine (the version in the SFN file migration utility is single-threaded).

Attribute mapping is supported, such that if NDS has been extended with additional attributes, these can be created in AD. It also handles the differences between NetWare and Windows file system permissions and file ownership (as NDS allows files to exist without an owner, but Windows does not).

It may be of interest that not all of Quest’s tools are available for purchase – some are only available to Quest’s professional services organisation, including NDS reporter (used to assess the NDS environment), workgroup migration tools, and a tool to remove the Novell NetWare client from Windows 2000 and XP clients.

In summary, there are many tools available to assist with the migration from NetWare to Windows and as with any migration, the key to success is in the planning. With careful preparation and by through becoming familiar with the tools that are available, administrators may be confident in performing a successful migration.

Links

Novell NetWare to Windows Server 2003 migration planning guide (Microsoft).
Quest NDS Migrator.

(Since I wrote the original notes for this post, the Microsoft TechNet Industry Insiders blog has carried another article on NDS Migrations, contributed by Darren Catteral from Quest Software).

3 thoughts on “Migrating from a Novell NetWare environment to the Windows Server System


  1. Hi Mark,

    Informative article, it touches on the project that I’m currently working on.

    What would be your suggestion for this scenario:
    single master domain(?) containing Novell 6 DC’s and Windows 2003 DC’s w/ AD.
    My company wants to clean up the Novell server, map its folders and users to the 2003 domain (bi-directional sync), so the users will authenticate to the 2003 domain. The company also wants to implement Group Policy (of course).

    Since both domain structures are flat, should there be any improvements that could be made to the 2003 domain?

    What would be your best recommendation on this approach?

    Thank you in advance….
    Rod


  2. Hi Rod,
    Sorry it’s taken me a few days to reply to your question – I’m not sure what you mean by “improvements” to the Windows Server 2003 domain but if you have no architectural reason to build a tree, single domain is always simple and simple is good :-)

    The main area that will impact upon your group policy design will be the organizational unit (OU) structure. I covered this in a series of posts I wrote on Active Directory design considerations

    Another good place to check out would be the Microsoft Infrastructure Planning and Design guides.

    Hope this helps! Mark


  3. thanks for the knowledge you’ve impacted into me. I’ve got a question similar to what wrote.
    It says, You are a Network Administrator for a small college, and the Engineering department has being running it own network for years with a Novell net ware server using IPX/SPX protocol. All 25 client are running windows XP professionals. The network is running a 10 base T Implementation that is physically separated from the campus network. Now you’ve being asked to bring this Department into the main campus, network as little disruption as possible to it current operation. The campus network runs windows server 2003 in a domain configuration and windows XP professionals client computers using TCP/IP Microsoft. Develop a plan that will allow clients from th Engineering department to access resources on the main campus network Discuss any question you must address before proceeding and list ant software that must be change or added to clients or server.

Leave a Reply