Hi mrusu ,

Thank you for engaging with the Microsoft Fabric Community. The issue appears to have started after the January 2026 Report Server upgrade. Since manual refreshes are successful, Analysis Services seems accessible, suggesting a possible temporary connection or timeout problem during scheduled refreshes.

Could you please check the following

1. Report Server logs at the time of the error

2. Status and load of Analysis Services during scheduled refresh

3. If multiple refresh jobs are running simultaneously, try staggering them

This should help us determine why scheduled refreshes fail while manual ones succeed.

Please try this once and let us know if the issue still continues. We’ll be happy to assist you further.

Regards,

Yugandhar.

Hi Yugandhar,

Thank you for your help. Note that the error is random and most of the refreshes work correctly. The hour when it occurs is also random, can be early morning or noon. Also, not specific to one report only, seems to happen with any of them.

I can see this kind of log entries in file RSPowerBI_2026_02_13_09_35_30.log:

2026-02-13 13:00:59.6288|ERROR|20|Error Processing Data Model Refresh: SessionId: ffbfd4b9-819b-46d2-b676-d5ab7d0f8010, Status: Error Failed to refresh the model, Exception Microsoft.PowerBI.ReportServer.AsServer.AsConnectionException: Failed to connect to AS ---> Microsoft.AnalysisServices.ConnectionException: A connection cannot be made. Ensure that the server is running. ---> 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: An existing connection was forcibly closed by the remote host

Regards.

Copilot answer:

What the evidence shows

1. This is a known PBIRS issue: scheduled refresh uses stricter timeouts

Microsoft’s own community support confirms that this error is not a permissions or connectivity problem but a background refresh timeout. PBIRS scheduled refresh runs under tighter limits than interactive use, so even normal variation in refresh duration can cause failures.

2. The key setting is not ExternalCommandTimeout

PBIRS ignores ExternalCommandTimeout. The relevant setting is:

• ProcessTimeout

• ProcessTimeoutGcExtension

Your default is likely 300 seconds, which is too low for many refresh workloads. Increasing it to 900 seconds (or more, depending on your environment) is the recommended fix.

3. This issue became more common after PBIRS updates

Users who upgraded to newer PBIRS builds (e.g., January 2026) reported random “Failed to connect to AS” errors that disappear when refreshing manually.

How to fix it

Step 1 — Edit RSReportServer.config

Located at:

C:\Program Files\Microsoft Power BI Report Server\PBIRS\ReportServer\RSReportServer.config

Add or modify:

<ProcessTimeout>900</ProcessTimeout>
<ProcessTimeoutGcExtension>300</ProcessTimeoutGcExtension>

(Values can be higher depending on your refresh duration.)

Step 2 — Restart the PBIRS service

This applies the new timeout settings.

Step 3 — Monitor refresh logs

Check:

C:\Program Files\Microsoft Power BI Report Server\PBIRS\LogFiles

Look for entries under AnalysisServicesDataRefresh to confirm timeout patterns.

🧠 Why this works

PBIRS scheduled refresh runs in a background process with a strict execution window. If your refresh sometimes takes 4 minutes and sometimes 7 minutes, a 300‑second timeout will cause intermittent failures. PBIRS then surfaces the generic error:

“Failed to connect to AS”

…but the underlying cause is simply that the refresh exceeded the allowed time.

Hi mrusu ,

Thank you for testing the timeout changes and sharing your update. Since the issue persists, it appears this isn't solely linked to the ProcessTimeout setting. The connection forcibly closed by the remote host message typically indicates that the Analysis Services engine is closing the connection, rather than a simple timeout.

Given that this began after the January 2026 upgrade and affects various reports at random, the next step is to check the Analysis Services logs and Windows Event Viewer around the time of the failure. This can help determine if the engine is restarting, experiencing memory pressure, or ending sessions.

If nothing unusual is found, we may need to consider proceeding with a support case for deeper analysis.

Please review and let us know what you discover so we can proceed accordingly.

Regards,
Yugandhar .

Hi mrusu ,

We haven’t received a response from your end yet. Please let us know whether the issue has been resolved or if you’re still facing any difficulties. Feel free to reach out if you need further assistance.

Thank you.