A long time ago, I learned while troubleshooting SQL Server Reporting Services (SSRS) reports. That your first step is always to open the report in a browser. Why? If it doesn’t work there, then there is no point in trying to access it via the console. Why because the console gets everything from SSRS. But, when you are not troubleshooting, is there an ideal spot to access reports from? Is accessing ConfigMgr reports the best from the browser or the console? Here’s my advice: ideally, you should always access reports in a browser because this avoids console overhead. I will explain the reasoning behind my recommendation in this blog post.
In the case of Power BI reports, I know that you can only open them in a browser because there isn’t a Power BI viewer in the console. However, you can still run a query from the console that lists all of the reports. This affects console overhead. With SSRS reports, not only can you run a report from the console, using the report viewer. But you can open the web report from the console. Only if you happen to be in the console would I ever be okay with accessing SSRS reports from there. But even then, I personally try to avoid it.
Accessing ConfigMgr Reports – Console Overhead
This might seem counter-intuitive, but it actually takes longer for SSRS and Power BI reports to load within the console when compared to the browser. This is where you might question my thinking. You could argue that the time is less than I think or if I’m not already in the console, of course, the time is slower. Hear me out.
What is the overhead? In the console, every time you access the Reports node, the MECM console queries the SSRS server or the Power BI Report Server (PBRS). It queries for all SSRS or Power BI reports and returns the list to your console. I’m sure that you are very familiar with the circling donut, “Returning list items…” as shown in the image above.
Too Many SSRS Reports
When you hit the too many results issue you must click on the OK button in order to rerun the query in the SSRS server or PBRS again. Just imagine if this was a slow network link too. As more folks work from home, including Enhansoft’s staff, having a slow network connection is a greater possibility. For example, one of our developer’s 10 Mbps internet connection really slowed down their productivity.
Once the list of reports is loaded within the console then you are given the option to Run in Browser or in the console – Run.
Notice that you get the same querying delay for Power BI reports too?
When the reports are loaded in the console, your only option is to run a Power BI report in a browser. Power BI Reports are only run via the browsers. In the case of Power BI reports, the console overhead is twice as much as what you would expect if you accessed these reports directly from the website.
Other Issues Using the Console
What other problems are there accessing reports via the console versus a browser? For the most part, there were a number of issues, however, most were cleared up. But, one outstanding issue remains: MANAGERS. I say managers, but really it could be anyone who needs to see reports or details from ConfigMgr. There are a couple of issues with this:
- Do you really want to take the time installing the ConfigMgr console on someone else’s computer just so they can view reports?
- Are you prepared to have a non-ConfigMgr Admin upgrade the console every 4 months? They would need to do this in order to access reports that could be easily seen from a browser.
If everything is coming from either the SSRS server or PBRS anyways. Then why not start from the server in a browser first?
Here’s my advice: If you are already within the console, then sure access the reports from there. But, if you need to see the report’s details then just jump directly to your SSRS server or PBRS and access the reports there. Remove the console from the equation.