Distributing MSI with Group Policy

How are you installing the secondary MSI files? If you are using scripts in the UI sequence then this will not work with group policy distribution as the install is silent and the UI sequence does not run.
If you are installing the secondary MSI files in the Execute sequence, then you must be using nested custom actions. Presumably you have tested your install manually using the /QN switch with msiexec to simulate Group Policy deployment?

Also, since you are using compressed files, these need to be uncompressed before installation, so SourceDir will point to the local temp folder where the uncompressed source files are located. If you need a pointer to the ORIGINAL location of the MSI files, then you need to be using the [OriginalDatabase] property as your pointer.

Thanks EdT for the reply. Actually I'm new to MSI "things" and very new to group policy.

In the UI sequence, vstor.exe were installed using the execute program from path. And yes, it doesn't work because gp distribution were installed in silent mode (I know about this only after reading your post). I also made the installer to detect and installed .net framework if it doesn't exist in the computer.

The secondary MSI files were installed using the "install msi from relative path". After testing my installer using the /QN switch, I found out that the result of the installation were same as the one installed using gpdistribution. And the secondary MSI in Execute sequence were not installed because a condition was used to detect either .net is installed or not. So, in the end the installer just skip that part.

One thing I didn't understand is the embedded vbscript. The script needs to read values from INI that is placed in the same location as the main MSI files. It uses SourceDir property as I mentioned in the first post. When you said that the sourcedir will point to temp directory, does it mean that all files including the main msi(plus the other msi/exe files and INI file) were also copied to the temp directory? Is it possible to read the INI files from that location?

Do I just need to replace the SourceDir property with OriginalDatabase in order to read the INI file?

I will make a few modifications to MSI files in order for it to be compatible when using with group policy distribution.  Thank you.

Before deploying with group policy, always test your installs using /QN to see if the install works. Anything in the way of pre-requisites that are installed by the UI sequence of a vendor MSI, will not be installed when you run a silent install via /QN or via group policy, so you will need to install any such pre-requisites separately. Autocad applications are notorious for installing things like MSXML6, DirectX, and other necessary pre-requisites via the UI sequence, so packaging these apps for silent deployment can result in a chain of 6 or 7 separate MSI installs.

Regarding the use of [OriginalDatabase], my advice to you is to give it a try and see if it solved your problem. It will either work or not, but due to many factors which cannot be predicted "remotely", I can only give you generic advice which you can then test IN YOUR SPECIFIC ENVIRONMENT.

In the same spirit of giving generic advice, if you have any MSI install which has compressed files, they will need to be uncompressed before installation, and this happens in the local temp folder. Since the install is then taking place from the local temp folder, that is where SourceDir will be pointing to. However, the process of "uncompressing" the files associated with the MSI is unaware of any other files associated with the install, so your INI configuration file will still be on the original source location, and will need to be referenced from there.

How much information does the INI file provide? If it's only one or two parameters, then perhaps an alternative way to insert this information into the MSI would be to pass it as one or more public properties via the installation command line .

Thanks for the suggestion. Currently the INI files contains a few lines only. Maybe the total lines will change in the future. ie: increase/decrease data.

May I know which command are you refering to? Is it the group policy?

Some starting advice:
Nested/concurrent install is not recommended as they cannot be handled separately.
Instead of using embedded vbscript custom action use "from installation" (stored in Binary table) instead as embedded contains some length limitations that may be taken inplace in the future.

.NET should be installed by itself and not as a nested install as this is a standard "component" used by (and prereqs for) many applications.


I would suggest if you have packages (MSIs) that needs to be installed prior to one package then sequence the installation (through GPO) by either add the first package to the GPO that needs to be installed prior to another or use ASSM (Assigned Software Sequence Manager) to reorder the order of installation. Make a launch condition or similar in the MSI (or transform) to prevent the MSI from being installed if the pre-req isn't in place.

For MSI files provided by a vendor you should modify any changes through a transform instead of directly doing anything within the MSI.

Installing through GPO per maching will install in quiet mode /qn and per user in basic mode /qb, per-machine is recommended as it's easier to manage.

I think Ed had a brain-fart ;) as command line cannot be used while deploying packages through GPO, instead of PUBLIC properties through command line add the properties to a transform.

Kim,
My brain has been donated to the British Museum due to it's age and beauty.
Therefore, I will rely on you to point out when I forget things. Yup, you need to use a transform to set property values in GPO. All these different distribution systems are coalescing into an indistinct fog in the place where the grey matter used to reside.......