Video Screencast Help

Installing to network drive on Windows 7

Created: 20 Jan 2011 | 3 comments

Hi --

We have several installs created with Wise Installation Express 7. We've run into a problem when any of the installs are run on Windows 7 machines, and we can duplicate the problem in-house.

 

When the user is prompted to enter the destination directory for the installation, if they choose to install on a network drive (F:\somedir, for instance) the installer gives an error citing an invalid drive letter. If they use the Browse button to choose a destination directory, only local drives are shown.

 

This problem doesn't occur when our installs are used on older versions of Windows, all valid local and network drive letters show up.

 

I looked around the forum expecting this would be a problem encountered by a lot of developers, but I can find no reference to it. Maybe it's something we did wrong in implementing the installs, but I'm not familiar enough with Wise to even guess what the solution might be (the developer who wrote the installs has since left the company).

 

Apologies if I'm not giving enough information, I'll provide any info I can, really need a solution. Got a lot of users hot under the collar about this!

 

Thanks, Allan

Comments 3 CommentsJump to latest comment

EdT's picture

The reason that this problem is not reported widely is that is it extremely bad practice to install MSI files to network folders, as you could end up with lots of error dialogs popping up if the network mapping becomes unavailable for any reason.

With Windows 7, you are working with a different security model to older operating systems such as XP. Thus even admin users don't actually have admin rights while UAC is turned on, and the user has to authorise the elevation of an installation via the security dialog so that it  is installed with admin rights. However, the local admin account used for the elevated install process has NO network credentials, so cannot see any network resources, only local ones.

You can test this by turn UAC off entirely on a Windows 7 workstation, then repeating the process with an account that has domain admin privileges, at which point you should be able to see the network shares.

If you need to have installs, or parts of installs, based on network shares, then these should be installed at the server itself.  This is really the only practical solution in a normally secure Windows 7 environment.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

AllanH's picture

Hi EdT --

All points well taken and thank you very much for the info! It seems as soon as I have one OS figured out MS comes up with a new one that changes all the rules. I'm gettin' too old for this...

We actually don't install anything to the network drive from the workstation in most of these installs. We're asking for the path to our app that was already installed on the server. We do this  so that we can create a desktop shortcut to the app on the workstation, and create registry entries that need the path info. This is needed to set up the workstations on a system to share that network app.

I can't see any obvious way to get around needing this info. We could ask for the folder info without actually verifying it, of course, but you know what would happen then -- the yahoos would invariably type the path wrong and it wouldn't work. Any suggestions?

Thanks again,

AllanH

EdT's picture

First of all, I personally do not favour the action of creating shortcuts directly pointing at network resources. Apart from the usual issues with shortcut creation when the target cannot be accessed, there are also possible consequences if the network resource is not available when the shortcut is activated. Windows can do stupid things like changing the shortcut target to try and point at a similarly named file elsewhere, and then you have a support issue.

In this scenario, my preferred solution is to use a shortcut "launcher", which can be something as simple as a batch file. The batch file logic checks whether the EXE can be "seen" on the target network share and if so, launches it. If the EXE cannot be "seen" then an error message is displayed for the user and the launcher terminates.  The launcher is deployed as part of the application and since it is local, the shortcut can be created without any issues and without needing access to the network.

On the other point, can you really not come up with a solution that avoids having to ask the user to input any information?  Presumably the drive mappings are under your control and handled by login script, so the same script could set environment variables or registry keys that would record the location of the various server apps you use, and your install could pick this up, taking the user out of the equation entirely and also avoiding entry errors.

If you have to involve the user, then you need to gather the information using a custom action that is running in the USER context and not SYSTEM context, as the user will presumably have access to the network resource and therefore your custom action can check the entry and update the registry, or set properties, accordingly.  However, it is again unusual to involve users in application deployment as you cannot rely on them inputting data reliably, so I would urge you to seriously consider alternatives which do not involve the user.

These techniques are operating system neutral so if you choose to go down this path, it should hopefully establish standards which can remain in place until Microsoft do something completely bizarre.

Hope this helps!

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.