MSI software deployment vs. using a script

Genesys found that deploying software using the formerly recommended base .msi installation package methods has the following limitations:

Machine policies require at least two reboots before the software is installed

When the computer is rebooted the first time, the software is installed in an advertised state. It shows up in Add/Remove programs, but it is not yet installed. The second reboot of the computer actually installs the software. This process can sometimes require three or more reboots depending upon the network, the group policy enforcement and other considerations.

User policies are installed in an advertised state

When the user logs onto the computer, the software is installed in an advertised state. Depending upon how the group policy was set up, the user will either need to click on a shortcut to fully install the product or open a file associated with the product. The user policy will not fully install the software on the computer without user action.

Applying patches to the GA install requires an administrative install

If the administrator wants to install the GA product and apply a patch at the same time, a patched administrative install needs to be created and the group policy needs to deploy the resulting .msi. Future patches cannot be applied to this installation directly - they require that a new administrative install be created, that install be patched, and then the patched .msi be redeployed. These types of installs cannot be patched using Interactive Update.

Using a group policy to apply a script to do the software install removes all of these limitations.