Thursday, September 1, 2011

Empty Reports in SCOM. What’s happening?

Last day I got the comment from a reader of my blog. No matter what he did or tried, the Reports in SCOM stay empty. Which is very frustrating. He read this series of postings of mine, all about how to get filled Reports but all to no avail.

Even though I do not work for Microsoft Customer Support Services (CSS) I felt myself obliged to try to help him. But just answering his comment in a few lines of text won’t do, so therefore I decided to write this blog posting.

Issue: Empty Reports
Might sound straight forward, but actually it isn’t. Many things can go wrong. Let’s start checking it out.

Step 01: The Basics
Let’s start at the beginning. Which isn’t SCOM related but all about SQL Server Reporting Services (SSRS). Go through this list in order to see all is well:

  • Is SSRS functional?
    • Is the ReportServer database running and OK? (Start SQL Server Management Studio, logon to the SQL Instance and check out the ReportServer database. No strange icons? Can open the database? Can you query the tables?)
    • Checkout the event log on the SQL server. No errors/warnings about the ReportServer database?
    • Is the SSRS service running?
    • Can you access Report Server through IE (http://localhost/reports)?
    • Are the Reports from the MPs uploaded to SSRS? When you can access Report Server through IE, do you see folders, reflecting the MPs you imported into your SCOM environment?  Remember, not ALL MPs do have Reports. But the Server OS MP does, also SQL, IIS and the AD MP for instance. Are they present in Report Server?
    • Start the Reporting Services Configuration tool and logon to the SSRS instance used for SCOM. Can you log on without any errors? Cycle through all items. No warnings? No errors? Nothing grayed out? Is the SSRS execution account OK? (Many times it’s the Data Warehouse Read Account).

  • Did you move the SCOM databases to another SQL server?
    • If so, go here for information and an url and here for the required SQL script.
    • Kevin Holman wrote an excellent posting about it.

  • How about the SCOM Accounts?
    • SCOM uses two accounts for Reporting: Data Warehouse Write Account and Data Warehouse Read Account.
      image 

      image

      Are these accounts operational and not locked out? Are the passwords recently changed of those accounts? Are those changes reflected in SCOM as well? If not, go here and here. Do those accounts STILL have access to the SQL database of SSRS (ReportServer database)? Check it out.

Step 02: Let’s take a look inside SCOM and use a KB article of Microsoft as well
No, this isn’t done through the SCOM Console. The OpsMgr event logs on the RMS and MS servers tell you a LOT. Do they have any errors or warnings? Is any of them about the Data Warehouse? Some EventIDs to reckon with are:

  • EventID 31552. This one can be serious. It’s about not being able to upload data to the Data Warehouse (might cause empty reports).
    • Do you have the Exchange 2010 MP in place? A certain dataset in that MP might cause partially empty reports. If so, go here.
    • If you don’t have the Exchange 2010 MP in place, other issues might be at play. Check this out.

  • EventID 33333.
    • Check this posting of mine.

  • EventID 2115.
    • Kevin Holman wrote a posting about it. Go here.

  • Microsoft KB
    • Microsoft has written a KB about troubleshooting empty Reports, KB2573329. Check it out as well. Much to be found there.

Step 03: Let’s take a look in the SCOM Console
Let’s take a look in SCOM in conjunction with Reporting.

  • Does the Reporting Tree load in the SCOM Console?
    • It may sound stupid, but when you open the SCOM Console and go to Reporting, does the Reporting Tree load? No errors?
    • Sometimes the tree won’t load because of wrong proxy settings in IE, running on the same computer where you run the Console from.
    • When the Reporting Tree is loaded, does it reflect the imported MPs? When you don’t know what MP contains Reports and what MPs don’t, download the guides and RTFM…

  • When the tree loads AND all Reports are in place it might be targeting.
    • Try to run a Report which runs all out of itself (so targeting is taken care of), like the Report found under Reports > Operational Data Reporting Management Pack > Management Group. This Report runs by itself and should display information about the Management Group. When that Report is filled, Reporting is working (to a certain extend that is) and functional.
    • Try to run a targeted Report, like described here. Do you get a filled Report now?

Conclusion
In all the SCOM R2 environments I bumped into where Reporting issues were at play, it turned out 99% that one or more of the above mentioned issues were at play. Many times those issues were easily fixed and only three times SCOM Reporting had to be removed (DON’T remove the SCOM Data Warehouse database!), SSRS reset, repaired and SCOM Reporting reinstalled.

After that all was well again.

But stay away from removing Reporting all together since that scenario is a challenge to tackle. It’s better to contact CSS and let them decide what to do and assist you in it as well.

5 comments:

Sunil HH said...

I am also running into these issues, did all the possibilities mentioned in the previous article

The performance view displays the data for one week in monitoring console.But no data in reporting.

I dint have "Data Warehouse Report Deployment Account" in the accounts, Had to add it, Was this affecting the reporting for my setup?

Marnix Wolf said...

Hi Sunhil HH.

It could be. Have checked all other things as mentioned in this posting?

Sunil HH said...

It worked,Adding "Data Warehouse Report Deployment Account",
Am able producing reports for me from today's date, Hope that was the solution.
Thanks a lot for your help.

Sunil HH said...

Hi Marnix,
Thanks for your timely help,Can you recommend me a good book for SCOM and SSCM.

Marnix Wolf said...

Hi Sunil HH.

That's good to hear! Glad to have helped you. This is the true spirit of the community!

Have a nice day.

Cheers,
Marnix