There is an updated MP for print services:
Unfortunately – the download and guide still reference “for Operations Manager 2007R2”. That is incorrect – this is for both SCOM 2007 R2 and all SCOM 2012 versions.
Note the update in the guide:
Changes in Version 6.0.7294.0
- Version 6.0.7294 of the Management Pack for Windows Print Server supports Print Clusters.
- Removed “Microsoft.Windows.Server.PrintServer.mp” since we have dropped support for Windows server 2003. Please ignore all sections in this document related to Windows Server 2003 / Microsoft.Windows.Server.PrintServer.mp.
This is a fairly simple and straightforward MP. We define classes for:
- Print Services Role (Print Server)
- Print Services Logical Print (Print Queue)
As you can see – my clustered print services are discovered.
****A note of caution. If you have VERY large print servers with a large number of print queues (I’m talking over 300 here) you can consider disabling the discovery for the print queues. There is only a handful of monitors which target the queues themselves, so if you are trying to streamline your MP’s for performance, this is a valid consideration. Most of the monitoring workflows targeting queues, are event based and could easily be re-written if needed.
Additionally, I have always recommended taking a hard look at the perf collection rules for this MP. These perf collection rules collect for “all instances” of the Print Queue object counters. This creates two big problems. First – in scenarios where you have a massive number of print queues, this will end up being a LOT of data coming from these servers. If you need it for populating views, that’s fine. However, there is a significant issue with how this is collected. Since we have a single rule that collects ALL INSTANCES, this breaks in the warehouse, when we do aggregations. We aggregate performance data PER RULE in the DW, so the hourly and daily data will be worthless, as we will combine all this data from all the instances together, and provide min/max/avg data on ALL your print queues, instead of each one separately. It wont work for dashboards, and has nothing to do with generating alerts. It will just create a big load on the SCOM server to collect all this data, and aggregate in the warehouse, and the data will be useless for reporting. So in summary, I don’t recommend collecting this perf data, and do recommend creating overrides to disable this performance collection. If you NEED perf collection for views, then I’d recommend creating new rules and target the queues and pass the instance name to the workflow, or collect it just like the default rules, but ONLY write it to the OpsDB.
My opinion is – we should track the _Total instance by default only for all these counters per print server. Then have some built in (but disabled) rules that target the print queues that collect more advanced per-queue instance data.
And remember – on clusters – we don’t monitor the services because they aren't set to automatic. Therefore – it is very important to import the updated Microsoft Cluster MP’s to monitor the online status of your print server role resource groups.