File Servers to Libraries
While working with my friends to upgrade a large company's infrastructure to Microsoft Corp.'s Systems Management Server (SMS) version 2, we moved a huge collection of SMS scripts -- canned procedures for installing hundreds of software packages -- from the old SMS server to the new one. As part of this process, we spent days tediously redefining legacy universal naming convention (UNC) definitions, repointing them from "\\server-x\scripts" to "\\server-y\scripts".
We thought we were finished, but we were wrong. Soon after retiring the old server, we received complaints from all over the company as UNC references and desktop shortcuts to our scripts that we didn't know about began failing. Dozens of operating departments learned where the scripts were kept over the years and coded several of their UNC references and shortcuts to our old SMS scripts file server. Boy, were they ticked off. This planted a huge black eye on our otherwise painless SMS migration. It taught us a valuable lesson: there's a difference between a file server and a library.
What's the difference? A file server is a computer system with shared directories on it, a physical entity bound to the hardware on which it lives. Rename the file server, or move the shared directories to a new server, and countless users -- not to mention numerous batch jobs and other canned procedures -- need to be re-educated about the change.
A library, on the other hand, is a logical entity independent of the hardware on which it resides. Users access libraries via logical names, which gets them to the library no matter where it exists.
So, how do you turn a Windows NT file server into a library? It is simple, but not exactly straightforward.
First, if the Windows NT infrastructure is based on TCP/IP rather than IPX or NetBEUI then you can define logical names in your domain name server (DNS) or Windows Internet Naming Service to refer to file servers. For example, if you have a file server named "files," with a commonly used shared directory called "videoclips" containing .AVI and .MPG files, you can hard-code UNC references or distribute desktop shortcuts referring to the clips with something like "\\files\videoclips." But if you ever move the videoclips to another server, you would have to recode them.
But if you can define a name in your DNS server "multimedia," a CNAME reference to the server named "files," users can refer to your video clip library via "\\multimedia\videoclips". If you move your shared multimedia information to another server, you can update the DNS "multimedia" CNAME reference to point to the new server. The hundreds of UNC references and desktop shortcuts to "\\multimedia\videoclips" will automatically and transparently refer to the new server.
If this kind of DNS spoofing isn't an option, you might consider Microsoft's Distributed File System (DFS) software for Windows NT Server. To be included as a standard feature of Windows 2000 Server, DFS v4.2 is available as a free download from Microsoft for Windows NT 4.0. By equipping one of your servers with a DFS root, you can present users with a browsable, logical collection of shared information that could be physically distributed on dozens servers throughout the network. If any of the information moves, update the DFS root definition with the new server's information, and users will never know the difference. DFS also provides for a measure of fault tolerance in libraries, allowing you to define several alternative paths to the same logical information.
Much of the promise of DFS, such as automatic replication of data distributed across several servers, will have to wait for Windows 2000. But you can use DFS now to turn your networked file servers into libraries. --Al Cini is a senior consultant with Computer Methods Corp. (Marlton, N.J.) specializing in systems and network integration. Contact him at al.cini@computermethods.com.