MSI ignores mapped drive

Hi:
When a local admin, who is just a regular user on our network, runs our setup package from the network, the MSI property SetupExeDir always returns the unc path, not the mapped dirve path.

This applies to all the other related properties in both MSI and the script (SRCDIR, SOURCEDIR, SetupDir)

Now, when a network admin runs the setup, SetupExeDir returns the mapped drive, not the unc path.

This is a critical problem for us, as the underlying application MUST be installed to a mapped path, and we are checking during the install that the user is running the install from a mapped path.

The installer is InstallShield 2009, with a mix of InstallScript and an MSI package.

How can I force the script to check the mapped drive, without resorting to external dlls?

Any rapid help MUCH appreciated!

TIA,
Dan
DanWalterAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nhenny2009Commented:
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.
0
DanWalterAuthor Commented:
nhenny:
Can you please expand on this a little: "capture the ouput of  net use"?
Thanks,
Dan
0
nhenny2009Commented:
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.
0
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

DanWalterAuthor Commented:
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
0
DanWalterAuthor Commented:
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
0
Vadim RappCommented:
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?
0
DanWalterAuthor Commented:
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
0
Vadim RappCommented:
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
0
Vadim RappCommented:
should be

msiexec /l*v c:\install.log /i test.txt
0
DanWalterAuthor Commented:
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
0
DanWalterAuthor Commented:
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
0
DanWalterAuthor Commented:
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
0
Vadim RappCommented:
Absolutely, every setup.exe in general and installscript in particular has always been evil. As you can see in the log,

MSI (c) (64:2C) [09:32:16:846]: Command Line: SETUPEXEDIR=\\WIN2003\Shared\Long\Path\Test\level1\level2\level3\level4\level5\ADM\Workstation Install SETUPEXENAME=setup.exe CURRENTDIRECTORY=\\WIN2003\Shared\Long\Path\Test\level1\level2\level3\level4\level5\ADM\Workstation Install CLIENTUILEVEL=0 CLIENTPROCESSID=3428

i.e. setup.exe calls MSI already with this UNC current directory, so MSI does not even see the mapped drive.

Throw away setup.exe and use MSI (unless the msi is actually using installscript - I hope not).
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DanWalterAuthor Commented:
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
0
Vadim RappCommented:
> 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.
0
DanWalterAuthor Commented:
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
0
DanWalterAuthor Commented:
We got better support from you than we did from Acresso, the current Installshield owner!  Thanks a bunch!
0
Vadim RappCommented:
> 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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Installation

From novice to tech pro — start learning today.