June 15, 2020 at 7:57 pm
We have noticed in the past that if we disable TLSv1.0 in HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols\TLS 1.0\Server\Enabled (set to 0), most functionality still works in SSRS, but "My Subscriptions" fails to load, giving the not-very-descriptive error: "An error has occured. Something went wrong. Please try again later." Upon changing the setting to 1, "My Subsriptions" works as it should. This happens using either Chrome or Firefox.
We had hoped that a new installation would make this problem go away, but have discovered that this is not the case. Any ideas how to troubleshoot this and/or how to fix it? Thanks.
June 15, 2020 at 9:20 pm
Step 1 - check the logs. SSRS logs, SQL Server logs, and Windows event logs. One of those will have more information about the error.
If the logs are not helpful, you have SSRS 2016 installed, correct? Not just SQL Server 2016 as the database with SSRS 2014 or older connecting to it? Or the opposite where you have SSRS 2016 with SQL Server 2014 or older as the database backend? If so, I would get both up to matching versions.
Do you have .NET 4.6 installed on the server?
Got my information for the above from:
https://www.mytecbits.com/microsoft/sql-server/disabling-tls1-ssl3-affects-sql-server
If you are on SSRS 2014 or older, you either need to upgrade OR do some non-recommended changes to make it work.
I would still start with the logs. SSRS logs, SQL Server logs, and the Windows event log. One or more of those should have more details about the error.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
June 25, 2020 at 8:47 pm
Sorry it took so long to reply - I got distracted with other projects but am now focused on this. This is a new installation of SQL Server 2016 Standard Edition with SSRS on the same server. Also, I just verified that we have .Net 4.6 installed.
I've browsed the SQL Server and SSRS and System and Application logs, but really I have no idea what I'm looking for and nothing really jumped out at me. I am trying to get a window of time where I can turn off TLSv1.0 and reboot the server, then take note of the time and then attempt to access "My Subscriptions", then search the various logs around that time, but it would be helpful if I knew what I was looking for. Thanks for any suggestions.
June 25, 2020 at 9:03 pm
As to what is in the logs, that I am not sure. I don't know what specific error messages will pop up, but the log will tell you exactly what the error is.
The error in a user interface for any well written software should be friendly; which is what you saw. That "Please try again later" error. Software used by end users generally has friendly errors like that; like a 404 page on a website.
But the "friendly errors" are not helpful for developers and support teams. Well, written software should be logging any errors like that in a log somewhere which the developer/support person should investigate.
Now what I would start looking for is the word "ERROR". Start at the end of the log, ensure the log has data from past the time the error came up, then start digging. It might be a permission error, could be an authentication error, could be some weird network packet error, could be missing or untrusted library, could be something I'm not thinking of. Since the application (SSRS web site) is saying it is an Error and not a warning or information popup, searching for "ERROR" (or "error" or "Error" if it is a case sensitive search), searching from the latest entry backwards until you find the error that caused that popup.
But if you are looking for what EXACTLY to look for, that would be the timestamp. Look at the timestamp a few seconds before you clicked the button and got the error to a few seconds after. The error should be logged right around the same time it is presented to you.
If you have a test system (or an MSDN/Visual Studio subscription), I would recommend replicating the environment in test and making changes there rather than getting downtime on live and testing there.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
June 25, 2020 at 9:39 pm
Good suggestions. I'll see if I can get a test environment up and running and post my results here next week.
June 25, 2020 at 9:55 pm
A test environment is good for this and for other things too.
If you want to deploy a report for an end user to test (for example), this works great! Or if you are planning on upgrading (2016 to 2019 for example), doing it on test to make sure it works and to get a good working upgrade document is very beneficial.
A good argument for it if the business won't let you build a test environment is to ask them how long they can survive with the report server being offline or a critical report not working? It is very easy to test and document your upgrade process and be sure that nothing is busted when you are done on the test system, plus you don't need downtime or overtime to do a test server upgrade. Plus when you are asking for the downtime for an upgrade, if you have upgraded the test system and documented it, you have a good timeline for an upgrade and thus a good timeline for the overtime (if applicable). And if problems DO come up, you have (hopefully) fixed them on test, so the downtime and overtime window will be minimized. Last thing you want is to plan 2 hours to do the upgrade and have a weird bug come up that keeps you occupied (researching, testing, changing things) for hours or days trying to get support. I've personally not hit a "multi-day" outage before, but there are times when upgrading test, I do it over a 2 or 3 day window simply because I have other things to do. start the upgrade, then forget about it until the next day and do the next step(s). On live, I do a lot more babysitting and as soon as step 1 is done, I start step 2 to minimize the outage time and the overtime.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply