SAN MATEO (05/08/2000) - When you have to integrate the IT resources of two organizations, defining what constitutes "enough" integration will determine the success or failure of the project. If your integration is insufficient, users will find it difficult to access network resources. But if you go too far, you will end up spending money and time that you could put to better use elsewhere. The key is to find that sweet spot, the "point of diminishing returns," and call the integration quits there.
This advice fits to a tee when you're combining two Novell Inc. NetWare installations. Because most organizations with NetWare use it for bread-and-butter file-and-print services and others depend on it for applications services, maintaining the availability of NetWare-hosted resources during any system integration is paramount.
Although I ran into some constraints while completing the NetWare integration project, I found that NetWare is, in a vanilla configuration, a very good "interoperator." Using Novell's latest generation of directory services can complicate matters, as happened in this case; but in the end, I discovered some simple work-arounds to this obstacle. Novell's score of Very Good for cross-version integration takes into account the assumption that a real-life integration project would also have successfully achieved its goal.
Although my evaluation did not include the NDS offerings for Linux, Microsoft Windows NT Server, or Sun Microsystems' Solaris, their presence in the market gives Novell a clear edge in cross-platform interoperability. Overall, I found NetWare's client support very good, although Mac OS clients must rely on third-party connectivity products.
Setting the stage
NetWare environments generally integrate without much fuss, thanks primarily to NetWare's built-in directory service. Because large companies are likely to have hundreds, if not thousands, of objects in NDS representing network resources, users, and groupings of the two, successfully merging the data sets into a usable whole is critically important. Botching this effort can cripple your network by complicating or preventing user access to servers and printers.
Fortunately you don't have to work without a net. A number of useful modeling and reporting tools can reduce the drudgery that goes into designing the new directory tree.
Because NetWare is integrated tightly with NDS, one of the trickiest parts of any assimilation project is deciding how far to proceed. In our hypothetical case, the acquiring company, Bigcorp, is running NetWare 5.0 with NDS eDirectory (formerly NDS 8) on top. Bigcorp wants to use NDS eDirectory to allow clients to authenticate via either NDS or Bigcorp's iPlanet Netscape LDAP server. The NDS tree associated with Bigcorp's NetWare installation has the basic schema of NDS 8, with the eDirectory extensions added.
Bigcorp's desktops use standard tools to connect to the company's servers. Our Windows clients used Novell client software to connect to Bigcorp's NetWare server, while the Macintosh client had Prosoft Engineering's NetWare Client for Mac OS 5.13 installed. Although the Windows desktops would have been quite happy in a pure-IP environment, limitations in the Mac client required us to use IPX on our test bed (see related article, below).
For this phase of our comparative analysis, Smallco's primary IT asset is a NetWare 5.1 server. Although NetWare 5.1 includes NDS 8 in the "red box," the standard installation sets up NDS 7.x. So I had two trees from two organizations running different versions of NDS. On the surface, it might appear that I had an easy task to perform. After all, how hard can it be to get two NetWare servers to communicate? But I did not anticipate how the addition of NDS 8 would complicate matters.
As experienced NetWare administrators know, it's not a big deal for a NetWare client to connect to more than one NDS tree at a time -- and it's no more difficult than mapping a network drive in Windows. This is, without a doubt, the quick solution to the problem. Of course, that tale would be rather short and not very instructive.
One of NetWare's strengths is the flexibility of its directory service, NDS.
From its experience with NDS, our fictitious IT staff decided to test the feasibility of a tree merge. Merging the trees would allow the Smallco network resources to remain in their customary hierarchy and simplify support during the reconfiguration of the merged companies' IT resources. This would require some reconfiguration of the Smallco clients that would connect to the "grafted" tree, but Bigcorp's IT staff assumed these changes would not be substantial.
Merging NDS trees is not an operation you perform lightly, but it helps a lot if you've kept up with Support Packs and interim patches to NDS. By keeping current with both, you guarantee that you have the latest versions of the tools that manipulate the tree and ensure its health by checking objects for consistency and validity. These checks are especially important when you are merging trees, because the price of a botched merge is, at best, an NDS tree full of garbage; at worst, you won't be able to access your servers.
As it transpired, I set myself up for a few "gotchas" when it came time to integrate the new NetWare server, but there was still a silver lining. Although Novell provides a server-based tool for merging NDS trees, DSMERGE, it does not work in a "pure" NDS 8 or eDirectory environment, and the utility does not run on a server using NDS 8. So, what alternatives exist for shops using NDS 8 or eDirectory?
The work-around Novell supplied proved simple. Our fictitious team could bring up a server running NDS 7 in the Bigcorp network. One of the team could then use Novell's client tools (ConsoleOne or NDS Manager) to "promote" the NDS replica on the new server to Master status. This would allow the team to run DSMERGE on the new server and import the data from the Smallco NDS tree. Once the merge was complete, the replica on the server running NDS 8 would be redesignated as Master.
In an ordinary environment, this probably wouldn't be much of an issue, and a resourceful IT staff probably has an extra server, or a workstation with lots of memory, that it can wheel into place for this task. In fact, a more realistic simulation for Bigcorp would have included a second NetWare server to add some fault-tolerance to NDS. (Novell recommends placing replicas of NDS on three servers if possible.) These considerations led me to add a NetWare server to the Bigcorp network, thus allowing me to complete the project. The key here is that you don't need anything more than a five-user license for NetWare, but if your NDS trees hold thousands of objects, you will need extra RAM and CPU horsepower on the server that's running DSMERGE. This can substantially reduce the time required to process the trees and can reduce the chance of corrupting NDS data due to low-memory conditions.
An alternative solution, but not one I would recommend, involves using the beta of Novell's DirXML product. This contains a prerelease version of NDS 8.5 and includes the merging features Novell left out of NDS 8 and eDirectory.
Even with the simple work-around, it wouldn't quite be a slam dunk. Merging NDS trees from NetWare 5 installations is trickier than performing the same operation on NetWare 4.x servers. The hitch is the Security object, a feature of NetWare 5.x that provides the hooks for adding PKI (public key infrastructure) support to NDS. It also complicates matters, as there can be only one Security container in a tree. In our case, we weren't using PKI on Smallco's NetWare 5.1 server, so the prospect of deleting this container from Smallco's tree didn't faze us. If Smallco's NetWare server had issued any certificates, they would have become invalid, but that wasn't the case here.
In the end, I found that it pays to be flexible when integrating NetWare installations. If you plan ahead and ask the right questions, you'll probably come out of the project OK. Although I thought I had painted myself into a corner, it turned out to be nothing that a resourceful, and well-funded, team couldn't solve. For this evaluation, Novell NetWare did a very good job providing ways to integrate with itself and other operating systems. Although there are some holes in the fabric, it's still one of the best choices for a versatile, flexible network operating system. I give NetWare a score of Very Good for interoperability.
P.J. Connolly (email@example.com) is a technology analyst in the InfoWorld Test Center. He covers network operating systems and other network software and hardware.
Netware, Macintosh reach a compromise
Any organization with Apple Macintosh users will confirm that Microsoft doesn't completely own the desktop. Shops often find it easier to coexist with islands of Mac OS machines, instead of forcing the content creators and designers who are the platform's most fervent loyalists to switch to Windows. Although Macs themselves traditionally require less support, they present challenges and sometimes unpleasant choices to IT managers.
In the past, the idiosyncrasies of Mac OS and NetWare limited you to one of two unnatural choices: Either you added IPX to your Macintosh, or you made your NetWare server run AppleShare protocols. Either method has its advantages. If you have only a few Macs, adding an IPX client is less disruptive than enabling a new protocol on your file server. On the other hand, you'll be attracted to a server-based solution if you don't have time to touch many desktops.
Novell used to offer both client-and server-based solutions; but unfortunately for customers, this sensible arrangement ended in 1998 with the release of NetWare 5 and Novell's decision to farm out its Macintosh development effort to Prosoft Engineering. Although Prosoft has shipped two minor releases to the client and a new version of the server software since then, anecdotal evidence indicates that shops with Mac clients have put off upgrading to NetWare 5.x because of the additional expense and hassle.
Certainly, customers resist paying for what they used to get for free -- and the Prosoft products don't come cheap. Our testing confirms that shops upgrading from NetWare 4.x may be able to use the Novell-supplied Mac client (Version 5.11) to access NetWare 5.x servers. But new customers have to pay up to $89 per desk to use Prosoft's Mac client (Version 5.13) or $695 per NetWare server to use Prosoft's NetWare 5 Services for AppleShare. Shops with large numbers of clients or servers get a break, as Prosoft offers aggressive discounts to these single-copy prices.
Another frustration when connecting Macs to a NetWare 5.x network is that NetWare no longer requires the IPX protocol. Unfortunately, that message hasn't quite seeped through to Prosoft's engineers -- even though NetWare 5 shipped more than 18 months ago. It's ironic that our only reason for using IPX on the NetWare test bed was to connect a Mac client. To be fair, Prosoft's Mac client improves on Novell's last attempt. Mac users will particularly enjoy the ability to select NetWare resources via the Chooser (the Mac's native network browser).
Recent statements from both companies indicate their awareness of the current situation's defects. In March, Novell announced that it would release NetWare 5 File and Print Services for Macintosh (a server-based product) later this year, while Prosoft indicated that an IP-based client for Mac OS desktops might be available this summer. For the time being, Novell will focus on server products, with Prosoft continuing client development efforts.
Prosoft Engineering Inc., in Pleasanton, California, is at www.prosofteng.com.
THE BOTTOM LINE: VERY GOOD
Novell NetWare 5.1 interoperability
Business Case: It pays to decide just how far to go when integrating two NetWare installations. Overdoing it can mean wasting effort and money on a project that looks nice on paper but delivers little to customers and users.
Conversely, if you fail to carry your integration as far as your resources permit, you won't get the most from your IT investment.
Technology Case: Simple NetWare integrations don't require much effort -- even the complex problem we faced had a simple solution.
+ Standard-issue NDS environments integrate easily with other NDS trees+ Simple integration tasks are easy to perform via ConsoleOne, NDS Manager, and NWAdmin administration tools+ Connecting to multiple trees is easy via client softwareCons:
- Latest Novell NDS does not easily integrate with other NDS trees- Existing LDAP services replace, rather than integrate with, Novell's LDAP services- Macintosh client software, previously free, now a separate purchase from third-party developer- Mac client software requires IPXNovell Inc., Provo, Utah; (801) 222-6000; www.novell.com.