Administrative Install Prerequisites
I have a question around performing Administrative installs of vendor MSI's that have installation prerequisites.
(For example, a vendor MSI that requires a certain version of isscript or .NET Framework to install.)
It's fair enough that the MSI is prevented from installing when running msiexec with a /i to install it. However, when running msiexec /a, I am prevented from performing an admin install due to the prerequisites not being installed on the machine I am using to generate the admin install.
I do not want to have to install all prerequisite software on the machine being used to perform the admin installs, therefore the question is - Is there a way to suppress the check for prerequisites when performing an admin install ?(as technically they are not needed, as the product is not actually being installed)
Alan
(For example, a vendor MSI that requires a certain version of isscript or .NET Framework to install.)
It's fair enough that the MSI is prevented from installing when running msiexec with a /i to install it. However, when running msiexec /a, I am prevented from performing an admin install due to the prerequisites not being installed on the machine I am using to generate the admin install.
I do not want to have to install all prerequisite software on the machine being used to perform the admin installs, therefore the question is - Is there a way to suppress the check for prerequisites when performing an admin install ?(as technically they are not needed, as the product is not actually being installed)
Alan
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
nheim
15 years ago
Hi Alan,
yes, of course this is possible (well most of the time...).
However, you need some in deep know how to achieve this.
To make progress, you need to log the beast and work through it to eliminate all the conditions, which are in the way.
Another trap is that quite a lot of MSI's lack the "AdminExecuteSequence" + "AdminUISequence" tables, which in the case of the "AdminExe..." one is a showstopper.
Regards, Nick
yes, of course this is possible (well most of the time...).
However, you need some in deep know how to achieve this.
To make progress, you need to log the beast and work through it to eliminate all the conditions, which are in the way.
Another trap is that quite a lot of MSI's lack the "AdminExecuteSequence" + "AdminUISequence" tables, which in the case of the "AdminExe..." one is a showstopper.
Regards, Nick
Posted by:
ab2cv
15 years ago
Hi Nick,
Thanks for the response.
Yeah, I was thinking along the same lines as you are, in that there are probably some actions that could be suppressed in the AdminExecuteSequence table, like (off the top of my head) LaunchConditions. Being a vendor MSI though, it would need to be a transform to effectively 'drop the row' from the table, and even then as you say, there could be other Custom Actions that are running prechecks and blocking the installation as a result. I speculatively wondered (hoped) that there may have been an extra switch on the commandline to override installation prechecks for administrative installs, but thinking about it further, this would rely on every vendors AdminExecuteSequence table conforming to a single standard, which isn't very likely.:-)
To give more background on what we're trying to achieve here, basically we are looking for an automated way of expanding the source for every MSI package we have, so that we can physically interogate the exe files that the package installs for various things (in particular, version number). Now I realise that the MSI File table contains a column for File Version - However, when we tried to use this, we discovered that this does not correlate to the version that SMS reports back when interrogating exe files installed on a machine. (right click -> properties on a versioned file and see that sometimes the internal version and file version differ ever so slightly in the way they are displayed).
Any other thoughts greatly appreciated.
Alan
Thanks for the response.
Yeah, I was thinking along the same lines as you are, in that there are probably some actions that could be suppressed in the AdminExecuteSequence table, like (off the top of my head) LaunchConditions. Being a vendor MSI though, it would need to be a transform to effectively 'drop the row' from the table, and even then as you say, there could be other Custom Actions that are running prechecks and blocking the installation as a result. I speculatively wondered (hoped) that there may have been an extra switch on the commandline to override installation prechecks for administrative installs, but thinking about it further, this would rely on every vendors AdminExecuteSequence table conforming to a single standard, which isn't very likely.:-)
To give more background on what we're trying to achieve here, basically we are looking for an automated way of expanding the source for every MSI package we have, so that we can physically interogate the exe files that the package installs for various things (in particular, version number). Now I realise that the MSI File table contains a column for File Version - However, when we tried to use this, we discovered that this does not correlate to the version that SMS reports back when interrogating exe files installed on a machine. (right click -> properties on a versioned file and see that sometimes the internal version and file version differ ever so slightly in the way they are displayed).
Any other thoughts greatly appreciated.
Alan
Posted by:
nheim
15 years ago
Hi Alan,
looks like an very uncommon task to me. What are you trying to achieve with this?
What are you doing with software, which has more than one exe? Which one determines the version?
What, if the new version has only changes within some configuration files (generally: unversioned files)?
This info gives you nothing to decide, if you have to install a new patch or version.
If you really need this, use some VB Script to read out the info from the MSI.
BTW: What are you going to do with SW that come with other installers like INNO or NSIS?
IMHO, you can put in hundreds of SW-versions by hand for years, before this effort pays off (if this point ever comes...).
To go back to your questions:
Had never the situation, that an action in the AdminExecuteSequence stopped the process.
The most common show stoppers are the absence of the hole AdminExecuteSequence table and launch conditions.
See: http://www.appdeploy.com/messageboards/fb.asp?m=25423 for a solution.
Regards, Nick
looks like an very uncommon task to me. What are you trying to achieve with this?
What are you doing with software, which has more than one exe? Which one determines the version?
What, if the new version has only changes within some configuration files (generally: unversioned files)?
This info gives you nothing to decide, if you have to install a new patch or version.
If you really need this, use some VB Script to read out the info from the MSI.
BTW: What are you going to do with SW that come with other installers like INNO or NSIS?
IMHO, you can put in hundreds of SW-versions by hand for years, before this effort pays off (if this point ever comes...).
To go back to your questions:
Had never the situation, that an action in the AdminExecuteSequence stopped the process.
The most common show stoppers are the absence of the hole AdminExecuteSequence table and launch conditions.
See: http://www.appdeploy.com/messageboards/fb.asp?m=25423 for a solution.
Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.