Microsoft Azure Operational Insights Preview Series – AD Assessment (Part 12)

Previously on Microsoft Azure Operational Insights Preview Series:

There is a new Intelligence Pack on the horizon. This IP uses the same model for information like the SQL Assessment IP. You can just go Intelligence Pack Gallery and add it: Continue reading “Microsoft Azure Operational Insights Preview Series – AD Assessment (Part 12)”

Several MPs Updated

This blog post is to inform you that several MPs have been updated with some important fixes/features. You can find all the information here.

My personal best improvement is:

  • Add Task launch PowerShell session on the remote machine for All Computers

New Version: Active Directory Domain Services Management Pack for System Center

Another new version of MP is out. According to the documentation this new version was prepared in December 2012 but released in January 2013. Here are the changes taken directly from the documentation:




Product knowledge improvements

· Client Monitoring alerts identify problematic domain controllers in the description.

· Interdomain trust alert identifies which trust is broken in the alert description.

· More specific action recommendations added to alert for “Could not determine FSMO role holder” and alert for “domain Controller’s Ops Master is inconsistent.”

· Knowledge Base article information added to alert for “The Active Directory database is corrupt.”

· Knowledge Base article information added to alert for “Two replication partners have an inconsistent view of the FSMO role holders.”

· Some rules with names that begin “Client Side script…“ but were not actually executed by client-side monitors were renamed.

· More specific action recommendation added to description for Event ID 1000.

Excessive alert fixes

· A duplicate alert that appears when a computer authentication fails was removed.

· Repetitive alerts for UserEnv and Netlogon were replaced with a single alert that includes a count of the number of occurrences.

· The alert for the number of allowable replication partners was increased from 100 to the maximum number of replication connections.

· The alert of FSMO role holder availability was refined so that it is issued less frequently in cases where operations master role holder is temporarily unavailable.

· Active Directory processor overload monitor was removed because it duplicates an existing monitor in the operating system management pack.

· Duplicate alerts for KDC errors and trust verification failures were removed.

· Informational alert was disabled for rule “The default security settings for the NTFS file systems have not been applied to Active Directory directory folders.”

Script error fixes

Multiple script errors were fixed to improve Active Directory site topology discovery, DNS verification, operation master role discovery, and other improvements.

Rule error fixes

Multiple rule errors were fixed to improve error handling, event logging, and server state reporting.


As you can see no new features just bug fixes. You can download version 6.0.8070.0 of Active Directory Domain Services Management Pack for System Center from here.

SLA Management in System Center Operations Manager

The idea behind this article is to show you how you can create dynamic groups that represent different Service Level Agreements (for example GOLD, SILVER or BRONZE). Depending what SLA level is certain CI (server) it will be put in the corresponding group.

Also I should mention that this solution is already available over Internet but is described in a couple of articles by different authors an I just want to gather all the information on one place and point out some tips that will be helpful if you decide to implement such solution on your own.


First you need to build your SLA model. The best way is to use Active Directory. Lets say you have 3 different SLAs – GOLD, SILVER and BRONZE then you can create 3 security groups for example SLA-GOLD, SLA-SILEVR and SLA-BRONZE. In these groups you will put the AD computer objects of your servers. For example if server have SLA GOLD the computer object of that server have to be added as member of group SLA-GOLD. With this example you distribute all your servers in the groups depending on your SLA. If you have servers that do not have SLA you do not add them in any of the groups. When you populate the 3 groups you have to create one GPO. That GPO should apply different registry key on the servers depending in which security group is. It is good idea the reg key to be applied in path like this HKLM\Software\CompanyName with DWORD Values like SupportLevel and data like 1 for GOLD, 2 for SILVER, 3 for BRONZE and 0 for NO-SLA. So if server doesn’t belong to any of the 3 groups DWORD Value SupportLevel with data 0 will applied. This GPO should be linked to the OU where you store the computer objects for your servers.

Note: You can use your own DWORD or String values for distinguishing SLA.

This SLA model for Active Directory was developed by my colleague Yordan Dimov.

Now that we have the registry keys applied to the servers we need to bring that information in SCOM. Kevin Holman has a great article describing how to do that titled “Creating custom dynamic computer groups based on registry keys on agents”.

The disadvantage of the proposed solution by Kevin is that it populates only the the SCOM computer objects in the dynamic groups. Kevin also mentions that disadvantage. Bu there is solution for that proposed by Tim McFadden in “Dynamic Computer groups that send heartbeat alerts”. In the article you will find out how to populate the groups the SCOM heartbeat object of the servers. In the comments of the article you can also find out a way to add the cluster names if the servers that are added to particular group are nodes of a cluster. I suggest to populate the groups with the heartbeat objects and the cluster names in order not to miss alerts when you forward them to SCSM or any other Configuration Management System.

Note: You have to have some some basic knowledge about the structure of management packs and XML.

After this you might think you are ready but there are some other obstacles you may face. If you have Hyper-V servers with virtual machines on top of them and you’ve imported Hyper-V management pack you will probably stumble on one particular issue. If you add Hyper-V server to SLA group all the virtual machines that are located on that server will be added to the SLA group in SCOM also. And some of these virtual machines may even do not have SLA and you alerts for them will be forwarded to your ticketing system. I can confirm that this issue is present in SCOM 2007 but you may also face it in SCOM 2012. In the Hyper-V Management Pack there is discovery that creates relationship between the Hyper-V server and the guest virtual machines but that association doesn’t work properly as it creates these weird issues. Another issue that you might face because of that association is for example if you put Hyper-V hosts in maintenance mode all virtual machines on that host will also be put in maintenance mode. But there is a cure for these issues also. You have to disable that discovery and Kevin described how in his article “Why do my group memberships for Windows Computers have machines that don’t belong there?”.

If you follow the steps described by Kevin and you still see this association for hyper-v servers that are part of clusters I suggest to follow these steps to resolve it completely:

1. Manually uninstall all SCOM agents on all nodes part of a cluster.

2. Remove the cluster name from agentless monitoring. If you can do it trough the SCOM console follow this article “Operations Manager (SCOM) 2007 – How to remove cluster objects from scom when computer objects in cluster cannot be deleted”.

4. Delete the nodes from Agent Managed views in Administration pane.

3. Run Remove-DisabledMonitoringObject command in SCOM PowerShell. Wait 20-30 min.

4. Install SCOM agents on all nodes.

5. Add cluster name to Agentless monitoring.

Now that you fixed any obstacles you can configure SCOM to send alerts to SCSM only for servers that are in SCOM SLA group. This can happen trough the following steps:

1. Open SCOM console.

2. Open Administration pane.

3. Open Internal connectors view.

4. Find the connector that sends alerts to SCSM and configure it to send alerts alerts only from your dynamic SLA groups.

Additionally with these SLA groups in SCOM you can create different overrides depending on SLA level.

Once again a big thank you to all members of the SCOM community.