SCOM 2007: Scheduled reports failing
Recently I got a mail of a user stating he’s not receiving his reports anymore via mail. They were created way back and normally these reports are in my category “set it and forget it”…
When I checked the schedule reports pane instantly I noticed that all the reports are showing an error as shown below:
“The Subscription Contains parameter values that are not valid” error message is in the status field.
During my search on the web the most common solution was to recreate the report which I did for one but because these are like 20 reports it will be a lot of work to recreate them all and risk the fact that they break again without knowing when and why.
So the next step I tried in my troubleshooting is to see whether I could fill in the missing parameters in the report which resides in a custom management pack holding all these special reports.
When I tried to run the report I noticed the following: Data Aggregation and Histogram are greyed out and it’s impossible to change them
When I tried to run the report the following error message came up:
So there is an issue with the ‘Data Aggregation’ parameter. No possibility to troubleshoot any further in the SCOM environment so we’ll have to dig deeper and turn our attention to the underlying SQL Reporting Services (SRS) install.
Connect to the SRS server and open up the SQL management studio.
Note: If you’re not sure where your SRS install resides navigate to SCOM console > administration > Reporting. The Reporting Server URL is filled in there so you can retrieve the server name / alias here.
Make sure you select “Reporting Services” in the Server Type and select the server name you’ve retrieved from your console.
Navigate to Home > “Your management pack” > reports > Subscriptions.
In this example we’re troubleshooting the “PROD3_IOReport”.
Right click and choose view report.
The web browser opens and will generate the report. However in this case the following error shows up:
Didn’t we have an issue with the “DataAggregation”? The error above shows we have an issue with our “ManagementGroupId”.
Let’s take a look at the report properties to find out.
Right click the report and choose Properties.
The familiar SQL properties page pops up.
Behind the “ManagementGroupID” (in the above print screen the sixth item) it’s indicated that there are multiple… We only have one management group so why should there be multiple?
If you open the value you get a drop down box with the 2 id’s listed
So which one is the correct one…
I opened a newly created report in the same management pack (which I recreated to solve the issue with the first report) and there there’s only one ID listed:
This report is working with all the parameters so this ID is the correct ID for our management group.
Next step is deleting the ”wrong ID” in my report parameters and click ok:
Now we go back to our SCOM console and check the report once more.
Open the report and now it’s possible to check the Data Aggregation and Histogram again.
After clicking “run” the report is generated successfully.
So all we need to do is change the parameters in our scheduled report.
Navigate back to the scheduled reports list, right click the report and choose edit.
Check the parameters and fill in the correct Data Aggregation / Histogram settings (and check the other settings as well while you’re at it).
Click finish and check back at the scheduled report view.
The report has gone from error to “ready” and is able to process when the scheduled time is there…
In this particular case it apparently was an issue when there were agents temporarily multi homed to a test environment and this test environment was deleted afterwards.
Although this was a mistake on our side I posted this blog post to illustrate that the error message in SCOM was not the cause of the real problem which was hidden in the SRS installation. This threw me off when troubleshooting the issue because I was focusing on the wrong error and has cost me a lot of valuable troubleshooting time.
I’ve posted my experience to save you some time in troubleshooting the issue