SharePoint Export to Excel: Where the Refresh Actually Runs

Export to Excel produces three different artifacts depending on the deployment, and the failure belongs to exactly one of them. A downloaded query file, a static CSV and a connected table that refreshes are not the same result, and each one fails at a different stage. Knowing which artifact you have decides whether the next step belongs to the network team, the identity team or the list owner. The mechanism below follows the handoff from the browser to Excel's own request.

What the export actually hands over

On classic SharePoint lists, Export to Excel downloads a small text file whose body is a URL, then Excel reads that file and issues its own request for the data behind it. The downloaded file is a pointer, not the list. A CSV export, by contrast, contains the rows themselves and has no connection to refresh. A newer connected table can embed the query directly in the workbook, so nothing lands in the Downloads folder at all.

Every connected form is one-way. Refresh pulls current rows from the list into the workbook, and editing the table does not send anything back. That asymmetry matters for diagnosis, because a workbook that opens with last week's rows has already proved that the file exists and the connection was saved, while telling you nothing about whether refresh works today.

So the first question is not why the export failed but which artifact the user expected. The answer narrows the investigation to one of three processes.

Three processes, three different identities

The browser download uses the browser session, with its own cookies, proxy configuration and sign-in state. Excel opening the file uses Office's HTTP stack, which generally follows the per-user Internet Options proxy rather than the machine-wide WinHTTP setting, and which authenticates with whatever Office identity the user holds. A later refresh reuses the saved connection and may pick up cached credentials from Windows Credential Manager instead of prompting.

Those three contexts can disagree on a single machine, which is why a browser that opens the list fine and an Excel refresh that returns a sign-in prompt is a coherent result rather than a contradiction. The tunnel changes the machine's routing for all three, but a proxy auto-configuration file can still send Office requests somewhere else.

Record the identity used at each stage before changing any of them. A fix applied to the browser cannot repair a request Excel makes under a different account.

Read the handoff file before changing anything

The downloaded file is plain text and usually short, so read it first. It names the host and the endpoint that Excel will call, and that host is the one that has to resolve and authenticate from the user's machine, not necessarily the address visible in the browser bar.

Get-Content "$env:USERPROFILE\Downloads\query.iqy"
Resolve-DnsName team.example.net
netsh winhttp show proxy

Compare the host in the file with the site the user thinks they exported from. A redirect during export, a legacy site collection or a migrated list can leave a pointer to a name that no longer serves the data, and the resulting error looks like a network failure. If the name resolves and the endpoint answers, the remaining candidates are authentication and the query itself.

Do not replace the hostname with an IP address to make it work. That breaks the certificate name check and hides the real problem behind a workaround that fails at the next certificate rotation.

Separate name, sign-in and query failures

Four outcomes cover almost every report, and each one has a different owner. A name that does not resolve belongs to DNS. A connection that times out belongs to routing or a proxy. A sign-in prompt or a 401 belongs to identity. A response that arrives but cannot be parsed belongs to the query or the endpoint the list now exposes.

The last row is the one people misdiagnose. A refresh that completes and returns the wrong rows has proved that every network and identity layer works, and the remaining question is which view or filter the query carries. Sending that ticket to the network team wastes a day.

Keep the exact error text and the time of the first failure. It decides which row of the table you are in, and it is the only evidence the list owner can act on.

Retest the refresh on the same list

Once the failing stage is identified, repeat the operation that failed rather than a cheaper one. Refresh the same list from the intended Excel environment, with the expected account and the approved network path, and confirm that the row count or a known changed value actually updates. Opening a saved workbook proves nothing about the connection.

Resist the broad repairs: clearing all saved credentials, running Office elevated or disabling a security feature may change the symptom without fixing the stage. If authentication is the failing layer, ask the list owner to confirm the account and the supported sign-in flow instead of guessing at the client.

Offer CSV only when a disconnected snapshot satisfies the task and that export is supported for the environment. Changing the output format changes the workflow, and it does not explain why the connected operation stopped working.