Thursday, December 22, 2011

Merry Christmas & a Happy New Year

From Saturday the 24th of December 2011 until the 3rd of January 2012 this blog will be silent since I am on vacation.

I want to thank you all for visiting my blog, your comments, time and advices. 2012 will be a special year since many new revamped System Center products will go RTM. So there’s enough to blog about!

For now I wish you all a Merry Christmas and a Happy New Year!

Exporting Linked Reports to another SSRS instance? Yes YOU can!

Bumped into the issue where some Linked Reports had to be exported to another SSRS instance used for SCOM R2. But out of the box that won’t work. So it was time for some investigation and guess what? I found a great tool which enables one to export all catalog items from one SSRS instance to another, among them Linked Reports! But before I tell you more about that tool, let’s start at the beginning.

What’s a LINKED Report?
A Linked Report isn’t a Report at all but a reference to the report definition of an existing Report, plus any settings and properties that one defines for a Linked Report. (This information is to be found here as well).

Basically this explains why a Linked Report can’t be exported directly as a RDL file. Since it’s simply not a RDL file but some kind of shortcut with some predefined parameters. And out of the box, Linked Reports can’t be exported to another SSRS instance.

Along came Jasper Smith
Who is he? Good question! He’s a UK based SQL MVP and runs a blog of his own, all about… SQL! He made a great tool, Reporting Services Scripter (, which enables one to export all items from a SSRS catalog.

The tool came to be in 2005 and has been developed ever since. The last version is built in 2009 and works with SQL Server 2008 R2 as well. I tested it myself and everything goes fine!

Some issues to reckon with
Even though the tool explains it self and comes with a good help file, there are some issues to reckon with:

  1. When running the tool against a x64 based version of SQL server, the path for SET RS in the batch file has to be modified to SET RS="C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\RS.EXE". Otherwise the batch file won’t be able to find the RS.EXE executable.
  2. When you export Linked Reports, you also want to export the predefined parameters like targeted Groups and the lot. In order to export those as well, you have to modify the Options of the tool. Go to the third tab Report, copy these settings and click Apply. Now all predefined parameters will be exported as well.
  3. Many times customized Reports are saved to a separate folder and presented as such in the SCOM R2/OM12 Console, like this:

    When running the tool in order to export the Linked Reports, it’s to be advised to select that folder.
    The contents of that folder (the Linked Reports) will be exported as well. When the script is run on the new SSRS instance, the folder AND it’s contents are automatically created. Saves one a lot of time.

  4. Last but not least: Only import the Linked Reports to the new SSRS instance when the referred Report Definitions and Reports are in place as well as the predefined parameters like Groups and computers for instance. Otherwise one might bump into some unexpected results like a faulty Report.

All credits go to Jasper Smith for building AND sharing such a magnificent tool! Thank you Jasper!

Tool can be found here.

Tuesday, December 20, 2011

Savision Live Maps Beta 2 for OM12 is available

For some weeks now the second beta of Savision Live Maps for OM12 RC is publicly available. I have installed it in one of the OM12 RC LAB environments (since the product is beta it’s advised not to install it in a OM12 RC environment which runs under the TAP program!) and it works perfectly. For now I can’t really say anything has changed under the hood.

Which is basically good since it enables one to export the Maps created in earlier versions of Savision Live Maps. In a posting soon to come I’ll tell you how to do that.

When you have OM12 RC running in a lab environment I advice you to install Savision Live Maps Beta 2 as well. Since this software really adds so much value to your OM12 environment, even with the new Widgets and Dashboard functionality by default present in OM12. Now you can test drive migrations from Savision Live Maps SCOM R2 environments to OM12 environments.

For download go here and select the last option (highlighted in yellow):

One has to enter some information like a valid email address and the name of the OM12 RC MG. After that one can start the download and install it in a couple of seconds.

Beta 1 is actually Beta 2…
Since it’s a beta product there are still many things under construction. When one double clicks the file LiveMapsV6_BETA2.exe, this screen will be shown:
But don’t let it fool you. It’s really Beta 2.

When all components are installed and one opens the Live Maps Authoring Console, it will still show the Beta 1 text. However, pay attention to the version number which tells it’s Beta 2:

Beta 1 has version number and was valid until 31st of December 2011. Beta 2 expires on the 1st of March 2012.

OM12 RC: Web Console vs OM12 Console

Cameron Fuller, a much respected MVP (yeah, I met him a couple of times and he’s also fun to be with. Especially when one orders food with hot hot hot peppers. He eats them like candy and he doesn’t explode. This still puzzles me…) posted a great article all about the differences between the OM12 RC Web Console and the OM12 RC Console.

Mind the ‘RC’ bit please since things still might change when OM12 goes RTM.

The excellent posting can be found here.

Cameron, thanks for sharing! Next time we meet I’ll buy you a huge bottle of Tabasco :).
TABASCO® Gallon Jugs

OM12 RC installation: Installation of Reporting stops and shows a red cross when entering the SQL Server Instance in installation screen

Got this one from a much respected reader of my blog, John Bradshaw from Australia. Thanks for sharing John!

When installing OM12 RC Reporting one has to enter the name of the SQL Server Instance:
After that a red cross is shown and the installation stops. No error messages are shown at all.

The SQL Server Agent on the SQL Server hosting the SSRS instance isn’t running. Therefore the ‘scheduled operations cannot be created’. These scheduled operations are scripts and the lot which are part of the OM12 Reporting installation.

Start the SQL Server Agent on the SQL Server hosting the SSRS instance and the installation will run now.

Background information
For myself I haven’t seen this issue because when I install the SQL server required for SCOMR2/OM12 I always set all SQL related services to start automatically. This has saved me the above mentioned issue.
But I can imagine situations where the SQL server is already provisioned by the DBA’s. In that case ask them to set all related SQL services to start automatically.

Friday, December 16, 2011

New KB article: SCOM R2 Config service consumes 100% cpu for a long time

Yesterday Microsoft released a new KB article about an issue with the SCOM R2 Config service. This service consumes 100% cpu for a long time.

KB2655633 tells the cause of this issue and how to solve it.

Thursday, December 15, 2011

Authoring has started: System Center 2012 Operations Manager Unleashed

Wow! Never I will forget the day a colleague of mine showed me THE book for SCOM: System Center Operations Manager 2007 Unleashed. All the questions I had were answered! It introduced me to the real world of SCOM.

The names on the cover were totally new and unknown to me. At that moment I didn’t expect to meet them in the flesh nor to become a MVP as well. At that time I even didn’t know what a MVP was :).

Much has changed! And now I have the honor to be a contributor for the new book, System Center 2012 Operations Manager Unleashed, as well! Wow! I am really honored to be part of the team which is writing this book. Already learning a great deal. Thank you Kerrie, Cameron and John for having me in this special group of people!

Want to know more about this book? Kerrie has written more about it, to be found here.

Also good to know, another much respected Dutch SCOM MVP writes the chapter about Management Pack authoring. For me personally he’s Da Master of MP Authoring: Oskar Landman. Deep respect man!

Wednesday, December 14, 2011

New KB article: SCOM R2 Linux Agent fails to deploy: ‘The certificate Common Name (CN) does not match’

Yesterday Microsoft released a new KB article about the SCOM R2 Linux Agent failing to deploy and showing this error: ‘The certificate Common Name (CN) does not match’.

KB2651766 tells the cause of this issue and how to solve it.

New KB article: SCOM R2 Console may crash while setting the scale on a performance view

Yesterday Microsoft released a new KB article about SCOM R2 Console crashes when setting the scale on a performance view. At this moment there isn’t a solution, only a workaround, to be found here: KB2652434.

Tuesday, December 13, 2011

Management Packs: What do YOU think about it?

Some time ago I posted an article about the level of quality of the MPs delivered by Microsoft. I got many comments on it, some of them a bit too ‘spicy’ to post. So it was difficult for me to get a clear picture about how YOU really feel about it.

However, looking at 2012 it will be an important year for Microsoft and the System Center Suite as a whole. Many SC products will be revamped and launched in H1 of 2012, among them Microsoft System Center 2012 – Operations Manager or OM12.

Even though the RC is publicly available and shows many new features it’s still the infrastructure. What makes any SCOM (R2) or OM12 environment ‘tick’ is the Management Pack. IMO, the MP is key to the success of any SCOM R2 /OM12 environment.

Therefore I am curious about what YOU think about the Management Packs delivered by Microsoft. So I have created an online survey to be found here. This survey is limited and accepts only the first 250 responses, so be quick!

And of course, I will post the outcome in January 2012. 

Thank YOU for participating in this survey.

Monday, December 5, 2011

Operations Manager Implementation Phases: At what level are YOU?

Whether your run a SCOM R2 environment or will migrate/install OM12 in H1 2012, there are certain phases to reckon with. Every phase comes with a set of deliverables which require attention.

Sometimes organizations tend to think that implementing SCOM is the most important phase and covers it all or at least 80% of it. Just some more work to be done but nothing special. Actually, that’s not true.

01 – Basic Monitoring
The implementation of SCOM itself is a straight forward process. Of course, whether or not Gateway Servers are required, monitoring of non-Windows based servers, making the SCOM environment itself high available can make it a bit more of a challenge. But still, at the end one gets a SCOM environment which covers the basics. And now another process kicks in, CONNECTING SCOM to the organization.

02 – Permissions and Notifications
Connecting SCOM to the organization starts out easy: Creating User Roles, related View and permissions. What is one allowed to do, see and act upon in certain Role, like DBA for instance? Also deciding what Alert gets out (as an e-mail message for instance, aka the Notification Model) to whom and when, is configured in this phase. Besides that tuning starts as well. What Alerts are OK and what Alerts require additional tuning?

This is an ongoing process which can take up considerable time when the SCOM environment is freshly installed or a MP gets an update. Afterwards, the time required for this tuning takes up an hour per week when performed by well trained staff.

Phases 1 and 2 are still – IMHO – the basics of SCOM. When these phases are covered, one has basic monitoring in place. And for many organizations this is a good starting point to evolve to the next level, Extended Monitoring, also referred to in this posting as the extended layer.

03 – Extension 1
In this phase additional MPs are loaded and configured, like MPs for covering Oracle, BlackBerry Enterprise Servers, extensive network monitoring. Also additional dashboards are created by using the Visio Add-in or 3rd party Software like Savision LiveMaps, with or without SharePoint Integration. And on top of it all, customized Reports are created. Reports which really have added value to your organization.

As you can see, in this phase the first steps are made in order to close the gap between SCOM and the organization. And also notice SCOM is the one who is closing the gap, and not the organization. Basically the technology is adjusting itself to adapt itself more into the organization.

04 – Extension 2
In this phase applications, which are business critical to your organization are being covered by SCOM. Some on a component per component basis, others E2E (end-to-end). But it doesn’t stop here. These applications also need some means of visualization, like comprehensive dashboards (Quality level: Single-Glance-and-You-Know-It) and some good reports (availability, performance, SLAs and the lot).

This can be a process which takes up some time. First of all you must know what to monitor, how to monitor it, where to monitor it. Then you must look into SCOM. Are the Objects already there or are additional MPs required? Or is some basic or deep MP authoring required? What kind of Reports are required? Does SCOM cover those or is additional Report Authoring required? And when chains of Objects are to be put together, does a couple of DAs cover it or we need many DA’s? And how to tie them together in order to make sense and to represent the application which requires monitoring?

Basically, phase 4 repeats itself per application. And per application it can be covered in a few days up to a few weeks depending on how the application is build (web server, front- and backend, client-, server application), what building blocks does the application use (Windows only (haven’t seen that a lot), or other mainstream building blocks like Oracle, Unix, Java and the lot) and what the requirements are.

But the more you find yourself in Phase 4, the more SCOM enters the organization and is tied into it. Dashboards are to be found not only at the desks of the system engineers, but also at the desks of the application owners, service managers and ICT managers as well. Reports flow on a regular basis to the stake holders so they know about their ICT environment all there is to know.

For some more clarification I have included this picture with the four phases and two ‘layers’, Basic and Extended. And ask yourself this question: At what level am I?

When you find your self at Level 1 or 2, take your time to complete those levels before you step to level 3 or 4. Because like a house, without any solid foundations, one can’t build anything good on top of it.

Friday, December 2, 2011

Community: SCOM Agent Health Tips

Daniele Grandini has posted an excellent article, all about SCOM Agent health tips.

Certainly every SCOM Admin can use these tips and advices. Want to know more? Go here.

Preparing for migrating to OM12: Moving from SQL 2005 to SQL 2008 – Part III: Phase II – The Migration

Postings in the same series:
Part  I – Along came a theory
Part II The Preparations

In the third posting of this series I will describe in more detail Phase II, the actual migration from SQL Server 2005 to SQL Server 2008 R2 SP1 . When you haven’t read the first and second posting of this series please do so now since otherwise you’ll be missing out the big picture here.
For the completeness here is the list of questions/steps which make up Phase II:

  1. Backup of your SCOM environment (SQL, RMS, MS servers and databases). This is step enables the fall-back scenario and not Step 5 since the SCOM R2 environment is already affected by then;
  2. Removal of the SCOM Reporting functionality (we KEEP the Data Warehouse of course!);
  3. Stopping of the Health Service on RMS and all MS servers;
  4. Stopping the Configuration and SDK service on the RMS;
  5. Backup the SCOM databases: OperationsManager and OperationsManagerDW (because no more data comes in these backups are the most current ones and won’t be outdated in any kind of way);
  6. Stop the SQL Server service (and all other related SQL services) on the old SQL Server;
  7. Restore of the SCOM databases OpsMgr and OpsMgrDW on the new SQL 2008 R2 SP1 server;
  8. Adjustment of the registry keys on the RMS, so the new SQL server is used;
  9. Adjustment of the registry keys on all MS servers, so the new SQL server is used;
  10. Adjustment of some entries on both SCOM databases on the new SQL Server so the new SQL server is correctly referred to in the database AND enabling CLR for the OpsMgr database;
  11. Enabling SQL Broker Service on the SCOM R2 database;
  12. Starting all SCOM related services on the RMS and checking the OpsMgr event log for any error;
  13. Launching the OpsMgr Console on the RMS to see whether all is OK;
  14. When all is well, starting the Health Service on the MS servers, one by one and checking the OpsMgr event logs on those servers whether all goes well;
  15. Installation of SCOM Reporting on the new SQL server;
  16. Checking SCOM Reporting by opening the SCOM R2 Console: is the Reporting Wunderbar present?;
  17. Checking the successful upload of data into the Data Warehouse (OpsMgr event logs of the RMS and MS servers);
  18. Restore of custom folders in SSRS and upload of custom RDLs to the correct Folders;
  19. Checking whether all Reports show up again in SCOM (this might take an hour or so).

As stated before, it won’t be a detailed step-by-step guide , but I will highlight the most crucial steps. In the list above the steps which are printed in blue will be explained by me in more detail. Let’s start since there is a lot to share.

Step 2
The SCOM R2 Reporting functionality must be removed now. Of course we KEEP the OperationsManagerDW database!

Open the SSRS server hosting the SCOM Reporting component and log on with admin permissions. Go to Control Panel > Add or Remove Programs and select System Center Operations Manager 2007 R2 Reporting Server > Remove > Yes:

The removal of SCOM R2 Reporting takes a few minutes. When it’s finished it won’t show a dialogue. The ‘installer screen’ just disappears. Open the SCOM R2 Console and the Reporting Wunderbar should be gone now:

Step 5
In order to create the backups one can use SQL Server Management Studio. This tool uses the correct VSS writer so a viable backup will most certainly be created. Also assure the backup is validated:

Step 7
Restoring the SCOM R2 databases to the new SQL 2008 R2 SP1 Server: Use the same medium for this procedure as you used for creating the backups. In this case SQL Server Management Studio. Connect to SQL instance and log on with an account which has sufficient permissions.

Click right on Database > Restore Database. A Wizard is started now. Select the option From device and click on the selection button (red circle):

Select for Backup Media File > Add. Select the backup file of the OperationsManager database > OK > OK

Select the option Restore. Option To database: select from the dropdown menu OperationsManager. Option: To a point in time select Most recent possible > OK.

Restore runs for a while and when all is OK:

Repeat the same steps for the Data Warehouse database:

Step 8
Adjustment of registry keys on the RMS so the correct SQL Server is referred to:

Log on to the RMS with local admin permissions and open the registry editor. Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

Change the key DatabaseServerName so the new SQL Server is referred to:

‘Save’ the changes and close the registry editor.

Step 10
Adjustment of some tables in both SCOM databases so the correct SQL Server is referred to. Open SQL Server Management Studio, logon with admin permissions on the SQL instance.

OperationsManager database
Go to Tables > MT_ManagementGroup > click right and select the option Edit Top 200 Rows. Search for record SQLServerName_6B1D1BE8_EBB4_B425_08DC_2385C5930B04

Modify it so it refers to the new SQL Server:

Close the table.

Enabling CLR on the OperationsManager database
Select the database > click right > new query > copy this code

sp_configure 'show advanced options', 1;




sp_configure 'clr enabled', 1;




> Execute:

OperationsManagerDW database
Go to Tables > MemberDatabase and search for the record ServerName

Modify it so it refers to the new SQL Server:

Close the table, but stay in SQL Server Management Studio.

Step 11
Enabling SQL Broker Service: See this posting of mine, Step 2.

Step 15
Installing SCOM R2 Reporting:

First and foremost, check the correct working of SSRS by opening this URL on the SSRS instance in IE (running with elevated permissions!): http://localhost/Reports:

When this screen is shown all is well. Otherwise fix any issues before continuing.

Before starting the installation first go through the steps mentioned in KB2425714. Otherwise the installation of SCOM Reporting won’t succeed.

Run the installation media of SCOM R2 with elevated permissions and an account which has admin permission locally on the SSRS server, within SCOM and permissions within the SQL instance hosting the Data Warehouse database. Otherwise the installation will fail…

Go through the setup wizard but don’t forget to DESELECT the Data Warehouse database:

Enter all the required information and later on SCOM R2 Reporting is installed successfully:


Step 17
Checking the successful upload of data into the Data Warehouse on the RMS and MS servers:

Check the OpsMgr event log on these servers for this kind of events: Category: Data Warehouse, EventID: 31554 (there are others as well).

Events like these indicate successful uploads of data into the Data Warehouse.

Step 18
Recreating the custom folders in SSRS and uploading the RDLs of the custom reports:

Recreate the custom folders in SSRS by using the web interface for SSRS http://localhost/Reports. Create the required folders:

Upload the RDL files of the custom Reports into the correct folders. This is also done within the web interface for SSRS.

As you can see, migrating from SQL Server 2005 to SQL Server 2008 R2 SP1 CU#2 isn’t something to be taken lightly. However, it can be done and in a good manner as well.

Planning and preparation are key here. And don’t hesitate to practice it in a lab environment. No licenses are required since you can download all the required software as trial versions and have a go at it. Test it, document it and try it. So you get the hang of it and know what you’re doing.

This way you can migrate safely to SQL Server 2008 R2 SP1 CU#2 for SCOM R2 without too much hassle.

In the last posting of this series I will describe the last steps, like cleaning up the ‘mess’ :).