There has been some spirited discussion within our IT department about mapping network drives. In particular, it has been said that mapping network drives is a bad thing and that adding DFS paths or network shares to your (Windows Explorer/Libraries) favorites is a far better solution.
Why is this the case?
Personally I find the convenience of z:\folder to be better than \\server\path\folder', particularly with cmd line and scripting (of course I'm not talking about hard-coded links, naturally!).
I have tried searching for pros and cons of mapped network drives, but I haven't seen anything other than 'should the network go down, the drive will be unavailable'. But this is a limitation of any network-accessed storage.
I have also been told that mapped network drives poll the network when the network resource is unavailable, however I haven’t found more information on this. Do network drives poll the network any more than a Windows Explorer library/favourite? Wouldn't this still be an issue with other network access mechanisms (that is, mapped Favourites) whenever Windows tries to enumerate the file system (for example, when a file/folder picker dialog is opened)?
Best Answer
I imagine the strongest reason for not mapping network drives is that the admins don't want to deal with the headaches of maintaining an index of a finite number of drive letters in addition to the network paths. For one, there might be too many commonly-used network shares to assign drive letters to all of them, and in a large organization, not everyone will have access to all the same shares. Share names are also more descriptive and potentially less ambiguous than drive letters (more on the ambiguity later).
Second, you can run into drive letter collisions. If someone's PC has a memory card reader, that might gobble up four or more drive letters. A and B are typically reserved for the floppy drives of last century, and C and D are usually reserved for the hard drive and optical drive, so the card reader will use E, F, G, and H. If one of your network drives is usually mapped to H: via a logon script, this poor person either won't be able to use the card reader's H: drive or won't be able to mount the network drive.
Unless someone within the organization is responsible for allocating drive letters for specific purposes, the network drives could also end up causing a lot of confusion. For example, suppose you map drive S: to the share that has the setup programs for all your site-licensed software, and someone else maps S: to the shared drive where they drop all kinds of shared documents. When you try to explain how to install some software, you tell them to open their S: drive and find the setup program for Microsoft Office, but all they can find is a folder named office, which contains a bunch of miscellaneous files someone dropped there for a temporary file transfer. It might take you 5 or 10 minutes to sort out the confusion.
There are also some potential performance issues if a server goes down or if a machine is taken off the network. For example, if you map network drives on a machine, then remove the machine from the network (maybe it's a laptop), the machine may appear to hang upon logon while Windows tries in vain to mount the missing network drives.
On the other hand, on older versions of Windows, I've noticed that file transfers to or from a mapped network drive often go much faster than if you browsed to the network folder and performed the same file transfer--in which case, most people would prefer to map network drives.