Page 1 of 1

GP Cmd Line Params AND specify target dir at install time

Posted: Tue Dec 09, 2008 4:23 pm
by jsmith
If I use the Group Policy wizard to create an MSI with Command Line Parameters specified, how can I later install the MSI silently to a path specified at install time without overriding the Command Line Parameters that were specified in the Group Policy Wizard?

I've read that the TARGETDIR can be specified by setting CMDLINE, thusly:

Code: Select all

msiexec /i My_Installer.msi CMDLINE="TARGETDIR=C:\\My\\Path" /quiet
But if I do this, it overrides the Command Line Paramters that were defined in the Group Policy Wizard. I also tried:

Code: Select all

msiexec /i My_Installer.msi CMDLINE="$CMDLINE$ TARGETDIR=C:\\My\\Path" /quiet
But this caused My_Installer.exe to go to 99% CPU usage and stay there until I killed it after 20 minutes or so. There was an entry in the application event log from MsiInstaller saying that my product had been installed successfully, but it doesn't appear in ARP and there's no trace of it on disk.

So... how can I install a group policy MSI to a path specified at install time without overriding the command line parameters specified in the Group Policy Wizard?

Posted: Fri Dec 12, 2008 9:37 am
by jsmith
Anyone? InstallAware folks?

Posted: Sun Dec 14, 2008 6:58 am
by sinan
When you set a variable to itself, you are starting an infinite loop as the variable is being constantly re-substituted with itself, without end. You cannot do that.

Overriding that variable will of necessity lose its default value, you can just override it while still providing the old values of the variable. You are not restricted to just one command line parameter in this variable so provide them all when overriding.

Posted: Mon Dec 15, 2008 10:08 am
by jsmith
Thanks for the reply.
When you set a variable to itself, you are starting an infinite loop as the variable is being constantly re-substituted with itself, without end. You cannot do that.
That is... surprising. In most programming and scripting languages, there is nothing wrong with the expression "myvar = myvar + 2;" I'm surprised that MSICode has such trouble with this.

...you can just override it while still providing the old values of the variable. You are not restricted to just one command line parameter in this variable so provide them all when overriding.
How can the end users be expected to know what the original values specified in the CMDLINE property within the MSI file were? The point of specifying them in Group Policy is so that they'll be set as defaults for the user. He needs to be able to specify the installation path without knowing and without losing these default values.

Posted: Thu Dec 18, 2008 2:39 pm
by jsmith
Bump...

Is there any way to install a group policy MSI to a path specified at install time without overriding the command line parameters specified in the Group Policy Wizard?

Posted: Tue Jul 14, 2009 3:06 pm
by jsmith
Before I move forward with plan to get around this limitation by altering the MSI programmatically to add some custom actions after gplwiz is done, I'll try asking here one more time...

Is there any way to install a group policy MSI to a path specified at install time without overriding the command line parameters specified in the Group Policy Wizard?

Thanks!

Posted: Tue Jul 14, 2009 3:20 pm
by MichaelNesmith
From the help file notes for the Group Policy Wizard:

Read the $GPOPATH$ variable inside your script to determine if Group Policy deployment is being used. When this pre-defined variable is empty, Group Policy deployment is not being used. When this variable is not empty, Group Policy deployment is being used, and the variable contains the full path of the folder containing the single file MSI package. This path information may then be used to read additional configuration settings from that distribution folder.

It might make sense to use Get INI File Settings to read an INI file in the same folder as the MSI with this variable, using the form $GPOPATH$\\my settings.ini. You could provide lots more options for customization this way, not just the target path. You could of course also use a custom format using Read from Text File, Parse String, etc.

Posted: Tue Jul 14, 2009 3:35 pm
by jsmith
Thanks for the reply, Michael. We'll consider that possible solution.

However, the reason we add some custom parameters to the CMDLINE using the Group Policy Wizard is so that the things that would be in an INI file are set to default values, thus avoiding the need for a supplemental INI file. Ideally, we'd be able to install the .msi file like this:

msiexec /quiet /i OurInstaller.msi CMDLINE="TARGETPATH=C:\\path\\to\\wherever"

and it would install to that custom path while maintaining the parameters defined when the Group Policy Wizard created the .msi.

Posted: Tue Jul 14, 2009 3:49 pm
by MichaelNesmith
You should already be able to do that, just use TARGETDIR and not TARGETPATH as the latter is not an InstallAware variable (unless, of course, you defined it).

Posted: Tue Jul 14, 2009 4:00 pm
by jsmith
Oh, sorry, I was using TARGETDIR. "TARGETPATH" was a typo on this forum. In the first post in this thread I had it correctly typed:
I've read that the TARGETDIR can be specified by setting CMDLINE, thusly:

Code: Select all

msiexec /i My_Installer.msi CMDLINE="TARGETDIR=C:\\My\\Path" /quiet

But if I do this, it overrides the Command Line Paramters that were defined in the Group Policy Wizard.

Posted: Tue Jul 14, 2009 4:14 pm
by MichaelNesmith
I see, well unfortunately since the CMDLINE property is specifying only the additional parameters in this case, I can see why it would "lose" the other specified values. I'm afraid I don't see a workaround for this one.

Posted: Tue Jul 14, 2009 4:18 pm
by jsmith
No worries. There are workarounds, such as using an INI file as you suggested, or an approach I'm thinking about would be to alter the MSI to have values in the Property table that correspond to each of our params, then a custom action that pulls them all together at runtime to create the CMDLINE property. This might work.

I just wanted to make sure I wasn't missing something simpler before moving forward. We're evaluating our options. Thanks.