InstallAware & GPO Deployment

[JXBURNS]

I've spent a while testing this over weekend, and have had a colleague duplicate this same effect ,which I can only think is something I have done wrong or a problem with InstallAware.

Running IA6.1. Captured a setup using PackageAware. Opened in IA, generated new GUID's just in case. Tidied up some entries & built the compressed EXE. Tested that fine manually running on a Win2003 Small Business Server and XP SP2 client.

Went back and used GPO Wizard to build a MSI file. Again tested that manually and worked OK.

Then went into a new GPO object, added the MSI to the software installation key and after a few seconds it is added. Restarted the client and the software is installed. All OK so far.

Then I noticed that the same software was installed on the server and appeared in Add/Remove Programs. Strange I thought as had not installed there. So removed it (which took ages compared to installation), restarted server. Not there - good. Went back to the GPO and removed the installer object which in turn removed from the client after a client reboot. Again as it should be.

Then added in again to the GPO and I noticed this time it was installed on the server at the same time the MSI file is either double-clicked. or OPEN button clicked, in the GPO dialogue box. Just before the software is displayed in the GPO object as ready for installation. That is when I had my colleague test with the same MSI as he runs a duplicate of my system as a secondary means of testing software.

OK I thought, let's try another MSI file (Microsoft's CalcPlus software), which is not InstallAware built, and that works perfectly. It installs on the client but not the server.

Well I cannot understand why an IA installer should install on the server through GPO even when the GPO object is no linked to that server, nor is the server in any security group or OU. I even created a brand new IA6.1 project with completely different software to be installed and exactly the same scenario happens in that the software is installed on the server.

I can't think it is a GPO problem as there are no reports on TechNet or anywhere like that so can only assume something in the MSI is being triggered.

Any ideas anyone?

Thanks - John

[GavinSmith]

You may have already done so but run the Resultant Set of Policy (RSoP) on the server to see exactly what GPOs are being applied. You can also select a user. E.g. The account you used to log onto the server.

If the software deployment is targeted per users and not computer, by logging onto the server this may be in-avertedly installing the software.

Good luck

[JXBURNS]

Gavin,

I had already run RSoP after I wrote my earlier message but nothing obvious springs out at me. I am only applying the software at computer level as has to go to all clients regardless of user. The fact my colleague, who built his system using Virtual Server, suffers the same problem is suspicious as his GPO objects are likely to be different from mine (or set to default).

To clarify, the software is being installed on the server as soon as I add it to the list of packages in the GPO. I am not restarting the server, logging off or even exiting the GPO when it does this - the hourglass flickers a few times so I know it is doing it. Removing the software from the GPO does not remove from the server but I am able to remove manually.

I seem to only have this problem on InstallAware built installers - the ones I have tried from others seem to install fine on client without installing on server. I'm not saying it is IA causing this but it's difficult to isolate the cause. Rebuilding the installers etc. makes no difference.

Thanks - John

[GavinSmith]

Hi John,

I had time to check this out last night. You are right. Every app that I have added in to be deployed via AD software distribution, user or computer based is installed on my admin server.
Easy way to double check was to compile the MSI with out the silent switch.
It pops up as soon as you add it in the GPO.
Am flat out nut will have time to dig deeper over the weekend.

[JXBURNS]

Gavin,

Thanks for that. I'm still not sure whether it is IA or something to do with GPO deployment but every non-IA MSI I test out works fine without installing to server.

I'm up to the proverbials as well but will have a go next week with some debugging stuff in to see what is happening.

I did think about setting the OS criteria so that installer should fail because wrong OS but realised that this uses minimum levels rather than saying "IF XP do this' or 'IF Win2003 do that'. Suggestion for IA (perhaps) to implement exact OS checking rather minimum levels in the 'APPLICATION REQUIREMENTS' option?

Rgds John

[MichaelNesmith]

Hi John,

Sorry - it took me a little while to research this for you. This behavior appears to be a natural side effect of InstallAware GPO packages. If this is undesired, you can simply check for the GPO command line on the server you are installing in your package (trying using MessageBox to show $CMDLINE$ to get started), and then exit if you determine the GPO is running on your host server.

[JXBURNS]

OK there is actually no command line value returned (as no parameters on the MSI) but guess I can have system expect a dummy one on a client and not on serve aborting if none found

Strange behaviour - is this planned to be fixed?

Thanks - John

[andrejzr]

Hello,

Uau, I was really glad to find this post - it explains exactly the same problems, I am experiencing when testing the Group Policy installations.

Have there been any updates regarding this issue?

I am thinking how I could use the CMDLINE parameter, I already checked, but it seems that the command line is the same, regardless of the MSI package being run on the server or on the workstation, where it is deployed to.

Any new on this issue?

Thanks
Andrej.

[MichaelNesmith]

Sorry, no updates.
I think the suggestion above to pass a new command line should work (to clients). This way it will abort on the server when the "magic" command line is missing.

[andrejzr]

Hi Michael,

Thank you for your answer. I am glad that there is a way to resolve this problem, but can you please give me some more details how to use the command line in in this case?

When I generate a GP MSI file, I add /s and one additional custom parameter (actually setting a value of a variable), that my main setup script is using. What should I do to distinguish between running the MSI on the server (the "wrong one") and running the setup on the client (when it is actually executed by the GP?

It might be obvious, but I just don't see how to do it

Thank you
Andrej

[MichaelNesmith]

To override the built-in command-line that you specified in the GP Tool, set the public CMDLINE MSI property (which will get passed to the inner setup).

[andrejzr]

Hello,

Thanks for the answer. During preparation of the MSI file, I already use few command line parameters (besides the /s), that define how the setup should operate. These command line parameters are defined during the "server" installation part of the software. This prepares the "client" installation (MSI file in this case) based on the parameters the user selects (using the GP tool in command line mode).

If I set the CMDLINE MSI property, I will loose the command line, generated while creating the MSI file. Did I get this correct?

Thanks
Andrej

[MichaelNesmith]

Yes, this allows you to override the built-in command line.

[JXBURNS]

Does anybody know if this original problem has been solved in the latest release?

Does MINIMUM requirement really mean that or if I select XP from the dropdown, it will only install on XP & not on Server 2003/Vista which are higher up the technology tree?

And I think I am being stupid but I have not been at all successful when it comes to setting the CMDLINE MSI property. Are there any examples?

Sorry to be a pain but my Win2003 server is currently U/S so I am relying on someone on other side of world with similar system to test and I don't want to keep have going backwards/forwards.

Thanks - John

[JXBURNS]

Answering my own message, the latest version (6.22) has still not fixed this problem.

Any MSI created using IA also installs on the host (Win2003) server when placed into the GPO object for software installation. This is despite setting the minimum level to XP in the installer.

This is actually quite a major problem as we are testing the client in this example, not the server, but the software is being installed on the server and potentially making unwarranted changes. I reiterate that MSI's created using other installers, or ones that MSFT generate for example, do not show the same symptoms.

If the MINIMUM option was changed to a series of check boxes for which OS to install on (and associated checking logic) then this would be better but as I do not know what is causing the MSI to be installed, I can't tell whether this would ultimately fix it.

Thanks - John