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
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…
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.