ZCM can do the SCCM part but what about SCOM which does the Monitoring
like HW Utilization and Reports and Services Monitoring and Status info
etc.
SCCM does the patch management for Windows Boxes too, so I believe
ZENworks Patch Management would be required.[/color]
You have several quite good open source alternatives for HW/SW
monitoring and reporting, incinga, nagios, zenoss etc…[/color]
For all solutions, the question usually isn’t cost, it is availability
of modules to monitor your kit - with netware nagios and its family have
a bit of an advantage (last I looked, SCOM was abusing the nagios client
code to avoid having to write their own monitor for that) - and SCOM
modules tend to be expensive and limited (their SNMP configuration is a
nightmare as it relies on importing the mibs to the underlying windows
os on each node, and password storage completely changed between 2007
and 2012 breaking all existing code) although that’s possibly improved
in scom 2016. The configuration mode (scan/detect rather than manual
config) has both benefits and limitations too.
Nagios tends to have some commercial-branch issues - if you go the
community release, it seems a bunch of the features are deliberately
reserved for customers, and the entire dev team has been booted twice
over that (not to mention the whole community plugin site being ripped
off by the vendor, which caused a major rift between the community and
the vendor at the time)
Icinga (and other nagios-based spinoffs) seem to at least patch some
of the more annoying bugs with nagios (and Icinga 1.x is a good drop-in
replacement for nagios core, with some caveats) but as with nagios, you
will need to be a decent script writer as the out of the box monitors
tend to be a bit crude and limited; we had to write our own a lot for
stuff that wasn’t basic MS boxes (netapp aggregates+volumes for example,
cisco config change monitoring (especially for ASAs with multiple
contexts), panzura, even MS SQL instances (which you would think would
be supported out-of-the-box) and WMI (which I “borrowed” the wmic build
from zenoss for). history data is a bit crude, tends to be stored in
individual RRDs, and dashboards tend to be third party/afterthoughts
rather than integrated in. That said, we have retained Icinga for our
airgapped customers (who can’t use the cloud solution we moved to as,
well, airgapped) and after a couple of years coding and tweaking, it
works well and reliably. A lot of the graphing stuff you would expect
to get from a decent monitoring solution though just doesn’t exist, so
we have to collect data twice (using cacti as the second collector) to
get port saturation, link usage (with percentile) and so forth. We could have eventually coded that stuff into Icinga ourselves, but the
keyword there is “eventually”.