In the past couple of weeks, I've started to get (on a more and more regular basis) errors with sending emails via scheduled subscriptions in SSRS 2016 (on Windows Server 2016). The error I'm seeing is:
ERROR: Error sending email. Exception: System.Net.Mail.SmtpException: Failure sending mail. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
This doesn't happen every time. For example I've got a report that should have been sent at 1pm - it failed with the above error but as SSRS retries every 15 minutes it actually got sent 30 minutes later.
From what I could find by googling, this might in some way relate to TLS 1.2 - but I can't see anywhere in SSRS where you define what it should use. I upgraded the .NET Framework to 4.8 but that has made no difference.
Any help would be greatly appreciated!
The issue turned out to be with TLS and the server configuration.
To fix it, I disabled TLS 1.0 and 1.1 - I also added the following keys to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
Related
I was working on my .NET Core Project in Visual Studio with MYSql as DB. Accidently I faced Issue while fetching any data 'Got timeout reading communication packets' on every API Call. But later I came to know that I am facing this issue on particular API address. because when I connected to my another network(mobile hotspot) It was working properly? How can I resolve this?
We currently have an issue where the report subscription is not being started by the linked SQL Agent Job. The SQL Agent job runs on the correct schedule, completes successfully but the report subscription itself does not start. This is happening across a few of our subscriptions, all of which are data driven.
Checking the SQL logs there's no errors, there are no errors in the event viewer and there's no errors in the report manager logs, in fact, when one report was supposed to run at 6:19 there was no entry in the report manager logs at all, but when I re-ran the subscription later it ran fine and then put an entry in to the report manager logs. (Re-running the subscription doesn't always work first time)
From everything we have looked at the issue appears to be that the Agent Jobs triggers the request for the subscription to run but the subscription does not start, I'm not sure if the request is even making it to the report server, but given there is no failure logs on the report server I'm leaning towards the request not making it.
Has anyone else experienced this issue?
For reference this is on SQL Server 2016 with SSRS 2016.
TIA,
Matthew
It looks like upgrading to "SQL Server 2016 CU13" is going to solve the problem, still testing but initial signs looks good.
The working assumption is that the windows updates that installed recently required a newer version of SQL.
I have an application token. According to documentation
If you are throttled for any reason, you will receive a status code
429 response.
I have received no errors that I am being throttled. Sending requests from other servers are accepted just not the one that has been working fine up until today. What needs to be done to unblock my server and/or prevent it from reoccurring?
I installed version in 6.0.1 of MarkPieszak/angular-application-insights, imported the module and specified the right instrumentation key from my Application Insights App (type: node.js). A track is sent with status code 200 but I don't see any data shown in Azure.
https://github.com/MarkPieszak/angular-application-insights
Is there something I overlook here?
I was expecting exceptions to show up in the Failure Panel in Azure. Now I found out that in there only server side failures are shown. After looking under Browser in Azure I found the received exceptions I was looking for. My bad.
I'm facing a problem with a 3-tier application. It uses IIS and SQL Server. And the problem is that sometimes (longer requests cause higher probability) client does not receive response from IIS. It hangs when there is no activity ON SQL Server, and when even when I kill an SQL Process I get no response with an exception. When I examine data after these hangs I find that my SQL requests have succeeded, so the problem appears to be on IIS. Unfotunately I don't have much control over the place where the application is hosted and I cannot reproduce the problem. There can be many answers to this question, but at least I need a hint in what direction I should investigate.
UPDATE: I also have an app running on the same server that does a small job: it inserts around a 100 lines line-by-line into a database. Artificially I made it run for about 10 minutes (by putting xlock on the table). After removing the xlock the process on IIS continued running and successfully inserted those 100 lines. However, control never returned to the client thereafter, it just waited indefinitely. It looks like this is a problem when returning a response to the client after a long running process.
BTW, this is not a website, but a WinForms app that uses Remoting.
If you're sure that SQL Server is returning to IIS, then you might want to check the IIS logs to see what might be happening to the request. The normal location for these logs is %SystemRoot%\system32\Logfiles\<service_name>.
If you're not sure about SQL Server, you might access the SQL logs, run Profiler, or check the Windows system logs for errors, run your site in debug in Visual Studio or add your own logging to your app to figure out which step it's hanging on.
I have finally figured out where the problem is. The application is run on a web farm and there is a balancer server between the client and IIS. There was a too small timeout on the balancer. For some reason it is not quite friendly with .net remoting and it doesn't return any timeout exceptions to the client. The issue has been solved by increasing the timeout.