Fejlfinding af ydeevne i forbindelse med planen for Office 365

Er det nødvendigt at kende trinnene til at identificere og løse forsinkelser, problemer med, at systemet hænger, og langsom hastighed mellem SharePoint Online, OneDrive for Business, Exchange Online eller Skype for Business Online og klientcomputeren? Før du ringer til supporten, kan denne artikel hjælpe dig med at foretage fejlfinding af Office 365-ydelsesproblemer og endda løse nogle af de mest almindelige problemer.

Denne artikel er rent faktisk en handlingsplan, som du kan bruge til at registrere værdifulde data om ydeevneproblemet, mens det sker. Nogle af de største problemer er også vist her.

Hvis netværksydeevne er nyt for dig, og du vil udarbejde en langsigtet plan til at overvåge ydeevnen mellem dine klientcomputere og Office 365, kan du se under Justering af ydeevnen og fejlfinding for Office 365 – administrator og it-medarbejder.

Eksempel på handlingsplan til fejlfinding af ydeevne

Denne handlingsplan består af to dele; en forberedelsesfase og en logføringsfase. Hvis du har et ydelsesproblem lige nu, og du skal udføre dataindsamling, kan du begynde at bruge denne plan med det samme.

Forberede klientcomputeren

  • Find en klientcomputer, som kan genskabe ydelsesproblemet. Denne computer bruges i løbet af fejlfindingsprocessen.

  • Notér de trin, som får ydelsesproblemet til at opstå, så du er klar, når det bliver tid til at teste.

  • Installér værktøjer til indsamling og registrering af oplysninger:

    • Installér Netmon 3.4 (eller brug et tilsvarende værktøj til netværkssporing).

    • Installér den gratis Basic Edition af HTTPWatch (eller brug et tilsvarende værktøj til netværkssporing).

    • Brug en skærmoptager, eller kør Trinoptager (PSR.exe), som leveres sammen med Windows Vista og nyere versioner, for at holde styr på de trin, du foretager under testen.

Registrer ydelsesproblemet

  • Luk alle overflødige internetbrowsere.

  • Start Trinoptager eller en anden skærmoptager.

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

  • Ryd din DNS-cache 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 Performance Analyzer til Exchange-klienten fra Office 365-administrationskonsollen.

  • Genskab de nøjagtige trin, som er skyld i ydelsesproblemerne.

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

  • På kommandolinjen skal du køre en sporingsrute til dit abonnement på Office 365 ved at skrive følgende kommando og derefter trykke på Enter:

    tracert <subscriptionname>.onmicrosoft.com

  • Stop Trinoptager, og gem videoen. Sørg for at medtage datoen og klokkeslættet for det registrerede, og om den udviser god eller dårlig ydeevne.

  • Gem sporingsfilerne. Igen skal du sørge for at skrive datoen og klokkeslættet for det registrerede, og om den udviser god eller dårlig ydeevne.

Hvis du ikke ved, hvordan du kører de værktøjer, der er nævnt i denne artikel, gør det ikke noget, fordi vi forklarer disse trin her efter. Hvis du er vant til at udføre denne type netværksregistrering, kan du gå til afsnittet Sådan læser du dine sporinger, der beskriver filtrering og aflæsning af logfilerne.

Rens DNS-cachen først

Hvorfor? Ved at rense DNS-cachen kan du starte din test med en ren tavle. Ved at rydde cachen nulstiller du indholdet i DNS Resolver til de mest opdaterede poster. Husk, at rensning ikke fjerner HOST-filposterne. Hvis du i høj grad bruger HOST-filposter, skal du kopiere disse poster ud til en fil i en anden mappe og derefter tømme HOST-filen.

Rens cachen i din DNS Resolver
  1. Åbn kommandoprompten, (enten Start > Kør > cmd eller Windows-tast > cmd).

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

    ipconfig /flushdns

Netmon

Microsofts værktøj til netværksovervågning (Netmon) analyserer pakker, dvs. trafik, der går mellem computere på netværk. Ved at bruge Netmon til sporing af trafik med Office 365 kan du registrere, få vist og læse pakkehoveder, identificere mellemliggende enheder, kontrollere vigtige indstillinger på netværkshardware, søge efter placerede pakker og følge strømmen af trafik mellem computere på dit virksomhedsnetværk og Office 365. Da den faktiske hoveddel af trafikken er krypteret, dvs. det rejser 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, pakken tager, som kan hjælpe dig med at finde problemets adfærd.

Sørg for, at du ikke anvender et filter på nuværende tidspunkt. I stedet skal du køre gennem 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 udføre disse trin:

Lav en Netmon-sporing, og genskab problemet
  1. Start Netmon 3.4.

    Der er tre ruder på siden Start: Recent Captures, Select Networks og Getting Started with Microsoft Network Monitor 3.4. Bemærk!. Panelet Select Networks vil også give dig en liste over de standardnetværk, hvorfra du kan registrere. Kontrollér, at netværkskortene er markeret her.

  2. Klik på New Capture øverst på siden Start. Dette tilføjer en ny fane ud for siden Start kaldet Capture 1.

    Nemons brugergrænsefladen med knapperne Ny note, Start og Stop fremhævet.

  3. For at lave en enkelt registrering skal du klikke på Start på værktøjslinjen.

  4. Genskab de trin, der udgør ydelsesproblemet.

  5. Klik på Stop > File > Save As. Husk at angive dato og klokkeslæt med en tidszone og at nævne, hvis det udviser dårlig eller god ydeevne.

HTTPWatch

HTTPWatch fås i en betalt og en gratis udgave. Den gratis Basic Edition dækker alt, hvad du skal bruge til denne test. HTTPWatch overvåger netværkstrafik og sideindlæser tiden direkte fra dit browservindue. HTTPWatch er et plug-in til Internet Explorer, som grafisk beskriver ydeevnen. Analysen kan gemmes og vises i HTTPWatch Studio.

Bemærkninger: Hvis du bruger en anden browser, f.eks. Firefox, Google Chrome, eller hvis du ikke kan installere HTTPWatch i Internet Explorer, skal du åbne et nyt browservindue og trykke på F12 på tastaturet. Du burde se udviklingsværktøjet komme frem nederst i din browser. Hvis du bruger Opera, skal du trykke på Ctrl+Shift+I for Web Inspector og derefter klikke på fanen Netværk og fuldføre testen, der er beskrevet her. Oplysningerne vil være lidt anderledes, men indlæsningstider vises stadig i millisekunder.

HTTPWatch er også nyttig til problemer med sideindlæsningstider for SharePoint Online.

Kør HTTPWatch, og genskab problemet
  1. HTTPWatch er en browser-plug-in, så det at bruge værktøjet i browseren er en anelse anderledes for hver version af Internet Explorer. Normalt kan du finde HTTPWatch under kommandolinjen i Internet Explorer-browseren.

    Hvis du ikke kan se HTTPWatch-plug-in'en i browservinduet, skal du kontrollere din version af browseren ved at klikke på Hjælp > Om, eller i senere versioner af Internet Explorer skal du klikke på tandhjulssymbolet og Om Internet Explorer. For at starte Kommandolinjen skal du højreklikke på menulinjen i Internet Explorer og klikke på Kommandolinje. Tidligere blev HTTPWatch knyttet til både kommandolinjen og Stifinder, så når du installerer, hvis du ikke umiddelbart kan se ikonet (selv efter genstart), kan du prøve at finde ikonet i under Funktioner og på dine værktøjslinjer. Husk, at værktøjslinjer kan tilpasses, og at indstillingerne kan føjes til dem.

    Internet Explorers kommandoværktøjslinjen med HTTPWatch-ikonet vist.

  2. Start HTTPWatch i et Internet Explorer-vindue. Den vises forankret i browseren nederst i vinduet. Klik på Post.

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

  4. Gem HTTPWatch eller Send via mail. Husk at navngive filen, så den indeholder dato og klokkeslæt og en angivelse af, om din Watch indeholder en demonstration af god eller dårlig ydeevne.

    HTTPWatch, som viser fanen Netværk for en sideindlæsning af Office 365-hjemmesiden.

    Dette skærmbillede er fra versionen Professional af HTTPWatch. Du kan åbne sporinger, der er taget i Basic Version på en computer med en Professional-version og læse det der. Ekstra oplysninger kan være tilgængelige via sporet gennem den pågældende metode.

Optager til problemtrin

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

Kør Optager til problemtrin (PSR.exe) for at optage dit arbejde
  1. Brug enten Start > Kør > skriv PSR.exe > OK, eller klik på Windows-tasten > skrive PSR.exe > og derefter trykke på Enter.

  2. Når det lille vindue med PSR.exe vises, skal du klikke på Start optagelse og reproducere trinnene, der genskaber problemet med ydeevnen.

    Du kan tilføje kommentarer efter behov ved at klikke på Tilføj kommentar.

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

  4. Klik på Gem.

Et skærmbillede af Trinoptager eller PSR.exe.

Tag et kig på disse skærmbilleder for at se, hvorfor dette værktøj alene kan være så praktisk, når du angiver et omfang af ydelsesproblemet.

Trinoptager, der viser et login til Office 365 i ét trin kl. 12:07 og 47 sekunder.

Trinoptager, som viser, at trin 8 klokken 12:09 og 6 sekunder, hvor siden gengives i ufuldstændig tilstand.

Datoen og klokkeslættet er registreret for dig. Dette linker din PSR til dit Netmon-spor og HTTPWatch i tide og hjælper med præcisionsfejlfinding. Datoen og klokkeslættet i registreringen viser også, at der er gået et minut mellem logon og browsing i URL-adressen, og den delvise gengivelse af admin-webstedet. I dette tilfælde skiftede webstedet fra en tom tilstand til en delvist gengivet tilstand efter dette – i tæt på to minutter – i dette tilfælde en god påmindelse om, at det er vigtigt at lave systemopdateringer og genstarte klientcomputere, ellers kan sidegengivelsesydeevnen være inkonsistent.

Læs dine sporinger

Det er ikke muligt at lære alt om fejlfinding af netværk og ydeevne, som du kan have brug for at vide, via en artikel. At få en god ydeevne kræver erfaring og viden om, hvordan netværket virker og fungerer. Men det er muligt at udarbejde en liste over de vigtigste problemer og vise, hvordan værktøjer kan gøre det nemmere for dig at fjerne de mest almindelige problemer.

Hvis du vil lære færdigheder med at aflæse netværkssporinger for dine Office 365-websteder, findes der er ingen bedre lærer end at oprette spor af sideindlæsninger regelmæssigt og ved at opnå erfaring ved at læse dem. F.eks. når du har mulighed for at indlæse en Office 365-tjeneste og spore processen. Filtrer kurven for DNS-trafik, eller søg på FrameData efter navnet på den tjeneste, du har gennemset. Scan sporet for at få en ide om de handlinger, der udføres, når tjenesten indlæses. På denne måde kan du se, hvordan almindelig sideindlæsning skal se ud, og i forbindelse med fejlfinding, særligt omkring ydeevne, kan du lære meget af at sammenligne gode og dårlige sporinger.

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 på en rulleliste. Hvis du f.eks. er bekymret over skaleringen af TCP-vinduet, kan du finde vej til et filter (f.eks. .protocol.tcp.window < 100) på den måde.

Skærmbillede af Netmon, som viser, at feltet Vis filter bruger IntelliSense.

Netmon-sporinger kan have en masse trafik i dem. Hvis du ikke er erfaren med at læse dem, kan du blive en anelse overvældet, første gang du åbner sporingen. Det første, du skal gøre, er at adskille signalet fra baggrundsstøj i sporingen. Du har testet op imod Office 365, og det er den trafik, som du gerne vil se. Hvis du er vant til at navigere gennem sporinger, har du måske ikke brug for denne liste.

Trafikken mellem din klient og Office 365 passerer via TLS, hvilket betyder, at hoveddelen af trafik 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 pakkehovederne og de oplysninger, som de indeholder.

Tip til at få et godt spor

  • Kend værdien af IPv4- eller IPv6-adresserne på klientcomputeren. Du kan få denne fra kommandoprompten ved at skrive IPConfig og derefter trykke på Enter. Hvis du kender denne adresse, kan du hurtigt se, om trafikken i sporet direkte involverer klientcomputeren. Hvis der er en kendt proxy, kan du pinge den og få dens IP-adresse.

  • Rens din DNS Resolver-cache og, hvis det er muligt, skal du lukke alle browsere, undtagen den hvor du kører din test. Hvis du ikke kan gøre dette, hvis f.eks. support bruger et browserbaseret værktøj for at se klientcomputerens skrivebord, skal du være klar til at filtrere dine spor.

  • Find den Office 365-tjeneste, du bruger, i et travlt spor. Hvis du aldrig eller sjældent har set din trafik før, er dette et nyttigt trin til at adskille ydelsesproblemer fra anden netværksstøj. Det kan du gøre på forskellige måder. Direkte før din test kan du bruge ping eller PsPing til URL-adressen for den specifikke tjeneste (f.eks. ping outlook.office365.com og/eller psping -4 microsoft-my.sharepoint.com:443). Du kan også nemt finde den pågældende PsPing i en Netmon-sporing (ud fra dets procesnavn). Så du får et sted at begynde at lede.

    Hvis du kun bruger Netmon-sporing på tidspunktet for problemet, er det også ok. For nemmere at kunne orientere dig kan du bruge et filter som f.eks. ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"). Du kan registrere dit rammenummer fra sporingsfilen. Det kan også være, at du vil rulle på ruden Rammeoversigt helt til højre og se efter kolonnen Samtale-id. Der er angivet et nummer der for id'et for denne specifikke samtale, som du også kan registrere og kigge på isoleret senere. Husk at fjerne dette filter, før du anvender nogen andre former for filtrering.

    Tip: Netmon indeholder en masse praktiske indbyggede filtre. Prøv knappen "Load Filter" øverst i filterruden Display.

    Find din IP-adresse ved hjælp af PSPing på kommandolinjen på klientcomputeren.

    Netmon-sporing fra den klient, som indeholder den samme PSPing-kommando gennem filteret TCP.Flags.Syn == 1.

    Bliv fortrolig med din trafik, og lær at finde de oplysninger, du skal bruge. Lær f.eks. at bestemme, hvilken pakke i sporingen der har den første reference til den Office 365-tjeneste du bruger (f.eks. "Outlook").

Hvis vi tager Office 365 Outlook Online som eksempel, begynder trafikken nogenlunde sådan:

  • DNS Standard Query og DNS-svar til outlook.office365.com med matchende forespørgsels-id'er. Det er vigtigt at være opmærksom på tidsforskydning for denne ekspedition, samt hvor i verden Office 365 Global DNS sender anmodningen om navneoversættelse. Ideelt set så lokalt som muligt, i stedet for halvvejs i den anden ende af verden. (Dette kan efterfølges af noget DNS-trafik ved onlinelogon).

  • En HTTP GET-anmodning, hvis statusrapport overføres permanent (301)

  • RWS-trafik herunder anmodninger om RWS-forbindelser og svar på forbindelser. (Dette er Remote Winsock, der oprettede forbindelse for dig).

  • En TCP SYN- og TCP SYN/ACK-samtale. En masse indstillinger i denne samtale påvirker ydeevnen.

  • Derefter en række TLS:TLS-trafik, som er det sted, hvor samtaler med TLS handshake og TLS-certifikat foregår. (Husk, at dataene er krypteret via SSL/TLS).

Alle dele af trafik er vigtige og tilsluttet, men små dele af sporet indeholder oplysninger, der er særligt vigtige med hensyn til fejlfinding af ydeevnen, så vi fokuserer på disse områder. Og eftersom vi har udført tilstrækkelig fejlfinding af ydeevnen for Office 365 hos Microsoft til at samle en top ti-liste over almindelige problemer, vil vi fokusere på problemerne, og hvordan du bruger værktøjerne, ved at udrede dem som det næste.

Hvis du ikke har installeret dem allerede, gør matrixen herunder brug af adskillige værktøjer. Hvor det er muligt. Gives links til installationspunkterne. Listen omfatter almindelige værktøjer til netværkssporing, f.eks. Netmon og Wireshark, men brug det sporingsværktøj, du har det bedst med, og hvor du har vænnet dig til at filtrere netværkstrafikken. Når du tester, skal du huske:

  • Luk dine browsere, og test kun med én browser, der kører – Dette vil reducere den samlede trafik, du registrerer. Det giver en mindre travl sporing.

  • Rens din DNS Resolver-cache på klientcomputeren – Dette giver dig en ren tavle, når du begynder at lave dine registreringer, hvilket giver en renere sporing.

Nogle af de største problemer

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

Vigtigste problem

Værktøj

Det, du er på udkig efter

TCP Windows-skalering

  • Findes i SYN - SYN/ACK.

  • Tidligere eller ældre hardware kan ikke benytte sig af TCP Windows-skalering.

  • Uden korrekte indstillinger til TCP Windows-skalering bliver standard 16-bit bufferen i TCP headere udfyldt i millisekunder.

  • Trafik kan ikke fortsætter med at sende, indtil klienten modtager en bekræftelse, som de oprindelige data har modtaget, hvilket medfører forsinkelser.

Netmon

Wireshark

Se efter SYN - SYN/ACK-trafik i din netværkssporing.

I Netmon skal du bruge et filter som tcp.flags.syn == 1. Dette filter er det samme som i Wireshark.

Filtrer i Netmon eller Wireshark for Syn-pakker for begge værktøjer: TCP.Flags.Syn == 1.

Bemærk, at for hver SYN findes der en kildeportal (SrcPort), der er matchet i destinationsporten (DstPort) af den relaterede Bekræftelse (SYN/ACK).

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

Grafik, der viser, hvordan du matcher SrcPort til DstPort i en sporing for at få vist deltatidspunkt.

Indstillinger for ledig TCP-tid

  • Historisk set er de fleste afskærmede netværk konfigureret til midlertidige forbindelser, hvilket vil sige, at inaktive forbindelser generelt afsluttes.

  • Inaktive TCP-sessioner kan opsiges af proxyer og firewalls på mere end 100 til 300 sekunder.

  • Dette er problematisk for Outlook Online, fordi den opretter og bruger langsigtede forbindelser, uanset om de er ledige eller ej.

  • Når forbindelserne er afsluttet af proxy- eller firewall-enheder, bliver klienten ikke informeret, og et forsøg på at bruge Outlook Online vil betyde, at en klientcomputer forsøger, gentagne gange, at genskabe forbindelsen, før du foretager en ny.

  • Du får muligvis set hængere i produktet, prompts eller langsom ydeevne ved indlæsning af siden.

Netmon

Wireshark

I Netmon skal du kigge på feltet Time Offset for en returkørsel. En returkørsel er tiden mellem klienten, der sender en anmodning til serveren og modtager et svar tilbage. Se mellem klienten og udgangspunktet (f.eks. Klient --> Proxy), eller Office 365-klienten (Klient --> Office 365). Du kan se dette i mange typer pakker.

Som eksempel vil filteret i Netmon 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 dit spor tilhører din DNS-server? Prøv at slå den op på kommandolinjen. Klik på Start > Kør > og skriv cmd, eller tryk på Windows-tasten > og skriv cmd. Når du bliver bedt om det, skal du skrive nslookup <the IP address from the network trace>. For at teste skal du bruge nslookup mod din egen computers IP-adresse.

Du kan få vist en liste over Microsofts IP-områder under Office 365-webadresser og IP-adresseområder.

Hvis der er et problem kan du forvente lang tid, inden forskydningerne vises, i dette tilfælde (Outlook Online), specielt i TLS:TLS-pakker, der viser passagen af programdata (f.eks. i Netmon kan du finde programdatapakker via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Du burde se et jævnt forløb i gang på tværs af sessionen. Hvis du får vist lange forsinkelser, når du opdaterer din Outlook Online, kan det skyldes, at der er en høj grad af nulstillinger, der sendes.

Ventetid/Returkørselstid

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

  • Der er båndbreddeberegnere til Office 365 på denne side Bedste fremgangsmåder for Office 365-båndbredde.

  • Har du brug for at måle hastigheden på din forbindelse eller din internetudbyders båndbreddeforbindelse? Prøv dette websted (eller lignende websteder): Speedtest Official Site og Pingtest.

Ping

PsPing

Netmon

Wireshark

For at registrere ventetid i en sporing kan du drage fordel af at have registreret klientcomputerens IP-adresse og IP-adressen på DNS-serveren i Office 365. Dette er med henblik på nemmere filtrering af sporinger. Hvis du opretter forbindelse via en proxy, skal du bruge din klientcomputers IP-adresse, IP-adressen på proxyen/udgangspunktet og IP-adressen på Office 365 DNS for at gøre arbejdet nemmere.

En ping-anmodning sendt til outlook.office365.com giver dig navnet på det datacenter, der modtager anmodningen, selvom ping muligvis ikke kan oprette forbindelse til at sende fortløbende ICMP-pakker. Hvis du bruger PsPing (et gratis værktøj til download) og angiver porten (443) og måske bruger IPv4 (-4), får du en gennemsnitlig returkørselstid for pakker, der er sendt. Dette fungerer for andre URL-adresser i Office 365-tjenesterne, f.eks. psping -4 yourSite.sharepoint.com:443. Faktisk kan du kan angive et antal ping for at få en større stikprøve til dit gennemsnit, prøv noget i retning af: psping -4 -n 20 yourSite-my.sharepoint.com:443.

Bemærk: PsPing sender ikke ICMP-pakker. Det pinger med TCP-pakker over en bestemt port, så du kan bruge en hvilken som helst, du ved er åben. I Office 365, som anvender SSL/TLS, kan du prøve at tilknytte port :443 til din PsPing.

Skærmbillede, der viser en ping, som løser outlook.office365.com, og en PSPing med 443, der gør det samme, men som også rapporterer en 6,5 ms gennemsnitlig RTT.

Hvis du har indlæst den langsomme indlæsning af Office 365-siden, mens du udfører en netværkssporing, bør du filtrere et Netmon- eller Wireshark-spor for DNS. Dette er en af de IP'er, vi leder efter.

Her er de trin, du skal følge for at filtrere din Netmon til at hente IP-adressen (og se nærmere på DNS-ventetiden). I dette eksempel bruges outlook.office365.com, men URL-adressen på en SharePoint Online-lejer kan også bruges (f.eks. hithere.sharepoint.com).

  1. Ping URL-adressen ping outlook.office365.com, og i søgeresultaterne skal du registrere navn og IP-adressen på den DNS-server, som ping-anmodningen blev sendt til.

    Ping-anmodning om at outlook.office365.com viser DNS og IP-adressen på namnorthwest.

  2. Netværkssporingen åbner siden eller udfører den handling, der giver dig ydelsesproblemet, eller hvis du ser en lang ventetid på selve pingen, kan du netværksspore den.

  3. Åbn sporingen i Netmon, og filtrer efter DNS (dette filter fungerer også i Wireshark, men der skelnes mellem små og store bogstaver – dns). Da du kender navnet på DNS-serveren fra din ping, kan du også filtrere hurtigere i Netmon som her: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), hvilket ser sådan ud i Wireshark dns and frame contains "namnorthwest".

    Åbn svarpakken, og i vinduet Frame Details i Netmon skal du klikke på DNS for at udvide for at få flere oplysninger. I DNS-oplysningerne finder du IP-adressen på den DNS-server, anmodningen kom til i Office 365 – du skal bruge denne IP-adresse i næste trin (PsPing-værktøjet). Fjern filteret, højreklik på DNS-svaret i Netmon i Netmons Frame Summary > Find Conversations > DNS for at se DNS-forespørgslen og svaret side om side.

    En sporing, som er filtreret efter Find samtaler og derefter efter DNS.

  4. I Netmon skal du også bemærke kolonnenTime Offset mellem DNS-anmodningen og svaret.

    Yderligere Netmon-resultater filtreret med DNS OG CONTAINSBIN(Framedata, ASCII, "namnorthwest"), som viser meget lav tidsforskydning mellem anmodning og svar.

I næste trin bliver det meget praktisk med værktøjet PsPing, der er nemt at installere og bruge, både fordi ICMP ofte er blokeret på firewall, og fordi PsPing elegant registrerer ventetiden i millisekunder. PsPing gennemfører en TCP-forbindelse til en adresse og port (i vores tilfælde den åbne port 443).

  1. Installer PsPing.

  2. Åbn en kommandoprompt (Start > Kør > skriv cmd, eller Windows-tast > skriv cmd), og skift mappe til den mappe, hvor du installerede PsPing for at køre PsPing-kommandoen. I mine eksempler kan du se, at jeg har lavet en mappe 'Perf" i roden af C. Du kan gøre det samme for at få hurtig adgang.

  3. Skriv kommandoen, så du laver din PsPing mod IP-adressen på Office 365 DNS-serveren fra din tidligere Netmon-sporing – husk at tilføje portnummeret. Med andre ord psping -n 20 132.245.24.82:445. Dette vil give dig en stikprøve på 20 pings og beregne gennemsnittet for ventetiden, når PsPing stopper.

    PSPing-kommandoen psping -n 20 132.245.24.82:443, som returnerer en gennemsnitlig forsinkelse på 25,51 millisekunder.

Hvis du vil til Office 365 via en proxyserver, er trinene lidt anderledes. Du skal først PsPing på din proxyserver for at få en gennemsnitlig værdi for ventetiden i millisekunder til proxy/udgangspunkt og tilbage og derefter enten køre PsPing på proxy eller på en computer med en direkte internetforbindelse for at få den manglende værdi (den ene til Office 365 og tilbage).

Hvis du vælger at køre PsPing fra proxy, kan du vælge mellem to millisekundværdier: klientcomputer til proxyserver eller udgangspunkt og proxyserver til Office 365. Og så er du færdig! I hvert fald med registrering af værdier.

Hvis du kører PsPing på en anden klientcomputer, og som har en direkte forbindelse til internettet, dvs. uden en proxy, har du to millisekundværdier: klientcomputer til proxyserver eller udgangspunkt og klientcomputer til Office 365. I dette tilfælde trækkes værdien af klientcomputer til proxyserver eller udgangspunkt fra værdien for Office 365-klientcomputeren, så har du RTT-tallene fra klientcomputer til proxyserver eller udgangspunkt og fra proxyserver eller udgangspunkt til Office 365.

Men hvis du kan finde en klientcomputer på den påvirkede placering, som er direkte forbundet, eller du kan tilsidesætte proxyen, kan du vælge at se, om problemet gengives der til at begynde med og derefter teste ved hjælp af det.

Ventetid, som det fremgår af en Netmon-sporing, vil disse ekstra millisekunder samle sig sammen, hvis der er tilstrækkeligt mange af dem i en given session.

Generel forsinkelse i Netmon med Netmon standardtidspunktet for Delta-kolonnen føjet til Rammeoversigt.

Bemærk: Din IP-adresse kan være forskellig fra de IP'er, der er vist her, din ping kan f eks. returnere noget mere, som f.eks. 157.56.0.0/16 eller et lignende område. Hvis du vil have en liste over områder, der bruges af Office 365, skal du se Office 365-webadresser og IP-adresseområder. Husk at udvide alle noderne (der er en knap øverst til dette), hvis du vil søge efter f.eks. 132,245.

Godkendelse af proxyen

  • Dette gælder kun for dig, hvis du benytter en proxyserver. Hvis dette ikke er tilfældet, kan du springe disse trin over.

  • Når proxygodkendelse fungerer korrekt, skal det foregå i millisekunder, på en ensartet måde. Du bør ikke se en forbigående dårlig ydeevne under perioder med spidsbelastninger (for eksempel).

  • Hvis proxygodkendelse er slået til, skal du, hver gang du laver en ny TCP-forbindelse til Office 365 for at få oplysninger, passere gennem en godkendelsesproces i baggrunden. Så når du f.eks. skifter fra Kalender til Mail i Outlook Online, skal du godkende. Og i SharePoint Online, hvis en side viser medier eller data fra flere websteder eller placeringer, skal du godkende for hver forskellig TCP-forbindelse, der er nødvendig, for at kunne gengive dataene.

  • I Outlook Online kan du opleve langsomme indlæsningstider, når du skifter mellem Kalender og din postkasse, eller langsomme sideindlæsninger i SharePoint Online. Der er dog andre symptomer, der ikke er vist her.

    Godkendelse af proxyen er en indstilling på din udgangsproxyserver. Hvis det giver problemer med ydeevnen sammen med Office 365, skal du kontakte dit netværksteam.

Netmon

Wireshark

Proxygodkendelse finder sted, når en ny TCP-session skal være roteret, normalt for at anmode om filer eller info fra serveren eller for at levere info. Du kan f.eks. få vist godkendelse af proxyen omkring HTTP GET eller HTTP POST-anmodninger. Hvis du vil se de rammer, hvor du godkender anmodninger i din sporing, skal du tilføje kolonnen 'NTLMSSP Oversigt' til Netmon og filtrere efter .property.NTLMSSPSummary. For at se, hvor lang tid godkendelsen tager, skal du tilføje kolonnen Time Delta. Sådan tilføjer du en kolonne til Netmon:

  1. Højreklik på en kolonne, f.eks. Description.

  2. Klik på Vælg kolonner. Find NTLMSSP-oversigt og Time Delta på listen, og klik på Tilføj.

  3. Flyt de nye kolonner på plads før eller bag kolonnen Description, så du kan læse dem side om side. Klik på OK.

Selvom du ikke tilføjer kolonnen, fungerer Netmon-filteret. Men fejlfindingen vil være meget nemmere, hvis du kan se, hvilken godkendelsesfase du er i. Når du søger efter forekomster af proxygodkendelse, skal du sørge for at undersøge alle rammer, hvor der findes en NTLM-udfordring, eller hvor en godkendelsesmeddelelse er til stede. Hvis det er nødvendigt, skal du højreklikke på den bestemte trafik og Find samtaler > TCP. Vær opmærksom på værdierne for Tidsdelta i disse samtaler.

Netmon-sporing viser godkendelse af proxyen, filtreret efter samtale.

En fire sekunders forsinkelse i godkendelse af proxyen, som det fremgår af Wireshark. Kolonnen Time delta from previous displayed frame blev udført ved at højreklikke på feltet med samme navn i detaljerne om billedet og vælge Tilføj som kolonne.

I Wireshark kan kolonnen "Time delta from previous displayed frame" oprettes ved at højreklikke på feltet med samme navn i detaljerne om billedet og vælge Tilføj som kolonne.

DNS-ydeevne

  • Navneoversættelse fungerer bedst og hurtigst, når det sker så tæt på klientens land som muligt.

  • Hvis DNS-navneoversættelse finder sted oversøisk, kan det tage ekstra sekunder at indlæse siden.

  • Ideelt set sker navneoversættelse på under 100 ms. Hvis dette ikke er tilfældet, bør du undersøge yderligere.

Tip: Er du ikke sikker på, hvordan klientforbindelser virker i Office 365? Se referencedokumentet til klientforbindelser her.

Netmon

Wireshark

PsPing

Analyse af DNS-ydeevnen er typisk et andet job for en netværkssporing. Men PsPing er også praktisk i forbindelse med at få en mulig årsag i betragtning eller ej.

DNS-trafik er baseret på TCP- og UDP-anmodninger, og svar er tydeligt markeret med et id, der kan hjælpe med at matche en specifik anmodning med dens specifikke svar. Du får vist DNS-trafik når, f.eks. SharePoint Online anvender et netværksnavn eller URL-adressen på en webside. Som en tommelfingerregel vil det meste af denne trafik, undtagen ved overførsel af zoner, køre over UDP.

I både Netmon og Wireshark er det mest grundlæggende filter, som gør det muligt at se på DNS-trafik, blot dns. Sørg for at bruge små bogstaver til angivelse af filter. Husk at rense din DNS Resolver-cache, før du begynder at genskabe problemet på klientcomputeren. Hvis du f.eks. har en langsom indlæsning af en SharePoint Online-side for startsiden, skal du lukke alle browsere, åbne en ny browser, starte sporing, rense din DNS Resolver-cache og finde dit SharePoint Online-websted. Når hele siden oversættes, bør du stoppe og gemme sporingen.

Et grundlæggende filter for DNS i Netmon er DNS.

Du vil se på tidspunktet for forskydning her. Og det kan være nyttigt også at tilføje kolonnen Time Delta til Netmon, hvilket du kan gøre ved at udføre disse trin:

  1. Højreklik på en kolonne, f.eks. Description.

  2. Klik på Choose Columns.

  3. Find Time Delta på listen, og klik på Add.

  4. Flyt de nye kolonner på plads før eller bag kolonnen Beskrivelse, så du kan læse dem side om side. Klik på OK.

Hvis du finder en interessant forespørgsel, kan du overveje at isolere den ved at højreklikke på den pågældende forespørgsel i panelet med rammedetaljer, vælge Find Conversations > DNS. Bemærk, at panelet Netværkssamtaler springer direkte til den bestemte samtale i sin log over UDP-trafik.

En Netmon-sporing af Outlook Online-indlæsning, som er filtreret efter DNS, og brug af Find samtaler og derefter DNS for at indskrænke resultaterne.

I Wireshark kan du lave en kolonne for DNS-tid. Tag din sporing (eller åbn en sporing) ind i Wireshark, og filtrer efter dns, eller mere nyttigt efter dns.time. Klik på en DNS-forespørgsel, og i panelet med detaljer skal du udvide detaljerne for Domain Name System (response). Her finder du et felt for tid (f.eks. [Time: 0.001111100 seconds]. Højreklik på denne tid, og vælg Apply as Column. Dette vil give dig en kolonne for Time for hurtigere sortering af dine spor. Klik på den nye kolonne for at sortere efter faldende værdier for at se, hvilke DNS-opkald der tog længst tid at løse.

En gennemgang af SharePoint Online-filtreret i Wireshark af dns.time (små bogstaver) med tidsoplysningerne fra detaljerne indført i en kolonne og sorteret stigende.

Hvis du gerne vil foretage flere undersøgelser af DNS-løsningstiden, kan du prøve et PsPing mod DNS-porten, der bruges af TCP (f.eks. psping <IP address of DNS server>:53). Har du stadig ydelsesproblemer? Hvis du gør, så er problemet mere tilbøjeligt til at være et større problem med netværket end et problem med et bestemt DNS-program, du forsøger at finde en løsning med. Det er også værd at nævne igen, at en ping til outlook.office365.com fortæller, hvor DNS-navneoversættelsen til Outlook Online finder sted (f.eks. outlook-namnorthwest.office365.com).

Hvis problemet ser ud til at være DNS-specifikt, kan du eventuelt kontakte din it-afdeling og bede dem om at kigge på DNS-konfigurationer og DNS-videresendelser for at undersøge dette problem yderligere.

Proxyskalerbarhed

  • Tjenester, som f.eks. Outlook Online i Office 365, giver klienter flere langsigtede forbindelser.

  • Derfor kan hver bruger bruge flere forbindelser, der kræver en længere levetid.

Tip: Har du brug for planlægning for båndbreddebrug, fordi du skal til at tilføje mange brugere til Office 365? Prøv Plan for brug af internetbåndbredde til Office 365. Der er båndbreddeberegnere tilgængelige der.

MAT

Der er ingen netværkssporing eller fejlfindingsværktøj specifikt til dette. I stedet er det baseret på båndbreddeberegninger med angivne begrænsninger og andre variabler.

TCP Maks. segmentstørrelse

  • Findes i SYN - SYN/ACK.

  • Udfør denne kontrol i en hvilket som helst netværkssporing af ydeevne, du har taget, for at sikre, at TCP-pakker er konfigureret til at foretage den maksimale mængde data.

  • Målet er at se en MSS på 1460 byte til overførsel af data.

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

Netmon

TCP Maks. segmentstørrelse (MSS) er en anden parameter i en trevejs-handshake i din netværkssporing, det betyder, at du finder de data, du skal bruge i SYN - SYN/ACK-pakken. MSS er faktisk ret nemt at se.

Åbn netværkssporingen for den ydeevne, du har, og find den forbindelse, du gerne vil vide mere om, eller som demonstrerer ydelsesproblemet.

Bemærkninger: Hvis du kigger på en sporing og skal finde den trafik, der er relevant for samtalen, skal du filtrere efter IP på klienten eller IP på proxyserveren eller udgangspunkt eller begge dele. Hvis du går direkte, skal du pinge den URL-adresse, som du tester IP-adresse for Office 365 for i sporingen og filtrere efter den.

Vil du gerne se nærmere på sporingen? Prøv at bruge filtre til at orientere dig. I Netmon skal du køre en søgning baseret på URL-adressen, f.eks. Containsbin(framedata, ascii, "sphybridExample"), vær opmærksom på rammetallet. I Wireshark kan du bruge noget i stil med frame contains "sphybridExample". Hvis du ser, at du har fundet RWS-trafik (Remote Winsock (den kan vises 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 registrere rammetallet, slippe filteret, klikke på All Traffic i vinduet Network Conversations i Netmon for at kigge på det nærmeste SYN.

Det vigtigste er, at hvis du ikke har modtaget nogen af IP-adresseoplysningerne på tidspunktet for sporet, vil det at finde din URL-adresse i sporet (en del af sphybridExample-my.sharepoint.com, for eksempel), give dig IP-adresser til at filtrere efter.

  1. Find forbindelsen i den sporing, du er interesseret i at se. Du kan gøre dette 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 Network Conversations i Netmon.

    Filtrering efter samtale. Højreklik på SYN-rammen, og klik på Find samtaler, TCP.

  2. Når du har fundet SYN-pakken, skal du udvide TCP (i Netmon) eller Transmission Control Protocol (i Wireshark) i panelet Frame Details.

  3. Udvid TCP-indstillingerne og MaxSegementSize.

  4. Find den relaterede SYN-ACK ramme, og udvid TCP-indstillinger og MaxSegmentSize.

  5. Den mindste af de to værdier skal være din Maks. segmentstørrelse.

På dette billede gør jeg brug af den indbyggede kolonne i Netmon kaldet TCP Troubleshoot.

Netværkssporing filtreret i Netmon ved hjælp af indbyggede kolonner.

Den indbyggede kolonne vises øverst på panelet Frame Details. (Du kan skifte tilbage til normal visning ved at klikke på Columns igen og derefter vælge Time Zone).

Her kan du finde rullemenuen Kolonner for indstillingen TCP-fejlfinding (øverst på Rammeoversigt).

Her er et filtreret spor i Wireshark. Der er et filter specifikt for MSS-værdien (tcp.options.mss). Rammerne i en SYN-, SYN/ACK-, ACK-handshake er sammenkædet nederst i Wireshark svarende til rammedetaljerne (så ramme 47 ACK, linker til 46 SYN/ACK, linker til 43 SYN) for at gøre denne type arbejde nemmere.

Sporing, som er filtreret i Wireshark af tcp.options.mss for maksimal segmentstørrelse (MSS).

Hvis du har brug for at kontrollere Selektiv bekræftelse (næste emne i denne matrix), skal du ikke lukke din sporing!

Selektiv bekræftelse

  • Findes i SYN - SYN/ACK.

  • Skal rapporteres som Tilladt i både SYN og SYN/ACK.

  • Selektiv bekræftelse (SACK) gør det muligt at have en jævnere retransmission af data, når en pakke eller pakker forsvinder.

  • Enheder kan deaktivere denne funktion, hvilket kan medføre problemer med ydeevnen.

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

Netmon

Selektiv bekræftelse (SACK) er en anden parameter i SYN-SYN/ACK-handshake. Du kan filtrere dit spor for SYN - SYN/ACK på mange måder.

  1. Find forbindelsen i den sporing, du er interesseret i at se, ved at scanne sporingen, filtrere efter IP-adresser eller ved at klikke på et samtale-id med vinduet Network Conversations i Netmon.

  2. Når du har fundet SYN-pakken, skal du udvide TCP i Netmon eller Transmission Control Protocol i Wireshark i afsnittet Frame Details).

  3. Udvid TCP-indstillinger og derefter SACK.

  4. Find den relaterede SYN-ACK ramme, og udvid TCP-indstillinger og dens SACK-felt.

  5. Det er tilladt at foretage visse SACK i både SYN og SYN/ACK.

Her er SACK-værdier, som det fremgår af både Netmon og Wireshark.

Selektiv bekræftelse (SACK) i Netmon som et resultat af tcp.flags.syn == 1.

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

DNS-geolokalitet

  • Hvor i verden Office 365 forsøger at løse dine DNS-opkald påvirker internetforbindelsen.

  • I Outlook Online efter det første DNS-opslag er udført, vil placeringen af den pågældende DNS blive brugt til at oprette forbindelse til dit nærmeste datacenter. Du får forbindelse til en Outlook Online CAS-serv, som kommer til at anvende et grundlæggende netværk for at få forbindelse til datacenteret (dC), hvor dine data lagres. Dette er hurtigere.

  • Når der oprettes forbindelse til SharePoint Online, vil en bruger, der er ude at rejse, blive omdirigeret til deres aktive datacenter – det er dC, hvis placering er baseret på deres SPO-lejers hjemmebase (altså et dC i USA, hvis brugeren er USA-baseret).

  • Lync Online har aktive noder i mere end ét dC ad gangen. Når forespørgsler sendes til Lync Online-forekomster, vil Microsofts DNS afgøre, hvor i verden anmodningen stammer fra, og returnere IP-adresser fra det nærmeste regionale dC, hvor Lync Online er aktiv.

Tip: Har brug for at få mere at vide om, hvordan klienter opretter forbindelse til Office 365? Se nærmere på referenceartiklen Klientforbindelser (og dens praktiske grafik).

Ping

PsPing

Anmodninger om navneoversættelse fra klientens DNS-servere til Microsofts DNS-servere vil i de fleste tilfælde resultere i, at Microsoft DNS returnerer IP-adressen på et regionalt datacenter (dC). Hvad betyder det for dig? Hvis dit hovedkvarter ligger i Bangalore, Indien, men du er ude at rejse i USA, når browseren foretager en anmodning for Outlook Online, bør Microsofts DNS-servere videregive IP-adresserne til datacentre i USA – et regionalt datacenter. Hvis mail er nødvendig fra Outlook, vil disse data passere på tværs af Microsofts hurtige basisnetværk mellem datacentre.

DNS fungerer hurtigst, når navneoversæ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) have kontakt til 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 værktøjet mod outlook.office365.com for at bestemme, hvor i verden din DNS-anmodning bliver distribueret. Hvis du befinder dig i Europa, skal du se et svar fra noget, der ligner outlook-emeawest.office365.com. I USA kan du forvente noget i stil med dette outlook-namnorthwest.office365.com.

  1. Åbn kommandoprompten på klientcomputeren (via Start > Kør > cmd eller Windows-tast > skriv cmd).

  2. Skriv ping outlook.office365.com, og tryk på Enter.

    Husk at angive -4, hvis du vil angive, at pinge via IPv4. De får muligvis ikke svar fra ICMP-pakkerne, men du bør kunne se navnet på den DNS, som anmodningen blev distribueret til.

Hvis du vil se tallene for ventetiden for denne forbindelse, skal du prøve PsPing til IP-adressen på den server, der returneres af ping.

Ping i outlook.office365.com, som viser opløsningen i outlook-namnorthwest.

PSPing til den IP-adresse, der returneres af ping til outlook.office365.com, som viser en forsinkelse på gennemsnitligt 28 millisekunder.

Program til fejlfinding af Office 365

Netmon

HTTPWatch

F12-konsol i browseren

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

Se også

Administrere Office 365-slutpunkter

Fejlfinding af Office 365-forbindelse

Del Facebook Facebook Twitter Twitter Mail Mail

Var disse oplysninger nyttige?

Fantastisk! Har du mere feedback?

Hvordan kan vi forbedre det?

Tak for din feedback!

×