This is not a question, so much as a request for comments regarding something I think I've figured out...

Leveraging GPO link sequence is ideal for providing ISscript to MSIs that need it.

Due to the fact that GPO foreground policy check goes like so (for let's say a 50 GPOs, all linked to a single OU) (also, I'm only focusing on GPOs that deploy MSIs here):
1) computer boots up
2) checks all GPO links that are computer enabled, from 1 to 50 (1, 2, 3, 4...), to see if any MSIs should be removed (assuming "uninstall when out of scope" was originally set)
3) as each one comes up that needs uninstalling - it uninstalls it
4) checks all GPO links that are computer enabled, from 50 to 1 (50, 49, 48, 47...), to see if any MSIs should be installed
5) as each one comes up that needs installing, it installs it

BTW: Admins that never leverage the "uninstall when out of scope" option on their GPOs will be kind of unfamiliar with steps 2 and 3 I guess.

So let's I have an MSI we'll call "FerretFace" that requires ISscript11, I would create the following (all GPOs set to "uninstall when out of scope"):
A GPO we'll call ISscript11 that pushes ISscript11.MSI
- I put AD group "FerretFace - Comps" it its scope
A GPO we'll call FerretFace that pushes FerretFace.MSI
- I put AD group "FerretFace - Comps" it its scope

So when I add an AD computer account to the AD group "FerretFace - Comps", and that computer boots up it does the following:
1) installs ISscript11.MSI
2) installs FerretFace.MSI (which it needs ISscript11 to do)

And when months later for whatever reason, I want to uninstall FerreFace from that computer I simply remove it from the group, and due to GPO link sequenced checking, it does the following in this order:
1) uninstalls FerretFace.MSI (which it needs ISscript11 to do)
2) uninstalls ISscript11.MSI*

* unless I've deployed let's say another MSI that needed ISscript11, and had put that MSI's GPO's scope's AD group into the scope of the ISscript11 GPO, AND this computer also belongs to this app's AD group then it'll just leave ISscript 11 on the computer.

So given the above, as long as I keep my ISscript deploying GPOs right at the top of my link sequence (so link number 393 out of 393) then I can always ensure it arrives just before the MSI that needs it, and leaves shortly after removing the MSI that needs it, simply by putting the AD group for that MSI into the scope of the ISscript GPO.

Clean, simple, flawless, yes? It even allows for multiple ISscript version deployments.

Does anyone have any comments or criticism of the above approach for handling ISscript dependent MSI deployments?

Thanks in advance for any feedback...
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Hi Kyle,
impressing, but unfortunately not the ultimate solution, IMHO.
Because the ISscript MSI's have problems of all sorts (concurrent productcode, permission problems etc.), i wouldn't recommend your setup.

Please read this: http://www.appdeploy.com/messageboards/tm.asp?m=9841

We consequently embed the appropriate MSM to packages that need an isscript engine and got a lot fewer problems with that approach.
Maybe not the feedback you where exactly after, but... :-)
Regards, Nick
Answered 03/28/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
I have to wholehartedly agree with nheim here. Using the "msm in mst" approach is the only one I'd recommend. Now if only Macromedia would let you easily download the different msm versions it'd be bar on easy. But they don't [&:]
Answered 03/29/2007 by: jib
Purple Belt

Please log in to comment
I agree MM's are the best way forward and are available here http://www.installshield.com/downloads/modules.asp?prod=ISX&lan=english&xmlUse=y (except 11 & 12 as jib pointed out)

Answered 03/30/2007 by: Tone
Second Degree Blue Belt

Please log in to comment