We are using Power BI Report server to publish Power BI Reports internally. And being in Australia we use a “sensible” date format of dd/mm/yyyy
However at a recent showcase with some of our end users they commented that our date format was “backwards” ie. mm/dd/yyyy
If you are using US regional settings on your PC you probably have not come across this issue, but for other regions this can be a problem.
Upon getting back to my desk I checked the report in Power BI Desktop and the date format was correctly picking up my local regional settings. I then opened the report in IE (which is what most of our End Users have as a default browser) and the report was still using the Australian format (dd/mm/yyyy):
However when opening the same report in Chrome or Firefox the date was using US regional settings (mm/dd/yyyy):
After doing some google/binging I found that both Chrome and Firefox have their own internal regional settings dialog and they both default to using US settings.
If you go into the Settings menu in Chrome and search for “Language” you will find the following, and it’s not just the default display language that matters the order is also important. Moving “English (Australia)” to the top of the list, then deleting cached images and files fixed this issue.
Clicking on the 3 dots to the right of the language gives you an option to move that language to the top.
Firefox has a very similar language dialog and the same fix works for it too.
If you’ve ever worked with Power BI Report server there is a handy button in the top menu that says “Edit in Power BI Desktop”.
And as you would expect this button will open the report you are currently viewing in Power BI Desktop where you can edit it. All in all a very handy button, particularly when you get sent a link to a report and get asked to help fix something or explain some data issue.
However recently I started seeing the following error stating “Server is not reachable” any time I tried to use this button
This is a bit strange as I’ve used this button many times before. So I tried going another way and using to File > Open in the Report Server version of Power BI Desktop and tried to open the report from the Report Server that way.
However I was again met with the same “Sever is not reachable” error which is not very helpful as I was definitely able to reach that server and view reports on it.
When this first happened I just went back to the tile view in the Report Server portal and chose the download option from the “…” menu on the report, then I was able to open the local copy and sort out the issue I had been asked to look at.
But today it happened to me again and I decided to do some digging to see if I could get to the bottom of this.
An initial solution
Doing some searches turned up a number of people hitting similar issues.
There was this one where the person was trying to connect using the webservice url instead of the portal url. But I knew that was not the issue in my case.
Then I stumbled across this one which suggested adding your credentials to the Windows Credentials section of Credential Manager. This actually worked for me, but I was not overly happy with this approach as in a few month time when my password expires I’d have to remember to come in here again and update my password. The more likely scenario would be that I would forget to do this and a few weeks later I’d realise that the “Edit in Power BI Desktop” button had broken again.
However while I was in the Credential Manager I clicked over to the web credentials and noticed the following interesting entry that started with SsrsSessionResourceKeyPrefix…
I knew that Power BI Report server was built on top of the old SSRS portal and when I expanded the entry it showed that these credentials had been saved by “Power BI”.
The Final Solution
Removing this entry and also removing the entry I just added to the Windows Credentials section fixed the issue properly. Now I don’t have to update a stored password and both the Edit in Power BI Desktop button and the File – Open option are both working as they should.
Last week I came across an issue where a number of our paginated report subscriptions at work failed to go out. When we checked in the Portal these subscriptions had a status of “Pending”. This happened on our production Power BI Report Server instance which is currently running the Sep 2019 release.
This was very strange as these subscriptions had been running for months and months without issue and just stopped all of a sudden. It was even more confusing as we had some reports with multiple subscriptions and some of the subscriptions were still working while others were stuck with a status of “Pending”.
With no other information to go on in the Portal I started looking through the log files. This was complicated in our case as we have over one and a half thousand users and hundreds of report subscriptions. We also have 2 instances of PBIRS (Power BI Report Server) behind a load balancer which means two sets of log files to search through.
So I started by going to one of the pending subscriptions and clicking on the edit option
When you do this you will see the URL change to something like the following where there is a guid at the end with the SubscriptionId:
By default PBIRS writes a number of log files out to a folder at C:\Program Files\Microsoft Power BI Report Server\PBIRS\LogFiles If you look in this folder it will look something like the following with a bunch of different files with date stamps on the end. In this case because the issue is with a paginated report we need to look in the ReportingServicesService*.log files
What I found in one of the log files when I searched for the subscription Id was the following error
Error processing data driven subscription a743db7f-bbbe-4c45-9da1-2e2e286992dd: Microsoft.ReportingServices.Diagnostics.Utilities.UnknownUserNameException: The user or group name '<domain>\<contractor user>' is not recognized.
Where the <domain> was our company’s AD domain and <contractor user> was the login that had been used by a short term contractor that had worked with us to build the report in question.
In our case the account in question had been disabled when the contractor left the organization. So obviously nothing was checking the enabled state of this account.
But as it turns out that our AD team had done one of their periodic clean-ups yesterday where they actually deleted a whole group of disabled accounts. So it appeared that this was related somehow to this account no long existing in AD.
We already knew from years of working with Reporting Services that when a subscription is executed that the Owner of the subscription is checked to make sure a valid account is specified. (I believe this is possibly a security measure to stop people setting up a schedule to send reports to somewhere after they have left a company). However we already had the contractor set the subscription owner to one of our service accounts when they created the subscription to try and prevent this very scenario from happening.
In fact searching through all the properties for the subscription in the portal showed no sign of the <contractor user> account anywhere.
At this point I decided to open up a PowerShell window and use one of the tools from the ReportingServicesTools PowerShell module to see if that could shed any more light on this issue.
When I ran the Get-RsSubscription cmdlet I noticed the following:
Sitting in the ModifiedBy property of the subscription object was a reference to our <contractor user> which we were seeing in the error in the log file.
When running Get-RsSubscription against a report where some subscriptions were working and others were stuck in a “Pending” state I could see that the working subscriptions had a ModifiedBy of an account belonging to someone who still had an active account in AD.
My guess as to what is happening here is that Report Server is attempting to populate some of the properties of a user object from Active Directory and is failing now that the users has been physically deleted and this is throwing an exception that is preventing the entire subscription from continuing with it’s execution.
So if you only have a handful of subscriptions stuck in a pending state like this you can just edit them in the portal and make some non-functional change like adding a full stop to the end of the subscription name. This will set the ModifiedBy to your user account and the subscription will start working again.
In our case we took a backup of the ReportServer database and then ran an update statement to set the guid of the ModifiedBy to the guid of our service account user. This is not a supported activity and something you would do at your own risk. But in our case it did allow us to quickly fix numerous “broken” subscriptions that would have taken hours to fix through the UI.
Power BI Report Server needs an Admin Portal
I think one area where Power BI Report Server could do with some more work is in the area of administrator tools. At the moment if a report fails to render because of an error you have to wait for a user to report it. And if a subscription fails to send there is no central place where you can see these issues and easily take steps to correct them.