We have been having issues for probably half an hour. Just get this
—> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
—> System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host.
I got that one too. Plus the normal “Low Disk Condition” error that we get all the time since August. Can you restart your task agent in the Cloud Mgmt Portal?
We have a ton of these in our SysMon:
Program Ice.Services.Lib.RunTask when executing task 3539548 raised an unexpected exception with the following message: RunTask:
System.Net.Http.HttpRequestException: An error occurred while sending the request.
—> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
—> System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host.
I see last nights maintenance went well.
I’ve got that too.
Sorry, I had gotten pulled into some other things. Our printing seems to have gone back to normal now (knock on wood)
We still have the issue. You can go through your systasks and see if you have users with it too or Display All.
Prism AI will solve this, I’m sure…
I added these errors to an already open EpicCare case from 01/22. Below is their response from today:
Hello Billy,
I apologize for the delay in following up with you on this case.
The following error: An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.
This issue is related to Problem PRB0304935 / Developer Ticket ERPS-296644
Other than manually reprinting any report that results in an ERROR status, Support is not aware of any additional workarounds to this concern.
Development has concluded that one of the main reasons for the issues is due to recent Kinetic reporting framework changes that are intended to make sure a customer’s custom report is correctly deployed in Reporting Services. These changes are having an unintended consequence of Reporting Services being overloaded.
Development is working on code changes and unofficially expect to have something checked into code by the end of February. I will provide you with all updates as they are received.
Let me know if you have further questions.
I was hoping that this weekend would resolve these issues. Maybe not.
So the scheduled-task feature is essentially neutered because you can’t trust SSRS jobs to be executed successfully…good times.
Wanna know whats funny, its only the SSRS portion of Task Agent that is intermittently failing…
So like, I thought of a relatively easy “fix” and literally already suggested it to epicor but they said it would be too difficult to implement.
All we gotta do is set up a scheduled task to fire every 10 minutes or so, look for failed SSRS reports deployed within the last hour matching the specific pattern (fail at 5%, ssrs errors in the SysTaskLog) that haven’t had a successful retry attempt - and fire a new SysTask.
It would probably take a few hours to code/test…
But really, why can’t epicor do that… band aid until they fix the root cause.
It isn’t really a matter of manually running the reports as that’ll take minutes for me to complete…it’s the principle. It’s supposed to work. It doesn’t. It apparently isn’t a priority to fix. 
Still occurring over here, error I have yet to see came about 30 min ago:
Program Ice.Services.Lib.RunTask when executing task 3539661 raised an unexpected exception with the following message: RunTask:
Ice.Core.SsrsReporting.SsrsCaller.SsrsException: The SSRS server returned the status code 500 (InternalServerError) with the following error text:
An error has occurred during report processing. —> Microsoft.ReportingServices.ReportProcessing.ProcessingAbortedException: An error has occurred during report processing. —> Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source ‘dsRMAForm’. —> Microsoft.Data.SqlClient.SqlException: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=12458; handshake=2569; —> System.ComponentModel.Win32Exception: The wait operation timed out
The fun thing is it’s not just scheduled tasks that fail, it’s manually run reports too. It’s a load/timing issue. So you could stay up to run your end of month reports and still hit a failure! But of course, you’re there to handle it at least 
Implementing a Scheduled Task to fix the broken Scheduled Tasks at least lets you nap… and have dreams of checking in a commit to Epicor’s git..
That’s the thing though manually running them doesn’t work either. Are you saying you have identified the issue @GabeFranco
I wrote a series of functions to create test scenarios in Pilot. There are numerous triggers, but in essense:
Epicor stores .rdls in 2 places in the current build, one in the usual database in the CustomReportStore table, which consists of a zip file in the “Content” field, containing the “reports\CustomReportStore...” folder structure and .rdl files.
A second copy is stored on the SSRS server, which is 1:many AppServer:SSRS server.
Epicor ran into scenarios where the CustomReportStore would be up-to-date but the report would not push to the SSRS server, so you would print an out of date “version” of the report vs. what you just updated/changed.
To fix this issue, Coinciding with the release of 2025.1, Epicor introduced sledgehammer code that always uploaded the .rdl file(s) to the ssrs server.
This introduces a process for every report print: → transfer zip to SSRS Server → unzip to file/folder structure → print
This then introduced concurrency issues from not properly checking if a file exists before opening a write handle to it and causing file io collisions.
This compounded with load issues from introducing a heckuvalotta unzip operations.
We all share an unknown number of SSRS Servers. I hope that it is nothing like the education servers, where there are hundreds of us on a single instance.
I think that about sums it up.
(of course, there is no transparency in this process, and that is the conclusion I have arrived at after much digging through code and creating test scenarios. In working with Epicor, one test was to throw more resources at our instance, and guess what worked…)
This is solvable on our side with the “Fire off a retry SysTasks until it works” Scheduled Task - but talk about a sledgehammer on top of a sledgehammer.
Epicor likely needs to re-architect that portion of the client/server communication occurring each print to optimize. Which explains the quite extended time…
Understood…manual or scheduled, either way it may fail. And if that’s the case then we won’t have monthend reports…no worries.
On second thought
