Today I bumped into an interesting issue. The customer needed to restrict access to the SCOM environment a SCOM Operator role and in addition access to the SCOM reports in the console. Therefore I created the SCOM Operator role with the needed permission and I also created a Report Operator role and added the user into both roles. Just to point out, the role permissions in SCOM are cumulative, meaning the sum of permissions is the final permission for that user. Finally I tested it with the customer and found an empty reporting pane like this…
If you are familiar with the reporting functionality, you know that reporting is communicating over http (port 80) or https (port 443). In my case it was configured to use http.
So I started troubleshooting…
- Checked proxy server settings on the client
- Checked permissions for the user again
- Verified reporting services permissions and functionality
- Checked ReportViewer installation
- Checked SCOM console installation
- Checked software installed on the client
- etc.
After I made sure that the problem must be client related, I asked the customer to login to a different client. The user could login to a another client and the SCOM reports would appear in the SCOM console.
Finally the problem was solved by adding the FQDN in SCOM under Administration/Settings/Reporting.
The bad configuration was like this…
changed to…
http://Server.domain.com/ReportServer
The actual problem was that it was a multi domain / multi forest environment and there was no DNS suffix for clients configured. Because of that, the client could somehow not resolve the flat reporting server name. The reporting server was located in a different Active Directory trusted forest. By changing the server name to FQDN which will use DNS to resolve the server name everything worked well.
Conclusion: Always use FQDN if you need to provide server names, don’t just add “flat” server names.
I have also seen proxy enabled in IE (and a proxy server is actually used) can cause the reports window in opsmgr console to not populate.
Hi Scott,
Thank’s for your comment.
Yes you are absolutely right. There are many more issues that can occur besides the one I posted as reporting depends on so many Technologie layers like http, network layer, application (SSRS) and so on…
Cheers,
Stefan
How would you solve this issue if it is caused by proxy.
In our case Proxy is used for internet access so cant remove that
Solved this one , I had to open IE under the Credentials of the admin user who was running the console from a client machine and then set the correct proxy in.
thanks
You are good. The moment i added the FQDN in SCOM under Administration/Settings/Reporting. I was able to view the reports after restarting the Operations Mgr console. Thanks!!