This is related to this issue: Command Prompt in Administrator mode doesn't see mapped drives
I'm needing to run a program (InstallShield) as an elevated user, but this program also needs to access files located on a network share. Due to max path length (and legibility) issues, I really want to access these files using a mapped drive (rather than the much longer UNC path). However, due to the issue referenced above, the drive I mapped (via Windows Explorer) is not recognized.
Unfortunately, the recommended EnableLinkedConnections registry hack doesn't appear to work at all for me. Instead, I can get things to (temporarily) work by mapping the drive via an elevated command prompt using the following command: net use Z: \\machine\path /persistent:yes
The problem is this mapped drive does not actually persist (despite the /persistent:yes parameter) after reboot. Granted I can just quickly remap it via a script I manually run, but I imagine there must be a better way.
I don't know how to automatically run login scripts as the elevated user, otherwise I would try that. I'm also wondering why the net use command isn't persisting as expected.
Since it may be relevant, this is a Windows 8.1 virtual machine. Also, the network share I'm trying to persistently map and access is provided by VMware Workstation (via its optional Shared Folders feature).
I'm wondering if this is maybe a timing issue? (see Why do mapped drives only reappear after logging out and back in, and not after a reboot?)
Update
I managed to find a workaround, although I still don't have an answer for why the mapping doesn't persist in the first place.
Anyway, I set up a simple scheduled task in Windows to run a batch file on login. This batch file maps the network share to the desired drive letter (via the same net use command). I also ensured the Run with highest privileges task setting was checked. Voila! Elevated processes can now see and access my mapped drive, even after rebooting.
No comments:
Post a Comment