Tuesday, May 31, 2011

Forefront Endpoint Protection Management Pack

When searching the System Center Marketplace for FEP MPs you should keep in mind that there are two different MPs.

One is only for server health and the other one(s) are FEP “deep dive” (well, more or less) security monitoring.

FEP Server Health Monitoring Management Pack:

Forefront Endpoint Protection Server Health Management Pack monitors health of the FEP servers and alerts on server health changes. As most of FEP functionality is based on Configuration Manager infrastructure, this MP only monitors two standalone components:
1) SQL agent job that copies data from Configuration Manager database to FEP Data Warehouse
2) FEP alerting service
Management Pack also alerts on events in Windows Event Log that indicate error conditions of FEP Server.


FEP Security Monitoring Management Pack:

The Forefront Endpoint Protection Security Management Pack provides real-time monitoring of your Forefront Endpoint Protection clients by using System Center Operations Manager. Alerts can be configured for virus activity, firewall downtime, or update failures. In addition to real-time event monitoring, the Forefront Endpoint Protection Security Management Pack also provides automated response capabilities to remediate security related issues.


Thanks for the hint to my friend and SCCM (and latterly) FEP expert Mirko!

All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...

Wednesday, May 25, 2011

System Center Marketplace & Unofficial System Center Catalog

After such a long time and as Dan Rogers announced at MMS in Las Vegas last March, Microsoft recently launched the new “System Center Marketplace” based on Pinpoint. And this time the catalog rocks!

Also, an (at the moment) unknown blogger launched the blog “The Unofficial System Center Catalog” for SCO (aka Opalis aka Orchestrator) and SCOM. It lists a lot of non-Microsoft IPs and MPs in the wild including hyperlinks to the vendor/developer. Hopefully the author maintains the blog so that the list will be up to date. Thanks for that anyway!

Check out both sites:



All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...

Friday, May 20, 2011

SCOM 2012: (Default) Management Pack selection

I just love that: no more selection of the Default Management Pack by mistake:


All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...

Sunday, May 15, 2011

How to use Resolution States in SCOM

Out of the box there are just two resolutions states, called New and Closed.

From my perspective it is a really good idea to use other resolution states too. So you are able to give information about the current state to other Operators too and keep a good overview about your alerts.

In the Administration pane you can add additional states to your environment by editing the list provided in Settings, Alerts, Alert Resolution States.

I usually configure the following resolution states in a SCOM Management Group:

ID Name Used for Used by
0 New (default) Alerts that has not been processed yet SCOM
1 Process running (M) External process running (e.g. Opalis, PowerShell) Opalis/Orchestrator, Scripts, …
5 Suspended (H) Not possible to solve at the moment Operator
6 Engineer On Duty (M) Engineer on-call has been notified Orchestrator, Scripts, …
10 1. Level (H/M) Alert has been assigned to 1. Level Operator, Orchestrator, Scripts
20 2. Level (H/M) Alert has been assigned to 2. Level Operator, Orchestrator, Scripts
248 Test Issue (H) Test Issue; no action needed Operator
249 Known Issue (H) already assigned to 2. Level but additional Alert Operator
254 Ticket Closed (M) The external ticket has been closed Connector, Orchestrator, Scripts
255 Closed (default) Problem solved SCOM, Operator

The appendix (H), (M) and (H/M) should show if this is resolution state is planned to be used by the machine (Orchestrator, Script, …) or by human (Operator).

Depending on the customers environment it may be necessary to add more than those resolution states. For example you can add a resolution state for your Server Team (maybe ID 21, because first specialized 2. Level group).

I recommend my customers to change the state as soon as an Operator has first contact with an alert. For example they should change the state to 1. Level (or 2. Level if they assign the alert to the next group) so that everybody who is working with the console can see that there is an action in progress.

Enjoy using the resolution states and see, how easy you and your colleagues can have a much better overview about your environment.

All information is provided "as is" without any warranty! Try in lab before. Handle with care in production.

Read Full Post...