Cloud SSRS reports failing since the upgrade on Monday

Kinetic ERP
21

J Jonah Jameson Laughing GIF

2 Likes
22

Probably depends if your lawyers are better than Epicor’s.
:rofl:

2 Likes
23

This error is giving me flashbacks to a rookie move I made way way back when I was new to SSRS, full of hopeful confidence, and short on learned paranoia.

Peeking inside an RDL with any text editor and Ctrl-F’ing DataSource, should look something like so:

<DataSource Name="your dataset name">
  <DataSourceReference>/SaaS[redacted]SSRS_[redacted]/reports/SharedReportDataSource</DataSourceReference>
  ...
</DataSource>

Is that different from what shows up in a newly created and functional SSRS RDL? It’s worth a shot to update the DataSourceReference path to see what happens.

24

Unfortunately, every one of these errors is intermittent and transient, the .rdl itself is unmodified from 2024.2.12 where we ran into no issues. The upgrade to 2025.1.8 (with no change to the .rdl or .rdd) triggered the issues, which then spread to a whole bunch of reports, even OOB ones.

4 Likes
25

This is a system issue not a custom reporting issue, rerunning the same report a few minutes later it will go through.

4 Likes
26

todo:< insert snarky support comment here >

3 Likes
27

Captain Obvious did finally reply to my ticket. At least there are eyes on it.

image

5 Likes
28

If they’re unable to provide real detail, we are required to assume that support right now must look like only one of these things.

pile up car GIF

male GIF

7 Likes
29

Recieved an update at 4:39 am that they “made some internal changes to the reporting servers”. Looking good for now, no errors this morning.

2 Likes
30

This is the update we received:

"The issue occurred because some internal configuration files were unavailable, which caused the secondary reporting services to go down. Since the reporting services run in an active-active setup between the primary and secondary, this led to the intermittent printing failures. The configuration has been restored, and printing should now work without further issues. "

No printing failures so far yet today but its early yet. I am in disbelief it took 2 weeks to notice such a major configuration error. I will refrain from commenting on this further.

4 Likes
31

It looks like we are still getting low disk errors on some of our custom reports. I was hoping that this would be resolved with the fixes that you all had but I guess not.

1 Like
32

Maybe they didn’t fix your configuration yet?

1 Like
33

Could you share your case so that we can reference it?

34

It’s up above. Unfortunately the configuration issue was a separate issue from the original issue which is still continuing.

2 Likes
35

Here you go @utaylor

1 Like
36

Thanks Randy.

37

This appears that it still isnt resolved.

You’d think such a large impacting issue would be visible on the status page.

image
image2182×1191 70.7 KB

5 Likes
38

I never saw anything in the portal at all when our printing was failing. I asked for a RCA on the incident this morning and got the following reply.

“Unfortunately, an official RCA is not available, as the incident was not recorded on the status portal. However, we can confirm that the issue was related to two reporting servers, and it has since been resolved through internal remediation efforts.”

Seriously? Guess that’s one way to keep the SLA numbers up. :man_shrugging:

2 Likes
39

I know at least one client who gets errors their RDLs are still not found…

2 Likes
40

I had the RDL’s not found issue and support had me run Conversions 405 and 410. That stopped the errors. Hope this helps someone.

2 Likes