File Servers to Libraries - Microsoft Corp.'s Systems Management Server 2.0 - Product Information

ENT, Jan 12, 2000 by Al Cini

While working with my friends to upgrade a large company's infrastructure to Microsoft Corp.'s Systems Management Server (SMS) version 2.0, 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 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 scripts began failing. Dozens of operating departments apparently learned where the scripts were kept over the years and coded several of their UNC references and shortcuts to the 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 "video-clips" 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 4.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 of servers. If any of the information moves, update the DFS root definition with the new server's information. 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.