System Center Influencers Program

Microsoft has launched a new program for the System Center products. It is called

System Center Influencers Program

What it does?

From the mailmessage I got I have copied the outlines of this program:

This program gives influencers—user group leads, MVPs, popular bloggers, and others recognized as influential in the community around System Center—the technical training content, people connections, and general guidance they need to enhance their credibility and impact in the community.

Key Benefits:

Access key content: Get access to the latest System Center technical training content to help you enhance your expertise. This also includes exclusive user group session content that you can use/present at your user group sessions.

Meet experts and peers in the community: Stay connected with System Center -focused events, or let others know about your upcoming events. You can register and find events, as well as request speakers with domain expertise for upcoming meetings.

Grow in influence: Learn about new opportunities to lead your community on and offline, find out about other opportunities to get more involved with Microsoft.

When one wants to know more about this program or wants to be invited, one must send a mailmessage to this address: scnetsup@microsoft.com.

Of course I have already contacted them and I am about to receive an invitation to join the program! Can't wait...

SCOM R2 will be RTM soon

Just heard that SCOM R2 will be RTM in 30 days.

Bob Kelly, Corporate Vice President, Server & Tools told this in the keynote at MMS.

This Keynote can be watched online here.

Create Counters Failed: Access to the registry key 'Global' is denied.

On the (SCOM) server hosting the SCOM WebConsole the above mentioned error might occur. EventID 10, source WebConsole is logged in the OpsMgr eventlog of the SCOM server:


Workaround: Add the group(s) which grant the users access to the SCOM WebConsole to the local groups 'Users' and 'Performance Monitor Users' groups on the server which hosts the SCOM WebConsole.

This solution comes from the System Center Forum, found here.

NLB MP for Windows Server 2008 released

Microsoft has just released the NLB (Network Load Balancing) MP for Windows Server 2008. It can be downloaded here.

Tons of EventID 10102 and 1103 on a monitored SQL-server

Many events with EventID 10102, immediatly followed by events with EventID 1103 occur on a monitored SQL-server.

This occurs when a 32-bit SQL instance is running on x64 based server. Only a small subset of the monitors will run on this server.

More information? Look here for the online guide of this MP with this known issue and here for the KB article KB891238.

Exchange 2007 MP Beta 2 released

On April the 24th Microsoft released beta 2 of it's native Exchange 2007 MP.

It can be downloaded from the Connect website. Personally I think it is a 'bit' late since Microsoft recently released the public beta of Exhange 2010.

Therefore I do hope Microsoft will release the native MP for this version of this Exchange a bit faster...

Visio Add-in for Operations Manager 2007 R2 Beta released

The source of this posting comes from the blog of the System Center Team, to be found here.

Because this Visio Add-in gives SCOM R2 more power, I post about it to give more exposure.

What it does? Somewhat like Savision Live Maps works which I posted about earlier, found here.

This add-in combines the strenghts of Visio 2007 SP1 and SCOM R2. It can be downloaded from Microsoft Connect. Examples:

When one creates a Distributed Application (DA) it can be exported as a Visio document. When this document is opened it shows automatically the live Healthstate of it's related components.

Also newly created Visio documents can contain shapes linked to an y managed object to show it's current Health State which can be automatically refreshed as well.

There is much more to tell about it. So go check the blog of the System Center Team.

There some screendumps can be found as well. MVP Anders Bengtsson also blogged about it and has put some nice screendumps on his blog as well. Found here.

Resetting SDK and Action-Account passwords

Resetting the passwords of the domain-accounts used for the SDK and Action accounts for SCOM can be a pit of a pain. Actually, this is a bit downplayed when I look at the issues I experienced at a customerssite.

This article is based upon a situation where the Action- and SDK-accounts are already Domain Accounts. If that is not the case, don’t read further, but go here.

Eventhough there is a small article about resetting the password used for the domain account for the SDK Service, found here, real-life experiences are a ‘bit’ more tedious. Especially when one is using Reporting in SCOM and this is running under the SDK-Account. Then more changes comes into play.

So let’s start.

The primary changes are straightforward on itself. In the AD one changes the passwords for the Action- and SDK-Account used by SCOM. On the RMS the related services (OpsMgr SDK Service and OpsMgr Config Service) have to be changed so these services reflect the new situation as well. These changes will occur after a restart of these services.

Now the SCOM Console has to be started. Go to the Administration pane and go to Security, Run As Accounts. Check every account listed under Action Account and Windows to see whether adjustments have to be made. If needed, do so and Apply the changes. Double check everything here to be sure all is well.

Then move on to the SQL-server which is also SQL Reporting Server. Open the Services mmc and check whether the SRS-service is running with the SDK-Account. If so, change the password to the new one as well. Restart this service.

Now start IIS Manager and go to Application Pools, Report Server. Right click it, go to the tab Identity and check whether the SDK-Account is being used here as well. If so, change the password to the new one as well. Restart this Application Pool.

On the same server, start the Reporting Services Configuration tool. Go to the fourth option, displayed on the left, Windows Service Identity. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply.

Now go to the sixth option, Database Setup. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply. Sometimes the first run can give an error. Click Apply for a second time and all is well.

Now go to the eleventh option, Execution Account. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply.

Click the button Refresh (upperleft) and check the status of SRS. All should be green, except for SharePoint Integration and Email Settings. These settings are not crucial for SCOM Reporting.

Check this webpage on the SRS server to see whether Reporting is up & running: http://localhost/Reports. It can take a while since the Application Pool has been restarted. But when all is well, the webpage of SRS should be displayed. If not, recheck everything and adjust what and where needed.

Go back to the RMS. Stop all SCOM related services. Start those services again with the OpsMgr Health Service as the least one. But before starting this service, empty the OpsMgr eventlog of the RMS. Keep this eventlog open.

Start the OpsMgr Health Service and check the OpsMgr eventlog. There shouldn’t be any EventID’s with number 7000,source Health Service. When these events occur there are still problems with the validation of the related accounts (Action and/or SDK). Check these events and check under Administration Pane of the SCOM Console to see whether some accounts haven’t been forgotten.

When all is well EventID’s 7026, source Health Service appear after a restart of the OpsMgr Health Service. These events tell you that the validation of the RunAs Accounts has been succesfully.

WMI Probe Module Failed Execution

Sometimes this Alert (warning) - from the DNS MP - will pop-up in SCOM:

Object enumeration failed Query: 'Select Name, Shutdown, Paused from MicrosoftDNS_Zone' HRESULT: 0x80041001

Eventhough one might think it is the DNS MP which goes wrong, there is a bigger change that WMI on that server is the real culprit.

How to solve it? Look here for an earlier blogposting of mine about it, or here to download a hotfix which makes WMI on W2K03 (SP1 & SP2) servers more robust.

After applying the hotfix the WMI Probe Module Failed Execution Alerts are in most cases gone.

Cluster Management Pack issue

Also with the latest release of the Cluster MP, sometimes a Cluster stays in an unmonitored state.

This issue happens eventhough KB958490 has been applied.

The solution is simple:
In the SCOM Console go to Monitoring, Microsoft Windows Cluster, Cluster Service State.

Select the underlying Cluster Services of the Cluster which is in an unmonitored state and put these Cluster Services for five minutes in Maintenance Mode (MM).

When these servers get out of MM, the Cluster will get into a monitored state within a couple of minutes.

Of course needs Proxying to be enabled on the Cluster Nodes, but that goes without saying since that is described in the manual of the Cluster MP: Read The Friendly Manual...

Maintenance Mode - Top 3 of questions I get the most

Eventhough I blogged earlier about it, (found here) customers of mine ask many questions about it. So with this blogposting I hope to answer the top 3 of them.

Question 1
Suppose one puts a server into MM. During this time the server will be brought down. SCOM will still Alert on it. Why?

The answer is simple. Eventhough the server isn’t monitored during MM, the SCOM Agent on this server still is. So when a server will be brought down for maintenance and one doesn’t want to get any alerts for it, one has to put these three objects into MM:

- Server
- Health Service
- Health Service Watcher

Microsoft even wrote a KB article about it. To be found here.

A good script to put all these three objects into MM can be found here. It works fast and like a charm. With using the schedulerservice on the RMS (for instance) one can easily plan MM in advance.

Question 2
Tim McFadden has made a very good tool, called Maintenance Mode Scheduler 2.0. It can be found here.

Eventhough it works like a charm, many questions arise. The question I do get the most is why it doesn’t run always on Groups. Whenever I get this question I ask what the group is made off, or better, what kind of objects are populating this group?

This really matters since the underlying scripts only work for Computerobjects. So when a group is being populated with non-computerobjects like Health Service of particular servers or Distributed Applications, they will not be put into MM.

So this tool only works for Computerobjects. When one bears this in mind, no problems will arise.

Question 3
Can I put other objects into MM as well? For instance a WebApplication?

Yes, you can. There is a very nice script which just does that. This script can be scheduled as well, so it can be planned in advance. That script can be found here.

This script has been made by Tim McFadden as well. So all the credits go to him, not to me. All I have done is grouped some information about MM logically together. That’s all.

SCOM R2 RC: Service Level Tracking

In SCOM SP1 a special MP was needed in order to check whether certain Line of Business Applications (LOBs) met there Service Level Agreements (SLAs).

This MP is called the Service Level Dashboard MP. A while ago I blogged about it, to be found here.

In SCOM R2 RC many of the options contained within that MP are available by default, eventhough it works a bit different.

On top of that, Microsoft has recently released a new (beta) version of the Service Level Dashboard MP for SCOM R2 RC. But this MP works very different compared to its predecessor, for instance it needs MOSS to operate. With this new MP new possibilities are available. In a future blogposting I will tell more about it.

This blogposting will be about the SLA monitoring capabilities which are by default available in SCOM R2 RC.

So let's start.

First of all, let's get familiarized with the terminology: when a company wants to know whether their LOBs are in conjunction with the SLAs, they set certain Service Level Goals. SCOM refers to these as Service Level Objectives or SLOs.

SLOs come in two different kinds: the Monitor State and the Collection Rule. The first checks the availability of a LOB. The second SLO checks its perfomance. Together they deliver the means to check whether a LOB lived up to it's SLA.

Of course, one needs a target for these SLO's. And here comes one of the differences with the earlier mentioned Service Level Dashboard MP: one can target a DA but also a group, lets say certain IIS servers. In the MP one needed to build a DA based on a special template. In SCOM R2 RC this isn't needed any more. Service Level Tracking in SCOM R2 RC has become much more flexible.

So when the target is chosen and the types and values for the SLOs are known, the Service Level Tracking component (found in the Authoring Console under MP Objects) can be built:


Then the report can be run. Where as the earlier mentioned MP delivered three different reports, here only one report is available. But Less is More since this report contains all the needed information. It works very straightforward - one has only to set the time/date range and select the needed Service Level - and it can be run. The report itself is very clear. The first page displays a summary of of the SLOs for the LOB:


Of course, a drilldown is also possible:

Conclusion:
Microsoft has integrated a much asked for part in SCOM R2 RC. It works faster than the MP needed in SCOM SP1 and is much more flexible since one is not constrained to use only DAs - based on a special template - but has the ability to target the SLOs to a group of servers (for instance).

The SLOs have become much more transparent so one has a better understanding about what is being built.

Eventhough the quantity of the reports has become less (from three in SCOM SP1 to one in SCOM R2 RC) the quality of the report has grown hugely. So Less is More!

Service Level Tracking has grown up in SCOM R2 and will most certainly become a part of SCOM with an added (and highly appreciated) value.

Removing ACS

Sometimes a SCOM component isn't needed anymore and needs to be removed. Most SCOM components are easily to be removed, but ACS can be a bit of a pain.

Disabling the ACS Forwarders is done easily in the SCOM Console: Goto Monitoring, Operations Mangager, Agent, Agent Health State. Select the Agent in the second window 'Agent State' and in the Actions Pane under the header Health Service Tasks, click Disable Audit Collection.

But how to go about disabling the ACS Collector itself? Not always an uninstall will work.

Somehow SCOM will still see the ACS Collector and raise Alerts as it is not working. And when one checks the ACS view in the Monitoring Pane (Microsoft Audit Collection Services, Collector, State View) the ACS Collector is still being displayed. Also the service for the ACS Collector is still being displayed in the services mmc.

The remedy is simple. On the ACS Collector go to the folder c:\windows\system32\Security\AdtServer and start the executable AdtSetup.exe. This will start the installer and a dialog what one wants to do.

Simply select the Remove option and within a couple of seconds all is well: The ACS Collector is gone: the service is gone, the errors in SCOM are vanished and the ACS Collector State View will turn up empty as it should.

Remember with the ACS removal that the steps need to be the opposite of the ACS installation: first disable the ACS Forwarders, uninstall the ACS Collector and finally remove the ACS Database.

Computer Verification: Module Error & EventID 11551 in the OpsMgr eventlog

When one starts the Discovery Wizard of SCOM in order to push new SCOM Agents to servers/clients and the Automatic Computer Discovery method is being used, Warnings will almost certainly pop-up in the SCOM Console with the alert: Computer Verification: Module Error.

With a reasonable sized AD hundreds of these warnings can be raised. The Alert Description will be like:

Computer verification failure for Machine Name: is 0x800706BA. The RPC Server is unavailable

When one looks into the OpsMgr eventlog of the RMS, many events with EventID 11551, Source Health Service Modules will be found.

Eventhough it seems very alarming, nothing is actually wrong. What happens is that SCOM scans the AD and every computerobject found which matches the query stated in the Discovery Wizard, SCOM will try to contact.

Many clients though will be offline so they cannot be reached. So for every time this happens, the earlier mentioned warning will be raised and an event with EventID 11551 in the OpsMgr eventlog of the RMS will be logged.

So these Alerts can be closed. But perhaps it is better to use one of those Alerts to set an override so whenever this happens again, not a Warning will raised but an Informational Alert. This way the SCOM Console will stay much nicer to look at instead of many many yellow ‘flags’ lighten it up.

See screendump about how to change this setting:

Save these settings into a NEW MP with a logical name like Overrides Computer Verification Module Error. This way the override is easy to be found.

Closing the Alerts with PowerShell
When there are so many Alerts in the Console it is better to use PS to close them. With a one-liner found here (*) this can be done easily.

(* : Read the comments on the page of this link since it contains important information.)

SCOM R2 RC: Overrides

Until now - SCOM SP1 level that is - it is hard to find where all the overrides on imported MPs are. In SCOM there is no simple way to find these. It can be done in PS or one can run certain queries on the OpsMgr database but that's about it.

Also - thanks to Stefan Stranger for reminding me - a report can be run showing the overrides. But until now I haven't found it to be very useful so that's probably why I forgot it... :)

So it was a good thing Boris Yanushpolsky made the tool Override Exlorer, to be found here.

This tool does what its name implies: it shows all the overrides applied on the imported MPs and on top of things, one can move an override into another unsealed MP.

However, SCOM R2 has now the ability to show the applied overrides in the SCOM Console. This view can be found in the Authoring pane under Management Pack Objects. This view can also be adjusted to fit one's needs. See screendump:


Until now I haven't found the ability to move overrides from one unsealed MP to another, but the good news is that Boris tool Override Explorer still works in SCOM R2! :)

SCOM R2 RC: Importing MPs

With SCOM R2 RC the way MPs are imported has been improved significantly. In the ‘old days’ (until SCOM SP1), one has to start IE, go to the MP catalog, download the needed MPs (in msi-format) install them (more like unpacking them on to a machine thus putting a lot of unneeded information into the local msi-database) and finally (!) import them within SCOM through the SCOM Console.

In SCOM R2 RC Microsoft has changed this. All the MPs are placed into a cloud. From the SCOM Console one can chose to import the MPs. This was already there but new is the option ‘Add from catalog’


When one choses this option, SCOM connects with the cloud and can choose from multiple options. One of the coolest – to my opinion – is the one offering to upgrade already imported MPs. (Of course one must only do that when the differences with the old ones is fully understood, but that’s another topic on it self….)


Another cool feature is that SCOM doesn’t only foresee problems when importing MPs, but also offers a change to solve it:


and


When one clicks the link Resolve this screen appears:


Click the button resolve and SCOM finds the solution to the problem. All one has to do is hit the button Install and all is well again:


The needed MPs are downloaded first and imported right afterwards. This is a real timesaver compared to the ‘old situation’.

Conclusion:

With SCOM R2 Beta the way SCOM imports MPs was already improved. With SCOM R2 RC Microsoft has taken it even further and made it run like clockwork. The management of MPs in SCOM has been enhanced greatly. One has only to bear in mind that BEFORE importing any MP a good read of the document related to the MP remains a MUST so one knows what is going to be imported into the SCOM enviroment...

Logical Disk Free Space Monitor & the three most common misunderstandings...

The Server OS MP contains many usefull monitors. One of these monitors is the one which checks the available free space of the logical disks. But there are some misunderstandigs about this monitor. And to be frankly, when the document included with this MP is properly read, most of these misunderstandings wouldn’t occur.

So RTFM (Read The Friendly Manual) before importing any MP...

The most common mistakes are:

1: Two values are being used by this monitor, not one.
This monitor uses TWO values to reflect the state: the percentage of available free diskspace AND the available MBs of free diskspace. Based on the outcome of both values this monitor will generate an alert. So when one of these values is well within the range where an alert will not be triggered, SCOM will not raise an alert.

Both values have to fall within a certain range before an Alert is raised. Ofcourse these values can be adjusted to a level which matches the monitored environment.

2: Only critical alerts are being shown, not the warnings.
Normally this monitor shows only a critical alert in the Alertview of SCOM, not a warning. This is by design. But what if one likes to get an warning when the disk is becoming almost too full so there is more time to (re)act?

For this an override is needed. Follow this easy procedure and a Warning like this screendump will be displayed in the Alertview of SCOM:

• Go to Tools, Search, Monitors.
• In the Searchbox type Logical Disk Free Space and hit enter.
• In the Monitor Details pane a link named View Knowledge appears. Click it.
• Go to the tab Overrides and click the button Override.
• Select the first option For all objects of type: Windows Server Logical Disk.
• Place a checkmark at the option Alert On State.
• Change the option in the column Override Setting to The monitor is in a critical or warning state.
• Save the changes into a NEW MP. Click Apply, OK.

Now one has more time to act.

3: Timeframe the monitor runs.
Sometimes customers complain the monitored disks ended up full without SCOM raising an alert in a timely fashion. But that is by design since this monitors runs once every hour. With an override this can be easily adjusted.

Follow the earlier mentioned procedure but at step 5 one must select For a specific object of type: Windows Server 200x Logical Disk. Select the server and disk for which the monitor needs to be altered. Then one adjusts the value of the row Interval (seconds) to a value that fits the scenario one is aiming at. Save your changes into a NEW MP and all is well again.

DNS 2003 Server External Addresses Resolution Alert

With the DNS MP (version 6.0.6480.0) this Alert keeps popping up:

DNS 2003 Server External Addresses Resolution Alert.

Remedy is simple: the hostname has to be adjusted so it doesn't contain the prefix 'www.'. For example, 'www.microsoft.com' becomes 'microsoft.com'.

Another solution is to adjust the 'Query Type' of this monitor (DNS 2003 External Resolution Monitor) to an A-record. With this adjustment the hostname doesn't have to be changed.

This can be done by an override on the monitor DNS 2003 External Resolution Monitor of this MP.

Thanks to Egghead Cafe, found here.

SCOM R2 RC: Upgradepaths and -tasks

The Upgrade Guide - to be found in the 'OpsMgr2007R2-RCDocs.zip' file - contains valuable information about what kind of upgradepaths to SCOM R2 (RC) are supported.

SCOM SP1 or SCOM R2 Beta
When the SCOM environment is at SP1 level you can upgrade directly to R2. Is the SCOM enviroment at beta level of R2, the same upgradepath can be followed.

SCOM RTM
Sometimes I bump into SCOM environments which are still at RTM level. These environments can't be upgraded directly to R2. First SP1 needs to be applied before an upgrade to R2 is possible. See this upgradepaths diagram:


Tasks to be completed BEFORE the upgrade
- Backup databases (OpsMgr, DW & MasterDB, it contains entries for SCOM)
- Backup EncryptionKey (write down the password!)
- Export Unsealed MPs
- Remove Agents from Pending
- Increase available space for data and logfiles of SCOMDBs
- Remove Agents from systems with standalone consoles
- Disable notification subscriptions
- Disable Connectors (if applicable)

Speeding up the upgrade
Nice thing is to run a stored procedure on the SQL-server hosting the SCOM-databases, which will speed up the upgrade process. The document advises to do so with Management Servers thats hosts more than 800 Agents. The stored procedure can be found in the same document.

But even when a (R)MS is hosting a lower number of Agents, it will also work (to a lesser extend though but it will make a difference). The same stored procedure had also to be run when one applied QFE KB956240, found here.

Upgrade order
Eventhough the document writes about another order to perform the upgrade, below is the list which - based on my personal experiences - works best :

1 RMS and SCOM-database
2 Reportingserver and DW-database
3 SCOM Console on RMS
4 Management Servers
5 SCOM Consoles on Management Servers
6 Gateways
7 Agents
8 Standalone SCOM Consoles (like on the systems of the SCOM Operators)
9 WebConsole

And - if applicable - the ACS Collector with the ACS-database

Patchlevel discovery of SCOM Agents

When one applies a SCOM hotfix/patch/QFE which is also applicable for the SCOM Agents, one would like to know whether the hotfix has been applied properly.

So the first thing todo is to build a view in SCOM which shows the Agents and their patchlevel:

Making view for Agents and their patchlevel:

• Open SCOM Console, goto Monitoring pane, right click the node monitoring.
• Select 'New' and 'State View'.
• In the namefield enter a name like 'Agents'.
• In the 'Criteria' tab select for 'Show data related to' as entity 'Agent' (button with 3 dots opens 'Select target type' screen where one can select 'Agent'.)
• In the 'Display' tab deselect 'Name' and select 'Patch List' (almost underneath in the list).
• Click 'OK'. Stateview of Agents is being built now.

However, the discovery of the patchlevel only runs every 6 hours. So with an override this time can be lowered to – for example – 5 minutes. This way one will see pretty fast what Agents got the hotfix and what Agents didn’t.

Afterwards this override can be exported (for later usage) and removed since it is not necessary to have the discovery run so often for a long time.

How to make this override? Very easy:

Making override for patchleveldiscovery:

• In the SCOM Console in the menubar go to 'Tools', 'Search', 'Object Discoveries'.
• In the searchbox type 'patch' and hit enter. The object discovery 'Discovers the list of patches installed on Agents' will be found.
• In the details part of the window a hyperlink 'View Knowledge' will be displayed. Click this hyperlink.
• The propertieswindow of this discovery will be opened. Go to the last tab 'Overrides'.
• Click the second button 'Overrride...' and select the first option 'For all objects of type: HealthService'.
• Make an new MP for it!. Give it an easy to recognize name like 'Override PatchLevel Detection'.
• Adjust the parametername 'Interval Seconds' to 300 seconds. Save the override by clicking 'OK'.

When you go back to the view you have built earlier, the patchlevel discovery on the Agents will run every 5 minutes so the Agent State view is updated much more frequently. When one has all the information needed, the MP with this override can be exported for later usage and deleted after a succesful export in order to keep the load on the SCOM environment at an acceptable level.