Here’s a moderately geeky tip about how to fix a nagging problem when a mapped drive disappears during installation of a program from a shared folder on another computer on the network.
Until a small business starts to use a document management system, it almost always stores business files in shared folders that appear on each person’s computer with a mapped drive letter. In Small Business Server 2003 it was the “Company” folder; in other businesses it’s “FirmDocs” or “Network Files” or the like.
In network parlance, the files are located at \sbsserverfirmdocs, but the employees always refer to it by the drive letter. They know that they store files in the M: drive, and that’s all they need to know.
At one time it was common for shared business programs also to require a mapped drive letter. That happens less often now (it’s not necessary for programs that run from SQL databases, or that have been redesigned to understand UNC paths), but I still run into it with warhorses resting on foundations that were developed back in the DOS days.
Programs for law offices spring to mind. I just went through another Timeslips exercise – it refuses to operate unless every computer is accessing it through precisely the same path. If the database is in T:Timeslips, then every computer had better look for it in T:Timeslips (including the computer that has the database stored safely on the C: drive) or it will throw a fit. Abacus and Time Matters were both like this until recently and it’s still true with Orion, A1Law, and more than a few others.
The problem turns up during installation of the program on a Windows 7 or Vista workstation.
- Map the program’s shared network folder to a drive letter.
- Run the setup program, clicking the routine UAC prompt.
- During installation, the setup program wants to browse to where the database is. Click the browse button and stare at the C: and D: options. The mapped drive has disappeared! All the mapped drives have disappeared!
- Program installation fails because you can’t find the data.
- Curse bitterly.
That last step is very important. I practiced it a lot. It took a while to figure out what was going on.
From Windows’ perspective, you map a drive as one user, with your normal everyday powers. You are issued a “standard user token” and the system shows you things within the range of your powers.
When you click the UAC prompt to install a program, you become Superman. At that moment you are given a second “administrative token” that Windows has been holding in case you need it. Although both of them were made for you, in some respects the computer acts almost as if a second user has logged onto the computer to do administrator things.
The standard user session and the administrative session don’t talk to each other very much.
The administrative session doesn’t know anything about mapped drives. They won’t show up during a program installation.
There’s more information about this in a Microsoft Knowledge Base article, and Mark Minasi explains the technical underpinnings in this article.
It’s possible to work around it by disabling UAC during program installation, but that requires a lot of restarting and the problem will undoubtedly turn up again.
The long-term fix is a registry edit that will make mapped drives visible in both standard and administrative sessions.
- In Regedit, navigate to HKLMSOFTWAREMicrosoftWindows CurrentVersionPolicies System
- Create a new REG_DWORD entry named "EnableLinkedConnections"
- Set its value to 1.
Reboot after adding the registry entry and programs will be able to see mapped drives forever.
Having said that, I have to add the obligatory – and dead serious – disclaimer.
Careless registry editing can cause irreversible damage to your computer. Do you see the word “irreversible”? Do you have it clearly in mind? You can kill your computer in seconds by mucking around in the registry. Don’t go there unless you are 100% sure of what you’re doing.
