This is in addition to my other post on fundamental problems in the product, which is still even satisfactorily answered, never mind addressed: 

1. 1. Create a dynamic custom group based on Windows 10 PCs that do not have software called “Google Chrome”.
2. 2. Create a software deployment job to push Google Chrome, using the already available and automatically updated Google Chrome template, in DC, to any PC that is a member of the above dynamic group.
3. 3. Sit and enjoy watching any PCs that are in the dynamic group, created in step one, get Chrome installed and then disappear from the dynamic group.
4. 4. I should also be able to create a custom report that, for example, emails me a list of any systems that are a member of one of the dynamic custom groups for longer than the software deployment targeting jobs schedule. This should be able to identify to me any system(s) that are not getting the software so we can investigate why?

Now, this is where I am thinking DC has a fundamental design flaw. Once I am happy our environment has Google Chrome on all the systems, I should be able to expect that any new systems that are added to the network or if someone or something manages to remove or delete Chrome from one of the systems that should have it; will simply have Chrome (re)installed, because, not having software called Google Chrome on them, by software inventory definition, would make them a member of the dynamic group. And this is the precise point of failure…

Point of failure/design flaw:

The software deployment job will run once it is set up and retry/repeat according to however many times I specify in the job. But then the job will cease to process any further deployments, even when members of the target group are added.

Resolution:

Software deployment jobs must be able to be configured as set and forget deployment jobs that run on a predetermined schedule. E.g. If someone is without Chrome for a few days or even a week, no big deal. However, if we consider something more critical such as antivirus software then you’d want to have the deployment job run multiple times per day, to see if there were any systems identified, by software inventory as not having the antivirus software installed.

Caveat: I do realise that another key driver in the scheduling of automated jobs, based on inventory, is the inventory gathering and updating cycles within DC. Setting inventory schedules to run, potentially multiple times per day is something that could prove prohibitively resource intensive. However, PC hardware resources and capabilities have been pretty well ahead of the requirements of the single user computing environments for a good while now. The biggest challenge to these environments is lazy/greedy software companies abusing this to produce bloated software. Also, DC is very dynamic in the reporting of changes to inventory based on software installation/uninstallation. So, if the software is removed from the system via an install/uninstall process, inventory should be updated, for that system in a similarly dynamic manner. The only scenario that wouldn’t be captured, in a more timely fashion would be if the software was simply deleted from the system, by deleting components or executables within Explorer. Then, this could only be captured via a file system inventory scan of some sort.

Now, this is essentially a pretty basic MOE software deployment lifecycle and should be considered as a fundamental part of a product such as DC. Sadly, according to an active case I have open, with the support team, the point of failure is looking precisely like that… A fundamental design flaw.

NB: This is something I was setting up in Altiris more than ten years ago, without any problems!