SharePoint-eksport til Excel: hvor opdateringen faktisk kører

Eksport til Excel giver tre forskellige artefakter afhængigt af udrulningen, og fejlen hører til præcis én af dem. En downloadet forespørgselsfil, en statisk CSV og en forbundet tabel, der opdateres, er ikke det samme resultat, og hver af dem fejler på et forskelligt trin. At vide, hvilket artefakt du har, afgør, om det næste skridt hører til netværksteamet, identitetsteamet eller listeejeren. Mekanismen nedenfor følger overdragelsen fra browseren til Excels egen anmodning.

Hvad eksporten faktisk overdrager

På klassiske SharePoint-lister downloader Eksportér til Excel en lille tekstfil, hvis indhold er en URL, og derefter læser Excel filen og sender sin egen anmodning om dataene bag den. Den downloadede fil er en pegepind, ikke listen. En CSV-eksport indeholder derimod selve rækkerne og har ingen forbindelse til at opdatere. En nyere forbundet tabel kan indlejre forespørgslen direkte i projektmappen, så der slet ikke lander noget i mappen Downloads.

Enhver forbundet form er envejs. Opdatering henter aktuelle rækker fra listen ind i projektmappen, og redigering af tabellen sender intet tilbage. Den asymmetri er vigtig for diagnosen, for en projektmappe, der åbner med sidste uges rækker, har allerede bevist, at filen findes, og at forbindelsen blev gemt, men siger intet om, hvorvidt opdatering virker i dag.

Det første spørgsmål er altså ikke, hvorfor eksporten fejlede, men hvilket artefakt brugeren forventede. Svaret indsnævrer undersøgelsen til en af tre processer.

Tre processer, tre forskellige identiteter

Browserdownloadet bruger browsersessionen med dens egne cookies, proxykonfiguration og logonstatus. Excel, der åbner filen, bruger Offices HTTP-stak, som generelt følger proxyen fra Internetindstillinger per bruger i stedet for den maskinbrede WinHTTP-indstilling, og som godkender med den Office-identitet, brugeren nu har. En senere opdatering genbruger den gemte forbindelse og kan hente cachelagrede legitimationsoplysninger fra Windows Legitimationsstyring i stedet for at spørge.

De tre kontekster kan være uenige på én maskine, og derfor er en browser, der åbner listen fint, og en Excel-opdatering, der returnerer en logonprompt, et sammenhængende resultat og ikke en modsigelse. Tunnelen ændrer maskinens routing for alle tre, men en proxy-autokonfigurationsfil kan stadig sende Office-anmodninger et andet sted hen.

Notér den identitet, der bruges på hvert trin, før du ændrer nogen af dem. En rettelse, der anvendes på browseren, kan ikke reparere en anmodning, som Excel sender under en anden konto.

Læs overdragelsesfilen, før du ændrer noget

Den downloadede fil er ren tekst og normalt kort, så læs den først. Den angiver den vært og det slutpunkt, som Excel kalder, og den vært er den, der skal slås op og godkendes fra brugerens maskine, ikke nødvendigvis den adresse, der ses i browserens adresselinje.

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

Sammenlign værten i filen med det websted, brugeren mener at have eksporteret fra. En omdirigering under eksporten, en ældre webstedssamling eller en migreret liste kan efterlade en pegepind til et navn, der ikke længere leverer dataene, og den resulterende fejl ligner en netværksfejl. Hvis navnet slås op, og slutpunktet svarer, er de resterende kandidater godkendelse og selve forespørgslen.

Erstat ikke værtsnavnet med en IP-adresse for at få det til at virke. Det bryder certifikatets navnekontrol og skjuler det egentlige problem bag en omvej, der fejler ved næste certifikatfornyelse.

Adskil navne-, logon- og forespørgselsfejl

Fire udfald dækker næsten hver rapport, og hvert af dem har en anden ejer. Et navn, der ikke kan slås op, hører til DNS. En forbindelse, der går i timeout, hører til routing eller en proxy. En logonprompt eller en 401 hører til identitet. Et svar, der ankommer, men ikke kan fortolkes, hører til forespørgslen eller det slutpunkt, som listen nu eksponerer.

Den sidste række er den, folk fejldiagnosticerer. En opdatering, der gennemføres og returnerer de forkerte rækker, har bevist, at hvert netværks- og identitetslag virker, og det resterende spørgsmål er, hvilken visning eller filtrering forespørgslen bærer. At sende den sag til netværksteamet spilder en dag.

Gem den præcise fejltekst og tidspunktet for den første fejl. Den afgør, hvilken række i tabellen du er i, og det er det eneste bevis, listeejeren kan handle på.

Test opdateringen igen på samme liste

Når det fejlende trin er identificeret, skal du gentage den handling, der fejlede, og ikke en billigere. Opdater den samme liste fra det tilsigtede Excel-miljø, med den forventede konto og den godkendte netværksvej, og bekræft, at antallet af rækker eller en kendt ændret værdi faktisk opdateres. At åbne en gemt projektmappe beviser intet om forbindelsen.

Modstå de brede reparationer: at rydde alle gemte legitimationsoplysninger, køre Office forhøjet eller deaktivere en sikkerhedsfunktion kan ændre symptomet uden at reparere trinnet. Hvis godkendelse er det fejlende lag, skal du bede listeejeren bekræfte kontoen og det understøttede logonflow i stedet for at gætte på klienten.

Tilbyd kun CSV, når et afkoblet øjebliksbillede opfylder opgaven, og den eksport understøttes for miljøet. At ændre outputformatet ændrer arbejdsgangen og forklarer ikke, hvorfor den forbundne handling holdt op med at virke.