Feilsøkingsplan for ytelsesproblemer i Office 365

Viktig: Denne artikkelen er maskinoversatt, se ansvarsfraskrivelsen. Du finner den engelske versjonen av artikkelen her som referanse.

Trenger du å vite hva som må gjøres til å identifisere og løse ventetid, henger og dårlig ytelse mellom SharePoint Online, OneDrive for Business, Exchange Online eller Skype for Business Online og klientdatamaskinen? Før du ringer kundestøtten, kan denne artikkelen hjelpe deg med å feilsøke Office 365-ytelsesproblemer og løse noen av de vanligste problemene selv.

Denne artikkelen er egentlig et eksempel på en handlingsplan du kan bruke til å registrere verdifulle data om ytelsesproblemer underveis. Enkelte vanlige problemer er også oppført her.

Hvis nettverksytelse er nytt for deg og du ønsker å lage en langsiktig plan for å overvåke ytelsen mellom klientmaskinene og Office 365, kan du ta en titt på Ytelsesjustering og feilsøking i Office 365 – Administrator og IT-ekspert.

Eksempel på handlingsplan for feilsøking av ytelsesproblemer

Denne handlingsplanen består av to deler: forberedelsen og loggingen. Hvis du opplever problemer med ytelsen akkurat nå og du må samle inn data, kan du begynne å bruke denne planen umiddelbart.

Gjør klar klientdatamaskinen

  • Finn en klientdatamaskin som kan reprodusere ytelsesproblemene. Den skal brukes i løpet av feilsøkingen.

  • Skriv ned trinnene som gir problemer med ytelsen slik at du er klar til å gjennomføre testen.

  • Installer verktøyene for innsamling og registrering av informasjon:

    • Installer Netmon 3.4 (eller bruk et tilsvarende nettverkssporingsverktøy).

    • Installer gratisversjonen Basic Edition av HTTPWatch (eller bruk et tilsvarende nettverkssporingsverktøy).

    • Bruk et skjerminnspillingsprogram eller kjør trinnregistrereren (PSR.exe) som følger med Windows Vista og nyere, for å holde oversikt over trinnene du utfører ta under testingen.

Logg ytelsesproblemet

  • Lukk alle overflødige nettlesere.

  • Start trinnregistrererer eller et annet skjerminnspillingsprogram.

  • Begynn å spille inn med Netmon (eller et nettverkssporingsverktøy).

  • Tøm DNS-bufferen på klientdatamaskinen fra kommandolinjen ved å skrive inn ipconfig /flushdns.

  • Start en ny nettleserøkt, og slå på HTTPWatch.

  • Valgfritt: Hvis du tester Exchange Online, kan du kjøre verktøyet Exchange Client Performance Analyzer i administrasjonskonsollen for Office 365.

  • Reproduser nøyaktig de trinnene som gir ytelsesproblemet.

  • Stopp Netmon eller det andre verktøyets sporing.

  • Kjør en sporingsrute til Office 365-abonnementet på kommandolinjen ved å skrive inn følgende kommando og deretter trykke ENTER:

    tracert <abonnementsnavn>.onmicrosoft.com

  • Stopp trinnregistrereren, og lagre videoen. Pass på å ta med dato og klokkeslettet for innspillingen og om den viser god eller dårlig ytelse.

  • Lagre sporingsfilene. Vi gjentar: Pass på å ta med dato og klokkeslettet for innspillingen og om den viser god eller dårlig ytelse.

Hvis du ikke vet hvordan du kjører de verktøyene vi har nevnt i denne artikkelen, så vær litt tålmodig. Vi skal forklare det nå. Hvis du er vant til å kjøre denne typen nettverksregistrering, kan du hoppe til delen Hvordan du leser sporene, som beskriver hvordan du filtrerer og leser logger.

Tøm DNS-bufferen først

Hvorfor? Når du tømmer DNS-bufferen, starter du testene fra et friskt utgangspunkt. Når du tømmer bufferen, tilbakestiller du innholdet i DNS-løseren til de mest oppdaterte oppføringene. Husk at selv om du tømmer bufferen, fjerner du ikke oppføringene til vertsfilen. Hvis du bruker oppføringene i vertsfilen mye, bør du kopiere disse oppføringene til en fil i en annen katalog og deretter tømme vertsfilen.

Tøm DNS resolver-bufferen

  1. Åpne ledeteksten (enten Start > Kjør > cmd eller Windows-tasten > cmd).

  2. Skriv inn følgende kommando, og trykk ENTER:

    ipconfig /flushdns

Netmon

Microsofts nettverket overvåking verktøyet (Netmon) analyserer pakker, som er trafikk som går mellom datamaskiner på nettverk. Se etter mislykkede pakker ved hjelp av Netmon spor trafikk med Office 365 kan du ta visning, og Les pakke topptekster, identifisere mellomliggende enheter, kontrollerer viktige innstillinger på nettverksmaskinvaren, og følg flyten i trafikk mellom datamaskiner på firmanettverket og Office 365. Ettersom faktisk brødteksten trafikken er kryptert, det vil si det (reiser på port 443 via SSL/TLS, du kan ikke lese filer som sendes. I stedet kan få du en ufiltrert sporing av banen i pakke utfører som kan hjelpe deg å spore problemet virkemåten.

Pass på at du ikke bruker et filter på dette tidspunktet. I stedet bør du gjennomføre trinnene og demonstrere problemet før du stopper sporet og lagrer det.

Når du har installert Netmon 3.4, åpner du verktøyet og gjør følgende:

Lag et Netmon-spor og Reproduser problemet

  1. Start Netmon 3.4.

    Det finnes tre ruter på startsiden: Nylige fanger opp, Velg nettverk og Getting Started with Microsoft nettverket skjerm 3.4. Legg merke til. Velg nettverk-panelet også gir deg en oversikt over standard nettverkene du kan ta. Pass på at nettverkskort velges her.

  2. Klikk New Capture øverst på Start-siden. Dette legger til fanen Capture 1 ved siden av Start-fanen.

    Nemon-brukergrensesnittet med knappene Nytt skjermklipp, Start og Stopp uthevet.

  3. Klikk Start på verktøylinjen for å ta et enkelt bilde.

  4. Reprodusere trinnene som leder til et ytelsesproblem.

  5. Klikk Stopp > Fil > Lagre som. Husk å oppgi dato og klokkeslett med tidssonen og nevne om den viser dårlig eller god ytelse.

HTTPWatch

HTTPWatch kommer inn belastet, og en gratis utgave. Gratis Basic Edition dekker alt du trenger for denne testen. HTTPWatch skjermer network trafikk og siden innlastingstiden direkte fra nettleservinduet. HTTPWatch er en plugin-modul i Internet Explorer som beskriver grafisk ytelse. Analysen kan lagres og vises i HTTPWatch Studio.

Kommentarer: 

  • Hvis du bruker en annen nettleser, for eksempel Firefox eller Google Chrome, eller hvis du ikke kan installere HTTPWatch i Internet Explorer, åpner du et nytt nettleservindu og trykker F12 på tastaturet. Du skal kunne se utviklerverktøyet i et eget vindu nederst i nettleseren. Hvis du bruker Opera, trykker du CTRL+SKIFT+I for Web Inspector og klikker deretter fanen Nettverk og fullfører testingen som er beskrevet nedenfor. Informasjonen vil være litt forskjellig, men sidelastingstidene vises fremdeles i millisekunder.

  • HTTPWatch er også svært nyttig for problemer med sidelastingstider for SharePoint Online.

Kjøre HTTPWatch og reprodusere problemet

  1. HTTPWatch er en plugin-modul, dermed varierer det litt når du bruker verktøyet i nettleseren, avhengig av hvilken versjon av Internet Explorer du har. Vanligvis kan du finne HTTPWatch under kommandolinjen i Internet Explorer-nettleseren.

    Hvis du ikke ser HTTPWatch plugin-modulen i nettleservinduet, kontrollerer du versjonen av nettleseren ved å klikke Hjelp > Om. I nyere versjoner av Internet Explorer klikker du tannhjulsymbolet og Om Internet Explorer. Høyreklikk menylinjen i Internet Explorer og klikk feltet Kommandoer for å starte Kommando-feltet. Tidligere har HTTPWatch vært forbundet både med Kommando- og Explorer-feltet. Hvis du ikke umiddelbart ser ikonet når du installerer (også etter omstart), må du kontrollere Verktøy og verktøylinjene for ikonet. Husk at verktøylinjer kan tilpasses, og alternativer kan legges til i dem.

    Internet Explorer-kommandoverktøylinjen med HTTPWatch-ikonet.

  2. Start HTTPWatch i et nettleservindu i Internet Explorer. Det vises forankret til nettleseren nederst i dette vinduet. Klikk Registrer.

  3. Reproduser den nøyaktige fremgangsmåten involvert i ytelsesproblemet. Klikk på Stopp-knappen i HTTPWatch.

  4. Lagre HTTPWatch-filen eller Send via e-post. Husk å gi filen navn slik at den inneholder dato og klokkeslett og en indikasjon på om Watch-filen din inneholder en demonstrasjon av god eller dårlig ytelse.

    HTTPWatch som viser Nettverk-fanen for en sidelasting på startsiden for Office 365.

    Dette skjermbildet er fra Professional-versjonen av HTTPWatch. Du kan åpne sporinger som er gjort i Basic-versjonen på en datamaskin med en Professional-versjon og lese dem der. Ekstra informasjon kan være tilgjengelig fra sporingen med denne metoden.

Problem Steps Recorder

Steps Recorder, eller PSR.exe, lar deg registrere problemer etter hvert som de oppstår. Det er et svært nyttig verktøy og enkelt å kjøre.

Kjøre problemet Trinnregistrereren (PSR.exe) til å registrere arbeidet

  1. Bruk enten Start > Kjør > skriv inn PSR.exe > OK, eller klikk Windows-tasten > skriv inn PSR.exe > og trykk deretter ENTER.

  2. Når det lille PSR.exe vinduet vises, klikker du Start registrering og reproduserer trinnene som gjenskaper ytelsesproblemet.

    Du kan legge til kommentarer etter behov ved å klikke Legg til kommentarer.

  3. Klikk Stopp post når du har fullført trinnene. Hvis ytelsesproblemet er en side gjengivelse, venter du til siden for å gjengi før du stopper innspillingen.

  4. Klikk Lagre.

Et skjermbilde av trinnregistreringen eller PSR.exe.

Dato og klokkeslett er registrert for deg. Dette koblinger til PSR til Netmon-sporing og HTTPWatch i tid og hjelper med å feilsøke presisjon. Dato og klokkeslett i PSR posten kan vise at et minutt gått mellom påloggingen og søk etter URL-adressen og delvis gjengivelse av admin-området, for eksempel.

Lese sporene dine

Det er ikke mulig å lære alt du trenger å vite om nettverk og feilsøking av ytelse fra en artikkel. Det krever erfaring og kunnskap om hvordan nettverket ditt fungerer og vanligvis yter, for at du skal bli god på ytelse. Men det er mulig å sette opp en liste over de problemene som forekommer oftest og vise hvordan verktøy kan gjøre det enklere for deg å eliminere de vanligste problemene.

Hvis du vil fortsette ferdigheter lese Nettverkssporinger for Office 365-nettsteder, er det ingen bedre læreren enn å opprette spor av sideinnlastingen regelmessig og få erfaring med å lese dem. Hvis du for eksempel når du har muligheten, laste inn en Office 365-tjenesten og spore prosessen. Filtrere sporingen for DNS-trafikk eller søke FrameData for navnet på tjenesten du viste. Skanne sporingen for å få en oversikt over trinnene som oppstår når tjenesten lastes inn. Dermed kan du lære hvilke normal sidelasting skal se ut, og når det gjelder feilsøking, spesielt rundt ytelse, sammenligne lurt å ugyldige sporinger kan lære deg mye.

Netmon bruker Microsoft Intellisense i feltet Vis filter. IntelliSense eller intelligent koden er fullført, er denne stikk der du skriver inn i en periode, og alle tilgjengelige alternativene vises i en rullegardinliste for rullegardinlisten. Hvis du for eksempel er bekymret for skalering av TCP-vinduet, kan du finne frem til et filter (for eksempel .protocol.tcp.window < 100) av det vil si at.

Skjermbilde av Netmon som viser at Vis filter-feltet bruker IntelliSense.

Netmon-spor kan inneholder mye trafikk. Hvis du ikke erfaring med å lese dem, er det sannsynlig du vil være overveldende åpne sporingen første gang. Er det første du vil skille signalet fra bakgrunnsstøy i sporingen. Du har testet mot Office 365, og som er trafikken du vil se. Hvis du brukte til å navigere gjennom sporinger, må du kanskje ikke denne listen.

Trafikk mellom klienten og Office 365 beveger seg via TLS, noe som betyr at hoveddelen av trafikken vil bli kryptert og ikke leselig i en generell Netmon-sporing. Ytelsesanalysen trenger ikke å vite detaljene i informasjonen i pakken. Den er imidlertid veldig interessert i pakkehodene og informasjonen de inneholder.

Tips for å få en god sporing

  • Kjenn verdien av IPv4- eller IPv6-adressene til klientdatamaskinen. Du kan få dette fra ledeteksten ved å skrive inn IPConfig og deretter trykke ENTER. Kjenner du denne adressen, kan du enkelt se om trafikk i sporingen involverer klientdatamaskinen direkte. Hvis det er en kjent proxy, kan du også pinge den og få IP-adressen.

  • Tøm DNS Resolver-bufferen og, hvis mulig, lukk alle nettlesere unntatt den du kjører testene i. Hvis du ikke kan gjøre dette, for eksempel hvis brukerstøtte bruker et nettleserbasert verktøy for å se skrivebordet på klientdatamaskinen, må du være forberedt på å filtrere sporinger.

  • Finn Office 365-tjenesten du bruker i en opptatt sporing. Hvis du har aldri eller sjelden Sett trafikken før, er et nyttig trinn i å skille ytelsesproblemet fra andre nettverk støy. Det finnes noen metoder for å gjøre dette. Direkte før testen, kan du bruke ping eller PsPing til URL-adressen for den bestemte tjenesten (ping outlook.office365.com og/eller psping -4 microsoft-my.sharepoint.com:443, eksempler). Du kan også enkelt finne det PsPing i en Netmon-sporing (etter prosessnavnet). Som gir deg et sted å begynne å se.

    Hvis du bare bruker Netmon-sporing på det tidspunktet problemet oppstår, er det også i orden. Du kan bruke et filter, for eksempel ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"), for å orientere deg. Du kan registrere rammenummeret fra sporingsfilen. Du vil kanskje også bla gjennom ruten Rammesammendrag helt til høyre og se etter Samtale-ID-kolonnen. Det er angitt et tall for ID-en til denne bestemte samtalen som du også kan ta registrere se nærmere på isolert senere. Husk å fjerne dette filteret før du bruker annen filtrering.

    Tips!: Netmon har mange nyttige, innebygde filtre. Prøv knappen Last inn filter øverst på filtreringsruten Vis.

    Finn IP ved hjelp av PSPing på kommandolinjen på klientdatamaskinen.

    Netmon-sporing fra klienten som viser den samme PSPing-kommandoen via filteret TCP.Flags.Syn == 1.

    Bli kjent med trafikken din, og lær å finne informasjonen du trenger. Du kan for eksempel lære å finne ut hvilken pakke i sporingen som har den første referansen til Office 365-tjenesten du bruker (for eksempel Outlook).

Bruker vi Office 365 Outlook Online som eksempel, begynner trafikken omtrent slik:

  • DNS standardspørring og DNS-svar for outlook.office365.com med samsvarende spørrings-ID-er. Det er viktig å merke seg tidsforskyvningen for denne omløpstiden, i tillegg til hvor i verden den globale DNS for Office 365 sender forespørselen for navneløsing. Ideelt sett så lokalt som mulig, i stedet for til den andre siden av kloden. (Dette kan være etterfulgt av en viss DNS-trafikk ved pålogging på nettet.)

  • En HTTP GET-forespørsel med statusrapport flyttes permanent (301)

  • RWS-trafikk inkludert RWS-tilkoblingsforespørsler og tilkoblingssvar. (Dette er Remote Winsock, som oppretter en tilkobling for deg.)

  • En TCP SYN og SYN/ACK for TCP-samtale. Mange innstillingene i denne samtalen påvirke ytelsen.

  • Deretter en serie med TLS:TLS-trafikk, som er der hvor TLS-håndtrykket og TLS-sertifikatsamtalene finner sted. (Husk at dataene er kryptert via SSL/TLS.)

Alle delene av trafikken er viktige og koblet til, men små deler av sporingen inneholder informasjon som er spesielt viktig med hensyn til feilsøking av ytelse, så vi skal fokusere på disse områdene. Siden vi har gjort nok feilsøking av ytelse i Office 365 hos Microsoft til å samle en liste over de ti vanligste problemene, vil vi dessuten fokusere på disse problemene og hvordan du bruker verktøyene vi har til å luke dem ut.

Hvis du ikke har installert dem allerede, kan du se forslag til flere verktøy nedenfor. Der det er mulig. Vi gir koblinger til installasjonspunktene. Listen inneholder vanlige nettverkssporingsverktøy som Netmon og Wireshark, men bruk et hvilket som helst sporingsverktøy du er fortrolig med, og som du er vant til å filtrere nettverkstrafikk med. Når du tester, må du huske følgende:

  • Lukk nettlesere, og test med bare én leser kjører - dermed reduseres generell trafikken du ta. Gjør det for en mindre trafikk sporing.

  • Tøm DNS Resolver-bufferen på klientdatamaskinen – Da begynner du helt forfra når du starter å registrere, slik at du får en renere sporing.

Noen vanlige problemer

Noen vanlige problemer som kan oppstå og hvordan du finner dem i nettverkssporingen.

Hovedproblem

Verktøy

Hva du er ute etter

Skalering av TCP-vinduer

  • Funnet i SYN–SYN/ACK.

  • Eldre eller aldrende maskinvare kan ha problemer med å dra fordel av skalering av TCP-vinduer.

  • Uten riktige innstillinger for skalering av TCP-vinduer fylles standard-16-bitersbufferen i TCP-hodet opp i løpet av millisekunder.

  • Trafikk kan ikke fortsette å sende før klienten får en bekreftelse på at de opprinnelige dataene er mottatt, noe som skaper forsinkelser.

Netmon

Wireshark

Se etter SYN-SYN/ACK-trafikk i nettverkssporingen.

Bruke et filter som tcp.flags.syn == 1i Netmon. Dette filteret er den samme i Wireshark.

Filter i Netmon eller Wireshark for Syn-pakker for begge verktøyene: TCP.Flags.Syn == 1.

Legg merke til at det er en kildeport for hvert SYN-port (SrcPort)-nummer som samsvarer i målporten (DstPort) til den relaterte godkjenningen (SYN/ACK).

Utvid først SYN, og deretter den relaterte SYN/ACK, for å se den Windows-skaleringsverdien som brukes av nettverkstilkoblingen.

Grafikk som viser hvordan du tilpasser SrcPort til DstPort i en sporing slik at du får tidsdelta.

Innstillinger for TCP-tid uten aktivitet

  • Historisk sett er de fleste perimeternettverk konfigurert for midlertidige tilkoblinger, noe som betyr at inaktive tilkoblinger vanligvis blir terminert.

  • Inaktive TCP-økter kan avsluttes av proxyer og brannmurer ved mer enn 100 til 300 sekunder.

  • Dette er problematisk for Outlook Online fordi det oppretter og bruker langsiktige tilkoblinger, enten de er inaktive eller ikke.

  • Når tilkoblinger blir avsluttet av proxy- eller brannmurenheter, blir klienten ikke informert, og et forsøk på å bruke Outlook Online betyr at en klientdatamaskin vil prøve, gjentatte ganger, vil gjenopplive tilkoblingen før du foretar en ny.

  • Du kan se heng eller spørsmål i produktet, eller at sidene lastes langsomt.

Netmon

Wireshark

I Netmon ser du i tidsforskyvningsfeltet etter en rundtur. En rundtur er tiden fra klienten sender en forespørsel til tjeneren og mottar et svar tilbake. Kontroller mellom klienten og grensekontrollerpunktet (f.eks. Klient --> Proxy), eller klienten til Office 365 (klient --> Office 365). Du kan se dette i mange typer pakker.

Eksempelvis kan kan filteret i Netmon se 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.

Tips: 

  • Vet du ikke om IP-adressen i sporingen tilhører DNS-serveren din? Prøv å slå det opp på kommandolinjen. Klikk Start > Kjør > og skriv inn cmd, eller trykk Windows-tasten > og skriv cmd. Ved ledeteksten skriver du inn nslookup <the IP address from the network trace>. Bruk nslookup mot IP-adressen til din egen datamaskin for å teste.

  • Hvis du vil se en liste over Microsofts IP-områder, kan du se Office 365 nettadresser og IP-adresseområder.

Hvis det oppstår et problem, forventer du lang tid forskyver skal vises, i dette tilfellet (Outlook Online), spesielt i TLS:TLS-pakker som viser tekstblokk Application Data (for eksempel i Netmon kan du finne programmet verdien SANN via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). En problemfri fremdrift i tiden skal vises på tvers av økten. Hvis du ser forsinkelser når du oppdaterer Outlook Online, kan dette skyldes en stor grad av tilbakestiller sendes.

Ventetid/Rundtur-tid

  • Ventetiden er et mål som kan endres mye avhenger av mange variabler, for eksempel oppgradering av aldrende enheter, legge til et stort antall brukere til et nettverk, og prosentvise totale båndbredden som brukes av andre aktiviteter på en nettverkstilkobling.

  • Båndbreddekalkulatorer for Office 365 er tilgjengelig fra denne siden Nettverksplanlegging og ytelsesjustering for Office 365.

  • Vil du måle hastigheten på tilkoblingen din eller ISP-tilkoblingens båndbredde? Prøv dette nettstedet (eller tilsvarende nettsteder): Speedtests offisielle nettsted og Pingtest.

Ping

PsPing

Netmon

Wireshark

Hvis du vil spore ventetid i en sporing, vil du dra nytte av å ha registrert klientdatamaskinens IP-adresse og IP-adressen til DNS-serveren i Office 365. Dette er for å gjøre det enklere å filtrere sporingene. Hvis du kobler deg til via en proxy, trenger du klientdatamaskinens IP-adresse, proxyens/grensekontrollerens IP-adresse og Office 365 DNS-IP-adresse for å gjøre arbeidet lettere.

Sender du en ping-forespørsel til outlook.office365.com, får du vite navnet på datasenteret som mottar forespørselen, selv om ping ikke får koblet seg til for å sende de sammenhengende varemerkede ICMP-pakkene. Hvis du bruker PsPing (et gratis verktøy som kan lastes ned), angir porten (443) og kanskje bruker IPv4 (-4), får du en gjennomsnittstid for rundtur for pakker som er sendt. Dette fungerer for andre nettadresser i Office 365-tjenestene, for eksempel psping -4 yourSite.sharepoint.com:443. Du kan faktisk angi en rekke ping-er for å få et større utvalg for gjennomsnittet ditt, prøv noe slikt som: psping -4 -n 20 yourSite-my.sharepoint.com:443.

Merknad: PsPing sender ikke ICMP-pakker. Det ping-er med TCP-pakker over en bestemt port, slik at du kan bruke en du vet er åpen. I Office 365, som bruker SSL/TLS, kan du prøve å feste port :443 til PsPing.

Skjermbilde som viser en ping løse outlook.office365.com, og en PSPing med 443 som gjør det samme, men også rapporterer et 6,5 ms gjennomsnittlig RTT.

Hvis du lastet den langsomme Office 365-siden mens du foretok en nettverkssporing, bør du filtrere en Netmon- eller Wireshark-sporing for DNS. Dette er én av de IP-adressene vi er ute etter.

Her er fremgangsmåten for å filtrere Netmon for å få IP-adressen (og se på DNS-ventetid). Dette eksemplet bruker outlook.office365.com, men kan også bruke nettadressen for en SharePoint Online-leier (for eksempel hithere.sharepoint.com).

  1. Ping nettadressen og ping outlook.office365.com registrer navnet og IP-adressen til DNS-serveren ping-forespørselen ble sendt til i resultatene.

    Ping-forespørsel til outlook.office365.com viser DNS og IP-adressen til namnorthwest.

  2. Network nettverksspore åpning av siden, eller handlingen som gir deg du et ytelsesproblem, eller, hvis du opplever lag ventetid ved ping, selve, nettverksspore den.

  3. Åpne sporingen i Netmon og filtrer for DNS (dette filteret fungerer også i Wireshark, men skiller mellom små og store bokstaver – dns). Siden du kjenner navnet på DNS-serveren fra ping kan du også filtrere raskere i Netmon slik: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), dette ser slik ut i Wireshark dns and frame contains "namnorthwest".

    Åpne svarpakken og klikk DNS i vinduet rammedetaljer i Netmon for å utvide det og få mer informasjon. I DNS-informasjonen finner du IP-adressen til DNS-serveren forespørselen gikk til i Office 365 – du trenger denne IP-adressen for neste trinn (PsPing-verktøyet). Fjern filteret, høyreklikk på DNS-svar i rammesammendraget i Netmon > Finn samtaler > DNS for å se DNS-spørringen og svaret side ved side.

    En sporing filtrert etter Finn samtaler og deretter DNS.

  4. Legg også merke til kolonnen Tidsforskyvning i Netmon mellom DNS-spørring og svar.

    Flere Netmon-resultater filtrert med DNS OG CONTAINSBIN(Framedata, ASCII, "namnorthwest") som viser svært lav tidsforskyvning mellom forespørsel og svar.

I neste trinn er enkel å installere og bruke PsPing verktøyet svært nyttig, både og fordi ICMP blokkeres ofte på brannmurer og PsPing sporer elegant ventetid i millisekunder. PsPing fullfører en TCP-tilkobling til en adresse og port (i vårt tilfelle åpen port 443).

  1. Installer PsPing.

  2. Åpne en ledetekst (Start > Kjør > skriv cmd, eller trykk Windows-tasten > skriv cmd) og endre katalog til katalogen der du installerte PsPing for å kjøre PsPing-kommandoen. I mine eksempler kan du se at jeg laget en Perf-mappe på roten av C. Du kan gjøre det samme for å få rask tilgang.

  3. Skriv inn kommandoen slik at du gjør PsPing mot IP-adressen til Office 365 DNS-serveren fra den tidligere Netmon-sporingen – husk å legge til portnummer. Med andre ord, psping -n 20 132.245.24.82:445. Dette gir deg et utvalg av 20 ping-er og den gjennomsnittlige ventetiden når PsPing stopper.

    Kommandoen PSPing psping -n 20 132.245.24.82:443 gir en gjennomsnittlig ventetid på 25,51 millisekunder.

Hvis du går til Office 365 via en proxy-server, er fremgangsmåten litt annerledes. Du må først kjøre PsPing på proxy-serveren for å få en gjennomsnittlig verdi for ventetid i millisekunder til proxyen/grensekontrolleren og tilbake, og deretter kjøre PsPing på proxyen, eller på en datamaskin med direkte Internett-tilkobling for å få den manglende verdien (den til Office 365 og tilbake).

Hvis du velger å kjøre PsPing fra proxyen, vil du ha to millisekund-verdier: klientdatamaskinen til proxy-serveren eller grensekontrollerpunktet, og proxy-serveren til Office 365. Og du er ferdig! I hvert fall med å registrere verdier.

Hvis du kjører PsPing på en annen klientdatamaskin som har en direkte tilkobling til Internett, det vil si uten proxy, må du to millisekund verdier: klientdatamaskinen proxyserveren eller utgangspunktet og klientdatamaskinen til Office 365. I dette tilfellet trekke fra verdien til klientdatamaskinen proxy-serveren eller grensekontrolleren punkt fra verdien til klientdatamaskinen til Office 365, og du må RTT tallene fra klientdatamaskinen til proxy-serveren eller utgangspunktet og fra proxy-serveren eller grensekontrolleren punkt Office 365.

Hvis du imidlertid kan finne en klientdatamaskin på den påvirkede plasseringen som er direkte tilkoblet, eller omgår proxyen, kan du velge å se om problemet reproduseres der til å begynne med, og deretter tester med det.

Som vist i en Netmon-sporing de ekstra millisekundene medføre ventetid, hvis det finnes nok av dem i en gitt økt.

Generell ventetid i Netmon, med Netmon standard Tidsdelta-kolonne lagt til rammesammendraget.

Merknad: IP-adressen din kan være annerledes enn IP-adressene som vises her, for eksempel kan ping returnere noe i likhet med 157.56.0.0/16 eller et lignende område. Hvis du vil ha en liste over områder som brukes av Office 365, kan du se Adresser og IP-adresseområder for Office 365. Husk å utvide alle nodene (det er en knapp øverst for dette) hvis du vil søke etter for eksempel 132,245.

Proxy-godkjenning

  • Dette gjelder bare hvis du går gjennom en proxy-server. Hvis ikke, kan du hoppe over disse trinnene.

  • Når den fungerer som den skal, skjer proxy-godkjenning konsekvent i løpet av millisekunder. Du skal ikke se uregelmessig, dårlig ytelse i høytrafikkperioder (for eksempel).

  • Hvis proxy-godkjenning er på, må du gå gjennom en godkjenningsprosess i bakgrunnen hver gang du foretar en ny TCP-tilkobling til Office 365 for å få informasjon. Når du for eksempel bytter fra kalenderen til e-post i Outlook Online, må du godkjenne. Og hvis en side viser medier eller data fra flere nettsteder eller steder i SharePoint Online, må du godkjenne for hver ulike TCP-tilkobling som er nødvendig for å gjengi dataene.

  • I Outlook Online kan du langsom innlasting når du bytter mellom kalenderen og postboksen, eller langsom sidelasting i SharePoint Online. Det er imidlertid andre symptomer som ikke vises her.

    Proxy-godkjenning er en innstilling på grensekontrolleren proxy-serveren. Hvis det skyldes et problem med ytelsen med Office 365, må du kontakte arbeidsgruppen nettverk.

Netmon

Wireshark

Proxy-godkjenning finner sted når en ny TCP-økt må være spun, ofte for å be om filer eller informasjon fra serveren, eller angi informasjon. Du kan for eksempel se proxy-godkjenning rundt HTTP GET eller HTTP POST forespørsler. Hvis du vil se rammer der du er godkjenne forespørsler i sporingen, legge til sammendrag av NTLMSSP kolonnen Netmon og filter for .property.NTLMSSPSummary. Hvis du vil se hvor lang tid tar godkjenningen, kan du legge til tidsdelta-kolonnen. Legge til en kolonne til Netmon:

  1. Høyreklikk på en kolonne, for eksempel Beskrivelse.

  2. Klikk Velg kolonner. Finn NTLMSSP Sammendrag og Tidsdelta i listen, og klikk Legg til.

  3. Flytt de nye kolonnene på plass foran eller bak kolonnen Beskrivelse slik at du kan lese dem side ved side. Klikk OK.

Selv om du ikke legge til kolonnen, fungerer Netmon-filteret. Men din feilsøking blir mye enklere hvis du kan se hvilke fase av godkjenning du er i. Når ser for forekomster av Proxy-godkjenning, må du huske å studere alle rammer der det er en utfordring NTLM eller et godkjenne meldingen er til stede. Hvis nødvendig, høyreklikker du bestemte typer trafikk og Finn samtaler og > TCP. Vær oppmerksom på tidsdelta verdiene i disse samtaler.

Netmon-sporing som viser proxy-godkjenning, filtrert etter samtale.

En fire sekunders forsinkelse i proxy-godkjenning i Wireshark. Kolonnen Tidsdelta fra tidligere vist ramme ble opprettet ved å høyreklikke feltet med samme navn i rammedetaljene og velge Legg til som kolonne.

I Wireshark kan kolonnen «Tidsdelta fra tidligere vist ramme» opprettes ved å høyreklikke feltet med samme navn i rammedetaljene og velge Legg til som kolonne.

DNS-ytelse

  • Navneløsing fungerer best og raskest når det skjer så nær klientens land som mulig.

  • Hvis DNS-navneløsing foregår i utlandet, kan det legge til sekunder til sideinnlastingen.

  • Ideelt sett bør navneløsing skje på under 100 ms. Hvis ikke, bør du undersøke nærmere.

Tips!: Er du ikke sikker på hvordan klienttilkobling virker i Office 365? Ta en titt på referansedokumentet for klienttilkobling her.

Netmon

Wireshark

PsPing

Analyse av DNS-ytelse er vanligvis en annen jobb en nettverkssporing gjør. Imidlertid er PsPing også nyttig når det gjelder å bekrefte eller utelukke en mulig årsak.

DNS-trafikken er basert på TCP- og UDP-forespørsler, og svar er tydelig merket med en ID som bidrar til å finne hvilket svar som tilhører en bestemt forespørsel. Du ser DNS-trafikk for eksempel når SharePoint Online bruker et nettverksnavn eller en nettadresse på en nettside. Som en tommelfingerregel går mesteparten av denne trafikken over UDP, unntatt når du overfører soner.

Mest grunnleggende filteret som lar deg se på DNS-trafikk er ganske enkelt dnsi Netmon og Wireshark. Pass på å bruke små bokstaver når du angir filteret. Husk å Tøm DNS resolver-bufferen før du begynner å gjenskape problemet på klientdatamaskinen. For eksempel hvis du har en treg SharePoint Online sidelasting på startsiden, bør du lukke alle nettlesere, åpne en ny nettleser, starter du sporingen, tøm DNS resolver-bufferen og bla deg frem til SharePoint Online-området. Når hele siden løser, bør du stoppe og lagre sporingen.

Et enkelt filter for DNS i Netmon er DNS.

Du vil slå på tidspunktet forskyvning her. Og det kan være nyttig å legge til kolonnen Tidsdelta i Netmon som du kan gjøre ved å følge denne fremgangsmåten:

  1. Høyreklikk på en kolonne, for eksempel Beskrivelse.

  2. Klikk Velg kolonner.

  3. Finn Tidsdelta i listen, og klikk Legg til.

  4. Flytt den nye kolonnen på plass foran eller bak kolonnen Beskrivelse slik at du kan lese dem side ved side. Klikk OK.

Hvis du finner en spørring interessante, bør du vurdere å isolere den ved å høyreklikke spørringen i panelet ramme detaljer, velge Finn samtaler og > DNS. Legg merke til at panelet Nettverkssamtaler hopper høyre til bestemte samtalen i loggen av UDP-trafikk.

En Netmon-sporing av Outlook Online-innlasting filtrert etter DNS og ved hjelp av Finn samtaler og deretter DNS for å begrense resultatene.

Du kan gjøre en kolonne for DNS-tiden i Wireshark. Ta sporingen (eller åpne en sporing) i Wireshark og filtrere etter dns, eller mer effektiviserer dns.time. Klikk på en DNS-spørring, og Utvid Domain Name System (response) detaljene i panelet som viser detaljer. Ser du et felt for klokkeslett (for eksempel [Time: 0.001111100 seconds]. Høyreklikk nå, og velg Bruk som kolonne. Dette gir deg en kolonne med klokkeslett for raskere sortering av sporingen. Klikk på den nye kolonnen du vil sortere etter synkende verdier for å se hvilke DNS-samtale tok den lengste for å løse.

En gjennomgang av SharePoint Online filtrert i Wireshark etter (små bokstaver) dns.time, med klokkeslettet fra detaljene gjort om til en kolonne og sortert stigende.

Hvis du vil gjøre flere undersøkelser av DNS-oppløsning tid, kan du prøve en PsPing mot DNS porten som brukes av TCP (for eksempel psping <IP address of DNS server>:53). Ser du fremdeles et problem med ytelsen? Hvis du gjør, deretter er problemet mest sannsynlig skal være en mer omfattende nettverk utstede enn et problem for bestemt DNS-programmet du er finne målgruppen for å gjøre oppløsning. Det er også verdt å nevne, på nytt, at en ping til outlook.office365.com forteller deg hvor DNS-navneløsing for Outlook Online foregår (for eksempel outlook-namnorthwest.office365.com).

Hvis problemet ser ut til å være DNS-spesifikt, kan det være nødvendig å kontakte IT-avdelingen for å se nærmere på DNS-konfigurasjoner og DNS-videresendere for å undersøke dette problemet ytterligere.

Proxy-skalerbarhet

  • Tjenester som Outlook Online i Office 365 gi klientene flere langsiktige tilkoblinger.

  • Derfor kan hver bruker bruke flere tilkoblinger som krever en lengre levetid.

Tips!: Trenger du å planlegge for båndbredde fordi du er i ferd med å legge til mange brukere i Office 365? Prøv Plan for bruk av Internett-båndbredde for Office 365. Der finner du båndbreddekalkulatorer.

Matematikk

Det finnes ingen nettverkssporing eller feilsøkingsverktøy spesielt for dette. I stedet er den basert på båndbreddeberegninger med gitte begrensninger og andre variabler.

Maksimal segmentstørrelse for TCP

  • Funnet i SYN - SYN/ACK.

  • Utfør denne kontrollen i en hvilken som helst nettverkssporing av ytelse du har iverksatt for å sikre at TCP-pakker er konfigurert til å bære så mye data som mulig.

  • Målet er å se en MSS på 1460 byte for overføring av data.

  • Hvis du er bak en proxy, eller du bruker en NAT, må du huske å kjøre denne testen fra klienten til proxyen/grensekontrolleren/NAT, og fra proxyen/grensekontrolleren/NAT til Office 365 for beste resultat! Dette er de ulike TCP-øktene.

Netmon

TCP Maks maksimumsstørrelsen for segmentet (MSS) er en annen parameter for tre-veis håndtrykk i Nettverkssporingen, som betyr at du finner dataene du trenger i SYN - SYN/ACK-pakke. MSS er egentlig ganske enkelt å se.

Åpne alle nettverkssporingene av ytelse du har og finn forbindelsen du er nysgjerrig på, eller som viser ytelsesproblemet.

Kommentarer: 

  • Hvis du ser på en sporing og må du finne trafikk som er relevant for samtalen, filtrerer du etter IP-adressen til klienten, eller IP-adressen til proxy-serveren eller grensekontrollerpunktet, eller begge deler. Går du direkte, må du pinge nettadressen du tester for IP-adressen til Office 365 i sporingen, og filtrere etter den.

  • Se på sporingen brukte? Prøv å bruke filtre til å vende selv. I Netmon, utfører et søk basert på URL-adressen, for eksempel Containsbin(framedata, ascii, "sphybridExample"), noter hvor ramme. Du kan bruke omtrent som frame contains "sphybridExample"i Wireshark. Hvis du oppdager at du har funnet ekstern Winsock (RWER) trafikk (det kan vises som en [PSH, ACK] i Wireshark), må du huske at RWER kobles kan ses like før relevante SYN - SYN/bekreftelse, som diskutert tidligere. På dette tidspunktet kan du spille inn hvor ramme, slipp filteret, klikk All trafikk i vinduet Nettverkssamtaler i Netmon kan se på den nærmeste SYN.

  • Det er viktig å huske på at hvis du ikke mottok noen av IP-adresseinformasjon da sporingen ble gjort, vil du få IP-adresser å filtrere etter når du finner nettadressen i sporingen (en del av sphybridExample-my.sharepoint.com, for eksempel).

  1. Finn kontakten i sporingen som du er interessert i å se. Du kan gjøre dette enten ved å skanne sporingen, ved å filtrere etter IP-adresser eller ved å velge spesifikke samtale-ID-er ved hjelp av nettverkssamtalevinduet i Netmon.

    Filtrering etter samtale. Høyreklikk SYN-rammen, og klikk Finn samtaler, TCP.

  2. Når du har funnet SYN-pakken, utvider du TCP (i Netmon), eller Transmission Control Protocol (i Wireshark) i panelet Rammedetaljer.

  3. Utvid TCP-alternativer og Maksimal segmentstørrelse.

  4. Finn den relaterte SYN-ACK-rammen og utvid TCP-alternativer og Maksimal segmentstørrelse.

  5. Den minste av de to verdiene skal være Maksimal segmentstørrelse.

I dette bildet, kan jeg gjøre bruk av den innebygde kolonnen i Netmon som heter TCP-feilsøking.

Nettverksporing filtrert i Netmon ved hjelp av de innebygde kolonnene.

Den innebygde kolonnen er øverst i Rammedetaljer-panelet. (Hvis du vil bytte tilbake til normalvisning, klikker du Kolonner på nytt, og velger deretter Tidssone.)

Hvor du finner rullegardinmenyen Kolonner for TCP-feilsøkingsalternativet (øverst på rammesammendraget).

Her er en sporing filtrert i Wireshark. Et filter er spesifikk for MSS-verdien (tcp.options.mss). Rammer av SYN, SYN/ACK, ACK handshake kobles nederst i Wireshark tilsvarer Rammedetaljer (så ramme 47 ACK, koblinger til 46 SYN/ACK, koblinger til 43 SYN) til å gjøre denne typen arbeid enklere.

Sporing filtrert i Wireshark etter tcp.options.mss for maksimumsstørrelsen for segmentet (MSS).

Hvis du trenger å kontrollere Selektiv bekreftelse (neste emne i denne matrisen), ikke lukk sporingen!

Selektiv bekreftelse

  • Funnet i SYN - SYN/ACK.

  • Må rapporteres som Tillatt i både SYN og SYN/ACK.

  • Selektiv bekreftelse (SACK) gir jevnere gjentatt overføring av data når en pakke eller pakker blir borte.

  • Enheter kan deaktivere denne funksjonen, som kan føre til problemer med ytelsen.

  • Hvis du er bak en proxy, eller du bruker en NAT, må du huske å kjøre denne testen fra klienten til proxyen/grensekontrolleren/NAT, og fra proxyen/grensekontrolleren/NAT til Office 365 for beste resultat! Dette er de ulike TCP-øktene.

Netmon

Selektiv bekreftelse (SACK) er en annen parameter i SYN-SYN/ACK-håndtrykket. Du kan filtrere sporingen for SYN - SYN/ACK på mange måter.

  1. Finn tilkoblingen i sporingen som du er interessert i å se enten ved å skanne sporingen, filtrere etter IP-adresser, eller ved å klikke en samtale-ID ved hjelp av vinduet Nettverkssamtaler i Netmon.

  2. Når du har funnet SYN-pakken, utvider du TCP i Netmon, eller Transmission Control Protocol i Wireshark i delen Rammedetaljer.

  3. Utvid TCP-alternativer og deretter SACK.

  4. Finn den relaterte SYN-ACK-rammen og utvid TCP-alternativer og det tilhørende SACK-feltet.

  5. Pass på at SACK er tillatt i både SYN og SYN/ACK.

Her er SACK-verdiene slik de kan sees både i Netmon og Wireshark.

Selektiv bekreftelse (SACK) i Netmon som et resultat av tcp.flags.syn == 1.

SACK som sett i Wireshark med filteret tcp.flags.syn == 1.

DNS-geolokasjon

  • Hvor i verden Office 365 prøver å løse DNS-samtale, påvirker tilkoblingshastigheten.

  • I Outlook Online, etter at det første DNS-oppslaget er fullført, vil plasseringen av DNS brukes til å opprette kobling til nærmeste datasenter. Du vil bli koblet til en Outlook Online CAS-server, som vil bruke ryggradsnettverket for å koble seg til datasenteret der dataene er lagret. Dette er raskere.

  • Ved tilgang til SharePoint Online blir en bruker som reiser utenlands, dirigert til sitt aktive datasenter – det er datasenteret der plasseringen er basert på SPO-leierens hjemmebase (altså et datasenter i USA hvis brukeren er basert i USA).

  • Lync Online har aktive noder i mer enn ett datasenter om gangen. Når forespørsler sendes for Lync Online-forekomster, vil Microsofts DNS avgjøre hvor i verden forespørselen kom fra, og returnere IP-adresser fra det nærmeste regionale datasenteret der Lync Online er aktivt.

Tips!: Vil du vite mer om hvordan klientene kobler seg til Office 365? Se referanseartikkelen Klienttilkobling (og dens nyttige grafikk).

Ping

PsPing

Forespørsler om navneløsing fra klientens DNS-serverne til Microsoft DNS-servere bør i de fleste tilfeller, resulterer i Microsoft DNS returnere IP-adressen til datasenteret (datasenter). Hva betyr dette for deg? Hvis din hovedkontoret i Bangalore, India, men du er på reise i USA, når leseren sender en forespørsel for Outlook Online, bør DNS-serverne til Microsoft hånd IP-adresser til datasentre i USA – regionale datasenteret. Hvis det kreves en e-post fra Outlook, reise disse dataene på tvers av Microsofts rask ryggraden nettverket mellom datasentre.

DNS fungerer raskest når navneløsing utføres så nær brukerens plassering som mulig. Hvis du er i Europa, du vil gå til et Microsoft-DNS i Europa, og (ideelt sett) forholde deg til et datasenter i Europa. Ytelse fra en klient i Europa som går til DNS og et datasenter i USA, vil være langsommere.

Kjør Ping-verktøyet mot outlook.office365.com for å bestemme hvor i verden DNS-forespørselen din blir rutet. Hvis du er i Europa, bør du se et svar fra noe i likhet med outlook-emeawest.office365.com. På det amerikanske kontinentet kan du forvente noe i likhet med outlook-namnorthwest.office365.com.

  1. Åpne ledeteksten på klientdatamaskinen (via Start > Kjør > cmd eller Windows-tasten > skriv inn cmd).

  2. Skriv inn ping outlook.office365.com og trykk ENTER.

    Husk å angi -4 Hvis du vil angi om du vil pinge via IPv4. Du kan mislykkes i å få svar fra ICMP-pakker, men du bør se navnet på DNS som forespørselen ble sendt.

Hvis du vil se ventetidstall for denne tilkoblingen, kan du prøve PsPing til IP-adressen til serveren som returneres av ping.

Ping av outlook.office365.com viser oppløsning i outlook-namnorthwest.

PSPing til IP-adressen som returneres av ping til outlook.office365.com og viser gjennomsnittlig 28 millisekund ventetid.

Feilsøking av Office 365-programmer

Netmon

HTTPWatch

F12-konsoll i nettleseren

Vi dekker ikke verktøy som brukes i programspesifikk feilsøking i denne nettverksspesifikke artikkelen. Du finner imidlertid ressurser du kan bruke på denne siden.

Beslektede emner

Administrere Office 365 endepunktene
Feilsøke Office 365-tilkobling

Merknad: Ansvarsfraskrivelse for maskinoversettelse: Denne artikkelen er oversatt av et datasystem i stedet for en oversetter. Microsoft tilbyr disse maskinoversettelsene slik at brukere som ikke snakker engelsk, får tilgang til innhold om Microsoft-produkter, -tjenester og –teknologier. Ettersom artikkelen er maskinoversatt, kan den inneholde feil i vokabular, syntaks eller grammatikk.

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Office Insiders

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×