MSI ignores mapped drive

You could add a CA that would translate the UNC path back to the mapped drive.  You could capture the ouput of  net use and then compare the output until it matches the UNC path location and then update all the required properties.

nhenny:
Can you please expand on this a little: "capture the ouput of  net use"?
Thanks,
Dan

Sure, you could run a net.exe use command and capture the output to a file or store in memory.

To send to file:
net.exe use > netuse.log

You'll get something like this:

Status       Local     Remote                    Network

----------------------------------------------------------------------------
Disconnected I:        \\ServerName\myshare       Microsoft Windows Network
OK           L:        \\ServerName\PVCRC$     Microsoft Windows Network
OK           M:        \\ServerName\Dist$     Microsoft Windows Network
OK           N:        \\ServerName\Conv$  Microsoft Windows Network
OK           O:        \\ServerName\qa$         Microsoft Windows Network
OK           P:        \\ServerName\CRE$        Microsoft Windows Network
OK           R:        \\ServerName\Sup$     Microsoft Windows Network
OK           S:        \\ServerName\Dev$ Microsoft Windows Network
OK           T:        \\ServerName\PVC$     Microsoft Windows Network
OK           U:        \\ServerName\builds      Microsoft Windows Network

You can then look for the UNC path in this output...and then find the associated drive letter.  You could do this in vbscript, c# etc.  Then just have add it as a custom action.  Once you have the drive letter than update the required install properties.

nhenny:

I tried to implement the solution you suggest.  There were two insurmountable problems:

1) It's hard to tell which map drive the user "wants" to use, if they have two mappings to the same server.  Now we could just take the mapping that matches more characters in the UNC string (e.g. if our unc is \\server\folder1\folder2\folder3, then we use drive E: that is mapped to \\server\folder1\folder2, rather than drive F: that is mapped to \\server\folder1).

2) It's impossible, AFAIK, or near enough, to properly parse the output from net use.  For example, how do I know the difference between this remote and this network?
OK           U:        \\ServerName\builds\Project 1\Source Data      Microsoft Windows Network
The spaces in the path become unworkable.

I am posting the REAL problem and our proposed solution next.

Thanks for your efforts,
Dan

All:
The REAL problem here is the hyper-vigilant UAC "helpfulness" in Vista.  And now I see that I neglected to mention that the problem occurs on a Vista workstation!

When we disable the UAC nonsense, not only does the install run amazingly fast, the install ALSO can read the mapped drive - tada!  So we are implementing a series of checks to temporarily (for the life of the install) change the uac policy, like this

C:\Windows\System32\cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f, and then to reset it (change DWORD value to 1) after the install.

This does require 2 reboots, as the change to the reqistry key requires a reboot to be activated.  But the method works reliably and requires no decisions on the part of the end user (the installee).

Any better ideas, especially to avoid the first reboot, would be much appreciated.

Thanks,
Dan

I tried this on sample MSI (however, created by Wise, not by IS), and with Installer 4.5 it did not happen - non-network-admin got SOURCEDIR=Z:\. Can you post the detailed log of the installation?

vadimrapp1:

Sorry for the delay - I had a bit of a time booting everything up!

Here is the sourcedir reference from the log:
Property(C): SOURCEDIR = \\WIN2003\Shared\Long\Path\Test\level1\level2\level3\level4\level5\ADM\Workstation Install\

I am attaching the entire log file.

Thanks,
Dan

wssetup.log.txt

this is not full log. http://support.microsoft.com/kb/223300

Here's attached file I created to try this out (renamed from .msi to .txt) - the SOURCEDIR shows up on the first screen, you can cancel the installation then. Run it from mapped drive by

msiexec /l*v /i test.txt

and see what it shows. And post the log.
test.txt

should be

msiexec /l*v c:\install.log /i test.txt

vadimrapp1:
Here is the log file from your test.  It did report the mapped drive correctly.  I will now run my install and post that log next.

Dan
install.logfromtestmsi.txt

vadimrapp1:
Here is the log file from my app.

Curiously, the msi runs just fine and reports the mapped drive when I am running only the MSI.  I will try the setup.exe (which calls the msi), and post the log from that, next.

Dan
install.logfromDANmsi.txt

vadimrapp1:

The problem seems to be, then, with the setup.exe, possibly something in the installscript?  See attached log file - very clearly the same msi package reports UNC path not a mapped path.

Thanks,
Dan

install.logFromSETUPEXE.txt

vadimrapp1:
LOL - We are using the setup.exe primarily to test whether the user is running the msi from a mapped drive!

The underlying application needs to use a mapped drive.

We were using the setup to determine the user's privileges for updating windows components before they get to the deferred execution time screens.  Also, using the setup allows us to do minor updates within the same msi version number - say an update from our msi version 8.0.1620 to 8.0.1621.  We will test various msi only solutions and get one that works.

The msi is in fact using the InstallShield InstallScript code to present and deal with the UI dialogs.  In this case, there are very very few requirements - only two in fact.  So we should be able to test for sourcedir and privileges just as we are, without the setup.exe wrapper.

Thanks for the help!
Dan

> The underlying application needs to use a mapped drive.
> We were using the setup to determine the user's privileges for updating windows components before they get to the deferred execution time screens.

I don't know the details of course, but all this smells like quite noncompliant solution that might be improved from the global perspective, so to speak. Just a feeling. Noncompliant solutions exercising tricks tend to be constant source of trouble, so the sentence "the very last problem is in fact always before-the-last one" fully applies.

vadimrapp1:
I think you are right - this is a "noncompliant solution".  I could go on and on about the reasons (old code, and the compliance standards do not fit our requirements), but I won't.  For now, we are going to use the msi only approach, and hope that Windows 7 removes some of the layers.  

Just a quick little rant, please?  Now, why would removing the UAC policies all of a sudden change what setup.exe can detect?

End of rant, and end of thread.

Thanks again!

Dan

We got better support from you than we did from Acresso, the current Installshield owner!  Thanks a bunch!

> why would removing the UAC policies all of a sudden change what setup.exe can detect?

a little rant in response. Probably for the same (quite general) reasons why "removing" war on terror and all other bs would also change the number of the holes in the road you are driving and number of computers in your kid's school. See general considerations at smokingmirrors.blogspot.com . UAC and the myriad of all other efforts to "protect" us is from the same sleeve, same philosophy.