Resource usage of mapped drives versus network location shortcuts?

Question

One group within our IT department wants to eliminate all drive mappings from our network and replace them with simple Network Location (UNC) shortcuts. The group claims the drive mappings consume too many resources on the servers and hurt performance. Another group believe the convenience of being able to relocate files as needed and alter the drive mappings through login scripts overrides the resource consumption concern. Does either method, drive mappings or network location shortcuts, have a significant advantage over the other? Is the resource consumption a legitimate concern? I realize that some applications may not be able to handle UNC paths; we will need to deal with that on a case-by-case basis. We have about 500 client PCs each having on average about 5 mapped drive connections. Thanks for your thoughts.

Answer 1

I've never heard of mapped drives taking up any more "resources" than non-mapped drives and we use mapped drives all over the place where I work. I work at a Fortune-5 with thousands of PCs and thousands of Windows servers...

I'd ask them to back their statements up with data. They have any Microsoft KB articles backing up their claims? Their claims don't seem to carry any water with me. A mapped drive, as I understand, does not cause any more or less network I/O overhead; the underlying protocol is still SMB/CIFS.

Answer 2

The only way that UNC connections would consume less resources than a mapped drive is in the single case of how often those connections are opened. When you have a large number of mapped drives, the simple act of opening Windows Explorer or any open/save dialog that displays drive maps causes that workstation to reconnect to those resources. Have 15 drive maps, open Explorer, cause potentially 15 new server connections. Open one UNC shortcut, create one connection to one server.

What's more, the kind of connection created by Windows in those open/save/explorer dialogs times out after 10 minutes of inactivity. Wait 10 minutes, and it'll close all those connections again. Microsoft does this to keep the concurrent-user count down.

The only reason they would be sensitive to this is in the case of seldom used resources getting a drive letter, and therefore getting a LARGE number of connections that are never actually used. In a VM environment where memory is a precious, precious commodity, those kinds of connection counts can cause increased memory usage.

---

Speaking personally, that IT group is either running things to close to the wire resource-wise than they really should, or are fond of Samba servers; Samba can't scale to Windows levels of concurrent-user counts yet but they can get pretty high. Connection tracking doesn't consume much memory on modern Windows servers.

With 500 PCs, you aren't even coming close to approaching the limits of Windows. We're just about 3x your size for daily use machines, and the most I've seen connected to a single share is about 600. At the same time, the home-directory servers rarely poke their heads over a collective 500 connections. The difference for that one share is that it is the shared volume for all PCs, and connections are being held open because of open files.

Those 500 machines with 5 mappings each is a maximum of 25,000 connections. You're never going to see that unless everyone logs in at the exact same time. If all those maps are to the same server, it could indeed cause problems. But Windows is designed to minimize the possibility of that.

Their argument is weak on the merits. They need to substantiate their claims better than a general appeal to efficiency. If they truly are seeing performance hits when connection counts climb too high, they're running their servers too lean memory wise for comfort. File-servers really do need scads of memory, they're not something you want to provide bare minimums for.