SharePoint-export till Excel: var uppdateringen faktiskt körs

Export till Excel ger tre olika artefakter beroende på distributionen, och felet hör till exakt en av dem. En nedladdad frågefil, en statisk CSV och en ansluten tabell som uppdateras är inte samma resultat, och var och en misslyckas i ett annat steg. Att veta vilken artefakt du har avgör om nästa steg tillhör nätverksteamet, identitetsteamet eller listägaren. Mekanismen nedan följer överlämningen från webbläsaren till Excels egen begäran.

Vad exporten faktiskt lämnar över

På klassiska SharePoint-listor laddar Export till Excel ned en liten textfil vars innehåll är en URL, och sedan läser Excel filen och skickar sin egen begäran efter data bakom den. Den nedladdade filen är en pekare, inte listan. En CSV-export innehåller däremot själva raderna och har ingen anslutning att uppdatera. En nyare ansluten tabell kan bädda in frågan direkt i arbetsboken, så att ingenting hamnar i mappen Hämtade filer över huvud taget.

Varje ansluten form är enkelriktad. Uppdatering hämtar aktuella rader från listan till arbetsboken, och att redigera tabellen skickar ingenting tillbaka. Den asymmetrin spelar roll för diagnosen, eftersom en arbetsbok som öppnas med förra veckans rader redan har bevisat att filen finns och att anslutningen sparades, men inte säger något om huruvida uppdatering fungerar i dag.

Den första frågan är alltså inte varför exporten misslyckades utan vilken artefakt användaren förväntade sig. Svaret begränsar undersökningen till en av tre processer.

Tre processer, tre olika identiteter

Nedladdningen i webbläsaren använder webbläsarsessionen med sina egna cookies, sin proxykonfiguration och sitt inloggningsläge. Excel som öppnar filen använder Offices HTTP-stack, som i allmänhet följer proxyn från Internetalternativ per användare i stället för den maskinövergripande WinHTTP-inställningen, och som autentiserar med vilken Office-identitet användaren än har. En senare uppdatering återanvänder den sparade anslutningen och kan plocka upp cachelagrade autentiseringsuppgifter från Windows Autentiseringshanteraren i stället för att fråga.

De tre kontexterna kan vara oense på en och samma maskin, och därför är en webbläsare som öppnar listan fint och en Excel-uppdatering som returnerar en inloggningsfråga ett sammanhängande resultat och ingen motsägelse. Tunneln ändrar maskinens routning för alla tre, men en proxykonfigurationsfil kan fortfarande skicka Office-begäranden någon annanstans.

Anteckna vilken identitet som används i varje steg innan du ändrar någon av dem. En åtgärd som tillämpas på webbläsaren kan inte reparera en begäran som Excel gör under ett annat konto.

Läs överlämningsfilen innan du ändrar något

Den nedladdade filen är ren text och oftast kort, så läs den först. Den anger värden och slutpunkten som Excel anropar, och den värden är den som måste slås upp och autentiseras från användarens maskin, inte nödvändigtvis den adress som syns i webbläsarens adressfält.

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

Jämför värden i filen med den webbplats användaren tror sig ha exporterat från. En omdirigering under exporten, en äldre webbplatssamling eller en migrerad lista kan lämna en pekare till ett namn som inte längre levererar data, och det resulterande felet ser ut som ett nätverksfel. Om namnet slår upp och slutpunkten svarar är de återstående kandidaterna autentisering och själva frågan.

Byt inte ut värdnamnet mot en IP-adress för att få det att fungera. Det bryter certifikatets namnkontroll och döljer det verkliga problemet bakom en kringgående lösning som fallerar vid nästa certifikatförnyelse.

Separera namn-, inloggnings- och frågefel

Fyra utfall täcker nästan varje rapport, och var och en har en annan ägare. Ett namn som inte slår upp hör till DNS. En anslutning som får timeout hör till routning eller en proxy. En inloggningsfråga eller en 401 hör till identitet. Ett svar som anländer men inte kan tolkas hör till frågan eller den slutpunkt som listan nu exponerar.

Den sista raden är den folk feldiagnostiserar. En uppdatering som slutförs och returnerar fel rader har bevisat att varje nätverks- och identitetslager fungerar, och den återstående frågan är vilken vy eller vilket filter frågan bär med sig. Att skicka det ärendet till nätverksteamet slösar en dag.

Spara den exakta feltexten och tiden för det första felet. Den avgör vilken rad i tabellen du befinner dig i, och det är det enda bevis listägaren kan agera på.

Testa uppdateringen igen på samma lista

När det misslyckade steget är identifierat, upprepa den åtgärd som misslyckades och inte en billigare. Uppdatera samma lista från den avsedda Excel-miljön, med det förväntade kontot och den godkända nätverksvägen, och bekräfta att radantalet eller ett känt ändrat värde faktiskt uppdateras. Att öppna en sparad arbetsbok bevisar ingenting om anslutningen.

Motstå de breda reparationerna: att rensa alla sparade autentiseringsuppgifter, köra Office förhöjt eller inaktivera en säkerhetsfunktion kan ändra symtomet utan att reparera steget. Om autentisering är det felande lagret, be listägaren bekräfta kontot och det inloggningsflöde som stöds i stället för att gissa på klienten.

Erbjud CSV endast när en frånkopplad ögonblicksbild uppfyller uppgiften och den exporten stöds för miljön. Att ändra utdataformatet ändrar arbetsflödet och förklarar inte varför den anslutna åtgärden slutade fungera.