This all should work assuming the following pre-requisites are met:

- System Center Operations Manager 2012 R2 is installed.
- SharePoint 2010 or greater is installed (steps below are for SharePoint 2013).
- The Visio Web Part for SharePoint is installed per the following link: https://www.microsoft.com/en-us/download/details.aspx?id=29268|
- Visio 2010 or Greater is installed on your system
- The Visio 2010 Add-in for System Center Operations Manager 2012 is installed per the following link: https://technet.microsoft.com/en-us/library/hh920815.aspx

Steps to Create and Configure a Dashboard:

Create the base Drawing Used for displaying your data, this can contain actual drawings or shapes.  Mine is shown here:

Configure the Data Source to connect to your Management Server and Web Console.  To do this, select the 'Operations Manager' Tab on the ribbon in Visio, and click 'Configure'.

Enter the FQDN of your Management Server and click 'Look up web console address' to ensure that the Management Server is recognized. Select the checkbox for Automatically refresh data and enter the refresh interval.

Add Data Links for each object that you want to monitor the state of.  This step can take a while depending on the number of objects.  In my example we are monitoring Domain Controller Health.  For Each Domain Controller I selected nine individual objects.  The first and obvious one is 'Windows Computer', This object is a roll up of a large number of things such as availability, performance, etc...  To add this Data Link click the 'Operations Manager' tab on the ribbon in Visio and select 'Add Data Links'

When the Add Data Links prompt appears, select the 'Windows Computer Class', Select the names of each Computer Object you want to monitor in this Dashboards and click 'Add'

To link this newly added object to a shape in the drawing simply select the object from the External Data box and drag it to the shape where you want to represent the health of that object

Repeat this process for every class and object that you want to monitor.  The majority of the classes in this particular dashboard can be found in the 'Active Directory Server 2008 and above (Discovery)' Management Pack.  To see these you will need to select 'Other class...' and uncheck the box for 'Show only commonly-used classes'.  Select each class and all objects associated with the objects you want to monitor.

Notice that in my environment the default data graphic automatically put a green check box in the top right corner indicating that the computer object is healthy.  This might vary depending on what you have in Visio.  I like the green check box, but would prefer that it is centered in the box.  To view and edit the data graphics select the objects that you want your changes to apply to in the Visio drawing and click the 'Data' tab on the ribbon.

The available data graphics will be shown.  You can simple select one of them, create a new data graphic, or edit an existing graphic.  Often I use colors instead of icons to indicate health.  In this example I will just edit an existing data graphic so that we only see the health icons in the center of the shape.  After clicking 'Edit Data Graphic' I deleted all rows except '={Health State}&{Is Available}&{In Maintenance}&{Managed}'.

On the remaining row click 'Edit Item', change Horizental to Center and Vertical to Middle.

Once you have added all data objects, linked them to their associated objects, and updated the data graphics your dashboard should look something like this.

Make sure to save the file as a .vdw (Visio Web Drawing) file.  To save to SharePoint either click 'Save and Send' or 'Save As', enter the location of a folder on your sharepoint site.

To add the Visio drawing to a SharePoint page.  Edit the page, Click Insert > Web Part.  Expand 'Business Data' and select 'Visio Web Access'

Edit the Web Part

Click the box next to the 'Web Drawing URL' and browse to the location where you earlier saved the .vdw file.  Set the refresh rate for the drawing and any other settings required for your drawing and click ok.

Save the page.  The final product should look something like this:

I hope this has been helpful in understanding the types of monitoring data that can be easily displayed in a custom Visio SCOM Dashboard. 

Active_Directory_Overview_Template.vdw

• In the Authoring Pane of the SCOM Console Expand Management Pack Objects > Rules. 
• Right click and Select ‘Create a new Rule’.  For Rule Type, select Collection Rules > Event Based > NT Event Log. 
• Enter a name the clearly identifies the Collection Rule such as 'Collection Rule: GPO Audit Events' and Choose ‘Windows Domain Controller’ as the Rule Target.
• For the Event Log Type Enter ‘Security’ as the Log Name. 
• For the Build Event Expression section Use the default AND group and Insert an OR Group Below it.  In the OR group enter Event ID’s 5136, 5137, & 5141.  In the AND Group enter 'Parameter 11' Contains 'groupPolicyContainer' as shown below.

• Choose Alert Generating Rules instead of Collection Rules
• On the Configure Alerts Section change the Severity to 'Information'
• Select 'Alert suppression' and check the following boxes: Event ID, Parameter 4 (user name), Parameter 10 (GUID), & Parameter 11 (Class)
• Select 'Custom alert fields' Choose 3 Custom Fields to save unique alert data that will be used later.  I chose 4, 5, & 6 because they were not used by any of my other custom rules. Other additional parameters can be used if additional data is needed.  Enter the following values:
  • GPO GUID:$Data/Params/Param[9]$
  • GPO Domain:$Data/Params/Param[7]$
  • UserName:$Data/Params/Param[4]$
• Click Ok and finish the Rule Wizard.

• In the Administration Pane of the SCOM Console Section right click and select New Channel > Command. 
• Enter a name such as PowerShell GPO. 
• For full path of the command file enter ‘c:\Windows\System32\windowspowershell\v1.0\powershell.exe’. 
• For Command Line Parameters enter something like ‘D:\Powershell\GPOAlert.ps1 –AlertID ‘$Data/Context/DataItem/AlertId$’ (change the location to match wherever you save the PowerShell script created in the next step).
• For Startup folder for the command line enter the same Folder Location as used above.

• In the Administration Pane of the SCOM Console right click and select ‘New Subscription’. 
• Name the Subscription ‘GPO Change Notification by PowerShell’ (or something that clearly describes the subscription).
• On the Criteria tab select the checkbox for ‘created by specific rules or monitors (e.g., sources)’ and select the checkbox for 'Alert rule previously created', Choose 'with a specific resolution state' and select 'New (0)'.

• On the Subscriber tab click New, Enter a name for the subscriber such as PowerShell GPO. 
• On the schedule tab ensure that the button for always send notifications is selected. 
• For the Address name you can use the same name as for the subscriber.
• For Channel Type select the drop down for Command, on the Command Channel drop down select the recently created PowerShell GPO Channel, click next and Finish.
• On the Channel Section search for the previously created Channel again, select it, click add, and click ok.  Click finish and close the wizard.

• Make sure to update the $MS parameter in the Script to reflect the SCOM Management Server being used.
• note: If different custom fields were used in the previously updated Alert Rule it is necessary to update the $gpoGUID, $gpoDomain, & $gpoUser lines in the script to reflect the custom fields used.

• From the Authoring pane of the SCOM Console expand Management Pack Objects and right click on Rules.  Select Create a new rule.
• Choose Alert Generating Rules > Event Based > NT Event Log (Alert)

• Choose a Rule Name that clearly identifies the GPO modification such as 'Informational - GPO Has been Modified"
• Set 'Management Server' as the Rule Target (since the custom event created earlier is saved to the Management Server Event Log).
• Enter 'Operations Manager' as the Log name in the Event Log Type section
• Enter Event ID for Parameter Name, Operator Equals, and Value of 11101 in the Build Event Expression Section.
• On the Configure Alerts section it is recommended to change the Severity to Informational.  The Alert description field should be modified to be: 'Event Description: $Data[Default="]/EventData$'

• The Generated Alert Should look something like this:

• From Here it is easy to create custom email subscriptions or custom Alert Views so that these Alerts can be easily viewed by those who have a need to Monitor for GPO Changes.

The simplest way to accomplish this is by creating an ‘Overrides Summary View’ in the ‘My Workspace’ pane of the Operations Manager Console.

From here it is possible to customize the Criteria for which overrides should be included along with the type of data that should be displayed.  Typically, I choose to display the following Columns and adjust the order as shown below: (Note: ‘unchecking the Management Pack Object Type’ will change the view to a simple list instead of having the overrides sorted by type)

Often the purpose for creating a view such as this is to track recent overrides that have been created.  To do this simply check the box ‘was added in a specified time period’ and identify the time period that you are interested in as seen below:

The final result should look something like this:

 
Hopefully this is helpful in simplifying the ways in which you can view and track SCOM Overrides in your environment.

The AD account had been configured for sudo Elevation per this TechNet article: https://social.technet.microsoft.com/wiki/contents/articles/7375.configuring-sudo-elevation-for-unix-and-linux-monitoring-with-system-center-2012-operations-manager.aspx

The account had also been given the required rights for the Agent Maintenance profile as specified here: ttp://technet.microsoft.com/en-us/library/hh287151.aspx

The issue we found is there was no apparent way to specify domain account when creating a UNIX\Linux Run As Account.  When entering the domain and account ie: ‘<domainname>\linuxsvcaccount’ in the username field, we got access denied errors on the systems.  Apparently RHEL systems do not know how to process ‘domain1\’.  After talking with the Linux system admin we decided to just leave out the domain name and see if it would resolve the actual account name to the domain.  This actually worked!  We found that the system first looks to see of the run-as account is a local account, when it finds that it does not exist locally it tries to resolve it against Active Directory.  As long as the account resolves properly and the account has been given the required rights it will work properly.  Just do not specify any domain details when configuring the account in SCOM.

Activities:

• The first activity in the runbook is the ‘Monitor Alert’.  This will monitor for any occurrence of the alert in question.  This activity can be found in the SC 2012 Operations Manager section.  Click the button to the right of the Sever > Connection field and select your SCOM Management Server from the list.  For testing purposes I like to trigger on both New Alerts and Updated alerts.  This allows me to manually set an alert to a new state in order to let the runbook monitor for it instead of waiting for an alert to trigger.  For my runbook I created the following 3 filters:

• Severity Equals Critical
• Name Equals Health Service Heartbeat Failure
• ResolutionState Equals New

• The second activity is a simple ‘Run Program’ which will ping the system to make sure it is online.  This activity can be found in the System section.  Create a link from the ‘Monitor Alert’ to the ‘Run Program’ activity.  There should be a default include filter created on the link for Monitor Alert returns success.  In the ‘Run Program’ properties select the Command execution mod and enter the name of the computer you are running it from, in this case I used the SCOM Management server since it should be able to talk to all SCOM Agents.  In the command field we will  subscribe to data from the Monitor Alert activity.  Type ping -4, right click to the right of the new text and select Subscribe >  Published Data.  Ensure that the Monitor Alert Activity is selected from the drop down at the top and select the ‘MonitoringObjectDisplayName’ for the published data before clicking OK.  Click Finish to complete the activity configuration.

• The third activity is ‘Get Service Status’ which will simply return the state of the HealthService.  The following activities will depend upon the state of this service.  This activity can be found in the Monitoring section.  Create a link from the ‘Run Program’ to the ‘Get Service Status’.  In the properties of the new activity we will subscribe to data from the ‘Monitor Alert’ to get the computer.  Right click in the Computer field and select Subscribe > Published Data.  Select Monitor Alert from the Activity drop down and choose the ‘MonitoringObjectDisplayName’.  The Service name will vary depending on whether you are running Operations Manager 2012 or 2012R2.  You can select the button to the right of the field to browse services on the current system or you can simply type the name of the service.  In a 2012 environment the HealthService will be named ‘System Center Management’ and in a R2 environment it will be ‘Microsoft Monitoring Agent’.  

• For the forth activity we will actually create two different versions.  Depending on whether the previous activity showed that the HealthService was running or stopped the runbook will choose one or the other.  Here we will create 2 versions of the ‘Start/Stop Service’activity in the System section.
  • Rename the first ‘Start/Stop Service’ activity to ‘Start HealthService’. Create a link from the ‘Get Service Status’ activity to the new ‘Start HealthService’ Activity.  On the link properties change the Include filter to ‘Service status from Get HealthService Status equals Service stopped’.  In the properties for the new ‘Start HealthService’ Activity click the action button for ‘Start service’.  Right click the Computer field and select Subscribe > Published data and select the Service Computer from the ‘Get HealthService Status’ Activity.  For the Service enter the Service name used in the previous activity (either Microsoft Monitoring Agent or System Center Management).

• Rename the second ‘Start/Stop Service’ activity to Stop HealthService. Create a link from the ‘Get Service Status’ activity to the new ‘Stop HealthService’ Activity.  On the link properties change the Include filter to ‘Service status from Get HealthService Status equals Service Running’.  In the properties for the new ‘Stop HealthService’ activity click the action button for ‘Stop service’.  Right click the Computer field and select Subscribe > Published data and select the Service Computer from the ‘Get HealthService Status’ Activity.  For the Service enter the Service name used in the previous activity (either Microsoft Monitoring Agent or System Center Management).
  (screenshots skipped since they are nearly the same as those shown above, except for the service state)

• For the fifth activity we will be deleting the stale health state on the problem system.  The ‘Delete Folder’ activity can be found in the File Management section.  Create a link from the ‘Stop HealthService’ Activity to this ‘Delete Folder’.  Open the Details section type \\ in the path field and right click in the field to the right.  Select Subscribe >  Published Data.  Select the ‘Get Health Service’ Activity and choose Service computer.  The the right of this text it will be necessary to type the path to the Health Service State folder.  This will vary depending on the version of Operations Manager you are running.  In 2012 R2 the default path is ‘\c$\Program Files\Microsoft Monitoring Agent\Agent\Health Service State’.  Ensure the ‘Delete all files and sub-folders’ option is selected.

• For the sixth and final step we will repeat the Start Service step from earlier.  Create a new ‘Start/Stop Service’ activity and rename it to ‘Start HealthService’. Create a link from the ‘Get Service Status’ activity to the new ‘Start HealthService’ Activity.  On the link properties change the Include filter to ‘Service status from Get HealthService Status equals Service stopped’.  In the properties for the new ‘Start HealthService’ activity click the action button for ‘Start service’.  Right click the Computer field and select Subscribe > Published data and select the Service Computer from the Get HealthService Status Activity.  For the Service enter the Service name used in the previous activity (either Microsoft Monitoring Agent or System Center Management).

For testing I would make sure you have a current Heartbeat Alert and set the resolution state to something other than new or manually stop the service on an agent system.  Make sure to start the runbook and set the heartbeat alert resolution state to new.  Monitor the runbook, the alert, and the SCOM Agent to ensure the process works as expected.  Good luck and I hope this helps with your re-occurring Heartbeat Alerts. 

Identifying the Overrides: The built-in Overrides report in the Reporting Workspace is useful in identifying. In the ‘Microsoft Generic Report Library’ the ‘Overrides’ report can be run. By default all Management Packs are selected, it is necessary to clear the selections for all but the ‘Default Management Pack’. The default criteria of ‘Select overrides DEFINED in the following Management Packs’ is correct. When the report is generated it will list the Management Pack affected, the rules or monitors. The affected element/value, and the target. These are useful both in identifying who may have created the override and identifying where to go to delete the current override and create in its correct location. After identifying the overrides in question it is necessary to manually delete each one and re-create it in the correct custom Management Pack.

Monitoring for future occurrences. Since we have two separate environments; one running 2007 and the other 2012 I decided to experiment with two different approaches.

• In the 2007 environment I used steps similar to what are defined here: https://blogs.technet.com/b/jonathanalmquist/archive/2008/11/12/monitor-default-management-pack.aspx. I am not going to go into detail on this approach since it is covered so well in the linked blog post. Using the steps set forth in the link above; I created two custom SCOM Rules. The first rule ran once per day and queried the AllOverrideView and ManagementPackView in the OperationsManager Database for any members where an override existed in the Default Management Pack. If more than 0 rules were found an event was created in the Operations Manager Event log. The second rule simply watched for the occurrence of the custom event and created an alert in SCOM if it was found. This process worked well and I was able to immediately start monitoring for any new occurrences of the problem. I set up an alert subscription so that I received an email anytime the alert was raised. 
• In the 2012 environment I decided to use a different tactic. My customer recently implemented System Center Orchestrator 2012 and I decided to try using it to accomplish the same goal using this tool in what would possibly be a cleaner and more controllable manner. I created a Runbook with 4 simple steps. (note: the SCOM Integration Pack needs to be installed for these steps to work). 

• Monitor Date/Time – This step is simply set to run every 1 day. The connecting Link to the following step continues if the step returns success. 
• Check Schedule – On this step I simply scheduled a pre-created schedule to run daily between 9pm & 3am. The connecting link continues if the Check Schedule returns success. 
• Query Database - This third step is the key step in this Runbook. The query I used is “Select count(*) as Overrides from AllOverrideView ao inner join ManagementPackView mp on ao.ManagementPackID = mp.ID where mp.name = ‘Microsoft.SystemCenter.OperationsManager.DefaultUser’”. I specified a SQL Server Database type for the connection and entered the server name and Initial Catalog (default name for the SCOM Database is OperationsManager). The connecting link after this step does require a few customizations. On the include step I selected ‘Numeric return value of the query’ from the Query Database ‘is greater than or equal to’ 1. I chose 1 because there should not be any overrides found here. 
• SCOM – Alert – Here I simply put in the Management Server name for the connection, set the Priority to High, the Severity to Critical, selected Description and Name as additional fields to include in the alert. I set the name to Default MP Overrides and description toe Overrides have been saved in the Default Management Pack.