Network drive mappings are a staple of Windows environments. However, in my opinion, they suck.
I remember Mark Russinovich writing a long and very interesting blog article back in the day, entitled “The case of the veeeerrrry slow logons“. This was a fascinating deep-drive into Windows internals – like all Mark’s posts generally are – and one which gave a great rundown on how to use SysInternals tools for solving problems. However, I could have saved Mark the time and trouble it took to go through all this troubleshooting, because, in the end, “it was the drive mapping wot done it”. Network drive mappings, in my experience, are nothing but problems that adversely affect logon times and other KPIs.
Indeed, just what are these things? Well, essentially, they’re just a shortcut to a shared network storage area. But in the early days of Windows, we generally provided these shortcuts as “drive mappings”, as if the shared storage area was a physical drive in the machine and not a remote mount point. The reason for this was because the “My Computer” area of the filesystem (which is now “This PC”) was generally the user’s first entry point when it came to looking for documents and content. The principle of “mapping a drive” to a shared storage area allowed users to save files to network locations, whether this be a personal “home drive” or a shared “departmental drive”. The principle of this has hung on grimly through the years, even though we now have multitudes of Windows “special folders” and new technologies like Enterprise File Share and Sync (EFSS). And as I said already, drive maps cause nothing but problems. Microsoft themselves still recommend using drive mappings “to save remembering a complex network path”, but this seems to me like a total copout – it’s nothing you couldn’t do with a standard shortcut.
But the main reason people like “mapped network drives” is because they appear in the shell in particular locations. They don’t just appear under “This PC” in File Explorer, but they also generally appear when you open up an application’s Save As or Open dialog. This makes them easy for users to find, and that’s why they often end up wedded to them so much you’d think a network drive mapping was made of crack cocaine.
Here’s a user “home drive” showing in the File Explorer window…
…and here it is showing in the Open dialog
Also, you can have multiple drive mappings for different shared areas, particularly “departmental” drives where shared documents are stored. Some people go completely crazy with them and have tens of drive mappings. Here’s an image showing a bunch of departmental mappings
You can map a network drive in a number of ways. The Active Directory user object offers you a way to map a “home drive” for the user on a interactive or Remote Desktop Session Host level.
You can also use the Windows Explorer GUI to do it.
Or you can go old-school and map it from the Windows command line using the “net use” command, from PowerShell using the New-PSDrive cmdlet, from VBScript – in fact many different scripting languages have support, which means you will often see complex logon scripts with multiple context-dependent drive maps.
You will also see this functionality within other tools like Ivanti User Workspace Manager, Citrix Workspace Environment Management, Group Policy Preferences Drive Maps, etc., all which have the capability to create a mapped drive.
In Windows, all drives are assigned a “drive letter”, and commonly you see many different ones used, although A, B, C, D and E are often reserved for local or removable drives.
Why do they cause problems? Well, a “network drive mapping”, despite the fact that it’s ostensibly just a shortcut, insists on actually contacting the remote location when it is mapped. So, if you’re mapping it as part of a logon script or something that runs at logon or even when an application is launched, if the location is unavailable, you’re looking at a long delay as it times out. The timeout varies, but is generally somewhere between 30 seconds and a couple of minutes. You will also see hangs in File Explorer as it tries to reconnect.
Another problem is that because mapped drives use letters of the alphabet, there’s a limit to them. I’ve seen places where they’ve gone over twenty drive mappings and they’ve physically run out of letters to map (with the local and removable drives added too).
I also see lots of places where people have hard-coded drive letters into scripts, or even worse, actual applications. This drives me insane – how lazy have you got to be? Using simple UNC paths and environment variables would be fine.
After all, a “network drive mapping” is literally a UNC shortcut that appears in File Explorer dialogs. That’s all it is. Wouldn’t it be much easier just to avoid “drive mappings” and use shortcuts that don’t need to be validated as they’re created? That would allow us to get around all of these problems and consign them to the dustbin of history.
First of all, forget the concept of a “home drive”. Why do we still persist with this? All Windows users have a “home drive” – it’s called the damned Documents folder. And if you’re using stuff like OneDrive, ShareFile, DropBox or some other EFSS solution that does cool stuff like selective in-session sync between local and remote – WHY THE HELL ARE YOU STILL MAPPING A HOME DRIVE?
Home drives defined on the AD user object also (apparently – depending on who you talk to or what you read) lock Group Policy processing into synchronous mode, so having a home drive defined will cause you even more problems than the whole “drive mapping” debacle. What you should do is simply map the user’s Documents folder to an EFSS folder like OneDrive, ShareFile, etc. and forget about it. If you’re using XenApp, then there are features such as OneDrive Files On Demand and similar that avoid the issues of storage locally on the device getting eaten up.
Ideally you should direct the Documents folder to an EFSS tool, but if you don’t have that option, simply redirect it to a specified network share and have done with it. I wouldn’t even use the GPO Folder Redirection CSE for this – simply point the Registry value Personal from HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders to the specific share, using environment variables where necessary.
“But what about the departmental drives?” Firstly, aren’t you using some form of document management system yet, like SharePoint? If you are, then you should be using this to set up departmental folders and whatnot, along with all of the extra stuff you get in there like version control, rather than leaning back on drive mappings. You can do cool stuff with Office365, if you get it set up right, or even things like Google Docs. Ideally, you should bin “departmental drives” in favour of better use of SharePoint or similar.
But to be fair – a lot of people hate SharePoint’s guts, and the concept of departmental drives on old-school SMB file server shares still works for them. And their users, to be fair. So if you’re in this mindset, then there is a trick you can use to create “shortcuts that appear in the File Explorer shell” the same way mapped drives do, without any of the issues.
There is a way to create “Network Shortcuts” in Windows, which simply sit in the folder %APPDATA%\Microsoft\Windows\Network Shortcuts. However, creating shortcuts in this folder on-the-fly isn’t satisfactory – they only appear under “Network Shortcuts”, and not in the Open and Save As dialogs, nor under File Explorer’s root This PC view. But with a bit of hacking around in Group Policy Preferences, you can achieve the desired result. You can also achieve this in Ivanti UWM, Citrix WEM, LiquidWare ProfileUnity or any one of the many UEM tools out there that can handle folders, shortcuts and ini file creation.
Firstly, you need to identify two things:-
a) the name you want to appear on your shortcut – e.g. Departmental Drive #1
b) the path you want it to go to – e.g. \\UKSLDC003\FileStore
Once armed with these, you first need to set up a Group Policy Folder Action as below, replacing the names as appropriate
Basically, we are creating a Folder in the %APPDATA%\Microsoft\Windows\Network Shortcuts folder with the name you want to give the shortcut. Also, call the GPP Folder Action itself the same name as you wish to give the shortcut, and set the attribute flag for Read-only as above.
Next you need to use the Group Policy Preferences Ini Files Action to create two .ini file updates (they will be two separate sections added to the same file). Both actions should be titled desktop.ini and they both need to point at the Folder you created above (so in this example, %APPDATA%\Microsoft\Windows\Network Shortcuts\Departmental Drive #1). The parameters of the first ini file should be
Section Name – .ShellClassInfo
Property Name – CLSID2
The next one has slightly different parameters
Section Name – .ShellClassInfo
Property Name – Flags
Property Value – 2
Finally, you need to create a Group Policy Preferences Shortcut, with the parameters below:-
Name – %APPDATA%\Microsoft\Windows\Network Shortcuts\Departmental Drive #1\target (basically the full path to your folder with a shortcut called target)
Target type – File System Object
Target path – \\UKSLDC003\FileStore (path to the UNC share you want)
So basically recreate what I’ve done above exactly, swapping Departmental Drive #1 for the name you want to see on your shortcut, and \\UKSLDC003\FileStore with the path to your UNC share.
You can repeat this as many times as you want, so create all these files for each “mapping”. It’s easy to simply copy the existing ones and then rename the two variables (the name and the path). Just be careful not to duplicate any paths – each path must be unique for each “mapping”. You can also leverage Item-Level Targeting (or whatever your UEM tool provides, if you’re not doing this in GPP) to deploy these on a per-group, per-user, or per-whatever basis.
So, let’s try firing it up for a test user with a couple of these new “shortcut mappings”. Here we can see what shows in File Explorer…
…and here’s what we see in the Open and Save As dialogs.
So there we go – a nice easy way to rid ourselves of the spectre of “network drive mappings” forever, saving logon times, freeing ourselves from dependence on drive letters, and not invoking the actual connection until clicked on – whilst still appearing where the users need them to. What’s not to like? Banish drive mappings from your Citrix environments today! With this in place alongside an EFSS Documents solution, my users don’t have any timeouts, they aren’t locked into synchronous processing mode, they aren’t limited in the numbers available, and the general session performance is better as it isn’t constantly validating the connections.
The config I used is available as a download here, should you want an example. I will also be recording a video showing how to do this soon!
