MSI installer can't install 3rd party setup files

[Ton_B]

I've created an application whitch will check if my msi-installer has been installed.
If not it creates a new process with administrator privileges, so the msi-installer can run.
It also creates a "NET USE" , because this administartor process does not have any mappings to the server (where the msi is located)

The application will then passes a commandline (Path) to the msifile which containes the location of the msi-file.

In a sub directory of the original msi-file are the setup-files of the 3rd party setups located.

Example:

{Sharename}:\\SetupFiles\\Mosos\\MososSetup.msi
{Sharename}:\\SetupFiles\\Mosos\\Components\\Dotnetfx.msi
{Sharename}:\\SetupFiles\\Mosos\\Components\\msxml.msi

All this workes fine, and the setup will start correctly.
If the prerequisits are not present the msi-installer will then try to start the 3rd party setup(s) using the Run Program command.

A strange problem occurs:
Using Windows XP the Dotnetfx and msxml setup-files will start, but the administrator privileges has dissapeard ! And in in Windows 2000 SP3 (our minimum requirement) nothing happens.

I've added a kind of errorhandler, checking if there are any files present in the subdirectory using the "Find all files" command.
And to my surprise running in windows 2000, it does not find the file(s) !!

I've also tested it, without my application, just by creating a DOS-box with administrator privileges, and entered the commandline by hand. But even then the setup will not run in windows 2000.

Any idea's how to solve this?
I really do not want to embedd the necessary requirements !!

It seems the run command uses the currnet logged-in user account in windows XP and windows 2000 can't seem to access the created NET USE share.

Thanks.

Ton Blokhuizen

[MichaelNesmith]

How exactly is this InstallAware related - I seem to miss that.

You realize don't have to embed these setups with InstallAware with web builds, and InstallAware offers pre-built runtimes for both the runtimes, right?

[Ton_B]

I know you can use web builds for deploying external setups, such as dotnet.
But our customers do not have an internet connection, and the location of the setup-files can be different per customer.
Therefore I pass the location of these files using the CMDLINE parameter.

But before you can run the main installation, you must have administrator privileges, and, and this is very important, you must have a connection to a server share, where the msi-file is located.
Most users do not have admin privileges, so I tried to simulate the "Run as user" command from microsoft windows, creating a Visual Basic program which does the following:

1) Opens a DOS-box with administrator privileges, using the local admin account. (the username and password are stored inside an incrypted file)
2) Because this DOS-box does not have any network shares I then create a connection to a networkshare like this:

Code: Select all

 NET USE X: \\\\SERVER-01\\Mosos\\Setup User:Domain\\Username Password PERSISTANT:NO

3) After the connection has been created I start the main installation, like this:

Code: Select all

X:\\Setup.msi CMDLINE="Location=X:\\Components"

The main installation will start just fine, and the variable location is read fine.
Inside my setup(IA) I then try to start the other installation programs located in "X:\\Components" using the Run Program command.
This is where the real problem occurs:
In Windows 2000 IA can't find any file inside "X:\\Components\"
Windows XP does find the files, but seems to start that setup file using the user-account instead of the admin account.

[Ton_B]

Hi Michael,

I misunderstood what you ment with "Web builds"

Instead of a selfextracting single exe, you can choose "Web build"
So, I've tested this kind of build and it looked fine, creating 1 setup-file and 3 7ZIP files probably compressed versions of the setup-files such as .NET and XML parser.

I was getting pretty happy, until I "converted" the executable to an msi using the pakcage and deployment wizard......
Running the new generated msi, it will result in an "error" which sais:

Code: Select all

Retry Extraction?
Extraction of installation data downloaded from the web has failed. What would you like to do? .... etc.

If I run the executable instead everything workes fine, but I do not want to create an exe?
Is there a workaround?
Do I have to pass the location of the files to the Executable using a commandline ??

We are getting close to the solution!

[EDIT]
I've tested the executable on a windows 2000 and XP machine, using my VB-program, and it works perfectly.
I really hope you can provide the answer of using this functionallity running the msi file!
looking forward to your answer!

Thanx in advance !

Ton Blokhuizen

[MichaelNesmith]

Aren't the weblock URLs available for download from the GP MSI at the given weblock URL? Remember, the weblocks won't be put inside the GP MSI, and putting them in the same folder as the GP MSI won't work either. You can however specify the path to the GP MSI folder as your weblock URL, or even use custom URLs with variables every time you run...

[Ton_B]

That is exactly what I have done, and at first it looked fine

Both the .NET framework and the XML parser were installed perfectly.

Restoring a clean image of a windows 2000 SP3 machine, I've tesed it again.
And, as expeced, next to the .NET framework and the XML parser my setup detected that Windows Installer 3.0 had to be installed first.
So it unpacked the 7zip file and began installing the MSI 3.0.

But then I've got an error saying something about, it could not install it and you had to do it using the windows update.

After some search I've came to the conclusion it is not possible to install the MSI 3.0 file when you have created a MSI installation package (which of cource is running using MSI 2.0)
It seems this is only possible when you create an EXE-setup !

Is there something I can do about this?

I've started my setup, using the following commandline inside a DOS-box:

Code: Select all

 c:\\>msiexec /i g:\\setup\\mosossetup.msi CMDLINE="Location=g:\\Setup\\"

[MichaelNesmith]

There is no way to work around that, you have to be able to run an EXE file to update MSI itself, naturally (althought that might work with a simple reboot request).