The Hammer for your Power BI Report Server Issues

For many IT admins, troubleshooting a Power BI Report Server can be a daunting task. With so many potential sources of error and so much data to collect, it can be difficult to know where to start. Fortunately, the Power BI Report Server Troubleshooting Tool is here to help.

Think of this tool as a giant hammer in your toolbox, ready to take on any nail that needs to be driven down. The hammer I provide is certainly not the right tool for all issues with Power BI Report Server but, I hope you will be able to address many of the nails / issues needing to be fixed. To be clear “the tool is not fixing anything, it is just collecting data”. This troubleshooting tool is designed to make your life easier with automating a majority of the collection of data you would do either way. This data is coming from various sources, therefore might also give you an idea about things to investigate which you have previously not considered.

The best part? It’s incredibly easy to use. All you need to do is download the script and execute it on your report server machine. Assuming you have the “reportserver” database on your localhost, everything should work just fine. Even if that’s not the case you will either way get prompted for various variables you could modify or not.

One important caution to keep in mind is that the script is designed to collect everything. Depending on the number of log files and rows in your executionlog, it may take some time to finish. However, the good news is that all of the scripts included in the tool are a great starting point for troubleshooting a wide range of scenarios.

So, what exactly does this tool collect? Here’s a quick rundown of what you can expect to be collected:

  • Executionlog3 view: This view provides a wealth of information about the execution of your reports, including data about the report itself, the user who ran the report, and any errors or warnings that were encountered.
  • Event table: This table contains a detailed log of all the events that have occurred on your report server. Normally this table should be empty, if that’s not the case you have most likely an issue or at least a backlog most likely with refreshes/subscriptions.
  • ConfigurationInfo table: This table contains information about the configuration of your report server, including settings related to email delivery, security, and more.
  • Subscription and schedule refresh last status: This script collects data about the last status of your report subscriptions and schedule refreshes. This is incredibly helpful to identify if end users created a subscription potential harmful for your report server, either because of errors or because of potentially unnecessary frequent scheduling.
  • Subscription and Schedule Refresh History table: This table contains a log of all the subscription and schedule refreshes that have occurred on your report server, including information about when they occurred.
  • Rsreportserver.config file: This file contains configuration settings for your report server, including information about database connections, security settings, and more.
  • All “.Log” files, trace and dump files are excluded. Log files are capturing almost every traffic happening to your report server. In the biggest majority of the cases if you see an issue in Power BI Report Server you will find here more details about this. Since the log files are an unstructured log file, having a timestamp is essential.
  • Timestamp of error from user input: This allows you to focus on specific errors or issues that you have encountered and make sure you focus during your troubleshooting on the right issue.

While this collection of data is certainly comprehensive, it’s important to note that the script could be elaborated to further scenarios, such as troubleshooting Kerberos, SSRS, or performance issues. This is just the start of this tool and I looking forward if someone takes it further with a different hammer or makes this hammer even bigger.

In conclusion, the Power BI Report Server Troubleshooting Tool is a valuable addition to any IT professional or developer’s toolkit. It simplifies the process of collecting data and provides a great starting point for troubleshooting a wide range of scenarios. So why wait? Download the script and give it a try today.

Power BI Report Server Monitoring Tool

As a support engineer, we often receive requests for usage, audit, or monitoring reports for Power BI Report Server. Sometimes, there are support requests, users could easily self-resolve themselves if they would just have the right tool. For Power BI Service there are audit and monitoring templates available, but for Power BI Report Server there is not much or at least to my knowledge nothing publicly available.

Hence, that’s why I hope the following work in progress pbix will be beneficial to you: https://github.com/KornAlexander/PBI-Tools/blob/main/PBIRS/PBIRS%20Monitoring.pbix

The report consists of three pages (WIP)

  1. Report Inventory & Usage Stats
  2. Schedule Refresh and Subscription Overview
  3. General Config Information

1. Report Inventory & Usage Stats

The first page is the most comprehensive one, with the highest information density, providing a report inventory and display for usage statistics at the same time. You could definitely consider separating the usage statistic from the report inventory.

Depending on the objective of analysis you have the option to switch the table with a bookmark navigation button to focus on users or reports.

This report page is also great to investigate the report which have rarely never or not lately been used. To define which unused reports you want to display I recommend to use the bottom right slicer. In case you have reports, which have never been open with an “interactive request” once, there is a separate slicer for this as well.

One main asset of the pbix is the following sql script for the purpose of building a catalog table. The sql script combines information from various tables into one catalog dimension for all of your items in your report and has the very most properties of each item.

2. Schedule Refresh and Subscription Overview

The second page is for subscription and schedule refresh already discussed in a previous article: Power BI Report Server Monitoring for Subscriptions and Schedule Refreshes. New here is on the bottom right corner the number of lines in the event table. The bigger the number the more likely you will be having an issue with a big backlog. Depending on the nodes you have this might take shorter or longer to catch up. In case you have not multiple nodes through scale-out deployment available, the server will be able to start 6 events (schedule refreshes or subscriptions) per minute.

3. General Config Information

The third page is nothing special, just some report server configurations, which you can easily see and adjust in the advanced properties of the report server.

More Info about the PBIX and how to get started.

All queries in the report use direct query mode, so there’s no need to refresh, and your monitoring is always up to date. To make the report work for you, replace the database parameter “ReportServer” with your database name. The report should be opened on your report server machine, since it is using server localhost. The report was created with Power BI Desktop for Report Server on Sep 22, so you should be able to use and publish it to your report server. Instead of a sql view in the database I chose to add the date dimension under utilizing the the system table “master..spt_values” starting from 2020 till the current date.

References and sources for report

  1. I want to give a shout out to Nikola Ilic for providing input for this pbix file through his blog post: Check Power BI usage metrics on Report Server! – Data Mozart (data-mozart.com)
  2. The pbix includes the job overview also already published in one of my previous blog posts. Essentially it incorporates the report into this report, but focuses just on report server: Power BI Report Server Monitoring for Subscriptions and Schedule Refreshes
  3. Info for the catalog dimension in regards to the report server’s internal analysis services instance and its related information was taken from Pedro Salinas-Ruiz blog Power BI Report Server Query to List Power BI Reports – Business wIntelligence
  4. There are various documentations how to get an overview of subscription and schedule refreshes such as the following community discussions: info1, info2 , but Filipe Caetano made me aware of a script which is used for one of the two overview tables in the subscription/schedule refresh page

Taking the report further

I am sure the report still has a lot of potential. It could be enhanced further if the decision would be made to divert from direct query connection to import connection mode. This would enable to integrate data from various other sources, such as report server log files, the rsreportserver.config, powershell or WEB API calls.

Furthermore there is quite some potential to optimize the sql queries even further. For example one could merge the subscription/schedule refresh dimension with the catalog dimension.

For sure visualization and report design wise the report is definitely not where I would like to have it. for example this monitoring report is definitely not IBCS compliant, but I would be happy to see someone taking it in this direction further.

Ask for a Power BI Report Server Assessment

In case you want to know more about this topic, I highly recommend that you reach out to a Microsoft representative in your region, such as your Customer Success Account Manager, for assistance and ask for a Power BI Report Server Assessment or for a Power BI Service Assessment potentially available to you.

Please send me Feedback

If you found the pbix helpful or if you have any feedback I would be happy to hear about it. Feel free to ping me via the channel that suits youi.

Also if you are able to develop the pbix further, I would be super happy if you send me your version back.

Power BI Report Server Monitoring for Subscriptions and Schedule Refreshes

As a Power BI Report Server Administrator, it is crucial to monitor the performance of your report server and keep track of your subscriptions and schedule refreshes. Inefficient utilization of report server capacity is a common issue, for instance, when there are specific periods of high server load and others with minimal activity. This can be a caused by schedule refreshes and subscriptions set up to be triggered all at the same time. This article explores how you can make use of a Power BI report, the job agent, and Power BI Report Server’s database table to visualize potential bottlenecks.

Thanks to Frederik Bogaerts, making me initially aware of this Power BI report and thanks to a blog post from Mattias de Smet, I was able to modify this Power BI report for monitoring not only the SQL Server Agent but also on a separate tab the Power BI Report Server. The main addition to Mattias’ report is that the main objective of my report is instead of monitoring only the SQL Server Agent I wanted to monitor the Power BI Report Server’s schedule refreshes and subscriptions as well. Nevertheless the pbix file and detailed description provided by Mattias was particularly helpful in getting started.

Inspiration for this report also came from Ganttchart’ paginated report blog post about “Visualizing Power BI Report Server Refresh Schedule”, which is particular good if the environment to monitor is a SQL Server Reporting Services and not a Power BI Report Server. This is due to the fact that Pedro’s WIP solution is a paginated report. Just like Pedro’s paginated report, also this solution is based on the dbo.SubscriptionHistory table.

Theoretically the SQL Server Agent could also be used to monitor the report server, with the exception that the report server’s jobs in the SQL Agent have a GUID, which need to matched with the report server’s database tables. Furthermore in my repro, the SQL agent cleared the history when modifying or deleting the schedule refreshes and the duration in seconds of the jobs were not captured.

This solution is work in progress and needs to be taken further for sure, not only by monitoring all jobs, PBIRS, SSAS, SSIS, but even more importantly with further analysis of the Power BI Report Server’s database tables, such as the ExecutionLog3 View. One additional requirement is that if you want to see jobs of all services in the report, you would need to run those on the same machine. If this is not the case, like in many environment, an ETL pipeline would need to be set up to consolidate the different services. I would be interested to see if someone can take this approach further.

There are quite a few further checks and Power BI Report Server Monitoring which could be included in this report.

Instructions How to Set Up the Report

Step 1: Download and Open the Power BI Desktop file on your Power BI Report Server and authenticate against your SQL Server.

Download and open the following .pbix file here: https://github.com/KornAlexander/PBI-Tools/blob/main/PBIRS/PBIRS%20Job%20Monitoring.pbix

Make sure to open the report on the report server machine, since it is using localhost to connect to your database.

Step 2: in Power Query –> Change “ReportServer” to match your database name

Go into PowerQuery and modify the SQL Statments to match the name of your report server database name. In my case the name is “Report Server”, you might have a different name of your database. Once you have changed this you should be done and good to go.

Optional: Step 3: Creating a SubscriptionsAndScheduleRefreshes VIEW Used in the following script and for PBIRS Monitoring

The following steps are optional and only need to be applied, in case you want to see your Power BI Report Server jobs from the SQL agent and not from the database, as well as SSAS or SSIS jobs potentially on your SQL Server Agent.

In this step, we will be creating a view called “SubscriptionsAndScheduleRefreshes” in the “ReportServer” database. This view will be used by the subsequent view “Job_Step_History_Analysis” and therefore needs to be created first.

/*CREATE Or ALTER View SubscriptionsAndScheduleRefreshes
This view selects the ReportID, ScheduleID as JobName, and Path columns from the dbo.ReportSchedule, dbo.Schedule, and dbo.[Catalog] tables. 
The script uses the WITH (NOLOCK) hint which allows the query to read data from tables that are being used by other queries. 
The script joins the tables on the ScheduleID, and ReportID columns respectively.*/

USE [ReportServer] --change this line to the report server database name
GO
Create OR ALTER View [SubscriptionsAndScheduleRefreshes]
AS
SELECT rs.ReportID
,REPLACE(REPLACE(s.ScheduleID , '{', ''), '}', '') COLLATE SQL_Latin1_General_CP1_CI_AS AS JobName
,cat.[Path]
FROM dbo.ReportSchedule rs WITH (NOLOCK)
INNER JOIN dbo.Schedule s WITH (NOLOCK) ON rs.ScheduleID = s.ScheduleID
INNER JOIN dbo.[Catalog] cat WITH (NOLOCK) ON rs.ReportID = cat.ItemID

The “WITH (NOLOCK)” statement is used to prevent the view from being locked while it is being queried.

Optional Step 4: Creating a View for “Job_Step_History_Analysis” for Analysis of SQL Agent

In this step, we will be creating a view called “job_step_history_analysis” in the “msdb” database. The view is made up of data pulled from multiple system tables such as “sysjobhistory”, “sysjobs”, “syscategories” and joined with the synonym “SubscriptionsAndScheduleRefreshes” created in step 2. It uses a common table expression called “job_history” to select various columns. The view then Selects from the “job_history” CTE to produce the final output.

USE [msdb]
GO

/****** Object:  View [dbo].[job_step_history_analysis]    Script Date: 1/20/2023 9:31:18 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

/*Create or ALTER VIEW job_step_history_analysis
This view selects various columns from the sysjobhistory, sysjobs, syscategories, and SubscriptionsAndScheduleRefreshes tables. The script uses the Common Table Expression (WITH) to define the job_history table. 
The script filters for enabled jobs and excludes steps with step_id = 0. 
The script also calculates various duration statistics and calculates the percentage increase of each duration from the average. The script also selects the error message if the job outcome is 'Failed'.*/

CREATE OR ALTER   VIEW [dbo].[job_step_history_analysis]
AS 

WITH job_history AS 
(SELECT SJ.[name] AS [Job],
        SJH.step_name [Step],
        SJH.step_id [Step Order],
        C.[name] AS [Category],
        msdb.dbo.agent_datetime(SJH.run_date, SJH.run_time) AS [Start Time],
        CASE
           WHEN SJH.run_status = 0 THEN 'Failed'
           WHEN SJH.run_status = 1 THEN 'Succeeded'
           WHEN SJH.run_status = 2 THEN 'Retry'
           WHEN SJH.run_status = 3 THEN 'Cancelled'
           ELSE 'Unknown'
        END [Job Outcome],
        SJH.run_duration % 100                           -- seconds
             +(SJH.run_duration / 100) % 100 * 60        -- minutes to seconds
             +(SJH.run_duration / 10000) % 100 * 60 * 60 -- hours to seconds
          AS [Duration In Seconds],
        IIF(SJH.run_status = 0, SJH.[message], '') AS [Error Message], --select error message if job failed
        S.[Path]
FROM [msdb].[dbo].[sysjobhistory] SJH
      JOIN [msdb].[dbo].[sysjobs] SJ ON SJH.job_id = SJ.job_id
      INNER JOIN [msdb].[dbo].[syscategories] C ON SJ.category_id = C.category_id
      JOIN [ReportServer].[dbo].[SubscriptionsAndScheduleRefreshes] S ON SJ.[name] = S.[JobName]
WHERE SJ.enabled = 1 --filter for enabled jobs
  AND step_id <> 0 --exclude steps with step_id = 0
 --AND SJH.run_duration > 0 --jobs with less than a second are not disabled
)

SELECT [Category],
       [Job],
       [Step],
       [Step Order],
       [Start Time],
       [Job Outcome],
       [Duration In Seconds],
       MIN(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Min Duration In Seconds], 
       MAX(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Max Duration In Seconds], 
       AVG(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step) AS [Average Duration In Seconds], 
       Case When job_history.[Duration In Seconds] = 0 THEN NULL
       Else ((1.0 * [Duration In Seconds] / (AVG(job_history.[Duration In Seconds]) OVER (PARTITION BY Job, Step))) - 1) END As [Pct Increase],
       [Error Message],
       [Path]
FROM job_history;
GO

The following is only informational: The following select statement is already automatically included in the Power BI report, therefore it is not needed to actually execute this select statement. I found it helpful for troubleshooting and therefore am including it here. I also included a Where statement to filter out for the jobs of the Power BI Report Server, so in case you are looking for SQL agents jobs from Power BI Report Server you won’t find them, but you already should have them from the historysubscription table.

This SELECT statement selects various columns from the “job_step_history_analysis” view created in step 3. Additionally, the script applies several IIF and CONVERT functions to the “Min Duration In Seconds”, “Max Duration In Seconds” and “Average Duration In Seconds” columns to convert their values from seconds to a more human-readable format (hours, minutes, seconds). These converted columns are named as “Min Duration”, “Max Duration” and “Average Duration” respectively.

/* Documentation: This select statement selects various columns from the job_step_history_analysis view 
and formats the duration columns to be in Hours, Minutes, and Seconds. 
It also selects the Pct Increase, Error Message, and Path columns from the view.*/

SELECT
	[Category], 
	[Job], 
	[Step], 
	[Step Order], 
	[Start Time], 
	[Job Outcome], 
	[Duration In Seconds],
	[Min Duration In Seconds],
	[Max Duration In Seconds],
	[Average Duration In Seconds],
	IIF([Min Duration In Seconds]/60/60>0,	
		CONVERT(VARCHAR, [Min Duration In Seconds]/60/60) + ' Hours ','') + 
		IIF([Min Duration In Seconds]/60> 0,	
			CONVERT(VARCHAR, [Min Duration In Seconds]%3600/60) + ' Minutes ','') + 
			CONVERT(VARCHAR, [Min Duration In Seconds]%60) + ' Seconds' AS [Min Duration],
	IIF([Max Duration In Seconds]/60/60>0, 
		CONVERT(VARCHAR, [Max Duration In Seconds]/60/60) + ' Hours ','') + 
		IIF([Max Duration In Seconds]/60> 0, 
			CONVERT(VARCHAR, [Max Duration In Seconds]%3600/60) + ' Minutes ','') + 
			CONVERT(VARCHAR, [Max Duration In Seconds]%60) + ' Seconds' AS [Max Duration],
	IIF([Average Duration In Seconds]/60/60>0, 
		CONVERT(VARCHAR, [Average Duration In Seconds]/60/60) + ' Hours ','') + 
		IIF([Average Duration In Seconds]/60> 0, 
			CONVERT(VARCHAR, [Average Duration In Seconds]%3600/60) + ' Minutes ','') + 
			CONVERT(VARCHAR, [Average Duration In Seconds]%60) + ' Seconds' AS [Average Duration],
	[Pct Increase], 
	[Error Message], 
	[Path]
FROM job_step_history_analysis
Where [Category] <> 'Report Server'