Feature Prerequisites, Setup.exe, and Group Policy Deployment

[DLee65]

As part of our testing process with IS2009 and the new feature prerequisite options, we wanted to explore deploying SQL 2005 Express using Group Policy on a per-machine instance.

So far my tests have not been successful. The best I can see is that for some reason the MSI log reports that conditions for the SQL package could not be met. However, if I run the full UI for the setup on the same OS then SQL will install properly as a Feature Prerequisite.

That leads me to believe that there is some type of limitation in deploying packages that include feature prerequisites using Active Directory and Group Policy. If so, I was wondering if InstallShield could comment on what their tests revealed. I have uploaded my PRQ file (zipped up using 7-zip) just in case anyone is interested.

Thanks.

[MichaelU]

I could be incorrect, but I believe most deployment solutions only run the execute sequence of the MSI, and tend not to launch setup.exe. Feature prerequisites are installed directly from setup.exe when launched to give MSI a parameter such as /qn, or called back into setup.exe from the UI sequence otherwise. If your entry point is the MSI, silently, no feature prerequisites will be installed. If your package depends on the prerequisites (which it likely will), they will need to be installed separately just like with setup prerequisites in this scenario.

[DLee65]

Michael,

Thanks for the response, and you are correct. Active Directory accesses the MSI directly and only runs the execute sequence.

I would imagine that SMS deployment should work since it can deploy an EXE file although it will pass in the /qn switch to deploy it silently.

Your response brings up some other questions. Since silent installs only run the execute sequence, does that mean feature prerequisites will not work for silent installs?

In general, I guess my initial enthusiasm for feature prerequisites is dimmed. I thought this was going to be a true chaining solution but apparently it is not since it does not work with Group Policy deployment. Part of the selling point for management in our company was going to be the ability to simplify our network deployment strategies.

Since we do not want to manage separate packages for consumer and network deployment stories I guess we are consigned to keeping all our prerequisites as setup prerequisites and not feature prerequisites.

For instance our software packages requires the following Prerequisites:
(note that we only support XP sp2 and newer, W2003sp1 and newer, W2008, and Vista)
DotNet 2.0
Jet 4.0 SP8
Microsoft Visual Studio 2005 Redistributables
SQL Server 2005 Express SP2


Having SQL Server 2005 Express SP2 as a feature prerequisite is very desirable because it allows us to display an optional feature element in the Custom Setup dialog. We can conditionally display this feature option based on the license level of the product - for instance the first two license levels do not need SQL Server installed - therefore I disable the feature and do not install it. Before the customer had to sort of know that they do not need SQL Server 2005 when prompted to install it as a setup perquisite.

Is there any way to reduce the complexity of this process and still have it work for network deployment methods? Thanks.

[Christopher_Pai]

In my experience, GPO deployment, well, sucks. I much preferred SMS 2003 back in the day but that's probably been replaced with something newer.

My typical SMS advertisement was `setup.exe /s /v"/qn"` and that would run everything we needed.

[DLee65]

Yeah I agree Christopher, unfortunately there is still significant customer base that still uses Active Directory and Group Policy Manager to create deployment packages 😞

[MichaelU]

Part of this came up in the beta, and just to make it clear here, running the following command line will install setup prerequisites, the msi, and the feature prerequisites for the features that would get installed by default:

setup.exe /s /v"/qn"

To go one step further and change the feature list, the following command line will install setup prerequisites, features F1 and F2, and the feature prerequisites tied to those features:

setup.exe /s /v"/qn ADDLOCAL=F1,F2"

I mention this, because if you can run the setup.exe as part of the deployment, this might be the solution.

If you can't, then you're back to telling them which prerequisites to run when. They're all packaged in the setup or on the media like setup prerequisites were, so there shouldn't be any new and unexpected steps about this; perhaps I misunderstand what about the differences between the consumer and network deployment requires changes to the packages if you use feature prerequisites.

If the worry is that your SQL related feature could be scheduled for install without the prerequisite in place, this can probably be addressed with a custom action in the execute sequence to remove the feature. At least all prerequisite installation will have concluded by then, so if it's marked for install and the SQL prerequisite hasn't been, you know something's wrong. Whether you abort the install or just deselect the feature is up to you.

[DLee65]

You know, now that I think of it, this might not be half bad anyway.

Active Directory and Group Policy Manager are free - well you have to have W2003 Server or something like that - but you get my drift.

We can just document the process for GPOs and realize that there is a price to be paid for free deployment software in that it increases the complexity of deploying complex installation packages.

The instructions for SMS deployment however can be greatly simplified and probably for most all other 'for profit' deployment.

In any case thanks for the clarification Michael. That is appreciated.

[Christopher_Pai]

How about just creating a trojan MSI to encapsulate your setup.exe? After all, this is what the Internet Explorer team does to get around GPO limitations.

http://blog.deploymentengineering.com/2007/10/ieak-7-another-fake-msi-using-wix.html

[DLee65]

Haha ha! Then I would feel all nasty and dirty and like a cheap installation engineer Christopher *laughs*

[Christopher_Pai]

You know, as you'll read from my blog, I'm not really against encapsulation / adapter patterns. I'm just against people who preach about how ugly it is and point out competitors who do it while their very own company does it on a flagship product.


The reality is MSI and GPO have lots of limitations. A `fake` MSI would allow you to get around some of them. I don't have a problem with that, after all, it's ok to break the rules as long as you know what the rules are ( and how to test the consequences ).

[DLee65]

Yeah, I remember reading the article.

So, if I encapsulate the SQL 2005 executable in a trojan MSI and then add that to the chaining option I should be OK? I could then pass in parameters and properties based on user feedback as well I guess.

[DLee65]

Michael,

I have a followup question concerning this. I was wondering why Setup.exe does not get authored into the MsiEmbeddedChainer table. If I understand the MSDN documentation correctly that is why it was added to Windows Installer 4.5 was to support running embedded chainers.

Why are feature prerequisites not authored into this table? It would seem to make sense that this is where these should reside so that Setup.exe is not required to run first.

[DLee65]

In looking at this some more - the prerequisites are handled completely different than the chaining for Windows Installer 4.5.

The packages to be chained together need to be bundled in a EXE that calls MsiJoinTransaction and then MsiEndTransaction. What is not as obvious is that for this to work all the packages have to be MSI packages. Well, since most redistributable packages are wrapped in an EXE and since we are not allowed to modify their setups at all, then the actual implementation of this for distributing third party apps is fairly limited, unless third party vendors start providing redistributables as MSI packages without the EXE wrapper.

When I add a MSI package to the chainer section in the Releases view - InstallShield then adds in an ISChainer.exe entry to the MsiEmbeddedChainer table. This does not happen for prerequisites - which I had hoped was going to happen.

[MichaelU]

One of the primary advantages of Feature Prerequisites over MSI Transaction Processing (chained MSIs), is that Feature Prerequisites work on older versions of MSI, as well as on non-MSI prerequisites as you mention. While I think we could cheat and have the chainer install non-MSI packages, reboots would likely wreak all sorts of havoc with the scenario, and they still wouldn't receive the rollback support. All in all, I think it's better to keep these two features distinct; blurring them together just adds confusion.

[alan_d_h]

MichaelU wrote:
Part of this came up in the beta, and just to make it clear here, running the following command line will install setup prerequisites, the msi, and the feature prerequisites for the features that would get installed by default:

setup.exe /s /v"/qn"

To go one step further and change the feature list, the following command line will install setup prerequisites, features F1 and F2, and the feature prerequisites tied to those features:

setup.exe /s /v"/qn ADDLOCAL=F1,F2"

I mention this, because if you can run the setup.exe as part of the deployment, this might be the solution.

What is the mechanism for installing the feature prerequisites for F1 and F2 or for the default features? Is the InstallShield bootstrapper preprocessing the "/v /qn" command line option and installing the feature prerequisites as setup prerequisites, or is there some magic undocumented property, transform, or custom action being applied to/in the MSI to force the feature prerequisites to run in the execute sequence of the MSI?

[MichaelU]

The former; setup.exe runs them before passing control to the silent install. Feature prerequisites are conceptually installed after feature selection. In a silent MSI, feature selection is not based on user input, so can happen alongside (although still after) setup prerequisites.