Network Shortcuts - Technology Tutorial - Tutorial

ENT, Dec 13, 2000 by Al Cini

Dating back to the early DOS/LAN Manager and NetWare eras, mapping drive letters to shared directories is an old and honored custom. Increasingly, however, it is one worth breaking. Here's why, along with some tips for kicking the drive-mapping habit.

Back in computer antiquity, when DOS -- the Dinosaur Operating System -- roamed the world, the easiest way to enable primitive DOS programs to access files on network shares was to fool them into thinking they were actually resident on locally attached drives. Early NetBIOS architecture accomplished this by transparently redirecting a computer's I/O routines from local BIOS-type drive letters -- such as C: -- to network-based files mapped to higher drive letters, such as X: or Y:. As NetBIOS evolved and DOS usage spread, this practice eventually became codified in common practice, perhaps by mapping U: to a user's personal share, M: to the network directory containing a user's email files, or L: to a library of server-based data shared by a group of users.

With 26 letters to choose from, using the alphabet to name network shares seemed practically limitless. Further, by simply coding the appropriate Net Use or Map commands in NetWare or Windows NT logon scripts, or by persistently mapping the appropriate drive letters, mapped drives are easy enough to implement across a broad base of users. So, what's wrong with mapping drives?

As network applications evolved and proliferated, today's users often need to access more than a couple of different file server shares over the course of a work day, resulting in conflicts over commonly used letters, say "5:" for "share." Similarly, when consolidating separate NetWare user communities -- each with its own, unique drive letter convention -- onto a single NT file server, conflicts can arise over the meaning of newly assigned drive letters to migrated shares.

Of course modern systems, such as Windows NT, offer a solution. Instead of mapping drive letters, users can refer to network shares via their Universal Naming Convention (UNC) identifiers, for example \\myservenmyshare. Such UNC references are unambiguous and can be used to refer to more than just 26 shares at the same time.

But UNCs are nasty looking, cumbersome, and not user-friendly. If only we had an easy way to generate shortcuts for users when they fogged on to Windows NT, pointing them to the UNCs of the shares they need. Sadly, while you can easily Net Use a drive letter into existence to refer to a share in an NT batch procedure, you can't generate a shortcut to point to it. Or can you?

Pay a visit to www.scriptlogic.com/usa/products.htm#FreeUtils. Through the courtesy of the folks who make the ScriptLogic logon script processing engine -- well worth checking out in its own right -- you'll find several free utilities, including a handy little tool called MakeScut. You can use MakeScut to dynamically create shortcuts -- pointing to any local or UNC path -- under the control of a batch procedure. MakeScut's command qualifiers allow you to specify any of the parameters of a shortcut, from destination path to window characteristics or even associated icon. You can also use it to generate shortcuts for Windows 98 network clients.

Unfortunately, some Windows-based applications -- including some biggies such as PeopleSoft -- have deeply buried DOS roots, and won't work with files on a network share unless they're mapped to a drive letter. Most Windows applications don't need mapped drives, though, and can be used with shortcut-mapped UNC paths.

If all this has you thinking about kicking the drive letter habit, MakeScut can help. And remember, it's free! -- Al Cini is a senior consultant with Computer Methods Corp. (Mar/ton, N.J.) specializing in systems and network integration.