Fejlfinding af ydeevne i forbindelse med planen for Office 365

Vigtigt: Denne artikel er maskinoversat. Se ansvarsfraskrivelsen. Du kan finde den engelske version af denne artikel her til din orientering.

Har du brug at vide, hvad du skal gøre at identificere og løse LAG'er, hænger og langsom ydeevne mellem SharePoint Online, OneDrive for Business, Exchange Online eller Skype for Business Online og klientcomputeren? Før du ringer til support, kan denne artikel hjælpe dig med at foretage fejlfinding af problemer med ydeevnen i Office 365 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:

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

    • Installer 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 din DNS resolver-cache

  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 Netværksovervågning værktøjet (Netmon) analyserer pakker, der er trafik, der passerer mellem computere på netværk. Se efter mistede pakker ved hjælp af Netmon til at spore trafik med Office 365 kan du hente, visning, og Læs pakke sidehoveder, identificere mellemliggende enheder, se vigtige indstillinger på netværkshardwaren, og følg strømmen af trafik mellem computere på virksomhedens netværk og Office 365. Da de faktiske brødteksten i trafikken er krypteret, det vil sige, den (rejser på port 443 via SSL/TLS, du kan ikke læse de filer, der sendes. I stedet, får du en ufiltrerede sporing af den sti, som de pakke træder som kan hjælpe dig med at finde frem til problemet.

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å startsiden: Seneste registrerer, Vælg netværk og Introduktion til Microsoft netværk skærm 3.4. Meddelelse om. Panelet Vælg netværk kan også give dig en liste over de standard-netværk, hvor du kan hente. Sørg for, at netværkskort 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 leveres opkrævet, og et gratis edition. Den gratis Basic Edition dækker alt, hvad du skal bruge til denne test. HTTPWatch skærme netværk trafik og siden indlæsningstiden direkte fra dit browservindue. HTTPWatch er en plug-in til Internet Explorer, der beskriver grafisk ydeevne. 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øre Problem Trinoptager (PSR.exe) til at registrere 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 kommentarer.

  3. Klik på Stop post, når du har fuldført trinnene. Hvis problemet med ydeevnen er en side gengivelse, vente på siden for at gengive, før du stoppe optagelsen.

  4. Klik på Gem.

Et skærmbillede af Trinoptager eller PSR.exe.

Dato og klokkeslæt er registreret for dig. Dette links fra din bestemte til din Netmon-sporing og HTTPWatch tidspunkt og hjælper med at foretage fejlfinding af præcision. Dato og klokkeslæt i posten, fra bestemte kan vise, at et minut overføres mellem logon og gennemsyn af URL-adressen og den delvise gengivelse af webstedet admin, f.eks.

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 vælge færdigheder læse netværk sporinger til din Office 365-websteder, er der ingen bedre lærer end at oprette spor af indlæse siden regelmæssigt, og at få læse dem oplevelse. For eksempel, når du har mulighed for, indlæse en Office 365-tjenesten og spore processen. Filtrere sporing til DNS-trafik, eller Søg FrameData for navnet på den tjeneste, du findes. Scanne sporingen for at få en ide om, de trin, der opstår, når tjenesten indlæses. Dette hjælper dig med at se, hvilke normal indlæsning af siden skal se ud, og i forbindelse med fejlfinding af særligt omkring ydeevne, sammenlignes med forkert sporinger kan lære dig mange.

Netmon bruger Microsoft Intellisense i feltet Vis filter. IntelliSense eller intelligent kode er afsluttet, er stikket sted, hvor du skriver i en periode, og alle tilgængelige indstillinger vises i en rullelisten valg. Hvis du er for eksempel bekymret TCP vinduet skalering, kan du kan finde frem til et filter (såsom .protocol.tcp.window < 100) på denne 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 erfarne med at læse dem, er det sandsynligvis du bliver overvældet åbne sporet første gang. Den første, du skal gøre er at adskille signalet fra baggrundsstøj i sporet. Du har afprøvet mod Office 365, og det er den trafik, du vil have vist. Hvis du har brugt til at navigere gennem sporinger, skal du muligvis ikke 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 Office 365-tjenesten, som du bruger i en sporing for optaget. Hvis du har aldrig eller sjældent set din trafik før, er en praktisk trin til at adskille problemet med ydeevnen fra andre netværk støj. Der er nogle måder at gøre dette. Lige før din test, kan du bruge ping eller PsPing til URL-adressen for den specifikke tjeneste (ping outlook.office365.com og/eller psping -4 microsoft-my.sharepoint.com:443eksempler). Du kan også nemt finde PsPing i en Netmon-sporing (efter procesnavnet). Der giver dig et sted at starte leder.

    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 SYN/ACK for TCP-samtale. Mange af indstillingerne i denne samtale påvirke 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. Der 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:

  • Lukke din browsere og teste med kun én browser, der kører - Dette mindsker overordnede trafikken du registrere. Det gør for en mindre belastet 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.

Bruge et filter som tcp.flags.syn == 1i Netmon. Dette filter er den samme 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 et eksempel vil 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.

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, forventer lang tid forskyder skal vises i dette tilfælde (Outlook Online), især i TLS:TLS-pakker, der viser overgang af Application Data (for eksempel i Netmon du kan finde programmet datapakker via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Du bør se jævne forløb i klokkeslættet på tværs af sessionen. Hvis du får vist lange forsinkelser, når du opdaterer din Outlook Online, kan det skyldes, at en høj grad af adgangskoder, der sendes.

Ventetid/Returkørselstid

  • Ventetid er en måling, der kan ændres meget, afhængigt af mange variabler, sådanne opgradering aldersfordelt enheder, tilføje et stort antal brugere til et netværk, samt procentdelen af overordnede båndbredde andre opgaver på en netværksforbindelse.

  • Der er båndbreddeberegnere til Office 365 på siden Netværksplanlægning og justering af ydeevnen for Office 365.

  • 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ærk netværkssporingen åbner siden eller udfører handlingen, der giver dig ydelsesproblemet, eller, hvis du ser en lang ventetid på selve pingen, 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 er let at installere og bruge PsPing værktøj meget praktisk, både da ICMP er ofte blokeret på Firewalls, og fordi PsPing elegant måde registrerer ventetid i millisekunder. PsPing fuldfører en TCP-forbindelse til en adresse og port (i vores tilfælde åben 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, der har en direkte forbindelse til internettet, det vil sige, uden en proxy, har du to millisekunder værdier: klientcomputeren til proxy-server eller udgangspunkt, og klientcomputeren til Office 365. I dette tilfælde subtrahere værdien af klientcomputeren til proxy-server eller udgangspunkt punkt fra værdien af klientcomputeren til Office 365, og du vil have RTT tallene fra klientcomputeren til proxy-server eller udgangspunkt, og fra proxy-server eller udgangspunkt punkt 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 en Netmon-sporing, disse ekstra millisekunder samle sig, 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 proxyserver udgangspunkt. Hvis det forårsager problemer med ydeevnen med Office 365, skal du kontakte dit netværk team.

Netmon

Wireshark

Proxy-godkendelse finder sted, hver gang en ny TCP-session skal spundet op, ofte for at anmode om filer eller oplysninger fra serveren, eller angive oplysninger. For eksempel kan du se proxygodkendelse omkring HTTP GET eller HTTP POST anmodninger. Hvis du vil se de billeder, hvor du godkendelse af anmodninger om i din sporing, skal du føje kolonnen 'NTLMSSP oversigt' til Netmon og filtrere efter .property.NTLMSSPSummary. For at se, hvor lang tid godkendelsen tager skal du føje kolonnen Time Delta. Sådan føjes 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 føje en kolonne, fungerer filteret Netmon. Men fejlfindingen vil være meget nemmere, hvis du kan se, hvilken fase af godkendelse, du er i. Når søger efter forekomster af godkendelse af proxyen, skal du sørge for at læse alle rammer, hvor der ikke er en NTLM udfordring eller et godkende meddelelse er til stede. Hvis det er nødvendigt, skal du højreklikke på den del af trafik og finde samtaler > TCP. Vær opmærksom på Time Delta værdierne 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 den mest grundlæggende filter, skal du se på DNS-trafik blot dns. Sørg for at bruge små bogstaver, når du angiver filteret. Husk at rens din DNS resolver-cache, før du begynder at Genskab problemet på klientcomputeren. Eksempelvis hvis du har en langsom SharePoint Online sideindlæsning til startsiden, skal du lukke alle browsere, Åbn en ny browser, start sporing, rens din DNS resolver-cache, og gå til SharePoint Online-webstedet. Når hele siden løser, skal du stoppe og gemme sporingen.

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

Du vil se klokken forskydning her. Og det kan være praktisk at føje kolonnen Time Delta til Netmon, som du kan gøre ved at udføre disse trin:

  1. Højreklik på en kolonne, f.eks. 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 forespørgsel af interesse, kan du overveje at isolere ved at højreklikke på forespørgslen i panelet frame details, vælge Find samtaler > DNS. Bemærk, at panelet Network Conversations springer højre til bestemte samtalen i dets log af 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.

Du kan gøre en kolonne for DNS-gang i Wireshark. Tage din sporing (eller åbne en sporing) i Wireshark og filtrere efter dnseller mere formulardesignprocessen dns.time. Klik på en hvilken som helst DNS-forespørgsel, og udvid Domain Name System (response) detaljerne i panelet med oplysninger. Du får vist et felt for tid (for eksempel [Time: 0.001111100 seconds]. Højreklik på nuværende tidspunkt, og vælg Anvend som kolonne. Dette kan give dig en kolonne med klokkeslæt for hurtigere sortering af din sporing. Klik på den nye kolonne til at sortere efter faldende værdier for at se, hvilke DNS-opkald tog den længst til 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 vil gøre flere undersøgelse DNS-opløsning tid, kan du prøve en PsPing mod DNS port bruges af TCP (for eksempel psping <IP address of DNS server>:53). Kan du stadig se problemer med ydeevnen? Hvis du gør, derefter er problemet mere sandsynligvis er et bredere netværk udstede end et problem med bestemt det DNS-program, du nå for at gøre opløsning. Det er også værd at nævne, igen, en ping til outlook.office365.com, som fortæller dig, hvor DNS-navneoversættelse for Outlook Online finder sted (for eksempel 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 maksimal segmentstørrelse (MSS) er en anden parameter af 3-vejs kvitteringen i din netværkssporing, der betyder, at du kan finde de data, du har brug for i SYN - SYN/ACK pakke. 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.

  • Se på sporet brugte? Prøv at bruge filtre til orientere dig selv. I Netmon skal køre en søgning, der er baseret på URL-adressen, som Containsbin(framedata, ascii, "sphybridExample"), skal du bemærke af ramme tal. Brug noget i retning af frame contains "sphybridExample"i Wireshark. Hvis du oplever, at du har fundet Remote Winsock (RW'ER) trafik (den kan vises som en [PSH, ACK] i Wireshark), skal du huske, at RW'ER opretter forbindelse kan ses kort før relevante SYN - SYN/pakker, som beskrevet tidligere. På dette tidspunkt, kan du registrere ramme antallet, slip filteret, klik på al trafik i vinduet Network Conversations i Netmon at kigge på den 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 for 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 en filtreret sporing i Wireshark. Der er et filter, der er specifikke for værdien MSS (tcp.options.mss). Rammer af SYN, SYN/ACK, ACK handshake er sammenkædet i bunden af den svarer til Frame Details Wireshark (så ramme 47 ACK, links til 46 SYN/ACK, links til 43 SYN) til 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 bør i de fleste tilfælde resultat i Microsoft DNS, der returnerer en regionale datacenter (dC) IP-adresse. Hvad betyder det for dig? Hvis din headquarters i Bangalore, Indien, men du er ude at rejse i USA, når browseren gør en anmodning for Outlook Online, skal Microsofts DNS-servere hånd du IP-adresser til datacentre i USA – en regionale datacenter. Hvis der kræves mail fra Outlook, rejser disse data på tværs af Microsofts hurtig grundlæggende element netvæ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. Du kan ikke få et svar fra ICMP-pakker, men du skal se navnet på DNS-Posterne, anmodningen blev sendt.

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.

Relaterede emner

Administrere Office 365 slutpunkter
fejlfinding i forbindelse med Office 365-forbindelse

Bemærk: Ansvarsfraskrivelse for maskinoversættelse: Denne artikel er blevet oversat af et computersystem uden menneskelig indgriben. Microsoft tilbyder disse maskinoversættelse for at hjælpe ikke-engelsktalende brugere til at kunne nyde indhold om Microsofts produkter, tjenester og teknologier. Da artiklen er maskinoversat, kan den indeholde forkerte ord eller syntaks- eller grammatikfejl.

Udvid dine færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Bliv Office Insider

Var disse oplysninger nyttige?

Tak for din feedback!

Tak for din feedback! Det lyder, som om det vil kunne hjælpe, hvis du bliver sat i forbindelse med en af vores Office-supportteknikere.

×