Installation Monitor Mode is not a recommended mode for something like Google Chrome.
Much safer to use Component Select.
Google Chrome Standalone installation allows you to do this:
chromestandalonesetup.exe /silent /install
Plenty of suggestions available via Google on how to uninstall silently too.
Hi Sumant.
I would suggest that using Installation Monitor Mode to publish modern applications is not a best practices approach. Instead I highly recommend using the Radia Publisher as the standard tool for promoting new content into. The publisher supports numerous types of content, and in my experience the best approach for publishing Google Chrome is as follows:
I have found that Google Chrome works better as a Basic MSI package than Advanced MSI package. I believe the reason for this is that there is a second MSI nested in the main MSI, and this type of nested MSI does not deploy successfully when published in the Advanced MSI mode. Fortunately, the Basic MSI mode still provides full management capability for the application, including install, verify, update, and delete. I would suggest that any MSI which does not deploy successfully in advanced mode should be tried in Basic.
Using the Basic mode in the publisher enables you to use consistent publishing practices across multiple applications and eliminates the need to "re-invent the wheel" by creating your own drop and run packages using Component Select. The ability to delete the payload after install (or not) is also a nice feature built in to the publisher.
If you try this approach I would be interested to hear the results.
Steve
I my opinion, Chrome is best managed via Radia Patch Manager using custom descriptor files. Radia 9.2 has the ability to acquire/manage Chrome, but the google_chrome.xml appears to be out of date regarding the version of chrome vs. the actual google*.msi that is acquired. The xml needs to be updated by the vendor so if it isn't updated there could be a mismatch of version vs. module.
My customers are having great success using custom descriptor files to manage Google Chrome, and other third party apps via Radia Patch Manager.
Hi Sumant,
The option to delete the payload is only available in the latest version (RCA 9.2). That didn't occur to me until I saw your comment or I would have mentioned it earlier. As to the package still not deploying successfully... One thing I have seen is the fact that the RCA Publisher will sometimes set the architecture flags either at package level or service level or both based on the architecture of the machine on which it was packaged. So if you packaged it on a 32-bit machine, the package and/or service can get tagged as a 32-bit package. Then when it is delivered to the client the installation is skipped on any machine with a 64-bit OS. To reset the package and service to deploy to both architectures, change the ZBITARCH attribute in the Package and the ZSERVICE to blank using the CSDB Editor.
If that is not the reason for the failed deployhment, there should be some further information in the client connect log at the point where the installation is attempted.
You are blowing my mind here Steve! "The option to delete the payload is only available in the latest version (RCA 9.2)". I had no idea! And we have been kicking around thought of doing something like this for years. Can you tell us how that is implemented? Client and/or CSDB flag (new field?), is that only for Basic MSI? If this is in the 9.2 doco then I will gladly read it. If it make sense to put this in a new thread go for it.
Hi Brian.
The option is mentioned on page 445 of the Systems Administrator Guide. It has been implemnented as a part of zcreate.cmd file which is delivered as part of the MSI Basic package. And yes, I think it is only valid for Basic MSI packages. As noted in the Guide:
If a service is published with the Delete payload
after install option, then a warning message is displayed to the user if they verify the
service after it is installed on the RCA Application Self-Service Manager. If the user clicks
Repair, the msi file will get repaired. If the user clicks Ignore, the status of service link is
displayed as broken. If Delete payload after install is not selected then, the local copy of
source msi file does not get deleted after the installation is complete.
This weird behavior is somewhat required because the verify function will not work if the MSI file is not present so it gets re-deployed if the user clicks repair and the verify is then performed. I had not really looked at MSI Basic packages before, but I believe they can be useful to standardize packaging functions for problematic MSI's.
Steve
Reading the doc again, it appears that this option may apply to both Basic and Advanced mode packages. It is primarily focused on removing the MSI itself since the ACP is stored on the Satellite unless cache options are enabled. However this is still useful since at times the MSI can be quite large.
Steve
Hi James,
Those are excellent points. In RCA 9.2 Google Chrome Browser updates are supported in the patch manager component even without the need to create any custom XML files. For previous versions however, it is that custom XML process that will be most challenging for some users. I do agree it is a far simpler management strategy once that hurdle is crossed.
Steve
To do the same thing with batch publisher, use the GUI publisher to publish up one MSI in basic mode and examine the ZCREATE.CMD and ZVERIFY.CMD files it creates in the file class, as well as all the ZSERVICE methods. Then you can easily emulate the same behavior in your batch publishing process. You would need to deliver standard ZCREATE.CMD and ZVERIFY.CMD files with your packages, but it will be the exact same files for each package. PACKAGE and ZSERVICE attributes are defined in the config file as ATTR options. It's worth taking a look to see it was done. Maybe you would choose to use some portion of this process in your batch packages. If you are already using a template to create the new config files, one you get the template fixed that part is done. And adding the two new files wouldn't be difficult.
I notice there is a sample MSI Basic package in the 9.2 CSDB that will deploy the RSM components to a client that was originally installed without RSM.
Steve
Hey Steve,
We need to meet up some time in the Queen city and shoot the breeze. I agree the custom xml is a hurdle that some will find difficult to master and that is why I offer custom xml support/services to all of my clients. They can send me a request for a custom xml file and I will create, test, and send it to back ready to go. Once a template is created for a specific product like Google Chrome, it can be updated/re-used with little effort when an update is available. Over the past couple of years we have managed to create well over 100 custom xml files to patch everything from Windows XP/10, Office, Adobe, Java, Chrome to 100% custom in-house vbscript compiled into executable and deployed via Patch Manager.
Using custom xml files over the default xml files allows for greater control over the assessment, deployment, and reporting of the products. For instance, the current Radia 9.2 supplied Google Chrome bulletin will download google chrome msi version 48, but the version listed for the assessment is version 36. The bulletin has a generic name of GOOGLE_CHROME which does not allow an easy way to identify version compliance. Acquiring and deploying this default bulletin will not yield great results. There are other examples of why custom xml files are more advantageous than default but that is for another conversation.
Hi
why not try to deploy google chrome MSI file by batch file
this batch file will deploy it , give it try it will work
:: Purpose: Installs a package
:: Requirements: 1. Run this script with a network admin account
:: Author: vocatus on Reddit
:: History: 1.0 Initial write
:: Prep
@echo off
set VERSION=1.0
:::::::::::::::
:: Variables ::
:::::::::::::::
:: Log location and name. Do not use trailing slashes (\)
set LOGPATH=%SystemDrive%\Logs
set LOGFILE=
:: Package to install. Do not use trailing slashes (\)
set LOCATION=\\tsar\network_installers\google\chrome
set BINARY=GoogleChromeStandaloneEnterprise_v22.0.1229.79.msi
set FLAGS=ALLUSERS=1 /q /norestart
::::::::::::::::::
:: INSTALLATION ::
::::::::::::::::::
:: This line installs the package from a network location
::"%LOCATION%\%BINARY%" %FLAGS%
:: This line installs the package from a local directory (if all files are in the same directory)
msiexec.exe /i "%BINARY%" %FLAGS%
the GoogleChromeStandaloneEnterprise_v22.0.1229.79.msi you can change the file as the installation file name you have
Ask, Discuss, Answer
