Network Shortcuts
Dating backto the early DOS/LAN Manager and NetWare eras, mapping drive letters to shareddirectories is an old and honored custom. Increasingly, however, it is one worthbreaking. Here's why, along with some tips for kicking the drive-mapping habit.
Back incomputer antiquity, when the Dinosaur Operating System (DOS) roamed the world,the easiest way to enable primitive DOS programs to access files on networkshares was to fool them into thinking they were actually resident on locallyattached drives. Early NetBIOS architecture accomplished this by transparentlyredirecting 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 becamecodified in common practice, perhaps by mapping U: to a user's personal share,M: to the network directory containing a user's e-mail files, or L: to alibrary of server-based data shared by a group of users.
With 26letters to choose from, using the alphabet to name network shares seemspractically limitless. Further, by simply coding the appropriate Net Use or Mapcommands in NetWare or Windows NT logon scripts, or by persistently mapping theappropriate drive letters, mapped drives are easy enough to implement across abroad base of users. So, what's wrong with mapping drives?
As networkapplications have evolved and proliferated, today's users often need to accessmore than a couple of different file server shares over the course of a workday, resulting in conflicts over commonly used letters, say "S:" for"share." Similarly, when consolidating separate NetWare usercommunities -- each with its own, unique drive letter convention -- onto asingle NT file server, conflicts can arise over the meaning of newly assigneddrive letters to migrated shares.
Of coursemodern NOS systems, like Windows NT, offer a solution. Instead of mapping driveletters, users can refer to network shares via their Universal NamingConvention (UNC) identifiers, for example \\myserver\myshare. Such UNCreferences are unambiguous and can be used to refer to many more than just 26shares at the same time.
But UNCsare nasty looking, cumbersome, and far from user-friendly. If only we had aneasy way to generate shortcuts for users when they logged on to Windows NT,pointing them to the UNCs of the shares they'd need. Sadly, while you caneasily Net Use a drive letter into existence to refer to a share in an NT batchprocedure, 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 scriptprocessing engine -- well worth checking out in its own right -- you'll findseveral free utilities, including a handy little tool called MakeScut. You canuse MakeScut to dynamically create shortcuts, pointing to any local or UNCpath, under the control of a batch procedure. MakeScut's command qualifiersallow you to specify any of the parameters of a shortcut, from destination pathto window characteristics or even associated icon. You can also use it togenerate 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 shareunless they're mapped to a drive letter. Most Windows applications don't needmapped drives, though, and can be used with shortcut-mapped UNC paths.
If all thishas you thinking about kicking the drive letter habit, MakeScut can help. Andremember, it's free! --Al Cini is asenior consultant with Computer Methods Corp. (Marlton, N.J.) specializing insystems and network integration. Contact him at al.cini@computermethods.com.