After proudly presenting a non-functional reporting environment in my own home lab while giving SCOM training at a client, it was time to examine what exactly was going wrong. The next time I’d like to show my audience the usefulness of certain reports. Let’s face it – certain reports are irreplaceable if you want to visualize your data stream into SCOM. So, let’s get going!
Usually, when reporting issues arise, the whole reporting pane remains empty – the folders simply do not appear. This time, however, was somewhat different. The reporting pane opened just fine. Also, the folders I expected were present, but unfortunately (except for the Application Monitoring reports) all were empty:
Now, in my home lab, the reporting server was installed quite late. It’s safe to say most management packs were already imported before even installing the reporting server. Would it be required to reimport those management packs again before the reports get properly deployed? After testing, the answer seemed to be no. Also, I estimated all run as profiles/accounts to be configured as they should be. That would pretty much rule out the basics that can be configured from the SCOM console; time to examine the management server’s event logs.
Besides the usual errors that probably appear in every management group, one particular event in the Operations Manager log caught my attention.
“Failed to deploy reports for management pack with version dependent id ‘1cdbe0c8-cde6-77a3-f024-4a1a2970b24c’. Uploading or saving files with .PerformanceBySystem extension is not allowed.”
This event that goes by the ID of 31567, tells me that one of the more popular reports cannot be deployed in SSRS due to its extension. As far as I can remember this has not been different for a very long time. However, recently there was a change in the SSRS security options. Since SSRS 2017 version 14.0.600.1274, a new advanced setting was introduced with the name of AllowedResourceExtensionsForUpload. And currently I’m at 14.0.7116.41940.
As the name of this setting already makes you suspect, it will restrict us from deploying reports into SSRS, that do not match the supported file extension. So let’s open SSMS and connect to the SSRS instance to view its security settings. Right click on the instance, properties, and open the advanced tab.
Bingo! A nice variety of extensions is listed, but .PerformanceBySystem is not part of it. It’s an easy task to add, but considering the naming convention of these reports where most reports have a unique extension, you might want to disable this setting sooner than you think. So, in my case, it’s best to just add *.* to the list.
After being patient for a few minutes this was exactly the solution I was looking for. Not only are the folders populated, the reports that are contained by them now provide output!
Concluding
Certain older versions of SSRS might leave you with an empty reporting console along with HTTP error 500. Newer versions might leave you with empty folder in your reporting pane. Update SSRS to the newest version, add *.* to the AllowedResourceExtensionsForUpload settings in the advanced pane of your SSRS instance properties window, and you’re good to go! This issue, and fix, apply to SCOM 1807 and up; earlier versions are not compatible with SQL 2017.
At the very least, I can enjoy my reports again, and I hope you will too!
