This is in addition to my other post on fundamental problems in the product, which is still even satisfactorily answered, never mind addressed:
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.
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!