Allow Network Drives

[Andrew Whittington]

We send our setups to individual users and/or IT administrators, so we cannot rely on the setup being run by technical users. The setup.exe needs to take care of itself.

However, as we have situations where the setup needs to run on several (already networked) PCs, each specifying a central PC or server for the location of the centralised data folder.

We provide blow-by-blow instructions on how to create the centralised data folder and  Map a Network Drive to it. So far even the ordinary folk have been able to accomplish this.

BUT, we are running into problems when the user chooses a Mapped Network Drive during the installation.

We have specifically added AllowNetworkDrive=yes to the [Setup] section of the Inno script (even though that's the default setting), but it makes no difference!!

During the setup, when the user clicks on Browse, the Mapped Drive letter is listed, but after choosing it and clicking Next, the setup raises the message "The drive or UNC share you selected does not exist or is not accessible"

I have read and understood that the setup is running under temporary (elevated) credentials, but I thought the AllowNetworkDrives would somehow compensate for that.

I tried inserting PrivilegesRequired=lowest and that fixed the Network Drive issue, but only raised subsequent issues because the installation needs admin rights.

Help!!

How can I get my inno script to handle Network Drives?

Andrew

[Martijn Laan]

See https://jrsoftware.org/isfaq.php#missingmappeddrives

Op 16 feb. 2021 om 05:41 heeft Andrew Whittington <rewin...@gmail.com> het volgende geschreven:

We send our setups to individual users and/or IT administrators, so we cannot rely on the setup being run by technical users. The setup.exe needs to take care of itself.

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/2862441a-9976-43f7-bcb5-0b82ced8154en%40googlegroups.com.

[Bill Stewart]

On Monday, February 15, 2021 at 11:14:41 PM UTC-7 Martijn Laan wrote:

See https://jrsoftware.org/isfaq.php#missingmappeddrives

Mapped drives are per-user. When you launch an installer elevated and provide credentials, the installer runs as that other user (for which you specified credentials), and the current user's drive mappings are not there, because the installer is running as a different user.

One way you could work around this is to use separate installers: One for the core files (that must run elevated) and another that installs "per-user" files and runs as the current user.

Bill

[Gavin Lambert]

On 17/02/2021 7:46 am, Bill Stewart wrote:
> One way you could work around this is to use separate installers: One
> for the core files (that must run elevated) and another that installs
> "per-user" files and runs as the current user.

A better way to do that is to have the installer only do the per-machine
files, and handle anything per-user when your app starts up and finds
the per-user settings missing. This properly handles the case where
multiple users use the app on the same machine. (You can install
"template" files per-machine that are later copied to per-user, if the
app can't generate them from scratch.)

Alternatively, for "network client" installs where everything has to use
the mapped drive, you should install with lowest privileges so that
everything is per-user. Of course, this also limits what and where you
can install.

[Bill Stewart]

On Tuesday, February 16, 2021 at 1:27:50 PM UTC-7 Gavin Lambert wrote:

On 17/02/2021 7:46 am, Bill Stewart wrote:
> One way you could work around this is to use separate installers: One
> for the core files (that must run elevated) and another that installs
> "per-user" files and runs as the current user.

A better way to do that is to have the installer only do the per-machine
files, and handle anything per-user when your app starts up and finds
the per-user settings missing. This properly handles the case where
multiple users use the app on the same machine. (You can install
"template" files per-machine that are later copied to per-user, if the
app can't generate them from scratch.)

 

Agreed, this is a good approach if you are the author of the program and can make said changes.

If not, then it may be necessary to implement other kinds of workarounds (such as the one previously suggested).

Bill