One of a network administrator’s biggest challenges is linking two completely different networking platforms together in a way that allows them to operate seamlessly within a business environment. A common type of multi-platform connection involves linking Windows and NetWare networks. In this article, I’ll explain some of the issues involved in joining a NetWare network to a Windows network and why Windows Services for Netware is a better choice for the job than Gateway Services for NetWare.

Why avoid Gateway Services for NetWare?
When I was working at my first network administration job back in the 1990s, a close friend who I respected very much told me that the trick to being a good administrator was to make complex technology invisible to the end user. My friend went on to say that it doesn’t matter how many hoops you have to jump through to make a connection work—the end user should never see any part of it beyond what they’d see when connecting to a normal network resource.

When you look at Gateway Services for NetWare, this advice seems especially fitting. Gateway Services for NetWare does a great job of hiding the technology behind the link to the NetWare server. Gateway Services for NetWare functions by placing a NetWare client onto a Windows server. Once the Windows server has established a link to a given NetWare resource, it maps a network drive letter to that resource. The Windows server then establishes a share point on the logical drive, which allows Windows clients to access the NetWare server through the share point.

Gateway Services for NetWare has been around since the days of Windows NT. It’s mature, performs extremely well, and is invisible to end users. Unfortunately, there’s one glaring problem: It’s a huge security risk.

There are a couple of reasons why Gateway Services for NetWare is such a security risk. First, it uses a single user account for access to all NetWare resources. This means that whether you’re an administrator, a guest, or somewhere in between, you’ll have the same permission set on the actual NetWare server when passing through the gateway.

To get around this problem, Windows uses share-level security to guard the share point. This means that, even though everyone has identical file-level access to the gateway, the share point on the Windows server controls security. So some users might be assigned full access, while others will be assigned read-only access or even no access at all.

The reason why share-level access is so insecure is that each share point is completely independent of the other share points. If you create a share point to a NetWare resource, users have the level of access that you’ve granted to them, not only to the shared folder but also to all subfolders beneath it. You can’t block access to a subfolder just by creating another share point because share points function independently of each other. A share point is only an entry portal; it does nothing to control security once the user has entered the share point.

Therefore, in a Gateway Services for NetWare environment, there’s no way to change the access level on a subfolder. The only real way to truly control access to it is to design your shared folder structure so that all share points are created at the lowest possible level in the folder hierarchy, and in a way that makes it impossible for any two share points to overlap.

As you can see, even a well-designed NetWare gateway is risky at best. Fortunately, there’s another solution for linking Windows and NetWare networks—Windows Services for NetWare.

Windows Services for NetWare 5.0
Rather than simply providing gateway functionality, Windows Services for NetWare 5.0 (SFN5) is actually an entire suite of programs, each component of which is designed to help you seamlessly operate in both environments. SFN5 operates under the assumption that your primary network is based on NetWare and that you want to introduce Windows 2000 into the existing NetWare environment. You can use SFN5 to migrate your entire NetWare network to Windows 2000 at a later time. Likewise, you can continue to use SFN5 to bridge the gap between Windows and NetWare, even if the Windows network eventually outgrows the NetWare network.

About the only time that it wouldn’t really be appropriate to use SFN5 would be in a situation in which you already have a Windows network, and you want to create a NetWare network from scratch and then link it to the Windows network. In such a case, SFN5 would probably get you by, but it may not be the best choice of products for that particular situation.

Now that you have an idea of the purpose of SFN5, I’ll describe the various components that are included with it. The major components are:

  • The Microsoft Directory Synchronization Service
  • The Microsoft File Migration Utility
  • File and Print Services for NetWare Version 5

The Microsoft Directory Synchronization Service
The first of SFN5’s main features is the Microsoft Directory Synchronization Service. This service allows you to synchronize a broad array of data between the Windows Active Directory and the NetWare Directory Service or the NetWare bindery (for NetWare 3.x).

The main advantage of this service is that it can migrate NetWare Directory Service and NetWare bindery-based information directly to Active Directory. As you can see, this feature would be extremely valuable for migrating from NetWare to Windows 2000 Server. One of the biggest challenges in migrating from one server operating system to another is moving all of the user accounts, groups, and other security information. Not only does Microsoft Directory Synchronization Service accomplish this complex feat, but it also automates the process.

What makes this process even handier is that the service supports two-way synchronization between Active Directory and the NetWare Directory Service. This means that if you were to add a user account to the NetWare network, the user would also be added to Active Directory. Likewise, if you created a user account in Active Directory, the account would be duplicated in the NetWare directory service.

If you’re presently using NetWare, you don’t have to immediately switch from the NetWare Directory Service to Active Directory, and you don’t need to incur the expense of managing two different directories. Instead, you can ease into learning Windows 2000 while your NetWare network continues to function.

Although Microsoft Directory Synchronization Service provides two-way synchronization (including password synchronization) between Active Directory and the NetWare Directory Service, it does have a limitation: It only supports one-way synchronization between Active Directory and the NetWare bindery. This means that you can migrate from older versions of NetWare to Windows 2000, but you can’t move Active Directory information into the NetWare bindery.

The Microsoft File Migration Utility
Another tricky issue when migrating from one operating system to another is what to do about transferring the files to the new operating system. While it’s relatively easy to copy files from one platform to another, files usually lose their permissions when moved to a different operating system. This is where the Microsoft File Migration Utility comes into play.

The biggest reason for using the Microsoft File Migration utility to move files from a NetWare server to a Windows 2000 server is that the utility preserves all of the file-level permissions associated with the file. This is a huge time-saver, since you don’t have to manually record permissions before the upgrade and re-implement them after the upgrade. There are third-party utilities that will record and re-implement permissions, but I always feel better with utilities that are built by Microsoft for Windows servers rather than relying on a third-party utility.

The Microsoft File Migration Utility does more than just preserve permissions, though. You can use it to select the destination of each individual folder that you’re copying. You can combine the data from many different NetWare Servers into a single Windows 2000 Server. Likewise, you can move the data from many different NetWare servers into many different Windows servers. This concept is known as many-to-one and many-to-many migration.

File and Print Services for NetWare Version 5
Gateway Services for NetWare can trick a Windows user into thinking that they’re accessing Windows server-based resources, rather than resources residing on a NetWare Server. File and Print Services for NetWare Version 5 works in just the opposite way. File and Print Services for NetWare Version 5 adds NetWare file and print services to a Windows 2000 Server. This means that NetWare clients can access file and print resources on a Windows 2000 Server just as if those resources resided on a NetWare server.

File and Print Services for NetWare Version 5 provides a full NetWare file and print server emulation. Administrators who are used to administering NetWare resources can administer file and printer resources by using the same NetWare management tools that they always have. This allows those administrators to gain the power of a Windows-based server without having to learn how to manage a new network operating system.

What makes this service even more efficient is that you don’t have to reconfigure your NetWare clients in order to access the Windows-based file and print resources. NetWare clients can access the resources without being reconfigured because the server is providing true NetWare emulation. The client machines think that they are attaching to a true NetWare machine, rather than to a Windows Server. Clients can attach to the Windows Server using either the TCP/IP or the IPX protocol.

Other utilities
In addition to the major components I’ve discussed, a few other odds and ends come with SFN5. For example, all of the command-line utilities commonly used in a NetWare environment will be available in Windows. This includes commands such as ATRACH, CAPTURE, MAP, and SLIST, just to name a few.

SFN5 also comes with the File and Print Services for NetWare Version 4. This software does the same thing as the File and Print Services for NetWare Version 5, with one major difference: Version 4 will run on a Windows NT 4.0 Server. File and Print Services for NetWare Version 4 is the only component in SFN5 that is compatible with Windows NT Server 4.0.

System requirements
Because SFN5 runs entirely on a Windows server, there are no direct system requirements beyond the obvious, such as having a functional NetWare server with enough licenses for your users. Your Windows server must be running Windows 2000 Server, Windows 2000 Advanced Server, or Windows 2000 Datacenter Server.

At a bare minimum, the Windows server must have 40 MB of RAM, 130 MB of free hard disk space, and a Pentium 133 MHz processor. A with most other Microsoft products, however, the minimum requirements don’t come close to what you’ll actually need to run the product with any sort of efficiency. My personal experience has been that, at a minimum, your machine should have at least a 500 MHz Pentium II, 128 MB of RAM, and 1 GB of free hard disk space. That’s probably still not enough power to run SFN5 in a production network with more than a few users. A good rule of thumb is that if your Windows 2000 Server gets the job done now without having any performance problems, then you probably have enough power to support SFN5.

Acquiring Windows Services for NetWare
Unlike Gateway Services for NetWare, which comes with Windows NT and Windows 2000, Windows Services for NetWare 5 is an add-on product. Windows Services for NetWare 5 has a manufacturer’s suggested retail price of $149.00. You can acquire the product from any Microsoft authorized reseller, but you may have to special order it. Another option is to buy the software online from Microsoft. If you’d prefer to try before you buy, you can order an evaluation CD. The CD is free, but Microsoft usually charges a nominal fee for shipping.