Plan for fejlfinding af ydeevnen for Office 365

Har du brug for at kende de trin, du skal udføre for at identificere og løse mellemliggende tid, stop og langsom ydeevne mellem SharePoint, OneDrive, Exchange Online eller Skype for Business Online og din klientcomputer? Før du ringer til support, kan denne artikel hjælpe dig med at foretage fejlfinding af Office 365 problemer med ydeevnen og endda løse nogle af de mest almindelige problemer.

Denne artikel er faktisk et eksempel på en handlingsplan, som du kan bruge til at indsamle værdifulde data om problemet med ydeevnen, efterhånden som det sker. Nogle af de mest populære problemer er også inkluderet i denne artikel.

Hvis du ikke kender netværkets ydeevne og gerne vil lave en langsigtet plan for overvågning af ydeevnen mellem dine klientcomputere og Office 365, kan du se Office 365 justering af ydeevnen og fejlfinding – Administration og IT Pro.

Eksempel på en handlingsplan til fejlfinding af ydeevne

Denne handlingsplan indeholder to dele. en forberedelsesfase og en logføringsfase. Hvis du har problemer med ydeevnen lige nu, og du skal udføre dataindsamling, kan du begynde at bruge denne plan med det samme.

Forbered klientcomputeren

• Find en klientcomputer, der kan genskabe problemet med ydeevnen. Denne computer bruges under fejlfinding.
• Skriv de trin ned, der medfører, at problemet med ydeevnen opstår, så du er klar, når det kommer til test.
• Installér værktøjer til indsamling og optagelse af oplysninger:
  • Installér Netmon 3.4 (eller brug et tilsvarende værktøj til netværkssporing).
  • Installér den gratis Basic-udgave af HTTPWatch (eller brug et tilsvarende værktøj til netværkssporing).
  • Brug en skærmoptager, eller kør trinoptageren (PSR.exe), der følger med Windows Vista og nyere, for at registrere de trin, du udfører under testen.

Logfør problemet med ydeevnen

• Luk alle overflødige internetbrowsere.

• Start Trinoptager eller en anden skærmoptager.

• Start din Netmon-registrering (eller værktøjet til netværkssporing).

• Ryd DNS-cachen på klientcomputeren fra kommandolinjen ved at skrive ipconfig /flushdns.

• Start en ny browsersession, og slå HTTPWatch til.

• Valgfrit: Hvis du tester Exchange Online, skal du køre værktøjet Exchange Client Effektivitetsanalyse fra Office 365 administrationskonsollen.

• Genskab de nøjagtige trin, der forårsager problemet med ydeevnen.

• Stop din Netmon eller andre værktøjs sporing.

• Kør en sporingsrute til dit Office 365-abonnement på kommandolinjen ved at skrive følgende kommando og derefter trykke på ENTER:

  tracert <subscriptionname>.onmicrosoft.com
  

• Stop Trinoptager, og gem videoen. Sørg for at inkludere dato og klokkeslæt for hentningen, og om det viser en god eller dårlig ydeevne.

• Gem sporingsfilerne. Husk igen at inkludere dato og klokkeslæt for hentningen, og om det viser en god eller dårlig ydeevne.

Hvis du ikke er bekendt med at køre de værktøjer, der er nævnt i denne artikel, skal du ikke bekymre dig, da vi giver disse trin næste. Hvis du er vant til at udføre denne form for netværksopfangning, kan du gå til Sådan indsamler du baselines, som beskriver filtrering og læsning af loggene.

Ryd FØRST DNS-cachen

Hvorfor? Når du rydder DNS-cachen ud, starter du dine test med en ren tavle. Når du rydder cachen, nulstiller du indholdet af DNS-fortolkeren til de mest opdaterede poster. Husk, at en rydning ikke fjerner VÆRTS-filposter. Hvis du bruger MANGE VÆRTS-filposter, skal du kopiere posterne ud til en fil i en anden mappe og derefter tømme HOST-filen.

Ryd din DNS-resolvercache

1. Åbn kommandoprompten (enten Start>kør>cmd eller Windows-nøgle-cmd>).

2. Skriv følgende kommando, og tryk på ENTER:

   ipconfig /flushdns
   

Netmon

Microsofts Netmon-værktøj (Network Monitoring) analyserer pakker (netværkstrafik), der overføres mellem computere på netværk. Ved at bruge Netmon til at spore trafik med Office 365 kan du registrere, få vist og læse pakkeheadere, identificere mellemliggende enheder, kontrollere vigtige indstillinger på netværkshardware, søge efter tabte pakker og følge strømmen af trafik mellem computere på virksomhedens netværk og Office 365. Da den faktiske brødtekst i trafikken krypteres, dvs. den kører på port 443 via SSL/TLS, kan du ikke læse de filer, der sendes. I stedet får du en ufiltreret sporing af den sti, som pakken tager, hvilket kan hjælpe dig med at spore problemets funktionsmåde.

Sørg for, at du ikke anvender et filter på nuværende tidspunkt. I stedet skal du gennemgå trinnene og demonstrere problemet, før du stopper sporingen og gemmer.

Når du har installeret Netmon 3.4, skal du åbne værktøjet og følge disse trin:

Tag en Netmon-sporing, og genskab problemet

1. Start Netmon 3.4. Der er tre ruder på startsiden: Seneste optagelser, Vælg netværk og Introduktion med Microsoft Network Monitor 3.4. Læg mærke til det. Panelet Vælg netværk giver dig også en liste over de standardnetværk, du kan hente fra. Sørg for, at netværkskort er valgt her.

2. Klik på Ny hentningøverst på startsiden. Dette tilføjer en ny fane ud for fanen Startside med navnet Hent 1.

3. Klik på Start på værktøjslinjen for at tage et enkelt billede.

4. Genskab de trin, der præsenterer et problem med ydeevnen.

5. Klik på Stop>fil>gem som. Husk at angive dato og klokkeslæt sammen med tidszonen og nævne, om det viser dårlig eller god ydeevne.

HTTPWatch

HTTPWatch leveres til betaling og en gratis udgave. Den gratis Basic Edition dækker alt, hvad du har brug for til denne test. HTTPWatch overvåger netværkstrafik og indlæsningstid for sider direkte fra browservinduet. HTTPWatch er en plug-in til Microsoft Edge, der grafisk beskriver ydeevnen. Analysen kan gemmes og vises i HTTPWatch Studio.

Bemærk!

Hvis du bruger en anden browser, f.eks. Firefox, Google Chrome, eller hvis du ikke kan installere HTTPWatch i Edge, skal du åbne et nyt browservindue og trykke på F12 på tastaturet. Du kan se pop op-vinduet Udviklerværktøj nederst i din browser. Hvis du bruger Opera, skal du trykke på CTRL+SKIFT+I for Webfremviser og derefter klikke på fanen Netværk og fuldføre den test, der er beskrevet nedenfor. Oplysningerne vil være lidt anderledes, men indlæsningstiden vises stadig i millisekunder. > HTTPWatch er også meget nyttig i forbindelse med problemer med indlæsningstider for SharePoint-sider.

Kør HTTPWatch, og genskab problemet

HTTPWatch er en plug-in til en browser, så det er lidt anderledes at vise værktøjet i browseren for hver version af Microsoft Edge. Du kan typisk finde HTTPWatch under kommandolinjen i Microsoft Edge-browseren. Hvis du ikke kan se HTTPWatch-plug-in'en i browservinduet, skal du kontrollere versionen af din browser ved at klikke på Hjælp>om eller i nyere versioner af Microsoft Edge, klikke på tandhjulssymbolet og Om Edge. Hvis du vil starte kommandolinjen , skal du højreklikke på menulinjen i Microsoft Edge og klikke på Kommandolinjer.

HTTPWatch har tidligere været knyttet til både kommandoerne og stifinderlinjerne, så når du først har installeret, skal du kontrollere Værktøjer og dine værktøjslinjer for ikonet, hvis du ikke straks ser ikonet (selv efter genstart). Husk, at værktøjslinjer kan tilpasses, og at der kan føjes indstillinger til dem.

1. Start HTTPWatch i et Microsoft Edge-browservindue. Den er fastgjort til browseren nederst i det pågældende vindue. Klik på Post.

2. Genskab de nøjagtige trin, der er involveret i problemet med ydeevnen. Klik på knappen Stop i HTTPWatch.

3. Gem HTTPWatch eller Send via mail. Husk at navngive filen, så den indeholder oplysninger om dato og klokkeslæt og en indikation af, om uret indeholder en demonstration af god eller dårlig ydeevne.

Dette skærmbillede er fra Professional-versionen af HTTPWatch. Du kan åbne sporinger, der er taget i basisversionen, på en computer med en Professional-version og læse den der. Der kan være flere oplysninger tilgængelige fra sporingen via denne metode.

Optager til problemtrin

Med Trinoptager eller PSR.exe kan du registrere problemer, efterhånden som de opstår. Det er et meget nyttigt værktøj og nemt at køre.

Kør Optager til problemtrin (PSR.exe) for at registrere dit arbejde

1. > Brug entenstartkørselstypen>PSR.exe>OK, eller klik på Windows-nøgletypen>PSR.exe> og tryk derefter på ENTER.

2. Når det lille PSR.exe vindue vises, skal du klikke på Start post og genskabe de trin, der genskaber problemet med ydeevnen. Du kan tilføje kommentarer efter behov ved at klikke på Tilføj kommentarer.

3. Klik på Stop post , når du har fuldført trinnene. Hvis problemet med ydeevnen er en sidegengivelse, skal du vente på, at siden gengives, før du stopper optagelsen.

4. Klik på Gem.

Dato og klokkeslæt registreres for dig. Dette linker din PSR til din Netmon-sporing og HTTPWatch i tide og hjælper med fejlfinding af præcision. Datoen og klokkeslættet i PSR-posten kan f.eks. vise, at der gik et minut mellem logon og browsing af URL-adressen og den delvise gengivelse af administrationswebstedet.

Læs dine sporinger

Det er ikke muligt at lære alt om fejlfinding af netværk og ydeevne, som nogen har brug for at vide via en artikel. At blive god til ydeevne kræver erfaring og viden om, hvordan dit netværk fungerer og som regel fungerer. Men det er muligt at runde en liste over de mest almindelige problemer op og vise, hvordan værktøjer kan gøre det nemmere for dig at fjerne de mest almindelige problemer.

Hvis du vil hente færdigheder, der læser netværkssporinger for dine Office 365 websteder, er der ingen bedre lærer end at oprette spor af sidebelastninger regelmæssigt og få erfaring med at læse dem. Når du f.eks. har en chance, kan du indlæse en Office 365 tjeneste og spore processen. Filtrer sporingen for DNS-trafik, eller søg i FrameData efter navnet på den tjeneste, du har gennemset. Scan sporingen for at få en idé om de trin, der opstår, når tjenesten indlæses. Dette hjælper dig med at se, hvordan normal sidebelastning skal se ud, og i tilfælde af fejlfinding, især i forbindelse med ydeevne, kan sammenligning af gode og dårlige spor lære dig meget.

Netmon bruger Microsoft Intellisense i feltet Vis filter. Intellisense eller intelligent kodefuldførelse er det trick, hvor du skriver i en periode, og alle tilgængelige indstillinger vises i en rulleliste. Hvis du f.eks. er bekymret for TCP-vinduesskalering, kan du finde vej til et filter (f.eks. .protocol.tcp.window < 100) på denne måde.

Netmon spor kan have en masse trafik i dem. Hvis du ikke har erfaring med at læse dem, er det sandsynligt, at du bliver overvældet over at åbne sporingen første gang. Den første ting at gøre er at adskille signalet fra baggrundsstøj i sporingen. Du har testet mod Office 365, og det er den trafik, du vil se. Hvis du er vant til at navigere gennem sporinger, har du muligvis ikke brug for denne liste.

Trafik mellem din klient og Office 365 rejser via TLS, hvilket betyder, at selve trafikken krypteres og ikke kan læses i en generisk Netmon-sporing. Din ydeevneanalyse behøver ikke at kende specifikationerne for oplysningerne i pakken. Den er dog meget interesseret i pakkeheadere og de oplysninger, de indeholder.

Tip til at få en god sporing

• Kend værdien af IPv4- eller IPv6-adressen på klientcomputeren. Du kan hente dette fra kommandoprompten ved at skrive IPConfig og derefter trykke på ENTER. Hvis du kender denne adresse, kan du hurtigt se, om trafikken i sporingen direkte involverer din klientcomputer. Hvis der er en kendt proxy, ping det og få sin IP-adresse samt.

• Ryd din DNS-resolvercache, og luk alle browsere undtagen den, hvor du kører dine test, hvis det er muligt. Hvis du f.eks. ikke kan gøre dette, hvis support bruger et browserbaseret værktøj til at se klientcomputerens skrivebord, skal du være forberedt på at filtrere din sporing.

• Find den Office 365 tjeneste, du bruger, i en optaget sporing. Hvis du aldrig eller sjældent har set din trafik før, er dette et nyttigt skridt i at adskille ydeevneproblemet fra andre netværksstøj. Der er et par måder at gøre dette på. Direkte før din test kan du bruge ping eller PsPing mod URL-adressen til den specifikke tjeneste (ping outlook.office365.com eller psping -4 microsoft-my.sharepoint.com:443f.eks. ). Du kan også nemt finde den ping eller PsPing i en Netmon-sporing (ved dens procesnavn). Det vil give dig et sted at begynde at lede.

Hvis du kun bruger Netmon-sporing på tidspunktet for problemet, er det også i orden. Hvis du vil orientere dig selv, skal du bruge et filter som ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"). Du kan optage dit billednummer fra sporingsfilen. Det kan også være en god idé at rulle i ruden Rammeoversigt helt til højre og kigge efter kolonnen Samtale-id. Der er angivet et nummer for id'et for denne specifikke samtale, som du også kan optage og se isoleret senere. Husk at fjerne dette filter, før du anvender anden filtrering.

Tip

Netmon har en masse nyttige indbyggede filtre. Prøv knappen Indlæs filter øverst i ruden Vis filter.

Bliv fortrolig med din trafik, og få mere at vide om, hvordan du finder de oplysninger, du har brug for. Få f.eks. mere at vide om, hvilken pakke i sporingen der har den første reference til den Office 365 tjeneste, du bruger (f.eks. "Outlook").

Hvis du f.eks. tager Office 365 Outlook Online, begynder trafikken noget i stil med dette:

• DNS-standardforespørgsel og DNS-svar for outlook.office365.com med matchende QueryID'er. Det er vigtigt at bemærke tidsforskydningen for denne turn-around, og hvor i verden Office 365 Global DNS sender anmodningen om navnefortsættelse. Ideelt set, så lokalt som muligt, snarere end halvvejs over hele verden.

• En HTTP GET-anmodning, hvis statusrapport er flyttet permanent (301)

• RWS-trafik, herunder RWS Connect-anmodninger og Connect-svar. (Dette er Remote Winsock, der opretter en forbindelse for dig).

• En TCP SYN- og TCP SYN/ACK-samtale. Mange indstillinger i denne samtale påvirker din ydeevne.

• Derefter en række TLS:TLS-trafik, som er det sted, hvor TLS-håndtryk og TLS-certifikatsamtaler finder sted. Husk, at dataene er krypteret via SSL/TLS.

Alle dele af trafikken er vigtige og forbundne, men små dele af sporingen indeholder oplysninger, der er vigtige for fejlfinding af ydeevnen, så vi vil fokusere på disse områder. Da vi har gjort nok Office 365 fejlfinding af ydeevnen hos Microsoft for at kompilere en Top 10-liste over almindelige problemer, vil vi også fokusere på disse problemer, og hvordan du bruger de værktøjer, vi skal bruge til at rodfæste dem ud næste.

Hvis du ikke allerede har installeret dem, bruger matrixen nedenfor flere værktøjer, hvor det nogensinde er muligt. Der leveres links til installationspunkterne. Listen indeholder almindelige værktøjer til netværkssporing, f.eks. Netmon og Wireshark, men brug et hvilket som helst sporingsværktøj, du er fortrolig med, og som du er vant til at filtrere netværkstrafik i. Når du tester, skal du huske:

• Luk dine browsere, og test med kun én browser kørende – dette reducerer den samlede trafik, du registrerer. Det giver en mindre travl spor.
• Ryd din DNS-resolvercache på klientcomputeren – Dette giver dig en ren tavle, når du begynder at tage din registrering, for at få en renere sporing.

Almindelige problemer

Nogle almindelige problemer, du kan støde på, og hvordan du finder dem i din netværkssporing.

TCP Windows-skalering

Fundet i SYN – SYN/ACK. Ældre hardware eller ældre hardware kan muligvis ikke drage fordel af TCP-windows-skalering. Uden de korrekte TCP Windows-skaleringsindstillinger udfyldes standardbufferen på 16-bit i TCP-headere i millisekunder. Trafikken kan ikke fortsætte med at sende, før klienten modtager en bekræftelse på, at de oprindelige data er modtaget, hvilket medfører forsinkelser.

Værktøjer

• Netmon
• Wireshark

Hvad skal du søge efter?

Se efter SYN - SYN/ACK-trafikken i din netværkssporing. I Netmon skal du bruge et filter som tcp.flags.syn == 1. Dette filter er det samme i Wireshark.

Bemærk, at der for hver SYN er et kildeportnummer (SrcPort), der matches i destinationsporten (DstPort) for den relaterede anerkendelse (SYN/ACK).

Hvis du vil se den Windows-skaleringsværdi, der bruges af din netværksforbindelse, skal du først udvide SYN og derefter den relaterede SYN/ACK.

Indstillinger for TCP-ledig tid

Historisk set er de fleste perimeternetværk konfigureret til midlertidige forbindelser, hvilket betyder, at inaktive forbindelser generelt afbrydes. Inaktive TCP-sessioner kan afbrydes af proxyer og firewalls på mere end 100 til 300 sekunder. Dette er problematisk for Outlook Online, fordi det opretter og bruger langsigtede forbindelser, uanset om de er inaktive eller ej.

Når forbindelser afbrydes af proxy- eller firewallenheder, informeres klienten ikke, og et forsøg på at bruge Outlook Online betyder, at en klientcomputer gentagne gange vil forsøge at genoplive forbindelsen, før der foretages en ny. Du kan muligvis se, at produktet hænger, bliver bedt om det, eller at ydeevnen er langsom ved sideindlæsning.

Værktøjer

• Netmon
• Wireshark

Hvad skal du søge efter?

I Netmon skal du se på feltet Tidsforskydning for en rundtur. En rundtur er tiden mellem, at klienten sender en anmodning til serveren og modtager et svar. Kontrollér mellem klienten og udgående punkt (f.eks. klient –> proxy) eller den klient, der skal Office 365 (klient –> Office 365). Du kan se dette i mange typer pakker.

Filteret i Netmon kan f.eks. se ud som .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12, eller i Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Tip

Ved du ikke, om IP-adressen i din sporing tilhører din DNS-server? Prøv at slå det op på kommandolinjen. Klik på Start>kør> , og skriv cmd, eller tryk på Windows-tasten> , og skriv cmd. Skriv i prompten nslookup <the IP address from the network trace>. Hvis du vil teste, skal du bruge nslookup mod din egen computers IP-adresse. >Hvis du vil se en liste over Microsofts IP-intervaller, skal du se Office 365 URL-adresser og IP-adresseområder.

Hvis der er et problem, kan du forvente, at lange tidsforskydninger vises i dette tilfælde (Outlook Online), især i TLS:TLS-pakker, der viser passagen af programdata (i Netmon kan du f.eks. finde programdatapakker via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Du bør kunne se et gnidningsløst forløb i tiden på tværs af sessionen. Hvis du oplever lange forsinkelser, når du opdaterer Outlook Online, kan det skyldes en høj grad af nulstilling, der sendes.

Ventetid/returtid

Ventetid er en måling, der kan ændre sig meget afhængigt af mange variabler, f.eks. opgradering af aldrende enheder, tilføjelse af et stort antal brugere til et netværk og procentdelen af den samlede båndbredde, der forbruges af andre opgaver på en netværksforbindelse.

Der er båndbreddeberegnere til Office 365 tilgængelige fra denne netværksplanlægning og justering af ydeevnen for Office 365 side.

Har du brug for at måle hastigheden af din forbindelse eller internetudbyderens båndbredde? Prøv dette websted (eller websteder kan lide det): Speedtest Official Site, eller forespørg din foretrukne søgemaskine til sætningen hastighed test.

Værktøjer

• Ping
• PsPing
• Netmon
• Wireshark

Hvad skal du søge efter?

Hvis du vil spore ventetid i en sporing, kan du drage fordel af at have registreret klientcomputerens IP-adresse og DNS-serverens IP-adresse i Office 365. Dette er for at lette sporingsfiltrering. Hvis du opretter forbindelse via en proxy, skal du bruge din klientcomputers IP-adresse, proxy-/udgående IP-adresse og Office 365 DNS-IP-adresse for at gøre arbejdet nemmere.

En pinganmodning, der sendes til outlook.office365.com, fortæller dig navnet på det datacenter, der modtager anmodningen, selvom ping muligvis ikke kan oprette forbindelse for at sende de på hinanden følgende ICMP-pakker med varemærker. Hvis du bruger PsPing (et gratis værktøj til download), og specifikke havnen (443) og måske til at bruge IPv4 (-4) får du en gennemsnitlig rundtur-tid for pakker sendt. Dette fungerer for andre URL-adresser i Office 365-tjenester, f.ekspsping -4 yourSite.sharepoint.com:443. . Faktisk kan du angive et antal pings for at få et større eksempel for dit gennemsnit, prøv noget i stil med psping -4 -n 20 yourSite-my.sharepoint.com:443.

Bemærk!

PsPing sender ikke ICMP-pakker. Den pinger med TCP-pakker over en bestemt port, så du kan bruge en hvilken som helst, du kender, til at være åben. I Office 365, der bruger SSL/TLS, kan du prøve at vedhæfte port :443 til din PsPing.

Hvis du har indlæst den langsomme ydeevne Office 365 side, mens du udfører en netværkssporing, skal du filtrere en Netmon- eller Wireshark-sporing for DNS. Dette er en af de IP-adresser, vi leder efter.

Her er de trin, du skal udføre for at filtrere din Netmon for at få IP-adressen (og se på DNS-ventetid). I dette eksempel bruges outlook.office365.com, men kan også bruge URL-adressen til en SharePoint-lejer (f.eks. hithere.sharepoint.com).

1. Ping URL-adressen ping outlook.office365.com , og registrer navnet og IP-adressen på den DNS-server, som pinganmodningen blev sendt til, i resultaterne.
2. Netværkssporing, der åbner siden, eller udfører den handling, der giver dig problemet med ydeevnen, eller, hvis du ser en høj ventetid på ping, selve netværket spore den.
3. Åbn sporingen i Netmon, og filtrer for DNS (dette filter fungerer også i Wireshark, men skelner mellem store og små bogstaver -- dns). Da du kender navnet på DNS-serveren fra din ping, kan du også filtrere mere hurtigt i Netmon på denne måde: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), der ser sådan ud i Wireshark dns, og rammen indeholder "namnorthwest".
   Åbn svarpakken, og klik på DNS i vinduet Netmon Frame Details for at få flere oplysninger. I DNS-oplysningerne finder du IP-adressen på den DNS-server, som anmodningen gik til i Office 365. Du skal bruge denne IP-adresse til næste trin (PsPing-værktøjet). Fjern filteret, højreklik på DNS-svaret i Netmon (Frame Summary>Find Conversations>DNS) for at se DNS-forespørgslen og -svaret side om side.
4. I Netmon skal du også bemærke kolonnen Time Offset mellem DNS-anmodningen og svaret. I det næste trin kommer det brugervenlige PsPing-værktøj meget praktisk, både fordi ICMP ofte er blokeret på firewalls, og fordi PsPing elegant sporer ventetid i millisekunder. PsPing afslutter en TCP-forbindelse til en adresse og port (i vores tilfælde åben port 443).
5. Installér PsPing.
6. Åbn en kommandoprompt ( > startkørselstype > cmd eller Windows-nøgletype > cmd), og skift mappe til den mappe, hvor du installerede PsPing for at køre Kommandoen PsPing. I mine eksempler kan du se jeg lavet en 'Perf' mappe på roden af C. Du kan gøre det samme for at få hurtig adgang.
7. Skriv kommandoen, så du foretager din PsPing mod IP-adressen på den Office 365 DNS-server fra din tidligere Netmon-sporing, herunder portnummeret, f.ekspsping -n 20 132.245.24.82:445. . Dette giver dig et udsnit på 20 pings og den gennemsnitlige ventetid, når PsPing stopper.

Hvis du vil Office 365 via en proxyserver, er trinnene lidt anderledes. Først PsPing til din proxyserver for at få en gennemsnitlig ventetidsværdi i millisekunder til proxy/udgående data og tilbage og derefter enten køre PsPing på proxyen eller på en computer med en direkte internetforbindelse for at få den manglende værdi (den, der skal Office 365 og tilbage).

Hvis du vælger at køre PsPing fra proxyen, har du to millisekundersværdier: Klientcomputer til proxyserver eller udgående punkt og proxyserver til Office 365. Og du er færdig! Nå, optagelse værdier, alligevel.

Hvis du kører PsPing på en anden klientcomputer, der har en direkte forbindelse til internettet, dvs. uden en proxy, har du to millisekundersværdier: Klientcomputer til proxyserver eller udgående punkt og klientcomputer, der skal Office 365. I dette tilfælde skal du trække værdien af klientcomputeren til proxyserveren eller udgangspunktet fra værdien af klientcomputeren til Office 365, og du har RTT-tallene fra klientcomputeren til proxyserveren eller udgangspunktet og fra proxyserveren eller udgående punktet til Office 365.

Men hvis du kan finde en klientcomputer på den påvirkede placering, der er direkte forbundet eller tilsidesætter proxyen, kan du vælge at se, om problemet genskabes der til at begynde med, og teste at bruge det derefter.

Ventetid, som vist i en Netmon-sporing, kan disse ekstra millisekunder tilføjes, hvis der er nok af dem i en given session.

Bemærk!

Din IP-adresse kan være forskellig fra de IP-adresser, der er vist her, f.eks. kan din ping returnere noget mere som 157.56.0.0/16 eller et lignende interval. Hvis du vil se en liste over områder, der bruges af Office 365, skal du se Office 365 URL-adresser og IP-adresseområder.

Husk at udvide alle noder (der er en knap øverst til dette), hvis du vil søge efter f.eks. 132,245.

Proxygodkendelse

Dette gælder kun for dig, hvis du går gennem en proxyserver. Hvis ikke, kan du springe disse trin over. Når du arbejder korrekt, skal proxygodkendelse ske i millisekunder på en ensartet måde. Du bør ikke se periodisk dårlig ydeevne i perioder med spidsbelastning (f.eks. ).

Hvis proxygodkendelse er slået til, skal du gennemgå en godkendelsesproces bag kulisserne, hver gang du opretter en ny TCP-forbindelse til Office 365 for at få oplysninger. Så når du f.eks. skifter fra Kalender til Mail i Outlook Online, godkendes du. Og hvis der vises medier eller data fra flere websteder eller placeringer på en side i SharePoint, godkendes hver enkelt tcp-forbindelse, der er nødvendig for at gengive dataene.

I Outlook Online kan du opleve langsomme indlæsningstider, hver gang du skifter mellem Kalender og din postkasse, eller langsomme sideindlæsninger i SharePoint. Der er dog andre symptomer, der ikke er anført her.

Proxygodkendelse er en indstilling på udgående proxyserver. Hvis det medfører problemer med ydeevnen med Office 365, skal du kontakte netværksteamet.

Værktøjer

• Netmon
• Wireshark

Hvad skal du søge efter?

Proxygodkendelse finder sted, når en ny TCP-session skal spundes, ofte for at anmode om filer eller oplysninger fra serveren eller for at angive oplysninger. Du kan f.eks. se proxygodkendelse omkring HTTP GET- eller HTTP POST-anmodninger. Hvis du vil se de rammer, hvor du godkender anmodninger i din sporing, skal du føje kolonnen 'NTLMSSP Summary' til Netmon og filtrere efter .property.NTLMSSPSummary. Hvis du vil se, hvor lang tid godkendelsen tager, skal du tilføje kolonnen Time Delta.

Sådan føjer du en kolonne til Netmon:

1. Højreklik på en kolonne, f.eks Beskrivelse.
2. Klik på Vælg kolonner.
3. Find NTLMSSP Summary and Time Delta på listen, og klik på Tilføj.
4. Flyt de nye kolonner på plads før eller bag kolonnen Beskrivelse , så du kan læse dem side om side.
5. Klik på OK.

Selvom du ikke tilføjer kolonnen, fungerer Netmon-filteret. Men din fejlfinding bliver meget nemmere, hvis du kan se, hvilken fase af godkendelse du er i.

Når du leder efter forekomster af proxygodkendelse, skal du undersøge alle rammer, hvor der er en NTLM-udfordring, eller der findes en Godkendelsesmeddelelse. Hvis det er nødvendigt, skal du højreklikke på det specifikke stykke trafik og Find samtaler TCP > . Vær opmærksom på deltaværdierne for tid i disse samtaler.

En fire sekunders forsinkelse i proxygodkendelse som vist i Wireshark. Deltaet Tid fra forrige viste rammekolonne blev foretaget ved at højreklikke på feltet med det samme navn i rammedetaljerne og vælge Tilføj som kolonne.

DNS-ydeevne

Navneopløsningen fungerer bedst og hurtigst muligt, når den finder sted så tæt på klientens land/område som muligt.

Hvis DNS-navnefortsættelse finder sted oversøisk, kan det føje sekunder til sidebelastninger. Ideelt set sker navnefortsættelse på under 100 ms. Hvis ikke, bør du undersøge det nærmere.

Tip

Er du ikke sikker på, hvordan Client Connectivity fungerer i Office 365? Se dokumentet Reference til klientforbindelsen her.

Værktøjer

• Netmon
• Wireshark
• PsPing

Hvad skal du søge efter?

Analyse af DNS-ydeevnen er normalt et andet job for en netværkssporing. PsPing er dog også nyttigt i forbindelse med afgørelsen af en mulig årsag.

DNS-trafik er baseret på TCP- og UDP-anmodninger, og svar er tydeligt markeret med et id, der hjælper med at matche en bestemt anmodning med dets specifikke svar. Du får vist DNS-trafik, når SharePoint f.eks. bruger et netværksnavn eller en URL-adresse på en webside. Som tommelfingerregel kører det meste af denne trafik, undtagen når du overfører zoner, over UDP.

I både Netmon og Wireshark er det mest grundlæggende filter, der lader dig se på DNS-trafik, simpelthen dns. Sørg for at bruge små bogstaver, når du angiver filteret. Husk at rydde din DNS-løsningscache, før du begynder at genskabe problemet på klientcomputeren. Hvis du f.eks. har en langsom SharePoint-sideindlæsning for startsiden, skal du lukke alle browsere, åbne en ny browser, starte sporing, rydde DNS-fortolkercachen og gå til dit SharePoint-websted. Når hele siden er løst, skal du stoppe og gemme sporingen.

Du vil se på tidsforskydningen her. Det kan også være nyttigt at føje kolonnen Time Delta til Netmon, som du kan gøre ved at udføre disse trin:

1. Højreklik på en kolonne, f.eks Beskrivelse.
2. Klik på Vælg kolonner.
3. Find Time Delta på listen, og klik på Tilføj.
4. Flyt den nye kolonne på plads før eller bag kolonnen Beskrivelse , så du kan læse dem side om side.
5. Klik på OK.

Hvis du finder en forespørgsel af interesse, kan du overveje at isolere den ved at højreklikke på forespørgslen i panelet med rammeoplysninger og vælge Find samtaler>DNS. Bemærk, at panelet Netværkssamtaler hopper direkte til den specifikke samtale i dens log over UDP-trafik.

I Wireshark kan du oprette en kolonne til DNS-tid. Tag din sporing (eller åbn en sporing) i Wireshark, og filtrer efter dnseller, mere nyttigt, dns.time. Klik på en HVILKEN som helst DNS-forespørgsel, og udvid Domain Name System (response) detaljerne i panelet, der viser detaljer. Du får vist et felt for tid (f.eks. [Time: 0.001111100 seconds]. Højreklik på dette tidspunkt, og vælg Anvend som kolonne. Dette giver dig en tidskolonne , hvor du hurtigere kan sortere sporingen. Klik på den nye kolonne for at sortere efter faldende værdier for at se, hvilket DNS-kald der tog længst tid at løse.

En gennemgang af SharePoint, der er filtreret i Wireshark efter (med små bogstaver) dns.time, hvor tiden fra detaljerne er angivet i en kolonne og sorteret stigende.

Hvis du vil undersøge DNS-opløsningstiden mere, kan du prøve en PsPing mod den DNS-port, psping <IP address of DNS server>:53der bruges af TCP (f.eks. ). Kan du stadig se et problem med ydeevnen? Hvis du gør det, er der større sandsynlighed for, at problemet er et bredere netværksproblem end et problem med specifikt det DNS-program, du er ved at løse. Det er også værd at nævne, at en ping til outlook.office365.com vil fortælle dig, hvor DNS-navnefortsættelsen for Outlook Online finder sted (f.eks. outlook-namnorthwest.office365.com).

Hvis problemet ser ud til at være DNS-specifikt, kan det være nødvendigt at kontakte it-afdelingen for at se på DNS-konfigurationer og DNS-videresendere for at undersøge problemet yderligere.

Proxyskalerbarhed

Tjenester som Outlook Online i Office 365 tildele klienter flere langsigtede forbindelser. Derfor kan hver bruger bruge flere forbindelser, der kræver en længere levetid.

Værktøjer

Matematik

Hvad skal du søge efter?

Der er intet værktøj til netværkssporing eller fejlfinding, der er specifikt for dette. Den er i stedet baseret på beregninger af båndbredde, der giver begrænsninger og andre variabler.

Maksimal TCP-segmentstørrelse

Fundet i SYN – SYN/ACK. Udfør denne kontrol af en hvilken som helst netværkssporing, du har foretaget, for at sikre, at TCP-pakker er konfigureret til at indeholde den maksimale datamængde.

Målet er at se en MSS på 1.460 byte til overførsel af data. Hvis du står bag en proxy, eller du bruger en NAT, skal du huske at køre denne test fra klient til proxy/udgående/NAT og fra proxy/udgående/NAT til Office 365 for at få de bedste resultater! Dette er forskellige TCP-sessioner.

Værktøjer

Netmon

Hvad skal du søge efter?

TCP Max Segment Size (MSS) er en anden parameter for det trevejs-håndtryk i netværkssporingen, der betyder, at du finder de data, du har brug for, i pakken SYN - SYN/ACK. MSS er ret enkelt at se.

Åbn en hvilken som helst netværkssporing for ydeevnen, og find den forbindelse, du er nysgerrig efter, eller som demonstrerer problemet med ydeevnen.

Bemærk!

Hvis du kigger på en sporing og har brug for at finde den trafik, der er relevant for din samtale, skal du filtrere efter klientens IP-adresse eller proxyserverens IP-adresse eller udgående punkt eller begge dele. Hvis du går direkte, skal du pinge den URL-adresse, du tester for IP-adressen for Office 365 i sporingen, og filtrere efter den.

Ser du på sporingen brugt? Prøv at bruge filtre til at orientere dig selv. I Netmon skal du køre en søgning, der er baseret på URL-adressen, f.eks Containsbin(framedata, ascii, "sphybridExample"). , tage rammenummeret til efterretning.

I Wireshark skal du bruge noget i stil med frame contains "sphybridExample". Hvis du bemærker, at du har fundet RWS-trafik (Remote Winsock) (det kan se ud som en [PSH, ACK] i Wireshark), skal du huske, at RWS-forbindelser kan ses kort før relevante SYN - SYN/ACKs, som beskrevet tidligere.

På dette tidspunkt kan du optage rammenummeret, slippe filteret og klikke på Al trafik i vinduet Netværkssamtaler i Netmon for at se på den nærmeste SYN.

Det er vigtigt, at hvis du ikke modtog nogen af IP-adresseoplysningerne på tidspunktet for sporingen, vil det give dig IP-adresser at filtrere efter, hvis du finder din URL-adresse i sporingen (f.eks. en del af sphybridExample-my.sharepoint.com. ).

Find forbindelsen i den sporing, du er interesseret i at se. Det kan du gøre ved enten at scanne sporingen ved at filtrere efter IP-adresser eller ved at vælge bestemte samtale-id'er ved hjælp af vinduet Netværkssamtaler i Netmon. Når du har fundet SYN-pakken, skal du udvide TCP (i Netmon) eller Transmission Control Protocol (i Wireshark) i panelet Frame Details. Udvid TCP-indstillinger og MaxSegmentSize. Find den relaterede SYN-ACK-ramme, og udvid TCP-indstillinger og MaxSegmentSize. Den mindste af de to værdier er din maksimale segmentstørrelse. På dette billede bruger jeg den indbyggede kolonne i Netmon kaldet TCP-fejlfinding.

Den indbyggede kolonne er øverst i panelet Rammedetaljer . Hvis du vil skifte tilbage til den normale visning, skal du klikke på Kolonner igen og derefter vælge Tidszone.

Her er en filtreret sporing i Wireshark. Der er et filter, der er specifikt for MSS-værdien (tcp.options.mss). Rammerne for en SYN, SYN/ACK, ACK-håndtryk er sammenkædet nederst i Wireshark, der svarer til Frame Details (så ramme 47 ACK, links til 46 SYN/ACK, links til 43 SYN) for at gøre denne form for arbejde nemmere.

Hvis du har brug for at kontrollere Selektiv anerkendelse (næste emne i denne matrix), skal du ikke lukke sporingen!

Selektiv anerkendelse

Fundet i SYN – SYN/ACK. Skal rapporteres som Tilladt i både SYN og SYN/ACK. SÆKKE (Selective Acknowledgment) giver mulighed for problemfri videretransmission af data, når en pakke eller pakker forsvinder. Enheder kan deaktivere denne funktion, hvilket kan medføre problemer med ydeevnen.

Hvis du står bag en proxy, eller du bruger en NAT, skal du huske at køre denne test fra klient til proxy/udgående/NAT og fra proxy/udgående/NAT til Office 365 for at få de bedste resultater! Dette er forskellige TCP-sessioner.

Værktøjer

Netmon

Hvad skal du søge efter?

SACK (Selective Acknowledgment) er en anden parameter i SYN-SYN/ACK-håndtrykket. Du kan filtrere din sporing efter SYN – SYN/ACK på mange måder.

Find den forbindelse i sporingen, som du er interesseret i at se, enten ved at scanne sporingen, filtrere efter IP-adresser eller ved at klikke på et samtale-id ved hjælp af vinduet Netværkssamtaler i Netmon. Når du har fundet SYN-pakken, skal du udvide TCP i Netmon eller Transmission Control Protocol i Wireshark i afsnittet Frame Details. Udvid TCP-indstillinger og derefter SACK. Find den relaterede SYN-ACK-ramme, og udvid TCP-indstillinger og feltet SACK. Sørg for, at SACK er tilladt i både SYN og SYN/ACK. Her er SACK-værdier som set i både Netmon og Wireshark.

DNS Geolocation

Hvor i verden Office 365 forsøger at løse dit DNS-opkald, påvirker din forbindelseshastighed.

Når det første DNS-opslag er fuldført i Outlook Online, bruges placeringen af den pågældende DNS til at oprette forbindelse til dit nærmeste datacenter. Du får forbindelse til en Outlook Online CAS-server, som bruger backbone-netværket til at oprette forbindelse til det datacenter (dC), hvor dine data er gemt. Det her er hurtigere.

Når du tilgår SharePoint, sendes en bruger, der rejser i udlandet, til deres aktive datacenter – det er den dC, hvis placering er baseret på deres SPO-lejers hjemmebase (så en dC i USA, hvis brugeren er baseret på USA).

Lync Online har aktive noder i mere end én dC ad gangen. Når der sendes anmodninger om lync onlineforekomster, bestemmer Microsofts DNS, hvor i verden anmodningen kom fra, og returnerer IP-adresser fra den nærmeste regionale dC, hvor Lync Online er aktiv.

Tip

Har du brug for at vide mere om, hvordan klienter opretter forbindelse til Office 365? Se artiklen Reference til Client Connectivity (og dens nyttige grafik).

Værktøjer

• Ping
• PsPing

Hvad skal du søge efter?

Anmodninger om navnefortsættelse fra klientens DNS-servere til Microsofts DNS-servere bør i de fleste tilfælde resultere i, at Microsoft DNS returnerer IP-adressen for et regionalt datacenter (dC). Hvad betyder det for dig? Hvis dit hovedkvarter befinder sig i Bengaluru i Indien, men du rejser i USA, skal Microsofts DNS-servere give dig IP-adresser til datacentre i USA – et regionalt datacenter, når din browser anmoder om Outlook Online. Hvis der er brug for mail fra Outlook, bevæger disse data sig på tværs af Microsofts hurtige backbone-netværk mellem datacentrene.

DNS fungerer hurtigst, når navnefortsættelsen udføres så tæt på brugerens placering som muligt. Hvis du er i Europa, vil du gå til et Microsoft DNS i Europa og (ideelt set) håndtere et datacenter i Europa. Ydeevnen fra en klient i Europa, der går til DNS, og et datacenter i Usa vil være langsommere.

Kør pingværktøjet mod outlook.office365.com for at finde ud af, hvor i verden din DNS-anmodning distribueres. Hvis du er i Europa, bør du se et svar fra noget i stil med outlook-emeawest.office365.com. I Amerika, forventer noget i stil med outlook-namnorthwest.office365.com.

Åbn kommandoprompten på klientcomputeren (via Start > kør > cmd eller Windows-nøgletype > cmd). Skriv ping outlook.office365.com, og tryk på ENTER. Husk, at du skal angive -4, hvis du vil angive ping via IPv4. Du kan muligvis ikke få et svar fra ICMP-pakkerne, men du bør se navnet på den DNS, som anmodningen blev sendt til. Hvis du vil se ventetidsnumrene for denne forbindelse, kan du prøve PsPing til IP-adressen på den server, der returneres af ping.

fejlfinding af Office 365 program

Værktøjer

• Netmon
• HTTPWatch
• F12 Console i browseren

Vi dækker ikke værktøjer, der bruges i programspecifik fejlfinding i denne netværksspecifikke artikel. Men du kan finde ressourcer, du kan bruge på denne side.

Relaterede artikler

Administrere Office 365-slutpunkter

Ofte stillede spørgsmål om Office 365 slutpunkter