Plan för prestandafelsökning för Office 365.

Behöver du veta vilka åtgärder du måste vidta för att identifiera och åtgärda fördröjningar, fördröjningar och långsamma prestanda mellan SharePoint, OneDrive, Exchange Online eller Skype för företag Online och klientdatorn? Innan du ringer supporten kan den här artikeln hjälpa dig att felsöka Office 365 prestandaproblem och även åtgärda några av de vanligaste problemen.

Den här artikeln är faktiskt ett exempel på en åtgärdsplan som du kan använda för att samla in värdefulla data om ditt prestandaproblem när det händer. Några av de viktigaste problemen ingår också i den här artikeln.

Om du är nybörjare på nätverksprestanda och vill skapa en långsiktig plan för att övervaka prestanda mellan klientdatorerna och Office 365 kan du ta en titt på Office 365 prestandajustering och felsökning – Admin och IT Pro.

Exempel på åtgärdsplan för prestandafelsökning

Den här åtgärdsplanen innehåller två delar. en förberedelsefas och en loggningsfas. Om du har prestandaproblem just nu och behöver utföra datainsamling kan du börja använda den här planen direkt.

Förbereda klientdatorn

• Hitta en klientdator som kan återskapa prestandaproblemet. Den här datorn kommer att användas under felsökningen.
• Skriv ned de steg som orsakar prestandaproblemet så att du är redo när det är dags att testa.
• Installera verktyg för att samla in och registrera information:
  • Installera Netmon 3.4 (eller använd ett motsvarande verktyg för nätverksspårning).
  • Installera den kostnadsfria Basic Edition av HTTPWatch (eller använd ett motsvarande verktyg för nätverksspårning).
  • Använd en skärmspelare eller kör den stegpost (PSR.exe) som medföljer Windows Vista och senare för att registrera de steg du utför under testningen.

Logga prestandaproblemet

• Stäng alla överflödiga webbläsare.

• Starta Steps Recorder eller en annan skärmspelare.

• Starta netmon-avbildningen (eller nätverksspårningsverktyget).

• Rensa DNS-cachen på klientdatorn från kommandoraden genom att skriva ipconfig /flushdns.

• Starta en ny webbläsarsession och aktivera HTTPWatch.

• Valfritt: Om du testar Exchange Online kör du verktyget Exchange Client Prestandaanalys från Office 365-administratörskonsolen.

• Återskapa de exakta steg som orsakar prestandaproblemet.

• Stoppa spårningen av netmon eller något annat verktyg.

• På kommandoraden kör du en spårningsväg till din Office 365-prenumeration genom att skriva följande kommando och sedan trycka på RETUR:

  tracert <subscriptionname>.onmicrosoft.com
  

• Stoppa Steps Recorder och spara videon. Se till att inkludera datum och tid för avbildningen och om den visar bra eller dåliga prestanda.

• Spara spårningsfilerna. Se återigen till att inkludera datum och tid för avbildningen och om den visar bra eller dåliga prestanda.

Om du inte är bekant med att köra verktygen som nämns i den här artikeln ska du inte oroa dig eftersom vi tillhandahåller dessa steg härnäst. Om du är van vid att göra den här typen av nätverksinsamling kan du gå vidare till Så här samlar du in baslinjer, som beskriver filtrering och läsning av loggarna.

Töm DNS-cachen först

Varför? Genom att tömma DNS-cachen startar du testerna med en ren skiffer. Genom att rensa cacheminnet återställer du INNEHÅLLET i DNS-matcharen till de senaste posterna. Kom ihåg att en tömning inte tar bort HOST-filposter. Om du använder HOST-filposter i stor utsträckning bör du kopiera dessa poster till en fil i en annan katalog och sedan tömma HOST-filen.

Rensa DNS-matchningscachen

1. Öppna kommandotolken (antingen Start>Run>cmd eller Windows key>cmd).

2. Skriv följande kommando och tryck på RETUR:

   ipconfig /flushdns
   

Netmon

Microsofts verktyg för nätverksövervakning (Netmon) analyserar paket (nätverkstrafik) som passerar mellan datorer i nätverk. Genom att använda Netmon för att spåra trafik med Office 365 kan du samla in, visa och läsa pakethuvuden, identifiera mellanliggande enheter, kontrollera viktiga inställningar på nätverksmaskinvara, leta efter borttagna paket och följa trafikflödet mellan datorer i företagets nätverk och Office 365. Eftersom den faktiska brödtexten i trafiken krypteras, dvs. den färdas på port 443 via SSL/TLS, kan du inte läsa filerna som skickas. I stället får du en ofiltrerad spårning av den sökväg som paketet tar, vilket kan hjälpa dig att spåra problembeteendet.

Se till att du inte använder ett filter just nu. Kör i stället igenom stegen och demonstrera problemet innan du stoppar spårningen och sparar.

När du har installerat Netmon 3.4 öppnar du verktyget och utför följande steg:

Ta en Netmon-spårning och återskapa problemet

1. Starta Netmon 3.4. Det finns tre fönster på startsidan: Senaste avbildningar, Välj nätverk och Komma igång med Microsoft Network Monitor 3.4. Lägg märke till det. Panelen Välj nätverk ger dig också en lista över de standardnätverk som du kan samla in från. Se till att nätverkskorten är markerade här.

2. Klicka på Ny avbildning överst på startsidan . Detta lägger till en ny flik bredvid fliken Startsida med namnet Avbildning 1.

3. Om du vill göra en enkel avbildning klickar du på Starta i verktygsfältet.

4. Återskapa de steg som presenterar ett prestandaproblem.

5. Klicka på Stoppa>spara fil>som. Kom ihåg att ange datum och tid med tidszonen och att nämna om det visar dåliga eller bra prestanda.

HTTPWatch

HTTPWatch debiteras och en kostnadsfri utgåva. Den kostnadsfria Basic Edition omfattar allt du behöver för det här testet. HTTPWatch övervakar nätverkstrafik och sidinläsningstid direkt från webbläsarfönstret. HTTPWatch är ett plugin-program till Microsoft Edge som grafiskt beskriver prestanda. Analysen kan sparas och visas i HTTPWatch Studio.

Obs!

Om du använder en annan webbläsare, till exempel Firefox, Google Chrome eller om du inte kan installera HTTPWatch i Edge, öppnar du ett nytt webbläsarfönster och trycker på F12 på tangentbordet. Du bör se popup-fönstret Utvecklarverktyg längst ned i webbläsaren. Om du använder Opera trycker du på CTRL+SKIFT+I för Web Inspector och klickar sedan på fliken Nätverk och slutför testningen som beskrivs nedan. Informationen skiljer sig något, men inläsningstiderna visas fortfarande i millisekunder. > HTTPWatch är också mycket användbart för problem med inläsningstider för SharePoint-sidor.

Kör HTTPWatch och återskapa problemet

HTTPWatch är ett plugin-program för webbläsare, så att exponera verktyget i webbläsaren skiljer sig något åt för varje version av Microsoft Edge. Vanligtvis hittar du HTTPWatch under kommandofältet i Microsoft Edge-webbläsaren. Om du inte ser HTTPWatch-plugin-programmet i webbläsarfönstret kontrollerar du versionen av webbläsaren genom att klicka på Hjälp>om eller i senare versioner av Microsoft Edge, klicka på kugghjulssymbolen och Om Edge. Om du vill starta kommandofältet högerklickar du på menyraden i Microsoft Edge och klickar på Kommandofältet.

Tidigare har HTTPWatch associerats med både kommandona och Explorer-staplarna, så när du har installerat, om du inte omedelbart ser ikonen (även efter omstart) markerar du Verktyg och dina verktygsfält för ikonen. Kom ihåg att verktygsfält kan anpassas och att alternativ kan läggas till i dem.

1. Starta HTTPWatch i ett Microsoft Edge-webbläsarfönster. Den visas dockad i webbläsaren längst ned i fönstret. Klicka på Arkivhandling.

2. Återskapa de exakta stegen i prestandaproblemet. Klicka på knappen Stoppa i HTTPWatch.

3. Spara HTTPWatch eller Skicka med Email. Kom ihåg att namnge filen så att den innehåller information om datum och tid och en indikation på om klockan innehåller en demonstration av bra eller dåliga prestanda.

Den här skärmbilden är från Professional-versionen av HTTPWatch. Du kan öppna spårningar som hämtats i den grundläggande versionen på en dator med en Professional-version och läsa den där. Extra information kan vara tillgänglig från spårningen via den metoden.

Inspelare för problemsteg

Med Steps Recorder, eller PSR.exe, kan du registrera problem när de inträffar. Det är ett mycket användbart verktyg och enkelt att köra.

Kör inspelaren för problemsteg (PSR.exe) för att registrera ditt arbete

1. Använd antingen startkörningstypen>>PSR.exe>OK eller klicka på Windows-nyckeltypen>PSR.exe> och tryck sedan på RETUR.

2. När det lilla PSR.exe fönstret visas klickar du på Starta post och återskapar de steg som återskapar prestandaproblemet. Du kan lägga till kommentarer efter behov genom att klicka på Lägg till kommentarer.

3. Klicka på Stoppa post när du har slutfört stegen. Om prestandaproblemet är en sidåtergivning väntar du tills sidan återges innan du stoppar inspelningen.

4. Klicka på Spara.

Datum och tid registreras åt dig. Detta länkar din PSR till din Netmon-spårning och HTTPWatch i tid och hjälper till med precisionsfelsökning. Datum och tid i PSR-posten kan till exempel visa att en minut har passerat mellan inloggningen och surfningen av URL:en och den partiella återgivningen av administratörswebbplatsen.

Läsa dina spårningar

Det går inte att lära ut allt om felsökning av nätverk och prestanda som någon skulle behöva veta via en artikel. För att få bra prestanda krävs erfarenhet och kunskap om hur nätverket fungerar och presterar vanligtvis. Men det är möjligt att samla ihop en lista över de vanligaste problemen och visa hur verktyg kan göra det enklare för dig att eliminera de vanligaste problemen.

Om du vill lära dig mer om att läsa nätverksspårningar för dina Office 365 webbplatser finns det ingen bättre lärare än att skapa spårningar av sidinläsningar regelbundet och få erfarenhet av att läsa dem. När du till exempel har en chans läser du in en Office 365-tjänst och spårar processen. Filtrera spårningen för DNS-trafik eller sök i FrameData efter namnet på den tjänst som du bläddrade i. Genomsök spårningen för att få en uppfattning om de steg som utförs när tjänsten läses in. Detta hjälper dig att lära dig hur normal sidinläsning ska se ut, och vid felsökning, särskilt kring prestanda, kan jämförelse av bra och dåliga spårningar lära dig mycket.

Netmon använder Microsoft Intellisense i fältet Visningsfilter. Intellisense, eller intelligent kodkomplettering, är det tricket där du skriver in en punkt och alla tillgängliga alternativ visas i en listruta. Du är till exempel orolig för TCP-fönsterskalning. Du kan hitta vägen till ett filter (till exempel .protocol.tcp.window < 100) på det här sättet.

Netmon-spårningar kan ha mycket trafik i sig. Om du inte har erfarenhet av att läsa dem är det troligt att du blir överväldigad när du öppnar spårningen första gången. Det första du ska göra är att separera signalen från bakgrundsbruset i spårningen. Du har testat mot Office 365 och det är den trafik du vill se. Om du är van vid att navigera genom spårningar kanske du inte behöver den här listan.

Trafik mellan klienten och Office 365 färdas via TLS, vilket innebär att trafikens brödtext krypteras och inte kan läsas i en allmän Netmon-spårning. Din prestandaanalys behöver inte känna till informationen i paketet. Den är dock mycket intresserad av pakethuvuden och den information som de innehåller.

Tips för att få en bra spårning

• Känna till värdet för IPv4- eller IPv6-adressen för klientdatorn. Du kan hämta detta från kommandotolken genom att skriva IPConfig och sedan trycka på RETUR. Genom att känna till den här adressen kan du snabbt se om trafiken i spårningen direkt involverar klientdatorn. Om det finns en känd proxyserver pingar du den och hämtar även dess IP-adress.

• Töm DNS-matcharens cacheminne och stäng om möjligt alla webbläsare utom den där du kör dina tester. Om du inte kan göra detta, till exempel om supporten använder något webbläsarbaserat verktyg för att se klientdatorns skrivbord, bör du vara beredd att filtrera spårningen.

• Leta upp den Office 365 tjänst som du använder i en upptagen spårning. Om du aldrig eller sällan har sett trafiken förut är det här ett användbart steg för att skilja prestandaproblemet från annat nätverksbrus. Det finns några sätt att göra detta på. Direkt före testet kan du använda ping eller PsPing mot URL:en för den specifika tjänsten (ping outlook.office365.com eller psping -4 microsoft-my.sharepoint.com:443, till exempel). Du kan också enkelt hitta ping eller PsPing i en Netmon-spårning (med dess processnamn). Det ger dig en plats att börja leta.

Om du bara använder Netmon-spårning vid tidpunkten för problemet är det också okej. Om du vill orientera dig använder du ett filter som ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"). Du kan registrera ditt bildrutenummer från spårningsfilen. Du kanske också vill rulla fönstret Ramsammanfattning hela vägen till höger och leta efter kolumnen Konversations-ID. Det finns ett tal som anges där för ID:t för den här specifika konversationen som du också kan spela in och titta på isolerat senare. Kom ihåg att ta bort det här filtret innan du tillämpar någon annan filtrering.

Tips

Netmon har många användbara inbyggda filter. Prova knappen Läs in filter överst i fönstret Visningsfilter .

Bekanta dig med trafiken och lär dig att hitta den information du behöver. Du kan till exempel lära dig att avgöra vilket paket i spårningen som har den första referensen till den Office 365 tjänst som du använder (till exempel "Outlook").

Med Office 365 Outlook Online som exempel börjar trafiken ungefär så här:

• DNS Standard Query och DNS-svar för outlook.office365.com med matchande QueryIDs. Det är viktigt att notera tidsförskjutningen för den här vändningen och var i världen Office 365 Global DNS skickar begäran om namnmatchning. Helst, så lokalt som möjligt, snarare än halvvägs över hela världen.

• En HTTP GET-begäran vars statusrapport flyttades permanent (301)

• RWS-trafik inklusive RWS Connect-begäranden och Connect-svar. (Det här är Remote Winsock som upprättar en anslutning åt dig.)

• En TCP SYN- och TCP SYN/ACK-konversation. Många inställningar i den här konversationen påverkar dina prestanda.

• Sedan en serie TLS:TLS-trafik, där TLS-handskaknings- och TLS-certifikatkonversationer äger rum. (Kom ihåg att data krypteras via SSL/TLS.)

Alla delar av trafiken är viktiga och anslutna, men små delar av spårningen innehåller information som är viktig när det gäller prestandafelsökning, så vi fokuserar på dessa områden. Eftersom vi har gjort tillräckligt med Office 365 prestandafelsökning på Microsoft för att kompilera en topp 10-lista över vanliga problem fokuserar vi på dessa problem och hur vi använder de verktyg vi har för att utrota dem härnäst.

Om du inte redan har installerat dem använder matrisen nedan flera verktyg där det är möjligt. Länkar tillhandahålls till installationspunkterna. Listan innehåller vanliga verktyg för nätverksspårning som Netmon och Wireshark, men använd alla spårningsverktyg som du är bekväm med och där du är van vid att filtrera nätverkstrafik. Kom ihåg följande när du testar:

• Stäng dina webbläsare och testa med bara en webbläsare som körs – Detta minskar den totala trafiken som du samlar in. Det ger en mindre upptagen spårning.
• Töm DNS-matcharens cacheminne på klientdatorn – Detta ger dig en ren skiffer när du börjar ta din avbildning för en renare spårning.

Vanliga problem

Några vanliga problem som du kan stöta på och hur du hittar dem i nätverksspårningen.

TCP Windows-skalning

Finns i SYN - SYN/ACK. Äldre eller åldrande maskinvara kanske inte drar nytta av TCP-windowsskalning. Utan rätt inställningar för TCP-windowsskalning fyller standardbufferten på 16 bitar i TCP-huvuden i millisekunder. Trafiken kan inte fortsätta att skickas förrän klienten får en bekräftelse på att ursprungliga data har tagits emot, vilket orsakar fördröjningar.

Verktyg

• Netmon
• Wireshark

Vad du ska leta efter

Leta efter SYN - SYN/ACK-trafiken i nätverksspårningen. I Netmon använder du ett filter som tcp.flags.syn == 1. Det här filtret är detsamma i Wireshark.

Observera att för varje SYN finns det ett källportnummer (SrcPort) som matchas i målporten (DstPort) för den relaterade bekräftelsen (SYN/ACK).

Om du vill se värdet för Windows-skalning som används av nätverksanslutningen expanderar du först SYN och sedan den relaterade SYN/ACK.

Inställningar för TCP-inaktivitetstid

Tidigare har de flesta perimeternätverk konfigurerats för tillfälliga anslutningar, vilket innebär att inaktiva anslutningar vanligtvis avslutas. Inaktiva TCP-sessioner kan avslutas av proxyservrar och brandväggar på mer än 100 till 300 sekunder. Det här är problematiskt för Outlook Online eftersom det skapar och använder långsiktiga anslutningar, oavsett om de är inaktiva eller inte.

När anslutningar avslutas av proxy- eller brandväggsenheter informeras inte klienten, och ett försök att använda Outlook Online innebär att en klientdator upprepade gånger försöker återuppliva anslutningen innan den skapar en ny. Du kan se låsningar i produkten, frågor eller långsamma prestanda vid sidinläsning.

Verktyg

• Netmon
• Wireshark

Vad du ska leta efter

I Netmon tittar du på fältet Tidsförskjutning för en rundtur. En tur och retur-resa är tiden mellan att klienten skickar en begäran till servern och tar emot ett svar tillbaka. Kontrollera mellan klienten och utgående punkt (t.ex. klient –> proxy) eller klienten för att Office 365 (klient -> Office 365). Du kan se detta i många typer av paket.

Till exempel kan filtret 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 inte om IP-adressen i spårningen tillhör DIN DNS-server? Försök att leta upp den på kommandoraden. Klicka på Starta>körning> och skriv cmd eller tryck på Windows-tangenten> och skriv cmd. I prompten skriver du nslookup <the IP address from the network trace>. Testa genom att använda nslookup mot din egen dators IP-adress. >En lista över Microsofts IP-intervall finns i Office 365 URL:er och IP-adressintervall.

Om det uppstår ett problem kan du förvänta dig att långa tidsförskjutningar visas, i det här fallet (Outlook Online), särskilt i TLS:TLS-paket som visar passagen av programdata (i Netmon kan du till exempel hitta programdatapaket via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Du bör se en smidig förlopp i tiden under sessionen. Om du ser långa fördröjningar när du uppdaterar Outlook Online kan det bero på att en hög grad av återställningar skickas.

Svarstid/tur och retur-tid

Svarstid är ett mått som kan ändras mycket beroende på många variabler, till exempel att uppgradera åldrande enheter, lägga till ett stort antal användare i ett nätverk och procentandelen av den totala bandbredden som används av andra uppgifter i en nätverksanslutning.

Det finns bandbreddskalkylatorer för Office 365 tillgängliga från den här sidan för nätverksplanering och prestandajustering för Office 365.

Behöver du mäta anslutningens hastighet eller internetleverantörens bandbredd? Prova den här webbplatsen (eller webbplatser som den): Speedtest Officiell webbplats eller fråga din favoritsökmotor för frashastighetstestet.

Verktyg

• Ping
• PsPing
• Netmon
• Wireshark

Vad du ska leta efter

Om du vill spåra svarstider i en spårning kan du dra nytta av att ha registrerat klientdatorns IP-adress och IP-adressen för DNS-servern i Office 365. Detta är för enklare spårningsfiltrering. Om du ansluter via en proxyserver behöver du din klientdators IP-adress, proxy-/utgående IP-adress och Office 365 DNS-IP-adress för att göra arbetet enklare.

En pingbegäran som skickas till outlook.office365.com talar om för dig namnet på det datacenter som tar emot begäran, även om ping kanske inte kan ansluta för att skicka ICMP-paket i följd för varumärket. Om du använder PsPing (ett kostnadsfritt verktyg för nedladdning) och specifik port (443) och kanske använder IPv4 (-4) får du en genomsnittlig tur-och-retur-tid för paket som skickas. Detta fungerar för andra URL:er i Office 365 tjänster, till exempel psping -4 yourSite.sharepoint.com:443. I själva verket kan du ange ett antal pingar för att få ett större urval för ditt genomsnitt, prova något i stil psping -4 -n 20 yourSite-my.sharepoint.com:443med .

Obs!

PsPing skickar inte ICMP-paket. Det pingar med TCP-paket via en specifik port, så att du kan använda vilken som helst som du vet är öppen. I Office 365, som använder SSL/TLS, provar du att ansluta port :443 till psping-enheten.

Om du har läst in den långsamma Office 365 sidan när du gör en nätverksspårning bör du filtrera en Netmon- eller Wireshark-spårning för DNS. Det här är en av ip-adresserna vi letar efter.

Här följer de steg du behöver vidta för att filtrera netmon för att hämta IP-adressen (och ta en titt på DNS-svarstid). Det här exemplet använder outlook.office365.com, men kan också använda URL:en för en SharePoint-klientorganisation (hithere.sharepoint.com till exempel).

1. Pinga URL:en ping outlook.office365.com och registrera namn och IP-adress för DEN DNS-server som pingbegäran skickades till i resultatet.
2. Nätverksspårning öppnar sidan eller utför åtgärden som ger dig prestandaproblemet, eller, om du ser en hög svarstid på pinget, själv, nätverksspårning.
3. Öppna spårningen i Netmon och filtrera efter DNS (det här filtret fungerar också i Wireshark, men är känsligt för skiftläge -- dns). Eftersom du känner till namnet på DNS-servern från din ping kan du också filtrera snabbare i Netmon så här: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), som ser ut så här i Wireshark dns och ramen innehåller "namnorthwest".
   Öppna svarspaketet och klicka på DNS i fönstret Netmon Frame Details (Netmon-raminformation) för att expandera för mer information. I DNS-informationen hittar du IP-adressen för DNS-servern som begäran gick till i Office 365. Du behöver den här IP-adressen för nästa steg (PsPing-verktyget). Ta bort filtret, högerklicka på DNS-svaret i Netmon (Frame Summary>Find Conversations>DNS) för att se DNS-frågan och svaret sida vid sida.
4. Observera även kolumnen Tidsförskjutning mellan DNS-begäran och svar i Netmon. I nästa steg är det lätt att installera och använda PsPing-verktyget mycket praktiskt, både eftersom ICMP ofta blockeras i brandväggar och eftersom PsPing elegant spårar svarstid i millisekunder. PsPing slutför en TCP-anslutning till en adress och port (i vårt fall öppen port 443).
5. Installera PsPing.
6. Öppna en kommandotolk (cmd för startkörningstypen >> eller cmd för Windows-nyckeltyp > ) och ändra katalogen till den katalog där du installerade PsPing för att köra PsPing-kommandot. I mina exempel kan du se att jag har skapat en "Perf"-mapp i C-roten. Du kan göra samma sak för snabb åtkomst.
7. Skriv kommandot så att du gör din PsPing mot IP-adressen för den Office 365 DNS-servern från din tidigare Netmon-spårning, inklusive portnumret, till exempel psping -n 20 132.245.24.82:445. Detta ger dig en sampling på 20 pingar och genomsnittlig svarstid när PsPing stoppas.

Om du ska Office 365 via en proxyserver är stegen lite annorlunda. Först psping till proxyservern för att få ett genomsnittligt svarstidsvärde i millisekunder till proxy/egress och tillbaka, och kör sedan antingen PsPing på proxyn eller på en dator med en direkt Internetanslutning för att hämta det saknade värdet (den till Office 365 och tillbaka).

Om du väljer att köra PsPing från proxyn har du två millisekunders värden: Klientdator till proxyserver eller utgångspunkt och proxyserver till Office 365. Och du är klar! Spela in värden i alla fall.

Om du kör PsPing på en annan klientdator som har en direktanslutning till Internet, dvs. utan proxy, har du två millisekunders värden: Klientdator till proxyserver eller utgångspunkt och klientdator till Office 365. I det här fallet subtraherar du värdet för klientdatorn till proxyservern eller utgångspunkten från värdet för klientdatorn till Office 365, och du har RTT-numren från klientdatorn till proxyservern eller utgångspunkten, och från proxyservern eller utgångspunkten till Office 365.

Men om du kan hitta en klientdator på den påverkade platsen som är direkt ansluten eller kringgår proxyn, kan du välja att se om problemet återskapas där till att börja med och testa med hjälp av det därefter.

Svarstid, som du ser i en Netmon-spårning, kan dessa extra millisekunder summeras, om det finns tillräckligt många av dem i en viss session.

Obs!

Din IP-adress kan skilja sig från ip-adresserna som visas här, till exempel kan din ping returnera något mer som 157.56.0.0/16 eller ett liknande intervall. En lista över intervall som används av Office 365 finns i Office 365 URL:er och IP-adressintervall.

Kom ihåg att expandera alla noder (det finns en knapp längst upp för detta) om du vill söka efter till exempel 132.245.

Proxyautentisering

Detta gäller endast för dig om du går igenom en proxyserver. Annars kan du hoppa över de här stegen. När den fungerar korrekt bör proxyautentisering ske i millisekunder konsekvent. Du bör inte se tillfälliga dåliga prestanda under perioder med hög användning (till exempel).

Om proxyautentisering är aktiverat måste du gå igenom en autentiseringsprocess i bakgrunden varje gång du skapar en ny TCP-anslutning till Office 365 för att få information. När du till exempel växlar från Kalender till E-post i Outlook Online autentiseras du. Och i SharePoint, om en sida visar media eller data från flera webbplatser eller platser, autentiserar du för varje annan TCP-anslutning som behövs för att återge data.

I Outlook Online kan det uppstå långsamma inläsningstider när du växlar mellan kalender och postlåda, eller långsamma sidinläsningar i SharePoint. Det finns dock andra symtom som inte anges här.

Proxyautentisering är en inställning på din utgående proxyserver. Om det orsakar prestandaproblem med Office 365 måste du kontakta nätverksteamet.

Verktyg

• Netmon
• Wireshark

Vad du ska leta efter

Proxyautentisering sker när en ny TCP-session måste knoppas upp, vanligtvis för att begära filer eller information från servern eller för att ange information. Du kan till exempel se proxyautentisering runt HTTP GET- eller HTTP POST-begäranden. Om du vill se de ramar där du autentiserar begäranden i spårningen lägger du till kolumnen "NTLMSSP Summary" i Netmon och filtrerar efter .property.NTLMSSPSummary. Om du vill se hur lång tid autentiseringen tar lägger du till kolumnen Time Delta.

Så här lägger du till en kolumn i Netmon:

1. Högerklicka på en kolumn, till exempel Beskrivning.
2. Klicka på Välj kolumner.
3. Leta upp NTLMSSP-sammanfattning och tidsdeltering i listan och klicka på Lägg till.
4. Flytta de nya kolumnerna på plats före eller bakom kolumnen Beskrivning så att du kan läsa dem sida vid sida.
5. Klicka på OK.

Även om du inte lägger till kolumnen fungerar Netmon-filtret. Men felsökningen blir mycket enklare om du kan se vilket stadium av autentisering du befinner dig i.

När du letar efter instanser av proxyautentisering bör du studera alla ramar där det finns en NTLM-utmaning eller ett autentisera meddelande. Om det behövs högerklickar du på den specifika delen av trafiken och TCP:t Hitta konversationer > . Tänk på värdena för Tidsdelta i dessa konversationer.

En fördröjning på fyra sekunder i proxyautentisering som visas i Wireshark. Kolumnen Time delta from previous displayed frame (Tidsdelta från föregående bildruta ) gjordes genom att högerklicka på fältet med samma namn i raminformationen och välja Lägg till som kolumn.

DNS-prestanda

Namnmatchningen fungerar bäst och snabbast när den sker så nära klientens land/region som möjligt.

Om DNS-namnmatchning sker utomlands kan det lägga till sekunder till sidinläsningar. I bästa fall sker namnmatchning på under 100 ms. Om inte, bör du göra ytterligare undersökning.

Tips

Vet du inte hur klientanslutning fungerar i Office 365? Ta en titt på dokumentet Referens för klientanslutning här.

Verktyg

• Netmon
• Wireshark
• PsPing

Vad du ska leta efter

Att analysera DNS-prestanda är vanligtvis ett annat jobb för en nätverksspårning. PsPing är dock också till hjälp när det gäller att avgöra en möjlig orsak.

DNS-trafik baseras på TCP- och UDP-begäranden och svaren är tydligt markerade med ett ID som hjälper till att matcha en specifik begäran med dess specifika svar. Du ser DNS-trafik när till exempel SharePoint använder ett nätverksnamn eller en URL på en webbsida. Som tumregel körs merparten av den här trafiken, förutom vid överföring av zoner, över UDP.

I både Netmon och Wireshark är det mest grundläggande filtret som låter dig titta på DNS-trafik helt enkelt dns. Se till att använda gemener när du anger filtret. Kom ihåg att tömma DNS-matcharens cacheminne innan du börjar återskapa problemet på klientdatorn. Om du till exempel har en långsam SharePoint-sidinläsning för startsidan bör du stänga alla webbläsare, öppna en ny webbläsare, börja spåra, tömma DNS-matcharens cacheminne och bläddra till SharePoint-webbplatsen. När hela sidan har lösts bör du stoppa och spara spårningen.

Du vill titta på tidsförskjutningen här. Och det kan vara bra att lägga till kolumnen Time Delta i Netmon, vilket du kan göra genom att utföra följande steg:

1. Högerklicka på en kolumn, till exempel Beskrivning.
2. Klicka på Välj kolumner.
3. Leta upp Tidsdelta i listan och klicka på Lägg till.
4. Flytta den nya kolumnen på plats före eller bakom kolumnen Beskrivning så att du kan läsa dem sida vid sida.
5. Klicka på OK.

Om du hittar en fråga av intresse kan du överväga att isolera den genom att högerklicka på frågan i panelen med raminformation och välja Hitta konversations-DNS>. Observera att panelen Nätverkskonversationer hoppar direkt till den specifika konversationen i loggen för UDP-trafik.

I Wireshark kan du skapa en kolumn för DNS-tid. Ta din spårning (eller öppna en spårning) i Wireshark och filtrera efter dns, eller, mer användbart, dns.time. Klicka på en DNS-fråga och expandera Domain Name System (response) informationen i panelen som visar information. Du ser ett fält för tid (till exempel [Time: 0.001111100 seconds]. Högerklicka den här gången och välj Använd som kolumn. Då får du en tidskolumn för snabbare sortering av spårningen. Klicka på den nya kolumnen för att sortera efter fallande värden för att se vilket DNS-anrop som tog längst tid att matcha.

En blickning av SharePoint som filtrerats i Wireshark efter (gemener) dns.time, med tiden från informationen i en kolumn och sorterad stigande.

Om du vill göra mer undersökning av DNS-matchningstiden kan du prova en PsPing mot DNS-porten som används av TCP (till exempel psping <IP address of DNS server>:53). Ser du fortfarande ett prestandaproblem? Om du gör det är problemet mer sannolikt ett bredare nätverksproblem än ett problem med specifika DNS-program som du stöter på för att lösa problemet. Det är också värt att nämna, återigen, att en ping till outlook.office365.com kommer att berätta var DNS-namnmatchning för Outlook Online äger rum (till exempel outlook-namnorthwest.office365.com).

Om problemet verkar vara DNS-specifikt kan det vara nödvändigt att kontakta IT-avdelningen för att titta på DNS-konfigurationer och DNS-vidarebefordrare för att undersöka problemet ytterligare.

Skalbarhet för proxy

Tjänster som Outlook Online i Office 365 bevilja klienter flera långsiktiga anslutningar. Därför kan varje användare använda fler anslutningar som kräver en längre livslängd.

Verktyg

Matematik

Vad du ska leta efter

Det finns inget specifikt verktyg för nätverksspårning eller felsökning. I stället baseras den på bandbreddsberäkningar med tanke på begränsningar och andra variabler.

Maximal segmentstorlek för TCP

Finns i SYN - SYN/ACK. Gör den här kontrollen i alla prestandanätverksspårningar som du har tagit för att se till att TCP-paket är konfigurerade för att bära den maximala mängden data som möjligt.

Målet är att se en MSS på 1 460 byte för överföring av data. Om du är bakom en proxyserver, eller om du använder en NAT, kom ihåg att köra det här testet från klient till proxy/utgående/NAT och från proxy/utgående/NAT till Office 365 för bästa resultat! Det här är olika TCP-sessioner.

Verktyg

Netmon

Vad du ska leta efter

TCP Max Segment Size (MSS) är en annan parameter för trevägshandskakningen i nätverksspårningen, vilket innebär att du hittar de data du behöver i SYN - SYN/ACK-paketet. MSS är ganska enkelt att se.

Öppna alla prestandanätverksspårningar som du har och hitta den anslutning som du är nyfiken på, eller som visar prestandaproblemet.

Obs!

Om du tittar på en spårning och behöver hitta trafiken som är relevant för konversationen filtrerar du efter klientens IP-adress eller IP-adressen för proxyservern eller utgångspunkten, eller båda. Direkt måste du pinga url:en som du testar för IP-adressen för Office 365 i spårningen och filtrera efter den.

Tittar du på spårningen i andra hand? Försök att använda filter för att orientera dig. I Netmon kör du en sökning baserat på URL:en, till exempel Containsbin(framedata, ascii, "sphybridExample"), och noterar bildrutenumret.

I Wireshark använder du något som liknar frame contains "sphybridExample". Om du märker att du har hittat RWS-trafik (Remote Winsock) (det kan visas som en [PSH, ACK] i Wireshark) bör du komma ihåg att RWS-anslutningar kan ses strax före relevanta SYN - SYN-/ACL:er, som vi diskuterade tidigare.

Nu kan du registrera bildrutenumret, släppa filtret och klicka på All trafik i fönstret Nätverkskonversationer i Netmon för att titta på närmaste SYN.

Om du inte fick någon IP-adressinformation vid tidpunkten för spårningen får du IP-adresser att filtrera efter genom att hitta din URL i spårningen (till exempel en del av sphybridExample-my.sharepoint.com.

Leta upp anslutningen i spårningen som du är intresserad av att se. Du kan göra detta genom att antingen genomsöka spårningen, filtrera efter IP-adresser eller genom att välja specifika konversations-ID:n med hjälp av fönstret Nätverkskonversationer i Netmon. När du har hittat SYN-paketet expanderar du TCP (i Netmon) eller Transmission Control Protocol (i Wireshark) på panelen Raminformation. Expandera TCP-alternativ och MaxSegmentSize. Leta upp den relaterade SYN-ACK-ramen och Expandera TCP-alternativ och MaxSegmentSize. Det mindre av de två värdena är din maximala segmentstorlek. I den här bilden använder jag den inbyggda kolumnen i Netmon med namnet TCP Troubleshoot.

Den inbyggda kolumnen finns överst på panelen Raminformation . (Om du vill växla tillbaka till din normala vy klickar du på Kolumner igen och väljer sedan Tidszon.)

Här är en filtrerad spårning i Wireshark. Det finns ett filter som är specifikt för MSS-värdet (tcp.options.mss). Ramarna i en SYN, SYN/ACK, ACK-handskakning är länkade längst ned i Wireshark som motsvarar Raminformation (så bildruta 47 ACK, länkar till 46 SYN/ACK, länkar till 43 SYN) för att göra den här typen av arbete enklare.

Om du behöver kontrollera selektiv bekräftelse (nästa avsnitt i den här matrisen) ska du inte stänga spårningen!

Selektiv bekräftelse

Finns i SYN - SYN/ACK. Måste rapporteras som tillåten i både SYN och SYN/ACK. Selektiv bekräftelse (SACK) möjliggör smidigare överföring av data när ett paket eller paket försvinner. Enheter kan inaktivera den här funktionen, vilket kan leda till prestandaproblem.

Om du är bakom en proxyserver, eller om du använder en NAT, kom ihåg att köra det här testet från klient till proxy/utgående/NAT och från proxy/utgående/NAT till Office 365 för bästa resultat! Det här är olika TCP-sessioner.

Verktyg

Netmon

Vad du ska leta efter

Selektiv bekräftelse (SACK) är en annan parameter i SYN-SYN/ACK-handskakningen. Du kan filtrera spårningen för SYN – SYN/ACK på många olika sätt.

Leta upp anslutningen i spårningen som du är intresserad av att se antingen genom att skanna spårningen, filtrera efter IP-adresser eller genom att klicka på ett konversations-ID med hjälp av fönstret Nätverkskonversationer i Netmon. När du har hittat SYN-paketet expanderar du TCP i Netmon eller Transmission Control Protocol i Wireshark i avsnittet Raminformation. Expandera TCP-alternativ och sedan SACK. Leta upp den relaterade SYN-ACK-ramen och Expandera TCP-alternativ och dess SACK-fält. Se till att SACK tillåts i både SYN och SYN/ACK. Här är SACK-värden som visas i både Netmon och Wireshark.

DNS-geoplats

Var i världen Office 365 försöker lösa dns-anropet påverkar anslutningshastigheten.

När den första DNS-sökningen har slutförts i Outlook Online används platsen för DNS för att ansluta till närmaste datacenter. Du kommer att anslutas till en Outlook Online CAS-server, som använder stamnätverket för att ansluta till det datacenter (dC) där dina data lagras. Det här går snabbare.

Vid åtkomst till SharePoint dirigeras en användare som reser utomlands till sitt aktiva datacenter – det är den dC vars plats baseras på deras SPO-klientorganisations hembas (så en dC i USA om användaren är USA-baserad).

Lync online har aktiva noder i mer än en dC i taget. När begäranden skickas för Lync-onlineinstanser avgör Microsofts DNS var i världen begäran kom ifrån och returnerar IP-adresser från närmaste regionala dC där Lync online är aktivt.

Tips

Behöver du veta mer om hur klienter ansluter till Office 365? Ta en titt på referensartikeln för Klientanslutning (och dess användbara grafik).

Verktyg

• Ping
• PsPing

Vad du ska leta efter

Begäranden om namnmatchning från klientens DNS-servrar till Microsofts DNS-servrar bör i de flesta fall resultera i att Microsoft DNS returnerar IP-adressen för ett regionalt datacenter (dC). Vad betyder det här för dig? Om huvudkontoret finns i Bengaluru, Indien, men du reser i USA bör Microsofts DNS-servrar ge dig IP-adresser till datacenter i USA – ett regionalt datacenter när webbläsaren skickar en begäran om Outlook Online. Om e-post behövs från Outlook överförs dessa data via Microsofts snabba stamnätverk mellan datacentren.

DNS fungerar snabbast när namnmatchningen görs så nära användarens plats som möjligt. Om du är i Europa vill du gå till en Microsoft DNS i Europa och (helst) hantera ett datacenter i Europa. Prestanda från en klient i Europa som går till DNS och ett datacenter i Amerika blir långsammare.

Kör pingverktyget mot outlook.office365.com för att avgöra var i världen din DNS-begäran dirigeras. Om du befinner dig i Europa bör du se ett svar från något som liknar outlook-emeawest.office365.com. I Amerika, förvänta dig något i stil med outlook-namnorthwest.office365.com.

Öppna kommandotolken på klientdatorn (via cmd startkörning >> eller Windows-nyckeltyp > ). Skriv ping outlook.office365.com och tryck på RETUR. Kom ihåg att ange -4 om du vill ange ping via IPv4. Du kanske inte kan få ett svar från ICMP-paketen, men du bör se namnet på DEN DNS som begäran dirigerades till. Om du vill se svarstidsnumren för den här anslutningen kan du prova PsPing till IP-adressen för den server som returneras med ping.

felsökning av Office 365-program

Verktyg

• Netmon
• HTTPWatch
• F12-konsolen i webbläsaren

Vi tar inte upp verktyg som används i programspecifik felsökning i den här nätverksspecifika artikeln. Men du hittar resurser som du kan använda på den här sidan.

Relaterade artiklar

Hantera Office 365-slutpunkter

Office 365-slutpunkter – vanliga frågor och svar