New DNS Management Pack released

Since december 19th, Microsoft has released the newest DNS MP, version 6.0.6480.0.

This MP contains the fixes for high cpu-usage and DNS servers which disappeared from the discovery.

The new MP can be downloaded from here

SCOM R2 Highlights. Posting 1, the WebConsole

SCOM R2 is certainly different compared to SCOM SP1. Eventhough the RTM is still some months away from now (planned for Q2 2009), there are certainly many things worthwhile to be mentioned on my blog.

With this posting - and others which will come later - I will talk about the most noticable changes to be seen and found in R2.

This posting is about the WebConsole of R2. Certainly this component is worth being posted about.

In SCOM SP1 one of the most heard questions about the WebConsole was: where is the Health Explorer to be found? Well, nowhere actually. It just isn't there...

This component though is very important for the daily operations of SCOM.

Let me first explain some things:
When an alert is raised within SCOM and this issue has been resolved, just closing the Alert in the Monitoringpane doesn't - in many cases - alter the HealthState of the related server. One needs to open the Health Explorer and to recalculate the HealthState or, a bit more rough, to reset it.

This way the related server will show up healthy again in the Monitoringpane of SCOM. When one doesn't do this, and the related component goes into errorstate again, a new Alert won't be triggered since this component was already before in errorstate.

So a WebConsole without HealthExplorer has very limited functionality and one finds himself in distributing the SCOM console to the Servicedesk colleagues since the WebConsole doesn't help them with their job at a sufficient enough level.

However, too many SCOM Consoles opened at the same time can be a bit of a drain on the RMS since every SCOM Console connects directly to the RMS. And the RMS is busy enough already. So just giving everyone involved the SCOM Console isn't a good choice as well.

That being said, let's go on about the WebConsole.

But now with R2, Microsoft has learned from its clients and payed attention to their remarks about SCOM SP1. So, the WebConsole in R2 does have a good working HealthExplorer.

Before one can use this WebConsole, the (IIS) server hosting the WebConsole needs an extra component to be installed. This component is solely needed for the HealthExplorer of the WebConsole. This is ASP.NET AJAX 1.0. No worries here, since the Prerequisite Viewer, included with the installationset for SCOM R2, will report on it.

Here are some screendumps of the WebConsole with the HealthExplorer:

1. HealthExplorer in the ActionsPane:
   
   


2. HealthExplorer in the Contextmenu's:
   
   
   
3. HealthExlporer itself:
   

Conclusion:

Now the HealthExplorer being an integrated part of the WebConsole, it leverages this component to a higher level of usage. Now one can give the url of the WebConsole to many IT-departments without being afraid giving a tool without enough options for the users to perform their daily duties. Microsoft has done a good job here.

SCOM Reporting, Installation issues. Posting 2, error ‘The XML page cannot be displayed’

This and the previous postings are about the most common errors one can bump into when testing SQL Reporting Services (SRS), and how to resolve these. SRS is needed to make SCOM Reporting work. So this posting - and the others to come - presume SRS is already installed AND configured.

The most common way to test SRS is to go to the website of SRS on the local server hosting the SRS services AND website. This latter is important since this server hosts the website with the SRS components.

When one tries to open the SRS website (http://localhost/reports) one can bump into this error:


Cause
There has been no ASP.NET selected for this website, or the wrong version.

Solution

1. Open IIS Manager
   
2. Open the properties for the website Reports
   
3. Go to tab ASP.NET
   
4. Select at ASP.NET Version version 2.0.50727
   
5. Close IIS Manager
6. Open a cmd-prompt
7. type iisreset followed by an enter

All should be fine now.

SCOM Reporting, Installation issues. Posting 1, error ‘Server Error in '/Reports' Application.’

SCOM without Reporting installed is using SCOM at is best at 50% of it capacity and benefits

That having said, making SCOM Reporting work can be a bit of a challenge. One can bump into all kinds of errors. My personal experience though is that 80% of these errors are directly related to SQL Reporting Services (SRS) or IIS. So one has to test the correct workings of SRS first before one starts installing SCOM Reporting.

With this posting - and others which will come later - I will talk about the most common errors one can bump into when testing SRS, and how to resolve these. So this posting - and the others to come - presume SRS is already installed AND configured.

Some errors are easy to fix, others can be puzzles on themselves. This one explained here is an easy one to fix.

The most common way to test SRS is to go to the website of SRS on the local server hosting the SRS services AND website. This latter is important since this server hosts the website with the SRS components.

When one tries to open the SRS website (http://localhost/reports) one can bump into this error:


Wow! There is not only an errorstatement but it is an understandable one as well. How neat! One doesn't need to be a rocketscientist to know what goes wrong: authorizations are at matter here.

All one has to do is to adjust the permissions on this folder in such a manner that the group ‘Users( \Users)’ has write permissions on that folder. All will fine afterwards.

BridgeWays Management Packs for SCOM

Finally! Xandros has announced the betaprogram for their BridgeWays Management Packs for SCOM.

With these MPs one can monitor non-Microsoft Enterprise applications like:

01 VMware,
02 PostgresSQL
03 Apache Tomcat
04 J BOSS
05 Oracle
06 IBM Websphere
07 MySQL
08 Apache
09 PostFix
10 DB2
11 Blackberry

Want to know more or even to participate in their Beta program? Look here.

Unique about it is the cooperation between Microsoft & Xandros. So these MPs should integrate tightly into SCOM. I have seen some demo's at TechEd Barcelona and it certainly looks good. No more crappy software like others (SNMP based!) which polutes the SCOM enviroment with a load of messages without any real meaning nor quality.

Novell has also setup this kind of cooperation with Microsoft and they will also deliver hig quality MPs for monitoring non-Microsoft Enterprise applications.

Al these products will make SCOM more heterogeneous, especially SCOM R2.

SCOM hotfixes won't install

This posting with the solutions is based on the input of Kevin Holman. Therefore all credits go to him.

However, since this issue can be a bit tedious and is one SCOM users can easily bump into, I have decided to post this case on my blog as well. With this posting the 'internetpresence' of this issue AND the solution will be raised, enabling SCOM users to find more easily the answer for this issue.

Issue
When one installs a certain SCOM hotfix, the installation states it was succesful. However, when one checks the dll's which had to be replaced, these are still of the older version. When one checks the MomPatch.LOG file, there will be an errorstatement, like this one:


Cause
Certain hotfixes for SCOM which have been previously installed have modified some registry entries which the OpsMgr installation uses.

Microsoft knows about this issue and is fixing the Hotfixes. Therefore it is recommended to download the most recent hotfixes. Older hotfixes, downloaded some weeks ago can better be disgarded.

However, one can still bump into issue. Errormessages can be displayed as well, like this one:

Product: System Center Operations Manager 2007 -- Error 1334.The file
File196.2FD07918_9082_437D_99BC_FD43602A4625 cannot be installed because the file cannot be found in cabinet file Data.Cab. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

The workaround is easy, but can be tricky since one has to edit the registry. Have you SCOM RTM installed and later on installed SP1? There are some extra things to reckon with. Even more so, when the server is x64 based, one has to look for other strings (GUIDS) as well. This posting describes what to do in all these situations.

Solution
Open the registry. Go to HKCR\Installer\Products\DF6E5EFF035E66C49971553D96AA0E4D\Patches.Backup this key (patches) by exporting it.

DO NOT FORGET THIS !!!

So far so good. These two steps are the same for every situation. Now the different steps are coming:

One has SCOM with SP1 installed (not first SCOM RTM and later on SP1 afterwards, but directly 'out-of-the-box' SCOM with SP1 included), follow these steps:

Once backed up... delete the REG_SZ GUIDS, and then open the "Patches" REG_MULTI_SZ key, and delete all guids from there.

Only an empty Patches multi string value should remain

When you run the setup, all should work. Import afterwards the key and all should be well.

One has SCOM RTM installed and later on SP1 and has done so on a x64 box, follow these steps:

Leave these two GUIDS in place:
727B3A3ADCF2D1945BFF1FD34105570A (this references MOM2007QFEPreSP1.msp)

88817A55B3D84652468BCF9B1E587B78F (this references MOM2007SP1.msp for AMD64)

These GUIDS must remain in the Patches multi string

When you run the setup, all should work. Import afterwards the key and all should be well.

One has SCOM RTM installed and later on SP1 and has done so on a x86 box, follow these steps:

Leave these two GUIDS in place:
727B3A3ADCF2D1945BFF1FD34105570A (this references MOM2007QFEPreSP1.msp)

8CABA70B215243145A51419A9073262F (this references MOM2007SP1.msp for x86)

These GUIDS must remain in the Patches multi string

When you run the setup, all should work. Import afterwards the key and all should be well.

WMI, SCOM and Windows 2003 server

On many W2K03 servers WMI can get hosed when the SCOM Agent is installed. This is not due to the SCOM Agent but due to the fact that WMI on W2K03 servers is a bit instable.

Since the SCOM Agent utilizes WMI to its fullest extend, the less stronger parts of WMI will be giving problems. There are ways to 'reset' WMI but there is also a hotfix for it. Look here for this hotfix.

Always read the KB article completely so one knows whether this hotfix applies to their situation as well.

However, when one wants to reregister the WMI repository on a W2K03 server this script will do the trick:

net stop winmgmt
c:
cd %windir%\system32\wbem\
for %i in (*.dll) do RegSvr32 /s %i
for %i in (*.mof, *.mfl) do Mofcomp %i
net start winmgmt

Be careful running this script on productionservers since it can cause high cpu-cycles for some time. Be also sure when to run it since it dives deep into the WMI repository of the server.

Another method is to 'reset' WMI. This script can be used for it:

net stop winmgmt
c:
cd %windir%\system32\wbem\
rmdir /s /q Repository
rmdir /s /q Logs
mkdir Logs
net start winmgmt

Eventhough this script has most of the times a low impact on a productionserver, be careful to run it as well.

Thanks go out to multiple other webpages which supplied the above mentioned scripts. I have run these on some occasions and found them to be the solution to many WMI related errors.

SCOM Console shows different information to different SCOM Admins

At a customers site I had this strange behaviour of the SCOM Console:

1. SCOM Administrator A starts the SCOM Console with A's credentials
   
2. SCOM Administrator B starts the SCOM Console with B's credentials
   
3. A creates a new Operator Role named Test A
   
4. B looks into the SCOM Console and sees the new role
   
5. A renames this role to Test A NEW NAME
   
6. B look into the SCOM Console and sees the renamed role
   
7. B renames this role to TEST AGAIN A NEW NAME
   
8. A look into the SCOM Console and will not see this name but the previous name Test A NEW NAME
   

This behaviour happens through the whole SCOM Console: with subscriptions, new views/folders in the Monitoring Pane, and so on. It puzzled me very much.

I searched through the SCOM Database with some queries but it revealed nothing strange. Starting the console with the /ClearCache switch didn't help either, nor deleting the local cache (C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Microsoft.Mom.UI.Console\momcache.mdb). Even removing the SCOM Console and reïnstalling it didn't resolve the issue.

Finally this customer opened a supportcase at Microsoft. However, they were just as puzzled as this customer was and couldn't reproduce this behaviour as well which made it hard for them to solve it.

A day ago however, I bumped into another error of this situation, but now it gave a real error message:

This gave me something to look for on the internet. However I didn't get much hits (2 in fact) but one hit gave me a direction:

In the past – being a systems engineer – I had some strange issues with another tooling/application. Finally (after long and frustrating searching) the cause was simple: the regional options of a server were different of the SQL-server hosting the applications databases. Could this be the cause now as well?

I checked the regional settings of the RMS, MS and SQL server. And YES they were different! The SQL-server (hosting the SCOM databases) and the RMS had the correct settings applied: English (United States). These settings are the standard for this company. However, the MS had these settings set to Dutch (Netherlands). After changing this to English (United States), closing the SCOM Console and deleting the local cache (C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Microsoft.Mom.UI.Console\momcache.mdb) of all SCOM users, all was well again!

So if you ever experience this strange behaviour, follow these steps and all is well again:

1. Close all SCOM Consoles

2. Check the regional options of the RMS, MS and SQL-server.

3. Make sure they match with each other (in my case English (United States) did the trick)

4. Adjust these settings as needed

5. Delete all local cached databases of the SCOM Consoles (whether they are local on the systems of the SCOM Admins, or on a terminalserver, or the SCOM servers them selves, make sure these caches are deleted)

6. Wait about 15 minutes

7. Open the SCOM Console

8. Refresh the panes one by one (Monitoring / Authoring / Reporting / Administration / My Workspace)

9. The information shown in the SCOM Consoles is the same again, no matter which SCOM Admin has the Console opened. Changes are reflected to every SCOM Admin again.

THERE IS A CHANGE THAT SOME LAST APPLIED CHANGES TO THE NAMES OF SUBSCRIPTIONS, USERROLES, USERPROFILES AND SO ON ARE GONE. THEY HAVE TO BE RECREATED. THIS TIME HOWEVER THESE CHANGES WILL BE SHOWN TO ALL SCOM ADMINS.