If you plan to migrate from NetWare to Windows Server 2003, use this guide to familiarize yourself with some of the major issues and avoid the pitfalls of poor planning.
Although NetWare has been around for a bit longer than the various Microsoft server products, both NetWare and Windows Server have been around in one form or another for a really long time. As you might expect of a mature product line, both products have evolved a lot over the years. While this evolution has given us many more features and better security than could be found in the original versions, it has been a double-edged sword. With additional features and security comes additional complexity.
It used to be fairly easy to migrate from NetWare to Windows or vice versa. However, this once simple operation has gradually turned into a major undertaking. Sure, various migration tools are available, but without proper planning your migration will be a disaster. Here are some of the various issues that you need to plan for when migrating from NetWare to Windows Server 2003.
From one directory service to another
When Novell released NetWare 4.x back in the mid-90s, they moved from a bindery-based authentication system to one based on directory services. As you probably know, Windows 2000 Server and Windows Server 2003 also use an authentication system based on directory services. You would think that this would make for a super-simple migration. Theoretically, it should be possible simply to combine the two directory services and then phase out the old servers.
Unfortunately, it doesn’t work that way. Even though both directory services are LDAP-based, they just don’t match up to each other very well. Differences between basic methods used for replication and directory partitioning mean that the directory service name space used by NetWare is not really suited for use by Windows.
Because of this, you may find yourself having to change your directory structure. The basic directory structure is not the only difference between the ways that the two operating systems implement directory services. There are about half a dozen critical services that work differently between the two operating systems, and you must bear this in mind when planning for a migration.
One of the major differences is that while both operating systems rely on DNS, Windows uses Dynamic DNS. This means that during the migration process, you must make sure that you have at least one Windows-based DNS server. Likewise, DHCP is affected in a similar manner. Both operating systems support DHCP, but only the Windows DHCP services are capable of working with the DNS dynamic update protocol.
You may want to consider moving DHCP operations to a Windows Server. This isn’t an absolute requirement in most organizations because both Windows and NetWare DNS servers can interoperate through standard zone transfers.
Another thing you need to pay attention to is your Web servers. Although NetWare and Windows both support hosting Web sites, the implementations are very different. NetWare assumes that your Web sites will be coded primarily in JAVA and HTML. Windows, on the other hand, is designed for hosting Web sites that are based on the .NET Framework.
Perhaps the biggest issue that you'll need to focus on when planning for a migration is security. When planning your migration, you need to consider whether long-term interoperability will be needed between the two network operating systems. The reason for this is that you'll need to design a security infrastructure that both network operating systems support. Fortunately, there are a lot of overlapping security features.
For example, both network operating systems support SSL, X.509, and PKI. Both operating systems also offer similar policy elements that can be used to lock down the network. If you're planning for long-term interoperability, you should focus on trying to use security mechanisms that are supported by both operating systems. You must keep in mind, though, that the two operating systems use very different authentication mechanisms. Windows uses Kerberos over IP. NetWare uses the NetWare Core Protocol over either IP (NetWare 5.x and later) or over IPX.
Migrating users and groups
Another aspect to the migration that requires some planning is how you will migrate user and group objects from the NetWare directory to the Windows Active Directory. To assist with the migration, Microsoft offers a tool called MSDSS. It is Microsoft’s Directory Synchronization And Object Migration Utility. As the name implies, this utility is used for migrating objects from one directory to the other. Although Microsoft does give you a utility to assist in migrating user and group objects, migrating from NetWare to Windows Server 2003 isn’t as simple as running this utility.
Prior to running MSDSS, you must determine if you want to perform a one-time migration or if you need to perform a staged migration. The type of migration that will be appropriate for your network really depends on your organization’s complexity and whether or not you intend to have a long-term co-existence between Windows and NetWare.
If you're planning on making a complete switch to Windows Server 2003, you'll want to do a one-time migration of directory objects. However, you might not be able to if you have applications on your network that depend on the NetWare NDS directory. For example, if you have an NDS-aware mail server on your network, it will cease to function if you move all of the directory objects over to a Windows server. In such a case, it's usually better to use a staged migration, which will allow you to initially migrate objects that the application does not depend on. After figuring out what to do about the NDS-dependent application, you can migrate the rest of the objects later.
Even if your organization is free from NDS-dependent applications, MSDSS might not be able to migrate everything. Microsoft designed MSDSS to migrate the most common types of objects from NDS to Active Directory. This includes objects such as user accounts, groups, distribution lists, and OUs. Unfortunately, this leaves a lot of different types of objects that must be manually migrated. Such objects include computer accounts, printer objects, and application objects. This limitation isn’t as bad as it sounds, though.
If you're moving away from NetWare, there's no reason to even have a NetWare-based computer object in the directory. Rather than migrating the computer object in such a case, you'd remove the NetWare requestor from the workstation and replace it with a Windows client. After doing so, you'd join the computer to the new domain, which would automatically create a new computer account within the Active Directory.
However, if you decide to manually migrate an object from one directory to the other, you must also manually migrate the object’s security attributes. I should mention that third-party utilities are available that will migrate all of the objects automatically. A good example of such a product is Quest NDS Migrator.
Another issue that you need to be aware of is that when you use MSDSS to automatically migrate objects, the objects might not be placed where you'd expect them to go within the Active Directory. As I mentioned earlier, there are some fundamental differences between the way NDS and Active Directory are laid out. The differences in the way that the directories are organized account for the weird way that MSDSS puts migrated objects into the Active Directory.
When MSDSS migrates objects, it attempts to mirror the general object hierarchy found within NDS. The reason is that doing so allows you to retain your previous directory structure. You'll be instantly familiar with the directory layout. As you'd probably expect, NDS user and group objects are converted to Active Directory users and groups. But the similarities end there.
NetWare has an object type called a container. Since Active Directory doesn’t have a container object per se, all NDS containers are converted into OUs during the migration. Another discrepancy between the two directory structures is that NetWare uses a directory object called an organization, which does not have an Active Directory equivalent. To get around this problem, if MSDSS encounters an organization object, it creates a domain local security group to take the organization object’s place.
Files, folders, and permissions
There's more to a network operating system migration than simply migrating directory service objects. You'll also have to migrate users' files and folders and the corresponding permissions. This is a fairly obvious step in the process if you're phasing out an old NetWare server, but you might be surprised to learn that you'll have to perform a file, folder, and permission migration even if the files aren’t moving.
For example, imagine that you have all of a user’s files stored on a NAS box. Since a NAS box is not running a true operating system, it might seem as though you don’t have to do anything with it. However, even though the NAS box isn’t a NetWare server and isn’t being migrated, the files contained on the server have NetWare-based access control lists associated with them. This means that each file has a specific list of users that are allowed access.
If you were to migrate your users from NDS to Active Directory, however, the permissions that are assigned to the files would cease to be valid because they reference NDS objects that no longer exist. Therefore, you'll have to perform a procedure to re-establish the proper security related to each file. For the purposes of this article, I'll assume that the files being migrated reside on a NetWare server and need to be physically moved in addition to having their permissions reset. Just keep in mind that situations such as the one that I just described are performed in a similar manner, but don’t require moving the files.
The easiest way to migrate files and folders is to use MSDSS in conjunction with the File Migration Utility. In case you're wondering, both utilities are included in the Services For NetWare.
Before you attempt to migrate any files, there are a couple of prerequisites that your Windows server must meet. First, you must have already used MSDSS to migrate the NDS directory objects to the Active Directory. Unless an MSDSS migration has been completed, all permissions to the various files and folders will be lost and will have to be manually rebuilt. The other prerequisite is that the destination volume on the Windows 2003 Server must be formatted with NTFS. Volumes running FAT-16 or FAT-32 are incapable of associating permissions with files and folders.
The process of migrating files and folders is extremely simple compared to the process of migrating directory objects. The first step in the process is to run the MSDSS utility. This time, though, you'll select the Migrate Files check box. Doing so won’t actually migrate any files, but it will build a log file detailing which files have and have not been migrated.
Next, you'll use the File Migration Utility to actually migrate the files. You have the option of migrating the files all at once or of migrating files in batches. The log file that was created by MSDSS allows the File Migration Utility to keep track of which files have and haven’t been migrated.
The migration process is pretty simple. The file structure is copied to the destination server in exactly the same way that it resided on the source server. Likewise, the file system permissions used by NetWare are very similar to those used by Windows, so translating permissions isn’t a problem.
One notable exception is that the NetWare file system makes use of a permission called Modify, for which there is no Windows equivalent. As a part of the migration process, anyone who has modify permissions to a file on a NetWare server will have read permissions to the file once it has been migrated. This is only the default setting, though, and the File Migration Utility allows you to give users with modify permissions on the NetWare server read/write permissions to the files once they have been moved.
Above, I said that the files are copied to the Windows Server in exactly the same way that they existed on the NetWare server in order to preserve the directory hierarchy. While this statement is absolutely true, you do have other options. The File Migration Utility gives you the option of mapping specific directories to specific Windows shares. You also can map multiple NetWare volumes to a single folder or share point on a Windows server.
Gateway Services for NetWare
In a lot of my previous NetWare migration articles, I've talked about using Gateway Services for NetWare as a migration tool. In case you're not familiar with Gateway Services for NetWare, it's a service that allows Windows clients to pass through a Windows server to gain access to file and print resources residing on a NetWare server.
Gateway Services for NetWare worked by pointing a Windows file share to a location within the NetWare server’s file system. Users who needed to access those files could navigate to this special share point and be redirected to the NetWare file system. The Windows administrator would control access by setting share level permissions. A gateway service account was used to allow the Windows server to log into the NetWare server.
Although Gateway Services for NetWare was a good idea, it had some major security problems. When a user passed through a share point to access resources on a NetWare server, the user’s share point permissions applied at the current directory level and also applied to all files and subdirectories beneath it. There was no way of restricting userd from accessing files within a subdirectory beneath a directory that they had been given access to. For this reason, Services for NetWare was excluded from Windows Server 2003.
So why am I telling you this? Imagine that you have used MSDSS to migrate all of your NetWare users over to Active Directory, but you have not yet had time to migrate everyone’s files. Services for NetWare would provide a way for the users to access their files until you could migrate them. You would just have to be careful about setting up the various share points so as not to accidentally give someone access to an unintended file or folder.
If you decide that Services for NetWare might be helpful, you can implement it by bringing a Windows 2000 Server into your domain. Although Services for NetWare has been omitted from Windows Server 2003, it was a standard feature in Windows 2000.