OM12 SP1: Additional Resolution States: Some Tips & Tricks

When SP1 for OM12 came out, additional Resolution States were introduced, all aimed at Team Foundation Server (TFS) synchronization:

As this TechNet article states: ‘…Through Team Foundation Server (TFS) synchronization, you can establish automatic work item routing for alerts that are raised in Operations Manager in System Center 2012 Service Pack 1 (SP1). This can be helpful if your information technology (IT) department uses TFS or if your process model requires that all application alerts must be tracked in TFS…’

So far so good. Until now I bumped into one customer who has TFS in place and joined it with OM12 SP1. And I must say, they like it very much. For them OM12 SP1 with APM and TFS synchronization is THE tool for which there aren’t any competitors to be found.

But what if you don’t have TFS in place or not going to synchronize it with OM12 SP1? And what if you don’t want the new Resolution States in OM12 since they simple clutter the overview of all available Resolution States and want only those Resolution States which are relevant to your organization?

Since I bump into this situations many times, I have decided to write this blog posting in order to answer the most common questions about what to do with these Resolution States.

1. Should I remove these Resolution States?
   Only when you’re 100% sure you’ll never going to use them. When there is the slightest possibility your organization is going to synchronize TFS with OM12 SP1, DON’T remove the related Resolution States. For now they’ll function like nothing more but place holders. But later they’ll be used. So don’t touch them.
   
   
2. I am not going to use TFS synchronization, ever. So I want to remove the related Resolution States, but how?
   These Resolution States are protected. Basically meaning they can’t be removed straight away from the Console. However, Daniele Muscetta wrote back in September 2008 a posting about how to modify the accessibility of the Resolution States, to be found here.
   
   
3. Is this supported?
   No, this isn’t supported, so you’re on your own here. Also know you can’t blame me neither, seriously. However, for some environments I removed the TFS related Resolution States and until now these OM12 SP1 environments are still running smoothly.
   
   
4. I have removed the TFS related Resolution States. Can I use the IDs they previously used?
   Yes you can. But I don’t know whether you should. Only when those IDs are really required for a connection with another product. In all other situations I prefer the approach to start with ID 10 and increment it by steps of 10, so: ID 10, ID 20, ID 30 and so on. This makes it easier to differentiate between the custom Resolution States and the default ones.
   
   
5. Awesome! Now I am going to remove/alter the Resolution States ‘New’ and ‘Closed’ as well. Or shouldn’t I?
   No you should NOT! This is the road to the destruction of SCOM, no matter what version you run. So NEVER EVER remove/alter those Resolution States.
   
   
6. Okay, I want to modify our custom Resolution States so they can’t be deleted either. Can I do that?
   Yes, you can. Simply modify the entry False to True in the column IsPredefined and you’re done. This helps you to protect your custom Resolution States from actual deletion.

Hopefully this Q&A assists you in making the right decisions when handling the Resolution States.

HELLO Exchange 2013 MP, GOODBYE Correlation Engine And Much More…

Yesterday Microsoft released the MP for monitoring Exchange Server 2013. This MP is far more than a simple upgrade of the previous MP for monitoring Exchange Server 2010.

In the past the Exchange team and their MP developer peers already showed not being afraid of change or whole new approaches to monitoring Exchange server with SCOM, let’s take a look at the history of the MPs for monitoring the different versions of Exchange Server:

1. Exchange Server 2003 MP
   This MP had the (in)famous Self-Tuning-Threshold (STT) Monitors. In theory these STT Monitors are miracles of monitoring. In real life however they aren’t that good at all. The last iteration of this MP had many of these STT monitors replaced by the regular ones which reduced the noise significantly. This MP also used a tool, titled the Configuration Wizard for Exchange 2003 Management Pack. It  helped people to get this MP configured in a fast way. However, this tool introduced new challenges as well. Overall this MP was noisy and had a high TCO because of the ongoing tuning.
   
   
2. Exchange Server 2007 MP
   This MP had no STT monitors what so ever. Also the separate Configuration Wizard used for the Exchange Server 2003 MP was dumped. Instead this MP was easily imported since all Monitors didn’t do anything. Simply because the related discoveries were turned of by default. Only one Discovery was running, the Discovery Helper. It showed people what Exchange 2007 servers were detected by this Discovery. When this was correct all other Discoveries could be turned on, one by one thus introducing a phased implementation of this MP. Many times the Discovery Helper identified servers as Exchange 2007 servers simply because the Exchange 2007 Server management tools were present. By tweaking this Discovery Helper process one could easily correct it, thus enabling correct monitoring of the Exchange Server 2007 environment. Overall this was a good MP and worked very well since it didn’t produced less noise and had a low TCO.
   
   
3. Exchange Server 2010 MP
   This MP is the most controversial MP the Exchange Server team introduced. It contained the Correlation Engine (CE) which was an additional process running on the RMS or OM12 MS server hosting the RMS Emulator Role. Again the theory behind the CE was very good, and still is. But in reality it introduced many unforeseen issues, like using some of the Custom Fields of the Alerts. Every Exchange Server 2010 Alert was processed by the CE which put some information into the Custom Fields of the Alerts shown in the SCOM Console. However, these same fields are used by Connectors and other similar processes which many time broke it. Another thing introduced were some whacky Data Sets which weren’t programmed very lean and mean. Because of it many of those queries contained in those Data Sets timed out, breaking the aggregation of raw data in the Data Warehouse, resulting in empty performance reports. This MP has seen many updates, some good and other outright bad. There was even an update which disabled mailboxes. So this MP has a whole history of its own and much of it isn’t that good at all.

No matter what one might think about it, it shows at least the Exchange Server team isn’t afraid of change and tries many new approaches when it comes down to the related Management Packs. And yes, many times I have cursed the Exchange Server 2003 MP and the Exchange Server 2010 MP. But at least these MPs go through a development cycle also after the first version has been released. Unfortunately the testing of those same MPs – before being released into the wild - didn’t prevent some serious issues hampering even more the already slightly negative experience index of the end users with this MP...

So now a new Exchange Server MP sees the light, the Exchange Server 2013 MP. And again this MP is totally different compared to its predecessor, because:

1. The Correlation Engine is gone;
2. The MP lacks the depth of its predecessor: it contains only some classes, and about 80 Monitors;
3. No performance collection takes place what so ever;
4. No Reports.

As the System Center Engineering Team states: ‘…each monitored Exchange server is responsible for monitoring its own health, and simply reports this via the Operations Manager agent. There is a little bit of roll-up going on, from Exchange server to Organization health. There are no special components running on the Operations Manager Management Servers…’

IMHO, this MP is just way too basic and misses out on collecting information required by many organizations. Also it plays down the role SCOM can play when monitoring a crucial service like e-mail. This MP reduces SCOM Agent to a proxy and skips all the intelligence present in any SCOM environment.

Yes, one could state the information required by those organizations is collected by Exchange Server 2013 itself. But why not expose that information to SCOM? Organizations want SCOM for many reasons, one of them being the SINGLE point where ALL information of many of their IT systems and services comes together. They don’t want anymore a huge collection of different points of information. A total overview is what they want and require.

Also the total lack of Reports isn’t a very good move either. IMHO, every MP should contain a set of Reports. Monitoring has grown up and has become far more then just looking at the current situation but also being able to report about how the situation has been in the past week/months and also being able to make future predictions.

So again the Exchange team and the related MP developers have chosen a course of action which I do not totally comprehend nor applaud to. I know my words sound harsh but I am just disappointed about the limited capabilities of this new Exchange Server 2013 MP. Hopefully future iterations of this MP will correct some of these ‘issues’ and missing (BASIC) features, like a mailbox count, mailbox size and so on…

The MP can be downloaded from here. The blog posting on the blog of the System Center Engineering Team about this new MP can be found here.

VMM 2012 Service Templates & Some Good Examples

As we all know, VMM 2012 (and later) is TOTALLY different compared to its predecessors. From a tool for managing a Virtual Infrastructure (VI) it has become the tool to manage your own private cloud(s).

In those very same private clouds Service Templates play a key role. Without them, your private cloud isn’t that exciting at all. Just a bunch of resources (compute, network & storage) people can ‘consume’ but that’s about it basically.

This is where Service Templates do come in. Instead of sharing resources, an entire organization is capable of deploying business applications as required WITHOUT going through the usual chorus which slows down the delivery of that same business application significantly. Instead with a few mouse clicks, the application is provided on a as-needed basis. And all the while it adheres to all company policies and requirements as well, simply because the Service Templates are build in such a manner that it’s fully compliant.

I know this is huge simplification of it all, but when all boiled down it is what it is and does.

So Service Templates have not only become key in VMM and the private cloud but also a challenge to get them right. So any good example is welcome in order to learn from it.

Therefore it’s good to know there are some very good blog postings out there all about building Service Templates:

1. A series of blog posts around the deployment of a SharePoint Farm using VMM Service Templates;
   Application Management-Example-Deploying a Service to Your Private Cloud (Part 1)
   Application Management-Example-Deploying a Service to Your Private Cloud (Part 2)
   Application Management-Example-Deploying a Service to Your Private Cloud (Part 3)
   Application Management-Example-Deploying a Service to Your Private Cloud (Part 4)
2. Application Management – Service Templates, real reusable examples

And check out this track since more posings are coming up: http://blogs.technet.com/b/privatecloud/archive/tags/application+management+track/

New MP: Amazon Web Services MP

Some days ago a totally new and UNIQUE MP has been released: a MP for monitoring Amazon Web Services (AWS) with SCOM 2007 R2 or OM12.

This MP is unique for a number of reasons (taken directly from the System Center Engineering blog):

1. It is the first MP of its kind to be able to separate the computer (Operating System) from the AWS Instance (Virtual Machine).
2. It creates a logical monitoring and reporting mechanism that can intelligently identify where a problem or error state exists, either in the AWS cloud or the server OS/application running within AWS.

IMHO, some other reasons why this MP is unique:

1. Microsoft helped to develop this MP even though AWS is a competitor of Microsoft’s cloud portfolio (Azure);
2. The MP is developed by VIAcode, a company which has an awesome and impressive track record for developing MPs.

Microsoft states they helped developing this MP in order to proof that System Center (read: SCOM) is capable of providing rich monitoring, alerting and reporting any application from any location in any cloud.

I haven’t tested this MP myself but not only Microsoft is totally happy about this MP but Amazon as well. And I know for sure they don’t want this kind of exposure when they don’t believe in it. So this MP must offer some very good things.

The MP can be downloaded for FREE and it’s good to know it comes in two flavors: SCOM 2007 R2 and OM12. I have checked the (online) guide and I must say, it looks pretty solid to me.

Here are the related links:

1. Blog posting by the System Center Engineering Team;
2. Blog posting by the AWS Team;
3. Download location of the AWS MP;
4. Online MP Guide.

So for anyone running SCOM 2007 R2/OM12 and using AWS, this MP is a MUST have!

New KB Article: SCOM 2007 R2 Agents & Teamed NIC Issue

Yesterday Microsoft published KB2847767, all about SCOM R2 Agents failing to discover teamed NICs.

A failing discovery = no  monitoring which isn’t a good situation at all. KB2847767 tells it all. The issue, its cause and how to solve it.

Let’s Hack Some XML For Report Export To Another SCOM MG & Data Warehouse

With SCOM 2007 R2 and later a new feature to save Reports is introduced: Saving self created Reports in SCOM to a Management Pack (MP).

Even though this feature works great it has ONE huge drawback: this MP can’t be exported and imported into another SCOM Management Group (MG) which runs another Data Warehouse database. Microsoft is pretty clear about it in it’s online TechNet documentation for SCOM 2007 R2 and OM12 SP1:

Management packs can be exported and imported into other management groups and the reports will work only when these management groups share the same data warehouse.

Yes, the MP itself containing those Reports can easily be exported from one MG and imported into another MP running a whole different Data Warehouse. But when those Reports are run into the other MG (where the MP is imported) this error is thrown: Object reference not set to an instance of an object:

But with some quick editing the XML of this MP it can be exported to another SCOM MG using ANOTHER Data Warehouse database. Afterwards the Reports contained in that MP will still need some additional attention (selection of the correct Groups/Objects where the Reports are targeted against) but at least you don’t need to rebuild those Reports all over again, saving you a lot of time and hassle.

The steps involved
These are steps required to make it work:

1. Create the Reports as required and save them to a single dedicated unsealed MP;
2. When all the Reports are made export the MP;
3. Open the related XML-file of the MP in a good editor like Notepad ++;
4. Search for the entry <Parameter Name="ManagementGroupId">, like this:
   
   The GUID defined between <Value> and </Value> has to be replaced by the ManagementGroupId of the MG where this MP will be imported;
5. Run the PS extensions on a MS of the MG where the MP exported in Step 2 will be imported and run this PS command: Get-SCOMManagementGroup | ft Id. Output will be like this:
   
   Copy this GUID;
6. Replace all the GUIDs for the ManagementGroupId as stated in Step 4 with the GUID found in Step 5;
7. Save the modifications to the XML file;
8. Export this XML file into the new MG and presto, the Reports will run now (*).

(*: When Groups are used, the targeting of that Group will most likely go wrong. Simply select the correct Group and all other predefined parameter selections will be just fine. Now the Report will run successfully.)

Updated MP: Windows Server OS, Version 6.0.7026.0

Yesterday Microsoft released an updated version of the Windows Server OS MP, version 6.0.7026.0.

Changes in this update:

• Fixed a bug in Microsoft.Windows.Server.2008.Monitoring.mp where the performance information for Processor was not getting collected.
• Made monitoring of Cluster Shared Volume consistent with monitoring of Logical Disks by adding performance collection rules. (“Cluster Shared Volume - Free space / MB”,”Cluster Shared Volume - Total size / MB”,”Cluster Shared Volume - Free space / %”,”Cluster Disk - Total size / MB”,”Cluster Disk - Free space / MB”,”Cluster Disk - Free space / %”)
• Fixed bug in Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.mp where the Cluster disks running on Windows Server 2008 (non R2) were not discovered.
• Fixed bug 'Cluster Disk Free Space Percent' and Cluster Disk Free Space MB' monitors generate alerts with bad descriptions when the volume label of a cluster disk is empty.
• Added feature to raise event when NTLM requests time out and customers are unable to use mailboxes, outlook stops responding, due to the low default value for Max Concurrent API registry Key (HLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters) , which is a ceiling for the maximum NTLM or Kerberos PAC password validations a server can take care of at a time. It uses the “Netlogon” performance counter to check for the issue.

MP can be downloaded from here.