Recently in one my projects I was involved with deploying some Google applications such as Google Chrome and Google Drive on Windows 8.1 clients. Company policy states that all applications (including the Google stuff) must be deployed automatically without any user intervention. Since System Center 2012 R2 Configuration Manager was used, the Application Model needs to be used.
From a technical perspective, this means that each application is configured with the following properties:
- All applications are configured to be silently installed
- A required deployment is configured to a User Collection
- Supersedence is used when an application is replaced by either a new version or a completely different application
While this approach works fine for most applications, it doesn’t work for the Google software such as Google Chrome or Google Drive.
The first Google application, let’s say Google Chrome, automatically installs Google Update. Google Update frequently calls home to check if a new version is available. If so, it will automatically download and install this updated version and uninstalls the old one. But then, the Configuration Manager client will run its required cycles. It will notice that deployed version is not detected anymore so it will start installing it again to meet the policy defined by the required deployment (you can clearly see that in the AppEnfore.log file). So the older version is installed again and I’ve seen it break applications completely. Extremely annoying for service desk crew and admins…
While you can manage Google Update using GPO, not all applications can be managed to suppress using Google Update.
From a management perspective, Google Update completely takes away control to have a functioning Release Management Process. While Google Update is great in consumer scenarios, it certainly isn’t in the corporate world.
When System Center 2012 R2 Configuration Manager is used, I only have the following technical workarounds available:
- Deploy it as an available deployment; this requires user intervention and kills some automation
- Deploy it as part of a Task Sequence; this gives the application to everyone and kills the ability to determine who is allowed to use it (you can create requirements etc. but it kills simplicity)
- Deploy it as a Package instead of an Application; this takes away all the nice features the Application Model can give and takes me back to System Center Configuration Manager 2007. Not to mention, Packages should be used for some ‘stateless’ action such as scripts or registry keys
- Publish it as an update using SCUP 2011; let’s not go there, the problem remains…
Since Google updates their software quite frequently, I don’t see organizations frequently adding and superseding these applications. Imagine how much one admin needs to commit to managing Google applications.
In other words: Google needs to take out Google Update and provide something more manageable for the corporate world…