SSRS Export Fails Through a Clientless VPN Portal: What Differs

The report opens in the browser, the parameters render, and the export button produces an error, an empty download, or a file the spreadsheet refuses to open. That combination has a standard shape. A working report page has tested rendering and authentication and nothing else. The export is a separate request with its own response, and through a clientless portal it also crosses a rewriting layer that was never designed around file downloads.

Two paths, one working page

Rendering and exporting are different operations even when they start from the same button. The report server renders the page for a browser and renders the export through a different output extension with its own content type and its own error behaviour, as the export documentation describes. A portal that passes the first perfectly can still mangle the second, because the second is a response the portal did not expect to see. The two share a session and an address, and almost nothing else.

Treat the working page as evidence about authentication and reachability only. It proves the account can reach the report server and that the portal forwards HTML. It says nothing about file responses, content disposition headers, or redirects that end in a download rather than in a document.

That is the whole reason to compare the export path on its own instead of re-testing the page that already works. Two requests that share a session are still two requests.

Three conditions that decide where the export breaks

Three questions place the fault quickly, and each answer points at a different owner.

First, does the same report, account and format export correctly from the internal network? If it does, the report server and its renderer are fine and the difference is in the access path. Second, does the failing response carry a file content type, or an HTML page wearing a file extension? That separates a renderer error from a portal substitution. Third, does the portal rewrite the request URL or strip headers from the response? A rewritten URL can land on a completely different endpoint.

Answer all three before changing a setting, because each one has a different remedy. A renderer fault belongs to the report server, a substituted body belongs to the portal, and a stripped header is a policy question rather than a bug.

Write the answers down. A support case built from those three lines is worth ten screenshots.

Read the export response instead of the status code

An HTTP success status proves only that something answered the request. Inspect the body and the headers together, because the interesting failure is a successful response carrying the wrong content.

curl -sS -D export.headers -o export.bin --location "https://portal.example.com/reports/export?format=xlsx"
file export.bin
head -c 300 export.bin

The header dump shows the content type and any content disposition the portal returned. The file command identifies what the body actually is, and a text file where a spreadsheet was expected is the classic substituted sign-in page. The head command shows enough to recognise HTML without dumping an entire report into a terminal.

Redact session cookies and tokens before sharing any of it. A capture of a working export is useful evidence, and a capture of a session belonging to someone else is an incident.

Scope an exception to the application, not the account

If the portal is rewriting or blocking the response, the tempting repair is to exempt the whole site or to make the report anonymous. Both fix the download and remove the reason the portal exists. A scoped exception names one application path, one content type and one direction, and it stays reviewable by whoever owns the policy.

Use the gateway version you actually run and its documented application settings. An option that a vendor once described as leaving traffic unchanged is not a general instruction, and copying it from an old forum thread is how a temporary exception becomes permanent architecture.

If the exception cannot be scoped that narrowly, the export probably belongs on the internal path with a different access method rather than behind the portal. A site-wide exemption is a decision for the portal owner, not a workaround for one report.

Accept the export, not the Save dialog

The last check is the file itself: it opens, it holds the expected columns, and its totals match the report the user approved.

A Save dialog appearing is not success, and a file that opens with a repair warning is not success either. Compare a row count and one known value against the on-screen report, because a truncated export passes every test that only looks at file size. Then export a second time, since a caching layer that serves the wrong body once may serve the right one on the next attempt.

Accept the workflow the user needed, and nothing less than that. A download that opens in the wrong application is still a failed export.