Update: As it turns out, this issue is solved in CU#1 for SQL Server 2016 and later CUs (#2 and #3) and in SQL Server 2016 SP1 as well. To be more specific, KB3172981 ‘FIX: Home page of SSRS web portal becomes empty after you enable My Reports feature in SQL Server 2016’ fixes this issue.
Issue
In one of my test labs I am rolling out System Center 2016 on Windows Server 2016. Using core editions as much as possible in order to learn how to handle those systems. On one box though I had to install the GUI edition of Windows Server since it hosts the SQL Server Reporting Services (SSRS) 2016 instance for SCOM.
Afterwards I succesfully installed SCOM 2016 RTM Reporting. All went well, and soon the SCOM Console showed the Reporting ‘wunderbar’ and all the reports. Nice!
However, when I tried to open the web portal url of the SSRS 2016 instance, I got this error: Could not load folder contents. Something went wrong. Please try again later.
This really surprised me since the SCOM Reporting component works great! Time for some troubleshooting.
How to troubleshoot SSRS 2016
Gladly SSRS 2016 logs by default quite a lot. The best approach is to clean up the ‘old’ logs and start fresh. This way you’re looking at the real issues at hand and not old issues.
Therefore I stopped the SSRS 2016 service on the problematic box (SQL Server Reporting Services ([SQL INSTANCE NAME])), SQL Server Reporting Services (MSSQLSERVER) in my case, and deleted all the logfiles present in the folder ~:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\LogFiles.
Then I started the SSRS 2016 service. When started two new logfiles are created:
- Microsoft.ReportingServices.Portal.WebHost_MM_DD_YYYY_HH_MM_SS.log;
- ReportServerService__MM_DD_YYYY_HH_MM_SS.log.
After starting the SSRS 2016 service, I started IE on the same box and opened the web portal url of SSRS 2016. And again I was thrown the previous mentioned error.
Time to check both logfiles. As it turned out only one logfile contained an error message, Microsoft.ReportingServices.Portal.WebHost_MM_DD_YYYY_HH_MM_SS.log: OData exception occurred: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentOutOfRangeException: The UTC time represented when the offset is applied must be between year 0 and 10,000.
A BUG?!!!
Time to Google! And soon I found this SSRS 2016 bug on Microsoft Connect:
What?! The SSRS box having this issue is set in the time zone UTC+1:00:
Could it really be this?!
Time to test it
So I set the Time zone to UTC without ANY offset:
Afterwards I restarted the SSRS 2016 service, and reopened the web portal url of SSRS 2016. Kabam!!!
So this is a serious bug!!! Sad to see that the bug is closed, reason being External:
And:
Basically meaning that SSRS 2016 out of the box doesn’t have this issue.
Just to be sure, I tested a new SSRS 2016 instance on a new VM (SSRSTestBug), with SSRS 2016 Reporting installed WITH UTC offset (UTC+1:00). On this the home folder of web portal url of SSRS 2016 is neatly loaded and shown:
CU#1 fixes this issue
A fellow MVP (Tao Yang) pointed out to me that he doesn’t experience these issues. But since he lives in Australia the SSRS server also has an offset. And yet it works for him.
As it turned out, he runs SP1 for SQL Server 2016. So I investigated and this issue is fixed in CU#1 for SQL Server 2016 and later CUs (#2 and #3). SP1 for SQL Server 2016 contains CU#3 (containing CU#2 and CU#1) and other fixes as well.
To be more specific, KB3172981 describes this issue and is folded into CU#1 and later, and SP1 as well. As a test I rolled out CU#1 which fixed this nagging issue. SP1 is scheduled to be applied later on.
Recap
The status of the bug report threw me off, since it didn’t show it was fixed, but ‘Closed as external’ instead. So apparently, this report hasn’t been updated accordingly.
However, at least I could have applied CU#3 for SQL Server 2016 at least, which would have fixed it for me. Of course, I could have rolled out SP1 instead. But I am always careful with rolling out SPs for SQL since they might break compatability with SC components.
No comments:
Post a Comment