I was working with a customer recently, and I realized that our MP’s to work with Audit Collection Forwarders could use a little help.
The default view for the “forwarder” discovers instances where the ACS Forwarder service is set to automatic, but it does some “bad” things like targets Windows Computer class, and the discovery is remotable. This means you get all kinds of cluster instances as a forwarder, which is invalid.
Another problem, is what if you wanted to change a large number of forwarders, to connect to another Collector? The built in tasks to Enable and Disable ACS are targeting the Healthservice class, so using the existing forwarder view wont help.
So I quickly wrote an addendum MP that properly discovers the Forwarders only on agents by targeting Windows Operating System class, set the discovery to non-remotable, and then added a copy of the enable and disable tasks and targeted my new forwarder class. My new forwarder class also uses the built in forwarder class a base class, so we will inherit the built in monitoring.
In the example below, I have a bunch of forwarder pointing to an old collector and in a warning state because of that. I now have a task exposed to enable them for a new collector:
Now all my forwarders are talking to the new collector and are all healthy:”"
Note – the class property of “Collector” is part of the forwarder class discovery, which runs every 4 hours, so it will take up to 4 hours to see all these updated to the current collector in the view.
Included in the management pack is a group of Windows Computers that have a “Forwarder” enabled call “ACS Forwarder Computers Group” This could be use to scope custom dashboards if needed, or to help create groups and views to show where you have machines that SHOULD be enabled for ACS but have not been.
The MP is attached.