Feilsøkingsplan for ytelse for Office 365

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

Denne artikkelen er faktisk en eksempelhandlingsplan som du kan bruke til å registrere verdifulle data om ytelsesproblemet mens det skjer. Noen av de viktigste problemene er også inkludert i denne artikkelen.

Hvis nettverksytelsen er ny og ønsker å lage en langsiktig plan for å overvåke ytelsen mellom klientmaskinene og Office 365, kan du ta en titt på Office 365 ytelsesjustering og feilsøking – Admin og IT Pro.

Eksempel på handlingsplan for feilsøking av ytelse

Denne handlingsplanen inneholder to deler. en forberedelsesfase og en loggingsfase. Hvis du har et ytelsesproblem akkurat nå, og du må utføre datainnsamling, kan du begynne å bruke denne planen umiddelbart.

Klargjøre klientdatamaskinen

• Finn en klientdatamaskin som kan gjenskape ytelsesproblemet. Denne datamaskinen brukes under feilsøking.
• Skriv ned trinnene som fører til at ytelsesproblemet oppstår, slik at du er klar når det er på tide å teste.
• Installasjonsverktøy for innsamling og registrering av informasjon:
  • Installer Netmon 3.4 (eller bruk et tilsvarende nettverkssporingsverktøy).
  • Installer gratisversjonen av HTTPWatch (eller bruk et tilsvarende nettverkssporingsverktøy).
  • Bruk en skjerminnleser eller kjør trinnopptakeren (PSR.exe) som følger med Windows Vista og nyere, for å holde oversikt over trinnene du utfører under testingen.

Loggfør ytelsesproblemet

• Lukk alle overflødige nettlesere.

• Start Trinnregistrering, eller en annen skjerminnopptaker.

• Start Netmon-opptaket (eller nettverkssporingsverktøyet).

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

• Start en ny nettleserøkt, og aktiver HTTPWatch.

• Valgfritt: Hvis du tester Exchange Online, kjører du Exchange Client Ytelsesanalyse-verktøyet fra Office 365-administrasjonskonsollen.

• Reprodusere de nøyaktige trinnene som forårsaker ytelsesproblemet.

• Stopp Netmon-sporingen eller sporingen av et annet verktøy.

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

  tracert <subscriptionname>.onmicrosoft.com
  

• Stopp trinninnspillingen, og lagre videoen. Pass på å inkludere datoen og klokkeslettet for innspillingen, og om det viser god eller dårlig ytelse.

• Lagre sporingsfilene. Husk på nytt å ta med dato og klokkeslett for innspillingen, og om den viser god eller dårlig ytelse.

Hvis du ikke er kjent med å kjøre verktøyene som er nevnt i denne artikkelen, trenger du ikke bekymre deg fordi vi følger disse trinnene. Hvis du er vant til å gjøre denne typen nettverksinnhenting, kan du hoppe til Slik samler du inn opprinnelige planer, som beskriver filtrering og lesing av loggene.

Tøm DNS-hurtigbufferen først

Hvorfor? Ved å tømme DNS-bufferen starter du testene med et rent ark. Ved å tømme hurtigbufferen tilbakestiller du innholdet i DNS-løseren til de mest oppdaterte oppføringene. Husk at en tømming ikke fjerner oppføringene i HOST-filen. Hvis du bruker vertsfiloppføringer mye, bør du kopiere disse oppføringene til en fil i en annen katalog og deretter tømme VERT-filen.

Tøm DNS Resolver-hurtigbufferen

1. Åpne ledeteksten (start-cmd>> eller Windows-tast-cmd>).

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

   ipconfig /flushdns
   

Netmon

Microsofts nettverksovervåkingsverktøy (Netmon) analyserer pakker (nettverkstrafikk) som passerer mellom datamaskiner på nettverk. Ved å bruke Netmon til å spore trafikk med Office 365 kan du registrere, vise og lese pakkeoverskrifter, identifisere mellomliggende enheter, kontrollere viktige innstillinger for nettverksmaskinvare, se etter utgåtte pakker og følge trafikkflyten mellom datamaskiner på bedriftsnettverket og Office 365. Fordi selve trafikkteksten krypteres, det vil si at den kjører på port 443 via SSL/TLS, kan du ikke lese filene som sendes. I stedet får du en ufiltrert sporing av banen som pakken tar, noe som kan hjelpe deg med å spore problemet.

Pass på at du ikke bruker et filter på dette tidspunktet. Kjør i stedet gjennom trinnene og demonstrer problemet før du stopper sporingen og lagringen.

Når du har installert Netmon 3.4, åpner du verktøyet og utfører disse trinnene:

Ta en Netmon-sporing og reprodusere problemet

1. Start Netmon 3.4. Det finnes tre ruter på Start-siden: Nylige opptak, Velg nettverk og Komme i gang med Microsoft Network Monitor 3.4. Legg merke til det. Velg nettverk-panelet gir deg også en liste over standardnettverkene du kan registrere fra. Kontroller at nettverkskort er valgt her.

2. Klikk Nytt opptak øverst på startsiden . Dette legger til en ny fane ved siden av Startside-fanen kalt Ta bilde 1.

3. Hvis du vil ta et enkelt bilde, klikker du Start på verktøylinjen.

4. Reprodusere trinnene som presenterer et ytelsesproblem.

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

HTTPWatch

HTTPWatch kommer i ladet, og en gratis utgave. Den gratis Basic Edition dekker alt du trenger for denne testen. HTTPWatch overvåker nettverkstrafikk og sidelastingstid direkte fra nettleservinduet. HTTPWatch er et programtillegg til Microsoft Edge som grafisk beskriver ytelsen. Analysen kan lagres og vises i HTTPWatch Studio.

Obs!

Hvis du bruker en annen nettleser, for eksempel Firefox, Google Chrome, eller hvis du ikke kan installere HTTPWatch i Edge, åpner du et nytt nettleservindu og trykker F12 på tastaturet. Du skal kunne se popup-vinduet for utviklerverktøyet nederst i nettleseren. Hvis du bruker Opera, trykker du CTRL+SKIFT+I for webinspeksjon, klikker deretter nettverkfanen og fullfører testingen som er beskrevet nedenfor. Informasjonen vil være litt annerledes, men innlastingstiden vises fremdeles i millisekunder. > HTTPWatch er også svært nyttig for problemer med innlastingstider for SharePoint-sider.

Kjør HTTPWatch og reprodusere problemet

HTTPWatch er en plugin-modul for nettleseren, så det å eksponere verktøyet i nettleseren er litt forskjellig for hver versjon av Microsoft Edge. Vanligvis kan du finne HTTPWatch under kommandolinjen i Microsoft Edge-nettleseren. Hvis du ikke ser HTTPWatch-plugin-modulen i nettleservinduet, kan du kontrollere versjonen av nettleseren ved å klikke Hjelp>om, eller i senere versjoner av Microsoft Edge, klikke tannhjulsymbolet og Om Edge. Hvis du vil starte kommandolinjen, høyreklikker du menylinjen i Microsoft Edge og klikker kommandolinjen.

Tidligere har HTTPWatch vært knyttet til både Kommandoer- og Utforsker-stolpene, så når du installerer, hvis du ikke umiddelbart ser ikonet (selv etter omstart), merker du verktøy og verktøylinjene for ikonet. Husk at verktøylinjer kan tilpasses, og alternativer kan legges til i dem.

1. Start HTTPWatch i et nettleservindu i Microsoft Edge. Den vises forankret til nettleseren nederst i vinduet. Klikk Oppføring.

2. Reprodusere de nøyaktige trinnene som er involvert i ytelsesproblemet. Klikk Stopp-knappen i HTTPWatch.

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

Dette skjermbildet er fra Professional-versjonen av HTTPWatch. Du kan åpne sporinger som er tatt i grunnleggende versjon på en datamaskin med en profesjonell versjon, og lese den der. Ekstra informasjon kan være tilgjengelig fra sporingen via denne metoden.

Problem Steps Recorder

Trinnregistrering, eller PSR.exe, lar deg registrere problemer etter hvert som de oppstår. Det er et veldig nyttig verktøy og enkelt å kjøre.

Kjør Problem Steps Recorder (PSR.exe) for å registrere arbeidet ditt

1. Brukstartkjøringstypen>>PSR.exe>OK, eller klikk Windows-tasten>PSR.exe>, og trykk deretter ENTER.

2. Når det lille PSR.exe vinduet vises, klikker du Start post og reproduserer trinnene som reproduserer 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 sidegjengivelse, venter du til siden gjengis før du stopper innspillingen.

4. Klikk på Lagre.

Datoen og klokkeslettet registreres for deg. Dette kobler PSR-en til Netmon-sporingen og HTTPWatch i tide, og hjelper deg med presisjonsfeilsøking. Datoen og klokkeslettet i PSR-posten kan for eksempel vise at det gikk et minutt mellom pålogging og nettadressen og den delvise gjengivelsen av administrasjonsnettstedet.

Les sporingene dine

Det er ikke mulig å lære alt om nettverks- og ytelsesfeilsøking som noen trenger å vite via en artikkel. Å bli god på ytelse krever erfaring og kunnskap om hvordan nettverket fungerer og vanligvis fungerer. Men det er mulig å runde opp en liste over de viktigste problemene og vise hvordan verktøy kan gjøre det enklere for deg å eliminere de vanligste problemene.

Hvis du vil hente ferdigheter til å lese nettverkssporinger for Office 365 nettsteder, finnes det ingen bedre lærer enn å opprette spor av sidelastinger regelmessig og få erfaring med å lese dem. Hvis du for eksempel har en mulighet, laster du inn en Office 365-tjeneste og sporer prosessen. Filtrer sporingen for DNS-trafikk, eller søk i FrameData etter navnet på tjenesten du viste. Skann sporingen for å få et inntrykk av trinnene som oppstår når tjenesten lastes inn. Dette hjelper deg med å lære hvordan vanlig sideinnlasting skal se ut, og når det gjelder feilsøking, spesielt rundt ytelse, kan det å sammenligne gode og dårlige spor lære deg mye.

Netmon bruker Microsoft Intellisense i visningsfilterfeltet. Intellisense, eller intelligent kodefullføring, er det trikset der du skriver inn et punktum, og alle tilgjengelige alternativer vises i en rullegardinliste. Du er for eksempel bekymret for skalering av TCP-vinduet, du kan finne veien til et filter (for eksempel .protocol.tcp.window < 100) på denne måten.

Netmon-sporinger kan ha mye trafikk i seg. Hvis du ikke har erfaring med å lese dem, er det sannsynlig at du blir overveldet når du åpner sporingen første gang. Det første du må gjøre er å skille signalet fra bakgrunnsstøyen i sporingen. Du testet mot Office 365, og det er trafikken du vil se. Hvis du er vant til å navigere gjennom sporinger, trenger du kanskje ikke denne listen.

Trafikk mellom klienten og Office 365 reiser via TLS, noe som betyr at brødteksten i trafikken krypteres og ikke leses i en generisk Netmon-sporing. Ytelsesanalysen trenger ikke å vite detaljene i informasjonen i pakken. Det er imidlertid veldig interessert i pakkehoder og informasjonen de inneholder.

Tips for å få en god sporing

• Kjenn verdien til IPv4- eller IPv6-adressen til klientdatamaskinen. Du kan få dette fra ledeteksten ved å skrive inn IPConfig og deretter trykke ENTER. Når du vet denne adressen, kan du raskt se om trafikken i sporingen involverer klientdatamaskinen direkte. Hvis det finnes en kjent proxy, pinger du den og får IP-adressen også.

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

• Finn Office 365 tjenesten du bruker, i en travel sporing. Hvis du aldri eller sjelden har sett trafikken før, er dette et nyttig trinn for å skille ytelsesproblemet fra annen nettverksstøy. Det finnes flere måter å gjøre dette på. Rett før testen kan du bruke ping eller PsPing mot nettadressen til den bestemte tjenesten (ping outlook.office365.com eller psping -4 microsoft-my.sharepoint.com:443, for eksempel). Du kan også enkelt finne ping eller PsPing i en Netmon-sporing (med prosessnavnet). Det vil gi deg et sted å begynne å lete.

Hvis du bare bruker Netmon-sporing på tidspunktet for problemet, er det også greit. Hvis du vil orientere deg, kan du bruke et filter som ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"). Du kan registrere rammenummeret fra sporingsfilen. Du kan også rulle rammesammendragsruten helt til høyre og se etter Kolonnen Samtale-ID. Det er angitt et tall for ID-en for denne bestemte samtalen som du også kan ta opp og se på isolert senere. Husk å fjerne dette filteret før du bruker annen filtrering.

Tips

Netmon har mange nyttige innebygde filtre. Prøv Last inn filter-knappen øverst i visningsfilterruten .

Bli kjent med trafikken, og finn ut hvordan du finner informasjonen du trenger. Lær for eksempel å finne ut hvilken pakke i sporingen som har den første referansen til den Office 365 tjenesten du bruker (for eksempel «Outlook»).

Hvis du tar Office 365 Outlook Online som et eksempel, begynner trafikken omtrent slik:

• DNS Standard Query og DNS Response for outlook.office365.com med samsvarende queryIDs. Det er viktig å merke seg tidsforskyvningen for denne omdreiningen, og hvor i verden Office 365 global DNS sender forespørselen om navneløsing. Ideelt sett, så lokalt som mulig, i stedet for halvveis over hele verden.

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

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

• En TCP SYN- og TCP SYN/ACK-samtale. Mange innstillinger i denne samtalen påvirker ytelsen.

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

Alle deler av trafikken er viktige og tilkoblet, men små deler av sporingen inneholder informasjon som er viktig når det gjelder feilsøking av ytelse, så vi skal fokusere på disse områdene. Siden vi har gjort nok Office 365 feilsøking av ytelse hos Microsoft til å kompilere en liste over vanlige problemer på topp 10, vil vi også fokusere på disse problemene og hvordan vi bruker verktøyene vi har til å rote dem ut neste.

Hvis du ikke allerede har installert dem, bruker matrisen nedenfor flere verktøy der det er mulig. Koblinger er gitt til installasjonspunktene. Listen inneholder vanlige verktøy for nettverkssporing, for eksempel Netmon og Wireshark, men bruker et hvilket som helst sporingsverktøy du er fortrolig med, og der du er vant til å filtrere nettverkstrafikk. Når du tester, må du huske:

• Lukk nettleserne, og test med bare én nettleser som kjører – Dette vil redusere den totale trafikken du registrerer. Det gir en mindre opptatt sporing.
• Tøm DNS Resolver-bufferen på klientdatamaskinen – dette vil gi deg et rent ark når du begynner å registrere deg, for en renere sporing.

Vanlige problemer

Noen vanlige problemer du kan møte, og hvordan du finner dem i nettverkssporingen.

TCP Windows-skalering

Funnet i SYN - SYN/ACK. Eldre eller aldrende maskinvare drar kanskje ikke nytte av skalering av TCP-vinduer. Uten riktige skaleringsinnstillinger for TCP-vinduer fylles standard 16-biters buffer i TCP-overskrifter ut i millisekunder. Trafikken kan ikke fortsette å sende før klienten mottar en bekreftelse på at de opprinnelige dataene er mottatt, noe som forårsaker forsinkelser.

Verktøy

• Netmon
• Wireshark

Hva du skal se etter

Se etter SYN- SYN/ACK-trafikken i nettverkssporingen. Bruk et filter som i Netmon, for eksempel tcp.flags.syn == 1. Dette filteret er det samme i Wireshark.

Legg merke til at for hver SYN er det et kildeportnummer (SrcPort) som samsvarer i målporten (DstPort) for den relaterte bekreftelsen (SYN/ACK).

Hvis du vil se Windows-skaleringsverdien som brukes av nettverkstilkoblingen, utvider du først SYN og deretter den relaterte SYN/ACK.

Innstillinger for TCP-tid uten aktivitet

Historisk sett er de fleste perimeternettverk konfigurert for midlertidige tilkoblinger, noe som betyr at inaktive tilkoblinger vanligvis avsluttes. Inaktive TCP-økter kan avsluttes av proxyer og brannmurer på 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 avsluttes av proxy- eller brannmurenheter, blir ikke klienten informert, og et forsøk på å bruke Outlook Online betyr at en klientdatamaskin gjentatte ganger prøver å gjenopplive tilkoblingen før du oppretter en ny. Det kan hende du ser heng i produktet, ledetekster eller dårlig ytelse på sideinnlasting.

Verktøy

• Netmon
• Wireshark

Hva du skal se etter

Se på Tidsforskyvning-feltet for en rundtur i Netmon. En rundtur er tiden mellom klienten som sender en forespørsel til serveren og mottar et svar tilbake. Kontroller mellom klienten og utgangspunktet (f.eks. klient --> proxy) eller klienten for å Office 365 (klient -> Office 365). Du kan se dette i mange typer pakker.

Som et eksempel kan filteret i Netmon se ut 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? Prøv å slå det opp på kommandolinjen. Klikk Start>kjør> og skriv inn cmd, eller trykk Windows-tasten> og skriv inn cmd. Skriv inn nslookup <the IP address from the network trace>i ledeteksten. Hvis du vil teste, kan du bruke nslookup mot ip-adressen til din egen datamaskin. >Hvis du vil se en liste over Microsofts IP-områder, kan du se Office 365 nettadresser og IP-adresseområder.

Hvis det er et problem, kan du forvente at lange tidsforskyvninger vises, i dette tilfellet (Outlook Online), spesielt i TLS:TLS-pakker som viser avsnittet av programdata (for eksempel i Netmon kan du finne programdatapakker via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Du skal kunne se en jevn fremdrift i tiden på tvers av økten. Hvis du ser lange forsinkelser når du oppdaterer Outlook Online, kan dette skyldes at en høy grad av tilbakestillinger sendes.

Ventetid/rundturtid

Ventetid er et mål som kan endre mye avhengig av mange variabler, for eksempel oppgradering av aldrende enheter, legge til et stort antall brukere i et nettverk, og prosentandelen av den totale båndbredden som forbrukes av andre oppgaver på en nettverkstilkobling.

Det finnes båndbreddekalkulatorer for Office 365 tilgjengelig fra denne nettverksplanleggingen og ytelsesjusteringen for Office 365 side.

Trenger du å måle hastigheten på tilkoblingen eller isp-tilkoblingens båndbredde? Prøv dette området (eller nettsteder liker det): Speedtest offisielt område, eller spør din favoritt søkemotor for uttrykkshastighetstesten.

Verktøy

• Ping
• PsPing
• Netmon
• Wireshark

Hva du skal se etter

Hvis du vil spore ventetid i en sporing, kan du dra nytte av å ha registrert IP-adressen til klientdatamaskinen og IP-adressen til DNS-serveren i Office 365. Dette er for enklere sporingsfiltrering. Hvis du kobler til via en proxy, trenger du klientdatamaskinens IP-adresse, proxy-/utgående IP-adresse og Office 365 DNS IP-adresse, for å gjøre arbeidet enklere.

En ping-forespørsel sendt til outlook.office365.com vil fortelle deg navnet på datasenteret som mottar forespørselen, selv om ping kanskje ikke kan koble til for å sende varemerket etterfølgende ICMP-pakker. Hvis du bruker PsPing (et gratis verktøy for nedlasting), og spesifikt porten (443) og kanskje bruker IPv4 (-4), får du en gjennomsnittlig rundtur for pakker som sendes. Dette fungerer for andre URL-adresser i Office 365-tjenestene, for eksempel psping -4 yourSite.sharepoint.com:443. Du kan faktisk angi et antall ping for å få et større utvalg for gjennomsnittet, prøv noe sånt som psping -4 -n 20 yourSite-my.sharepoint.com:443.

Obs!

PsPing sender ikke ICMP-pakker. Den pinger 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 å knytte port :443 til PsPing.

Hvis du lastet inn den langsomme ytelsen Office 365 siden mens du utførte en nettverkssporing, bør du filtrere en Netmon- eller Wireshark-sporing for DNS. Dette er en av parlamentsmedlemmene vi leter etter.

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

1. Ping url-adressen ping outlook.office365.com og, i resultatene, registrere navnet og IP-adressen til DNS-serveren ping forespørselen ble sendt til.
2. Nettverkssporing åpner siden eller utfører handlingen som gir deg ytelsesproblemet, eller, hvis du ser en høy ventetid på ping, selve, nettverkssporing.
3. Åpne sporingen i Netmon og filtrer for DNS (dette filteret fungerer også i Wireshark, men skiller mellom store og små bokstaver -- dns). Siden du vet navnet på DNS-serveren fra ping, kan du også filtrere raskere i Netmon slik: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), som ser slik ut i Wireshark dns og rammen inneholder "namnorthwest".
   Åpne svarpakken, og klikk DNS i vinduet Netmon Frame Details for å utvide for 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-svaret i Netmon (Frame Summary>Find Conversations>DNS) for å se DNS-spørringen og svaret side ved side.
4. Legg også merke til Tidsforskyvning-kolonnen mellom DNS-forespørselen og svaret i Netmon. I det neste trinnet er verktøyet for enkel installasjon og bruk av PsPing svært praktisk, både fordi ICMP ofte er blokkert på brannmurer, og fordi PsPing elegant sporer ventetid i millisekunder. PsPing fullfører en TCP-tilkobling til en adresse og port (i vårt tilfelle åpne port 443).
5. Installer PsPing.
6. Åpne en ledetekst (start > kjøretype > cmd eller Windows Key > type cmd) og endre katalogen til katalogen der du installerte PsPing for å kjøre PsPing-kommandoen. I mine eksempler kan du se at jeg har laget en Perf-mappe på roten av C. Du kan gjøre det samme for hurtigtilgang.
7. Skriv inn kommandoen slik at du lager PsPing mot IP-adressen til den Office 365 DNS-serveren fra den tidligere Netmon-sporingen, inkludert portnummeret, for eksempel psping -n 20 132.245.24.82:445. Dette gir deg et utvalg på 20 ping og gjennomsnittlig ventetid når PsPing stopper.

Hvis du skal Office 365 gjennom en proxy-server, er fremgangsmåten litt annerledes. Først PsPing til proxy-serveren for å få en gjennomsnittlig ventetidsverdi i millisekunder til proxy/utgående og tilbake, og kjør deretter PsPing på proxyen, eller på en datamaskin med en direkte Internett-tilkobling for å få den manglende verdien (den som skal Office 365 og tilbake).

Hvis du velger å kjøre PsPing fra proxyen, har du to millisekunders verdier: Klientdatamaskinen til proxy-serveren eller utgangspunktet, og proxy-server for å Office 365. Og du er ferdig! Vel, innspillingsverdier, uansett.

Hvis du kjører PsPing på en annen klientdatamaskin som har en direkte tilkobling til Internett, det vil si uten proxy, har du to millisekunders verdier: Klientdatamaskinen til proxy-serveren eller utgangspunktet, og klientdatamaskinen som skal Office 365. I dette tilfellet trekker du verdien av klientdatamaskinen til proxy-serveren eller grensepunktet fra verdien til klientdatamaskinen til Office 365, og du har RTT-tallene fra klientdatamaskinen til proxy-serveren eller grensepunktet, og fra proxy-server eller grensepunkt til Office 365.

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

Ventetid, som vist i en Netmon-sporing, kan disse ekstra millisekunder legge sammen, hvis det er nok av dem i en gitt økt.

Obs!

IP-adressen kan være forskjellig fra IP-adressene som vises her, for eksempel kan ping returnere noe mer som 157.56.0.0/16 eller et lignende område. Hvis du vil se en liste over områder som brukes av Office 365, kan du se Office 365 URL-adresser og IP-adresseområder.

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 for deg hvis du går gjennom en proxy-server. Hvis ikke, kan du hoppe over disse trinnene. Når du arbeider som den skal, skal proxy-godkjenning skje konsekvent i millisekunder. Du bør ikke se uregelmessig dårlig ytelse i perioder med høy trafikk (for eksempel).

Hvis proxy-godkjenning er aktivert, må du gå gjennom en godkjenningsprosess bak kulissene hver gang du oppretter en ny TCP-tilkobling til Office 365 for å få informasjon. Så når du for eksempel bytter fra Kalender til E-post i Outlook Online, godkjenner du. Og i SharePoint, hvis en side viser medier eller data fra flere nettsteder eller plasseringer, godkjenner du for hver forskjellige TCP-tilkobling som kreves for å gjengi dataene.

I Outlook Online kan det hende du opplever treg innlasting når du bytter mellom Kalender og postboksen, eller hvis du laster inn en treg side i SharePoint. Det er imidlertid andre symptomer som ikke er oppført her.

Proxy-godkjenning er en innstilling på utgående proxy-server. Hvis det forårsaker et ytelsesproblem med Office 365, må du kontakte nettverksteamet.

Verktøy

• Netmon
• Wireshark

Hva du skal se etter

Proxy-godkjenning finner sted når en ny TCP-økt må spunnet opp, vanligvis for å be om filer eller informasjon fra serveren, eller for å oppgi informasjon. Du kan for eksempel se proxy-godkjenning rundt HTTP GET- eller HTTP POST-forespørsler. Hvis du vil se rammene der du godkjenner forespørsler i sporingen, legger du til kolonnen NTLMSSP Summary i Netmon og filtrerer etter .property.NTLMSSPSummary. Hvis du vil se hvor lang tid godkjenningen tar, legger du til Tidsdelta-kolonnen.

Slik legger du til en kolonne i Netmon:

1. Høyreklikk på en kolonne, for eksempel Beskrivelse.
2. Klikk Velg kolonner.
3. Finn NTLMSSP-sammendrag og tidsdelta i listen, og klikk Legg til.
4. Flytt de nye kolonnene på plass før eller bak beskrivelseskolonnen , slik at du kan lese dem side ved side.
5. Klikk OK.

Selv om du ikke legger til kolonnen, fungerer Netmon-filteret. Feilsøkingen blir imidlertid mye enklere hvis du kan se hvilket godkjenningstrinn du er i.

Når du ser etter forekomster av proxy-godkjenning, må du huske å studere alle rammer der det finnes en NTLM-utfordring, eller en godkjenningsmelding finnes. Hvis det er nødvendig, høyreklikker > du på den bestemte delen av trafikken og Finn samtaler TCP. Vær oppmerksom på Tidsdelta-verdiene i disse samtalene.

En fire sekunders forsinkelse i proxy-godkjenning som vist i Wireshark. Tidsdeltaet fra den forrige viste rammekolonnen ble gjort ved å høyreklikke på feltet med samme navn i rammedetaljene og velge Legg til som kolonne.

DNS-ytelse

Navneoppløsningen fungerer best og raskere når den finner sted så nær klientens land/område som mulig.

Hvis DNS-navneløsing foregår i utlandet, kan det legge til sekunder i sideinnlastinger. Ideelt sett skjer navneløsing på under 100 ms. Hvis ikke, bør du gjøre videre undersøkelser.

Tips

Er du ikke sikker på hvordan klienttilkobling fungerer i Office 365? Ta en titt på referansedokumentet for klienttilkobling her.

Verktøy

• Netmon
• Wireshark
• PsPing

Hva du skal se etter

Analyse av DNS-ytelse er vanligvis en annen jobb for en nettverkssporing. PsPing er imidlertid også nyttig for å utelukke, eller ut, en mulig årsak.

DNS-trafikk er basert på TCP- og UDP-forespørsler, og svar er tydelig merket med en ID som bidrar til å samsvare en bestemt forespørsel med det spesifikke svaret. Du vil se DNS-trafikk når SharePoint for eksempel bruker et nettverksnavn eller en nettadresse på en nettside. Som en tommelfingerregel kjører mesteparten av denne trafikken, bortsett fra når du overfører soner, over UDP.

I både Netmon og Wireshark er det mest grunnleggende filteret som lar deg se på DNS-trafikk ganske enkelt dns. Pass på å bruke små bokstaver når du angir filteret. Husk å tømme DNS Resolver-bufferen før du begynner å reprodusere problemet på klientdatamaskinen. Hvis du for eksempel har en treg innlasting av SharePoint-siden for hjemmesiden, bør du lukke alle nettlesere, åpne en ny nettleser, starte sporingen, tømme DNS Resolver-bufferen og bla til SharePoint-området. Når hele siden er løst, bør du stoppe og lagre sporingen.

Du vil se på tidsforskyvningen her. Og det kan være nyttig å legge til Tidsdelta-kolonnen i Netmon som du kan gjøre ved å fullføre disse trinnene:

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 før eller bak beskrivelseskolonnen , slik at du kan lese dem side ved side.
5. Klikk OK.

Hvis du finner en interessespørring, kan du vurdere å isolere den ved å høyreklikke spørringen i panelet for rammedetaljer og velge Finn samtaler>DNS. Legg merke til at panelet Nettverkssamtaler hopper rett til den bestemte samtalen i loggen over UDP-trafikk.

I Wireshark kan du lage en kolonne for DNS-tid. Ta sporingen (eller åpne en sporing) i Wireshark og filtrer etter dns, eller, mer nyttig, dns.time. Klikk på en DNS-spørring, og utvid Domain Name System (response) detaljene i panelet som viser detaljer. Du ser et felt for tid (for eksempel [Time: 0.001111100 seconds]. Høyreklikk denne gangen, og velg Bruk som kolonne. Dette gir deg en Tid-kolonne for raskere sortering av sporingen. Klikk på den nye kolonnen for å sortere etter synkende verdier for å se hvilket DNS-kall som tok lengst tid å løse.

En bla gjennom SharePoint filtrert i Wireshark etter (små bokstaver) dns.time, med tiden fra detaljene gjort til en kolonne og sortert stigende.

Hvis du vil gjøre flere undersøkelser av DNS-løsningstiden, kan du prøve en PsPing mot DNS-porten som brukes av TCP (for eksempel psping <IP address of DNS server>:53). Ser du fortsatt et ytelsesproblem? Hvis du gjør det, er det mer sannsynlig at problemet er et bredere nettverksproblem enn et problem med dns-programmet du trykker på for å løse problemet. Det er også verdt å nevne at en ping til outlook.office365.com forteller deg hvor DNS-navneløsingen for Outlook Online finner sted (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 på DNS-konfigurasjoner og DNS Forwarders for å undersøke dette problemet ytterligere.

Proxy-skalerbarhet

Tjenester som Outlook Online i Office 365 gi klienter flere langsiktige tilkoblinger. Derfor kan hver bruker bruke flere tilkoblinger som krever en lengre levetid.

Verktøy

Matematikk

Hva du skal se etter

Det finnes ingen nettverkssporings- eller feilsøkingsverktøy som er spesifikke for dette. I stedet er den basert på båndbreddeberegninger gitt begrensninger og andre variabler.

Maksimal segmentstørrelse for TCP

Funnet i SYN - SYN/ACK. Gjør denne kontrollen i nettverkssporing for ytelse som du har tatt for å sikre at TCP-pakker er konfigurert til å bære maksimalt mulig datamengde.

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 klient til proxy/utgående/NAT, og fra proxy/utgående/NAT til Office 365 for best resultat! Dette er forskjellige TCP-økter.

Verktøy

Netmon

Hva du skal se etter

Maksimal segmentstørrelse for TCP (MSS) er en annen parameter for treveis håndtrykk i nettverkssporingen, som betyr at du finner dataene du trenger i SYN -SYN/ACK-pakken. MSS er ganske enkelt å se.

Åpne en hvilken som helst ytelsesnettverkssporing du har, og finn tilkoblingen du er nysgjerrig på, eller som demonstrerer ytelsesproblemet.

Obs!

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

Ser du på sporingen brukt? Prøv å bruke filtre til å orientere deg. Kjør et søk basert på nettadressen, for eksempel Containsbin(framedata, ascii, "sphybridExample")i Netmon, noter rammenummeret.

Bruk noe sånt som frame contains "sphybridExample"i Wireshark. Hvis du legger merke til at du har funnet Remote Winsock (RWS)-trafikk (det kan vises som en [PSH, ACK] i Wireshark), må du huske at RWS-tilkoblinger kan sees kort tid før relevante SYN - SYN / ACKs, som beskrevet tidligere.

På dette tidspunktet kan du registrere rammenummeret, slippe filteret og klikke All trafikk i vinduet Nettverkssamtaler i Netmon for å se på nærmeste SYN.

Hvis du ikke mottok noe av IP-adresseinformasjonen på sporingstidspunktet, vil det å finne nettadressen i sporingen (del av sphybridExample-my.sharepoint.comfor eksempel) gi deg IP-adresser å filtrere etter.

Finn tilkoblingen i sporingen som du er interessert i å se. Du kan gjøre dette ved enten å skanne sporingen, ved å filtrere etter IP-adresser eller ved å velge bestemte samtale-ID-er ved hjelp av nettverkssamtalevinduet i Netmon. Når du har funnet SYN-pakken, utvider du TCP (i Netmon) eller Transmission Control Protocol (i Wireshark) i Rammedetaljer-panelet. Utvid TCP-alternativer og MaxSegmentSize. Finn den relaterte SYN-ACK-rammen og utvid TCP-alternativer og MaxSegmentSize. Den minste av de to verdiene vil være maksimal segmentstørrelse. I dette bildet bruker jeg den innebygde kolonnen i Netmon kalt TCP Troubleshoot.

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

Her er en filtrert sporing i Wireshark. Det finnes et filter som er spesifikt for MSS-verdien (tcp.options.mss). Rammene til et SYN-, SYN/ACK-, ACK-håndtrykk er koblet nederst i Wireshark som tilsvarer Rammedetaljer (så ramme 47 ACK, koblinger til 46 SYN/ACK, koblinger til 43 SYN) for å gjøre denne typen arbeid enklere.

Hvis du må kontrollere selektiv bekreftelse (neste emne i denne matrisen), må du ikke lukke sporingen!

Selektiv bekreftelse

Funnet i SYN - SYN/ACK. Må rapporteres som tillatt i både SYN og SYN/ACK. Selektiv bekreftelse (SACK) muliggjør jevnere overføring av data når en pakke eller pakker forsvinner. Enheter kan deaktivere denne funksjonen, noe som kan føre til ytelsesproblemer.

Hvis du er bak en proxy, eller du bruker en NAT, må du huske å kjøre denne testen fra klient til proxy/utgående/NAT, og fra proxy/utgående/NAT til Office 365 for best resultat! Dette er forskjellige TCP-økter.

Verktøy

Netmon

Hva du skal se etter

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.

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. Når du har funnet SYN-pakken, utvider du TCP i Netmon eller Transmission Control Protocol i Wireshark i delen Rammedetaljer. Utvid TCP-alternativer og deretter SACK. Finn den relaterte SYN-ACK-rammen og Utvid TCP-alternativer og SACK-feltet. Sørg for at SACK er tillatt i både SYN og SYN/ACK. Her er SACK-verdier som vist i både Netmon og Wireshark.

DNS Geolocation

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

Når det første DNS-oppslaget er fullført i Outlook Online, brukes plasseringen av DNS til å koble til nærmeste datasenter. Du blir koblet til en Outlook Online CAS-server, som bruker ryggradsnettverket til å koble til datasenteret (dC) der dataene er lagret. Dette er raskere.

Når du åpner SharePoint, blir en bruker som reiser utenlands, dirigert til sitt aktive datasenter – det er DC-en hvis plassering er basert på SPO-leierens hjemmebase (så, en dC i USA hvis brukeren hvis USA-basert).

Lync Online har aktive noder i mer enn én DC 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 nærmeste regionale distribusjonsinstans der Lync Online er aktivt.

Tips

Trenger du å vite mer om hvordan klienter kobler seg til Office 365? Ta en titt på referanseartikkelen for klienttilkobling (og dens nyttige grafikk).

Verktøy

• Ping
• PsPing

Hva du skal se etter

Forespørsler om navneløsing fra klientens DNS-servere til Microsofts DNS-servere bør i de fleste tilfeller føre til at Microsoft DNS returnerer IP-adressen til et regionalt datasenter (dC). Hva betyr dette for deg? Hvis hovedkvarteret ditt er i Bengaluru, India, men du er på reise i USA, bør Microsofts DNS-servere gi deg IP-adresser til datasentre i USA – et regionalt datasenter når nettleseren gjør en forespørsel om Outlook Online. Hvis e-post er nødvendig fra Outlook, vil disse dataene bevege seg over Microsofts raske ryggradsnettverk mellom datasentrene.

DNS fungerer raskest når navneløsing utføres så nær brukerplasseringen som mulig. Hvis du er i Europa, vil du gå til en Microsoft DNS i Europa, og (ideelt sett) håndtere et datasenter i Europa. Ytelsen fra en klient i Europa som går til DNS og et datasenter i Amerika, blir langsommere.

Kjør Ping-verktøyet mot outlook.office365.com for å finne ut hvor i verden DNS-forespørselen rutes. Hvis du er i Europa, bør du se et svar fra noe sånt som outlook-emeawest.office365.com. I Amerika, forvent noe sånt som outlook-namnorthwest.office365.com.

Åpne ledeteksten på klientdatamaskinen (via Start > Kjør > cmd eller Windows-tasten > cmd). Skriv inn ping outlook.office365.com, og trykk ENTER. Husk å angi -4 hvis du vil angi ping via IPv4. Det kan hende du ikke får svar fra ICMP-pakkene, men du skal kunne se navnet på DNS-en som forespørselen ble rutet til. Hvis du vil se ventetidsnumrene for denne tilkoblingen, kan du prøve PsPing til IP-adressen til serveren som returneres av ping.

feilsøking av Office 365 program

Verktøy

• Netmon
• HTTPWatch
• F12-konsollen i nettleseren

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

Relaterte artikler

Administrere Office 365-endepunkter

Vanlige spørsmål om Office 365 endepunkter