>The main use case for mapped drive letters is for regular (not sysadmin) user convenience. It's a lot easier to remember "F:" than "\\SomeVirtualMachine\SomeFileShareName" for accessing and saving files.
>
>Sometimes a sysadmin working interactively at the command line will temporarily map a drive letter to make typing commands shorter. But they have no place in scripts or other automation; UNCs, environment variables or the equivalent should be used instead.
>
>Some might argue that adding a layer of abstraction can make some functions simpler such as switching a group of users between test and production environments. A sysadmin would just have to change the group's logon script and ask them to log off/log on, and their drive F: could be mapped to either environment as required. But most if not all such arguments really boil down to user convenience, the same thing could be done with UNCs.
>
>A lot of people rely on the implicit /persistent:y that gets applied when they interactively map network drive letters in, say, Windows Explorer. Most of the time that makes mappings persist across logons/boots but it's not 100% reliable, and every failure generates a support incident. Automatically or manually run scripts can work around this but are often not used.
>
>Depending on client hardware you can also run into some subtle and hard to debug problems. For example, I've seen laptops with all-in-one memory card readers where each of 5 card slots gets its own hardware drive letter e.g. E: through I: inclusive. If you have any kind of script running NET USE F: \\SomeHost\SomeShare /persistent:y, then that command will fail, either silently or with an error the end user may not notice or understand. This gives the user an F: drive with nothing on it (all their files are gone!), so they have a heart attack and support gets a priority 1 elevated incident to handle.
>
>In short, there is one legitimate reason to use mapped drive letters, but they are overused or abused in almost all other scenarios.

As you said, simplicity for the users is the main (and IMO very valid) reason and there might be some minor other reasons (such a software incompatibility with UNC paths (yes they exist)), but since the fact they are used everywhere in the corporate world indicates it is far from outdated technology.

Walter,







>>Lutz,
>>
>>I'm not sure how many enterprises you visit in your profession, but mapped drives are used a lot in the corporate world. Every client (clinics, hospitals and universities) do use mapped drives.
>>
>>So, I do not recognize your assertion that mapped drives are outdated technology.
>>
>>Walter,
>>
>>
>>>>Excuse me, but normally I discuss how goes the car,
>>>>not the driver as a guide.
>>>
>>>Car? Thing with four wheels and one steer to transport from A to B?
>>>I don't pick up the picture. Puzzled.
>>>
>>>Never mind. If you still stuck with mapped drives 20 years or so after M$ has introduced UNC paths (WIN95 for all I remember) you seem to be happy with it.
>>>Thats o.k. I'm fine with it
>>>I found it depricated from the day UNC was available in the WallHole OS, even while VFP needed several years to close that gap.
>>>
>>>I only point out that there is a cheap way around your problem for decades.
>>>Read the WIN10 behaviour as a hint to skip mapped drives finaly. Somebody near Redmond WA found it superfluous.