We have been using SCOM 2007 R2 for some time now, in fact we were the first organisation in the UK to implement the product as part of a Microsoft Rapid Deployment Programme (RDP). Since then I have been one of the biggest advocates of the product, however, one bug that I did come across relates to the description of one of the reports – Performance History (% Processor Time) which is part of the Windows Server 2003 Operating System Management Pack.

This is untrue, the object you actually need to monitor is ‘Windows Server Operating System’.

To filter your search results to include this class, you need to do the following:

1. Double click on the Performance History (% Processor Time) report from the Windows Server 2003 Operating System Management Pack in the reporting pane of your SCOM console and click on the “Add Object” button:

2. Select “Options” from the second window that pops up as shown below:

5. You should find yourself back at the original search screen from step 2. If you click the “Search” button this should bring back all instances and you can select the servers you want to monitor from the “Path” column as shown below:

Once you’ve added you servers you should be confronted with the report you wanted. I haven’t used many of the reports in the console but I’m guessing there may be others that suffer similar issues. I need to take some time out to read the details of what is fixed in Cumulative Update 1 or the latest version of the Management Pack, we’re currently using 6.0.6321.5 as this may be resolved. If you know, feel free to leave a comment!

We have been expanding the current SCOM infrastructure to monitor servers which exist in out DMZ. These servers are not Domain integrated and they have a firewall which seporates them from the rest of our infrastructure as you’d expect.

So, if you’re in the same position, the first thing you need to do is ensure that your firewall ins’t blocking traffic on port 5723. Once you’ve established that, I would urge you to read the following post from one of my Senior Server Techs:

One of the benefits we were looking for after the implementation of SCOM 2007 R2 was the ability to be alerted when any account is added to or removed from important groups such as Domain Admins, Schema Admins, Enterprise Admins… You get the picture!

With a little bit of assistance from our friendly Gold Partners we now generate alerts with subscriptions whenever accounts are added to these groups. The steps we took to complete this are shown below:

We’ve been working through deploying agents to our entire server infrastructure over the past few weeks. In an effort to follow best practice we have a pre-production and production SCOM environment. Anyway, over the weekend we shut the entire infrastructure down for some electrical work and when everything came back online we found that some servers remained in a ‘Not Monitored’ state. The bizarre thing was, this was only in pre-production, everything in Production was ‘Healthy’. So to solve the issue, what we found (with thanks to our Microsoft Gold Partner) was the following fixed the issue:

The whole process takes no time at all and if you’re quick enough SCOM doesn’t even record and outage given that you need to miss three heartbeats before the server is down. I managed to perform this on all servers that were having issues without putting them into maintenance mode or suffering any reported outages.

This week we started the deployment of SCOM R2 agents in anger and the first production servers to be attempted were the Domain Controllers (we thought we’d start with the least important role!).

Anyway, the method of deployment here is SMS2003 using active directory integration for multihoming the agent between our production and pre-production SCOM installs, however, we ran into issues using this method to deploy the agent to our Domain Controllers as the “System Center Management” service would not start. When we tried to start the service manually there was an error generated – “could not start the system center management on local computer… -2130771901” apart from being pretty poor English it didn’t give us a lot to go on.

After a little research we managed to discover the issue related to Domain Controllers being unable to use the Active Directory integration, therefore, the management groups were not being picked up. We could confirm this by checking the service paramaters in the registry to find that no management groups were defined.

To resolve the issue, my partner in crime over at http://serverchronicle.blogspot.com found an article with commands to add management groups. So, with the agent installed, we ran the following commands:

Obviously you need to amend the path to your MOMAgent.msi, management group name and the management server name, once complete you should have multihomed agents deployed and operational on your Domain Controllers.