12

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.

2 Answers 2

2

I have had a similar issue and these were the steps I conducted across the network and all PCs I did this work on have maintained the mapping after rebooting. (I did not want to use a batch file as this would provide the Administrator's password to the users if they were to find the file.)

  1. On the workstation, after a reboot, double click the disconnected mapped drive. Enter the Administrator's user name and password login to enable the mapping. The drive will be mapped successfully.
  2. Open a command prompt.
  3. Type the following command: net use \computername\sharedfoldername administratorpassword /user:administratorloginname /persistent:yes
  4. There will usually be an error message stating that this cannot be done multiple times; however, disregard the error message.
  5. Restart the computer.
  6. I have found the drive will always be permanently mapped after this procedure irrespective of reboots.

Example syntax:

  • Computer Name: ABCD123-DT
  • Administrator Login Name: Admin
  • Password: 321DCBA!
  • Shared folder name: SharedData

c:>net use \abcd123-dt\SharedData 321DCBA! /user:Admin /persistent:yes

NOTE: If you want confirmation of your success prior to restart, in the command prompt, type in net use and then press enter, you should see the mapped drive listed.

1
  • 1
    My experience is that once the drive has been mapped manually (step 1) all of the other steps have no impact on the result. If you stop at step 1 and restart, the drive will be present. The problem that many face is that we're trying to get rid of step 1, and only perform the remote console steps, and these changes do not persist on restart! Commented Aug 31, 2018 at 17:07
1

We have been facing similar issue and ended up using the task scheduler in following way:

schtasks /create /tn "my_mount" /tr "net use V: \\hostname\path /persistent:yes" /sc onstart

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .