In my experience, administrators care most that the needed software and settings are applied to a machine. They care less about how the software and settings got applied. It could be via bundle, manually, or with a 3rd party tool.
They want to know whether or not the software and settings are there.
Enter, the Device Requirements Policy!
This policy simply contains a set of system requirements based on the current ZENworks system requirements framework.
These policies would be assigned to applicable devices as determined by the administrator.
These could also be made into sets of Device Requirements Policies and assigned as policy sets.
The assigned devices would regularly scan to determine compliance with the assigned policies.
There would be reports and dashlets to show the administrator the current compliance with the policies and policy sets.
To bring the devices into compliance, the administrator could create a bundle or bundles to make the needed changes.
The bundles would be assigned to the applicable Device Requirements Policy instead of to the devices themselves.
The bundles would follow the need for compliance allowing the administrator to set and forget once he/she knows the bundle works.
In short, the Device Requirements Policy allows the administrator to report on software and settings compliance in a way that can be directly and automatically acted on.
by: Peter S. | over a year ago | Application Mgmt
Comments
I think this is a fantastic idea. From supporting ZCM for many, many years, across a variety of customer bases, I can tell you this would be a godsend.
So basically something like Ansible for Windows baked into ZCM? YES. PLEASE.
TBH, we currently use Bundles and Bundle groups to achieve everything you have mentioned, and ZRS for reporting. We use bundle requirements of the exe file NOT existing to block reinstallation. Bundles, and groups associated with a heirachy of devices and device folders, which allows flexible association. I get the feeling a policy for device requirements might cause confusion, and increase risk of logic loops... Alex: yes, we're using ZCM as we'd use Ansible.
Hmm...sounds to me like the current method of Bundles and Bundle groups to "achieve everything you have mentioned" is complex enough that I personally would consider it a "work-around" rather than a "feature". If it isn't simple and straight-forward, the customer probably won't attempt it. But that's just my two cents.
I agree that this would be useful, but when brought up, I was wondering why it couldn't be done as Simon P mentioned. I like the idea about blocking re-installation, and that I hadn't thought about. That's something I can use for current installs. I also agree with Benjamin and OP about it needing to be easier for realistic adoption.
I feel our setup is simple now, but we had to work through several scenarios before settling on a strategy that worked. If there were policies for installing software that relied on bundles, then you might want a 1:1 mapping of bundle:policy, which might be tedious.
Our bundle global requirement for the application NOT being installed came quite early on in our setup so that ZCM stops caching the software locally. (We use the content repo heavily).
I want to emphasize that Simon P is exactly right. Most if not all of this can be done with ZENworks Configuration Management right out of the box if the right approach is taken. The biggest thing I see that is missing is the ability to report compliance first before creating a bundle to do the actual work.
The main idea for this came from how ZENworks does Patch Management. With Patch Management, the first focus is on compliance reporting. The administrator wants to know which patches have been applied and are effective on the device. Sometimes those patches get applied by ZENworks, and sometimes they don't. In the case of Patch Management, bundles are then created automatically in the background to apply the patches themselves.
My vision for the Device Requirements Policy would extend that reporting first capability to anything that could be detected by the current ZENworks system requirements framework. The difference would be that administrators would create the bundles themselves rather than have them be automatically created from the patch feed. Having said that, someone could make a good business out of creating common requirements policies and matching bundles for customers.
The main benefit of this approach is that ZENworks would be extremely useful as a compliance reporting mechanism first even before bundles were created. Obviously, the next logical step would be to add the bundles to bring the devices into compliance.