Two problems I have with scheduled deployments (long, sorry) ;)
I posted this to Reddit but am posting it here as well since it's potentially a different audience. :)
I am using the Auto-Download feature combined with the provided Device Collections to try to keep my machines up to date. I'm running into TWO different problems and am hoping for a Work Around. Here's the problem I'm running into using Chrome as an example.
In the Collection Library, there is a collection for Chrome Enterprise (Old). This obviously contains all the machines that do not have the latest version of Chrome.
In the Package Library, there is an item for Chrome Enterprise. This updates automatically.
PROBLEM 1 - Unsupported OSes
Chrome no longer supports old OSes such as Win7, Win8, and Server 2012. Those machine are limited to the Chrome 109 version. There is a Collection in the library called Chrome Enterprise 109 (Deprecated) that shows all these machines. The problem is, these machines also show up in the Chrome Enterprise (Old) collection.
This means that every night, my Chrome Deployment attempts to install to the Chrome (Old) collection. All the machines that have an unsupported OS get skipped and show as FAILED in the Deployment. These machines will never move out of the Chrome (Old) collection so they will get targeted by the Deployment every day, forever, and will fail every time. This clutters up my deployment history with Failed deployments every night.
Is there any way around this? IMHO, the Chrome Enterprise (Old) collection should be reconfigured to remove OSes that cannot be upgraded since they're not really Old if Old means Out of Date. They are as upgraded as they will ever be. They shouldn't be in the 109 collection and the Old collection since the Old collection is there to be targeted with upgrades but these machines CANNOT be upgraded.
Does that make sense? The only thing I've come up with is to make my own Chrome (Old) collection and filter to the older OSes and then target that new collection with my deployments. But that kind of defeats the purpose of having the built-in collection library....
PROBLEM 2 - Auto-download Approvals
The default setting to automatically approve an auto-download is 7 days. This leads to the following scenario. This would apply to any software if it has a Daily Scheduled deployment to keep it updated.
Monday - Chrome releases a new version and it gets packaged and released by PDQ. Device collections update and machines move to the Old collection. Chrome Deployment goes into the 7-day waiting period before it becomes active.
Tuesday morning - Daily update deployment sees machines in the Chrome Old collection and run the scheduled deployment. Because the new Chrome version is in the approval waiting period, it installs the same version that is already installed on the machines. Machines do not upgrade so they stay in the "Old" collection.
Wednesday morning - Same as Tuesday
Thursday morning - same as Wednesday.
Eventually, the Chrome updated deployment gets approved and installs. However, since Chrome sometimes updates more than once per week, all the machines are still "Old" as the next new install is probably waiting in the Approval queue.
This means that a Daily Chrome Update will potentially run every day but will never actually be installing the latest version so machines will never leave the "Old" group.
The only thing I've come up with is to set the Approval delay to a smaller number (0 or 1) to minimize the problem. Anything other than 0 will cause a scheduled Daily update to reinstall the same version that's already installed at least once.
My suggestion is to somehow link the Device Collection with the Auto-Approval queue and not update the Device Collection version numbers until the Deployment for that version has been approved. Is there any other way around this?
This anyone else running into these scenarios? Is it just me?