Office
Aanmelden

Office 365-prestatieafstemming gebruikt basislijnen en prestatiegeschiedenis

Er zijn enkele eenvoudige manieren om de prestaties van de verbinding tussen Office 365 en uw bedrijf te controleren, waarmee u een algemene indruk krijgt van uw connectiviteit. Kennis over de geschiedenis van de prestaties van de verbindingen van de clientcomputer kan u helpen nieuwe problemen vroeg op te sporen, te identificeren en te voorspellen.

Als u niet gewend bent om prestatieproblemen op te lossen, kunt u hierbij de veelgestelde vragen in dit artikel raadplegen. Bijvoorbeeld: hoe weet u dat het probleem dat u ziet een prestatieprobleem is en niet een Office 365-service-incident? Hoe kan ik ervoor zorgen dat mijn prestaties op de lange termijn goed blijven? Hoe kan ik de prestaties in de gaten houden? Als uw team of uw klanten vertragingen ondervinden bij het gebruik van Office 365 en u meer wilt weten over een van deze vragen, lees dan verder.

Belangrijk: Hebt u momenteel last van een prestatieprobleem tussen de client en Office 365? Volg de stappen in Prestatieproblemen oplossen met Office 365: planning.

Wat u moet weten over de prestaties van Office 365

Office 365 bevindt zich in een speciaal Microsoft-netwerk van hoge capaciteit dat continu wordt gemonitord. Niet alleen automatisch, maar ook door personen. Het afstemmen van de prestaties en het verbeteren van de efficiëntie waar dit mogelijk is, maakt deel uit van het onderhouden van de Office 365-cloud. Sinds klanten van de Office 365-cloud verbinding moeten maken via internet, wordt er voortdurend getracht de prestaties van de Office 365-services precies af te stemmen. Prestatieverbeteringen houden niet op bij de cloud en er is inmiddels een grote hoeveelheid kennis beschikbaar om de cloud gezond en snel te houden. Mocht u last krijgen van een prestatieprobleem in verband met uw verbinding met Office 365, dan kunt u dit maar beter niet proberen op te lossen via de ondersteuning. In plaats daarvan gaat u het probleem van 'binnenuit' onderzoeken. Dat wil zeggen, begin binnenin het netwerk, en volg het spoor naar buiten, naar Office 365. Voordat u een probleemgeval met de Office 365-ondersteuning opent, kunt u gegevens verzamelen en acties ondernemen die het probleem verkennen en mogelijk oplossingen biedt.

Belangrijk: Houd rekening met capaciteitsplanning en -limieten in Office 365. Dankzij deze informatie loopt u voorop bij het oplossen van een prestatieprobleem. Hier is een koppeling naar de Servicebeschrijving van Office 365-platform. Dit is een centrale hub van waaruit alle services van Office 365 een koppeling naar hun eigen servicebeschrijvingen hebben. Dat betekent dat, mocht u bijvoorbeeld een overzicht van de standaardlimieten voor SharePoint Online nodig hebben, dan klikt u op Servicebeschrijving van SharePoint Online en zoekt u naar de sectie met SharePoint Online Limits(limieten voor SharePoint Online).

U moet zich ervan bewust zijn dat prestatie een glijdende schaal is en dat u bij het oplossen van het probleem geen ideale waarde kunt nastreven en deze kunt vasthouden. Als u dat denkt dan kunnen taken die hoge bandbreedte vereisen, zoals een groot aantal actieve gebruikers ineens of het uitvoeren van grootschalige datamigraties, veel stress opleveren. U kunt in die gevallen beter rekening houden met prestatieafnames. U kunt (en moet) weliswaar enigszins een idee hebben welke prestaties u verlangt, maar er spelen hierbij een hoop variabelen een rol die van invloed zijn op de prestaties. Dat is de aard van prestaties.

Het oplossen van prestatieproblemen gaat niet over het voldoen aan bepaalde doelstellingen en het eindeloos handhaven van de streefcijfers, het gaat om het verbeteren van de bestaande activiteiten, gegeven de aanwezige variabelen.

Hoe ziet een prestatieprobleem eruit?

Eerst moet u er zeker van zijn dat uw probleem inderdaad een prestatieprobleem is en geen service-incident. Een prestatieprobleem verschilt van een service-incident in Office 365. U houdt ze als volgt uit elkaar:

Als de Office 365-service problemen ondervindt, is er sprake van een service-incident. U ziet rode of gele pictogrammen onder Huidige status in het Office 365-beheercentrum. Mogelijk hebt u ook last van vertragingen op clientcomputers die verbinding maken met Office 365. Als Huidige status een rood pictogram meldt en er naast Exchange Wordt onderzocht wordt weergegeven, krijgt u mogelijk een grote hoeveelheid oproepen van personen in uw organisatie die klagen dat de clientpostvakken die gebruikmaken van Exchange Online slecht presteren. Het is in dat geval redelijk om te veronderstellen dat de prestatie van uw Exchange Online het slachtoffer is van problemen met de service.

Het Office 365-statusdashboard met alle werkbelasting in het groen, met uitzondering van Exchange, waarin Service hersteld wordt getoond.

Op dit punt aangekomen moet u, de Office 365-beheerder, regelmatig Huidige status en vervolgens Details en geschiedenis weergeven controleren om op de hoogte te blijven van het onderhoud dat we op het systeem uitvoeren. Het dashboard Huidige status is gemaakt om u te informeren over wijzigingen aan en problemen met de service. Aan de hand van de notities en de uitleg die in de statushistorie door de beheerders voor de beheerders wordt geschreven, kunt u de gevolgen inschatten. Zo wordt u op de hoogte gehouden van werk in uitvoering.

Een afbeelding van het Office 365-statusdashboard waarin wordt uitgelegd dat de Exchange Online-service is hersteld, met de reden waarom.

Een prestatieprobleem is geen service-incident, hoewel incidenten tot vertragingen kunnen leiden. Een prestatieprobleem ziet er als volgt uit:

  • Een prestatieprobleem treedt op ongeacht wat Huidige status van het Office 365-beheercentrum over de service heeft te melden.

  • Bewerkingen die eerder relatief naadloos leken te verlopen, duren nu erg lang en worden niet of erg laat voltooid.

  • U kunt het probleem zelfs repliceren; dat wil zeggen dat u weet dat het gaat optreden als u de juiste stappen uitvoert.

  • Als het probleem zich onregelmatig voordoet, is er toch nog een patroon. U weet bijvoorbeeld dat u tegen 10 uur telefoontjes krijgt van gebruikers die niet of nauwelijks toegang kunnen krijgen tot Office 365 en dat het aantal telefoontjes rond het middaguur afneemt.

Dit klinkt waarschijnlijk bekend, mogelijk al te bekend. Zodra u weet dat u te maken hebt met een prestatieprobleem, rijst de vraag: "Wat moet ik nu doen?". In de rest van dit artikel kunt u dat precies te weten komen.

Hoe definieert en test u een prestatieprobleem?

Prestatieproblemen doen zich vaak pas na enige tijd voor, zodat het lastig kan zijn om het feitelijke probleem te definiëren. U moet een goede beschrijving van het probleem maken, een goed idee hebben van de gang van zaken rond het probleem en herhaalbare teststappen opstellen om tot een goed eindresultaat te komen. Anders raakt u het spoor bijster, zonder dat u er wat aan kon doen. Waarom? Hier volgen enkele voorbeelden van probleembeschrijvingen die niet voldoende informatie bieden:

  • Ik kon in no-time overschakelen van mijn Postvak IN naar mijn agenda en nu kan ik beter koffie gaan drinken. Kunt u ervoor zorgen dat het weer werkt zoals eerst?

  • Het uploaden van mijn bestanden naar SharePoint Online duurt eeuwen. Waarom is het ‘s middags langzaam, terwijl het op andere momenten snel is? Kan het niet altijd snel gaan?

De hierboven genoemde probleembeschrijvingen bevatten enkele flinke uitdagingen. Er komen met name een aantal dubbelzinnigheden voor. Bijvoorbeeld:

  • Het is niet duidelijk hoe het schakelen tussen het Postvak IN en de agenda voorheen op de laptop verliep.

  • Als de gebruiker zegt: "Kan het niet altijd snel gaan?”, wat is dan ‘snel’?

  • Hoe lang is 'eeuwen'? Gaat het om enkele seconden, of minuten, of kan de gebruiker gaan lunchen en is het pas tien minuten nadat hij terugkomt klaar?

En dan hebben we het nog niet eens over het feit dat de beheerder en de probleemoplosser niet op de hoogte kunnen zijn van de vele details die juist niet in dergelijke probleembeschrijvingen staan. Bijvoorbeeld wanneer het probleem voor het eerst optrad, dat de gebruiker thuis werkt en slechts zelden last heeft van traag overschakelen op een thuisnetwerk, dat de gebruiker enkele andere RAM-gevoelige toepassingen op de lokale client moet uitvoeren of dat de gebruiker een oud besturingssysteem heeft of de laatste tijd geen updates heeft uitgevoerd.

Als gebruikers een prestatieprobleem melden, moet er heel veel informatie worden verzameld. Het verzamelen van deze informatie maakt deel uit van een proces dat Scoping wordt genoemd. Dit houdt in dat het probleem wordt onderzocht. Hieronder vindt u een eenvoudige scopinglijst die u kunt gebruiken voor het verzamelen van informatie over het prestatieprobleem. Deze lijst is niet volledig, maar vormt het uitgangspunt voor die van uzelf:

  • Op welke datum is het probleem opgetreden en op welk tijdstip (zowel overdag als ‘s nachts)?

  • Welk type clientcomputer gebruikt u en hoe maakt u verbinding met het bedrijfsnetwerk (VPN, bedraad, draadloos)?

  • Werkte u op afstand of was u op kantoor?

  • Hebt u dezelfde acties op een andere computer uitgevoerd en hetzelfde gedrag gezien?

  • Doorloop de stappen die de problemen veroorzaken, zodat u de uitgevoerde handelingen kunt opschrijven.

  • Hoe lang duurt de vertraging (in seconden of minuten)?

  • Waar ter wereld bevindt u zich?

Sommige van deze vragen zijn duidelijker dan andere. Bijna iedereen zal begrijpen dat een probleemoplosser de exacte stappen nodig heeft om het probleem te kunnen reproduceren. Hoe kun je anders registreren wat er aan de hand is? En hoe zou je anders moeten testen of het probleem is verholpen? Minder duidelijk zijn bijvoorbeeld zaken als "Op welke datum en op welk tijdstip deed het probleem zich voor?" en "Waar ter wereld bevindt u zich?" - informatie die gecombineerd gebruikt kan worden. Afhankelijk van wanneer de gebruiker aan het werk was, kunnen enkele uren verschil betekenen dat er al onderhoud wordt uitgevoerd op delen van het bedrijfsnetwerk. Als uw bedrijf bijvoorbeeld een hybride implementatie heeft, zoals een hybride SharePoint Search, die query’s kan uitvoeren op zoekindexen in zowel SharePoint Online als een on-premises SharePoint Server 2013-exemplaar, kunnen er al updates worden uitgevoerd voor de on-premises farm. Als uw bedrijf zich volledig in de cloud bevindt, bestaat het systeemonderhoud wellicht uit het toevoegen of verwijderen van de netwerkhardware, het uitbrengen van updates voor het hele bedrijf of het aanbrengen van wijzigingen in de DNS of andere kerninfrastructuur.

Als u een prestatieprobleem wilt oplossen, doet het enigszins denken aan de plaats van een misdrijf. U moet nauwkeurig en alert zijn om conclusies uit de bewijzen te kunnen trekken. Daarom moet u voor een goede probleembeschrijving zorgen door bewijzen te verzamelen. Hierin moet worden beschreven: de context van de computer, de context van de gebruiker, het tijdstip waarop het probleem begon en de precieze stappen die duiden op een prestatieprobleem. De probleembeschrijving moet de belangrijkste pagina in uw notities zijn en blijven. Als u de probleembeschrijving nogmaals doorloopt nadat u aan het probleem hebt gewerkt, voert u de stappen uit om te testen en te bewijzen of de handelingen die u uitvoert tot de oplossing hebben geleid. Dit is van groot belang om te weten wanneer uw werk, op die plek, af is.

Weet u wat de prestaties waren toen alles nog goed werkte?

Als u pech hebt, weet niemand dat. Niemand had de cijfers. Dit betekent dat niemand de eenvoudige vraag "Hoeveel seconden duurde het voordat een Postvak IN werd weergegeven in Office 365?" kan beantwoorden. En evenmin de vraag "Hoe lang duurde het als de bedrijfsleiding een vergadering had via Lync Online?", een normale gebeurtenis in veel bedrijven.

Wat hier ontbreekt is een basislijn voor prestaties.

Basislijnen kunnen een context voor de prestaties bieden. Afhankelijk van de behoeften van uw bedrijf moet u af en toe of regelmatig een basislijn maken. Als u een groter bedrijf hebt, kan het team voor productie en infrastructuur al bezig zijn met het maken van basislijnen voor uw lokale omgeving. Als u bijvoorbeeld alle Exchange-servers op de eerste maandag van de maand met elkaar verbindt en alle SharePoint-servers op de derde maandag, dan beschikt het team voor productie en infrastructuur waarschijnlijk al over een lijst met taken en scenario’s die na het verbinden worden uitgevoerd om aan te tonen dat kritieke functies operationeel zijn. Bijvoorbeeld het openen van het Postvak IN, klikken op Verzenden/Ontvangen en ervoor zorgen dat de mappen worden bijgewerkt of, in SharePoint, bladeren door de hoofdpagina van de site, naar de zoekpagina van de onderneming gaan en een zoekopdracht uitvoeren die resultaten retourneren.

Als uw toepassingen zich in Office 365 bevinden, behoren enkele van de belangrijkste basislijnen die u kunt maken de metingen van de tijd (in milliseconden) vanaf een clientcomputer in uw netwerk naar een uitgangspunt, het punt waar u uw netwerk verlaat en naar Office 365 gaat. Hier volgen enkele nuttige basislijnen die u kunt onderzoeken en registreren:

  • Identificeer de apparaten tussen de clientcomputer en het uitgangspunt, bijvoorbeeld uw proxyserver.

    • U moet uw apparaten kennen, zodat u een context hebt (IP-adressen, type apparaat, enzovoort) voor de prestatieproblemen die zich voordoen.

    • Proxyservers zijn algemene uitgangspunten, dus kijk in uw browser of en welke proxyserver er is ingesteld.

    • Er bestaan hulpprogramma's van derden waarmee u uw netwerk kunt identificeren en in kaart brengen, maar u kunt dit het beste vragen aan iemand uit uw netwerkteam.

  • Stel vast wie uw internetprovider is, noteer de contactgegevens en vraag hoeveel circuits en hoeveel bandbreedte u hebt.

  • Identificeer binnen uw bedrijf de resources tussen de client en het uitgangspunt, of zoek een contactpersoon voor noodgevallen met wie u over netwerkproblemen kunt praten.

Hier volgen enkele basislijnen die enkele eenvoudige hulpprogramma’s door middel van testen voor u kunnen uitrekenen:

  • Neem de tijd op van uw computer naar uw uitgangspunt (in milliseconden).

  • Neem de tijd op van uw uitgangspunt naar Office 365 (in milliseconden).

  • Bepaal de locatie van de server die de URL's voor Office 365 omzet tijdens het browsen.

  • De snelheid van het omzetten door de DNS bij uw internetprovider (in milliseconden), inconsistenties in pakketontvangst (netwerkstoringen), up- en downloadtijden (in milliseconden).

Mocht u niet weten hoe u deze stappen moet uitvoeren, in dit artikel wordt er dieper op ingegaan.

Wat is een basislijn?

Als er problemen optreden, weet u wat de invloed ervan is, maar als u de historische prestatiegegevens niet kent, dan hebt u geen context voor hoe groot die invloed zou kunnen zijn geworden, of wanneer. Dus zonder basislijn ontbreekt de belangrijkste aanwijzing om de puzzel op te lossen: het plaatje op de doos. Bij het oplossen van prestatieproblemen, moet u een vergelijkingspunt hebben. Eenvoudige prestatiebasislijnen zijn makkelijk om te maken. Het team voor productie en infrastructuur kan worden gevraagd deze taak volgens schema uit te voeren. Stel dat uw verbinding er zo uitziet:

Een graphic van een basisnetwerk met client, proxy en Office 365-cloud.

Dat betekent dat u hebt overlegd met uw netwerkteam en dat er een proxyserver wordt gebruikt voor een verbinding met internet. Deze server behandelt alle verzoeken die de clientcomputer naar de cloud verstuurt. In dit geval moet u een vereenvoudigde versie tekenen van uw verbinding met alle tussenliggende apparaten. Neem vervolgens de hulpprogramma’s in de tekening op die u kunt gebruiken om de prestaties te testen tussen de client, het uitgangspunt (waar het netwerk wordt verlaten voor het internet) en de Office 365-cloud.

Basisnetwerk met client, proxy en cloud, en voorgestelde hulpprogramma’s zoals PSPing, TraceTCP en netwerktraceringen.

De opties worden weergegeven als Eenvoudig en Geavanceerd vanwege de hoeveelheid expertise die u nodig hebt om de prestatiegegevens te vinden. Een netwerktrace kost veel tijd vergeleken met het uitvoeren van opdrachtregelprogramma’s als PsPing en TraceTCP. Deze twee opdrachtregelprogramma’s zijn gekozen omdat ze geen gebruik maken van ICMP-pakketten. Deze worden namelijk door Office 365 geblokkeerd. Het voordeel is dat ze de tijd in milliseconden aangeven voor hoe lang het duurt om de clientcomputer te verlaten, of de proxyserver (als u toegang hebt), en aan te komen bij Office 365. Elke afzonderlijke hop van de ene computer naar de andere krijgt een tijdswaarde mee. Deze zijn erg belangrijk voor basislijnen. Het is minstens zo belangrijk dat u met deze opdrachtregelprogramma’s een poortnummer aan de opdracht kunt toevoegen. Dat is handig omdat Office 365 over poort 443 communiceert, de poort die door SSL (Secure Sockets Layer) en TLS (Transport Layer Security) wordt gebruikt. Het kan echter zijn dat hulpprogramma’s van derden geschikter zijn in uw situatie. Microsoft biedt geen ondersteuning voor al deze hulpprogramma's, dus mochten PsPing en TraceTCP niet werken, dan kunt u verder gaan met een netwerktrace met een hulpprogramma zoals Netmon.

U kunt vóór kantooruren een basislijn nemen, vervolgens tijdens veelvuldig gebruik en er weer na. Dat betekent dat de mappenstructuur er ten slotte uit komt te zien zoals hieronder:

Graphic van een manier om prestatiegegevens in mappen te ordenen.

U moet voor uw bestanden ook een naamconventie kiezen. Hier volgen enkele voorbeelden:

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

Er zijn talloze manieren waarop u dit kunt doen, maar het gebruik van de indeling <dateTime><what's happening in the test> is een goed startpunt. Als u deze werkwijze nauwkeurig volgt, scheelt dat een hoop als u later problemen moet gaan oplossen. Later zult u zeggen: "Ik heb op 8 februari twee traces genomen, een met een goede prestaties en een met een slechte, zodat we ze kunnen vergelijken." Dit is ontzettend handig bij het oplossen van problemen.

Houd een duidelijk overzicht bij van uw historische basislijnen. In dit voorbeeld produceerden de eenvoudige methoden drie maal een opdrachtregeloutput en de resultaten werden verzameld als schermopnamen, maar wellicht beschikt u over netwerkopnamebestanden. Kies de methode die het geschiktst voor u is. Sla uw historische basislijnen op en raadpleeg ze op momenten wanneer u wijzigingen ziet in het gedrag van onlineservices.

Waarom moet ik prestatiegegevens verzamelen tijdens een testfase?

Het beste tijdstip om basislijnen te maken is tijdens een testfase van de Office 365-service. Mogelijk kent uw kantoor duizenden gebruikers, enkele honderdduizenden of misschien slechts vijf, maar zelfs met weinig gebruikers kunt u tests uitvoeren om prestatiefluctuaties te meten. Bij grote bedrijven kan een testfase met een representatieve steekproef van enkele honderden personen die Office 365 gebruiken, worden uitvergroot tot enkele duizenden, zodat u weet waar u aan toe bent vóór er problemen optreden.

In geval van een klein bedrijf, waar de meeste gebruikers meteen actief met de service bezig zullen gaan en er geen testfase is, moet u prestatiemetingen bewaren zodat u gegevens kunt laten zien aan degenen die een slecht verlopende bewerking moeten oplossen. Bijvoorbeeld als u merkt dat u helemaal rond het gebouw kunt lopen in de tijd om een graphic van gemiddelde grootte te uploaden, terwijl dit normaal gesproken erg snel gaat.

Basislijnen verzamelen

Voor alle plannen voor het oplossen van problemen moeten in elk geval de volgende zaken bekend zijn:

  • De clientcomputer die u gebruikt (het type computer of apparaat, een IP-adres en de acties die het probleem hebben veroorzaakt)

  • Waar de clientcomputer zich bevindt in de wereld (bijvoorbeeld of deze gebruiker met een VPN-verbinding op het netwerk, extern, of via het bedrijfsintranet werkt)

  • Het uitgangspunt dat door de clientcomputer wordt gebruikt vanuit uw netwerk (het punt waarop verkeer uw bedrijf verlaat voor een internetprovider of internet)

De lay-out van het netwerk kunt u opvragen bij de netwerkbeheerder. Als u een klein netwerk hebt, kijkt u dan eens naar de apparaten via welke u verbinding met internet hebt. Bel uw provider als u vragen over de lay-out hebt. Maak een overzicht van de uiteindelijke lay-out en bewaar dit.

Deze sectie is opgedeeld in een deel over eenvoudige opdrachtregelprogramma’s en methoden, en een deel over meer geavanceerde opties. We bespreken eerst de eenvoudige methoden. Maar als u nu al een prestatieprobleem hebt, moet u het deel met de geavanceerde methoden raadplegen en het proefactieplan voor het oplossen van prestatieproblemen uitproberen.

Eenvoudige methoden

Het doel van deze eenvoudige methoden is om in de loop van de tijd eenvoudige prestatiebasislijnen te leren maken, begrijpen en op de juiste wijze bewaren. Op die manier raakt u vertrouwd met de prestaties van Office 365. Hier is een heel eenvoudig diagram voor eenvoudige methoden, zoals u al eerder hebt gezien:

Basisnetwerk met client, proxy en cloud, en voorgestelde hulpprogramma’s zoals PSPing, TraceTCP en netwerktraceringen.

Notities: 

  • TraceTCP is opgenomen in deze schermafbeelding omdat het een handig hulpprogramma is voor het weergeven, in milliseconden, van hoe lang het duurt voor een verzoek wordt verwerkt en hoeveel netwerkhops (verbindingen van de ene computer naar de volgende) het kost om een doel te bereiken. TraceTCP kan ook de namen van de servers geven die tijdens de hops worden gebruikt. Dat kan handig zijn voor iemand die problemen oplost met Office 365.

  • TraceTCP-opdrachten kunnen heel eenvoudig zijn, bijvoorbeeld:

  • tracetcp.exe outlook.office365.com:443

  • Vergeet niet het poortnummer in de opdracht op te nemen.

  • TraceTCP kan gratis worden gedownload, maar is gebaseerd op Wincap. Wincap is een hulpprogramma dat ook door Netmon wordt gebruikt en geïnstalleerd. Netmon wordt ook gebruikt in de sectie over geavanceerde methoden.

Als u meerdere kantoren hebt, moet u ook gegevens bewaren van een client in elk van deze locaties. Met deze test wordt de latentie gemeten, wat in dit geval een getal is waarmee wordt aangegeven hoe lang het duurt voor een aanvraag door een client naar Office 365 wordt gestuurd en voor Office 365 erop reageert. Het testen begint in een van uw clientcomputers. Er vindt een meting plaats van een roundtrip vanaf uw netwerk, via een uitgangspunt en internet naar Office 365 en terug.

U kunt het uitgangspunt, in dit geval de proxyserver, op verschillende manieren behandelen. U kunt een trace nemen van 1 tot 2 en vervolgens van 2 tot 3, waarna u de tijd (in milliseconden) toevoegt om een totaal te krijgen van de tijdsduur tot aan de grens van uw netwerk. U kunt ook de verbinding configureren om de proxy voor Office 365-adressen te omzeilen. In een groter netwerk met een firewall, reverse-proxy of een combinatie van beide, moet u mogelijk een uitzondering maken voor de proxyserver waardoor verkeer kan passeren voor een groot aantal URL's. Zie Office 365-URL's en IP-adresbereiken voor een overzicht van de eindpunten die door Office 365 worden gebruikt. Als u een verificatieproxy hebt, begint u met het testen van uitzonderingen voor de volgende punten:

  • Poort 80 en 443

  • TCP en HTTP's

  • Verbindingen naar een van deze URL's:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Alle gebruikers moet worden toegestaan om deze adressen te bereiken zonder tussenkomst of verificatie van een proxyserver. In een kleiner netwerk moet u deze in de browser toevoegen aan de lijst met adressen die door de proxyserver moeten worden overgeslagen.

Als u de adressen aan uw lijst met te negeren adressen in Internet Explorer wilt toevoegen, gaat u naar Extra > Internetopties > Verbindingen > LAN-instellingen > Geavanceerd. U vindt op het tabblad Geavanceerd ook uw proxyserver en proxyserverpoort. Mogelijk moet u het selectievakje Een proxyserver voor het LAN-netwerk gebruiken inschakelen om de knop Geavanceerd te activeren. Controleer of Proxyserver niet voor lokale adressen gebruiken is ingeschakeld. Zodra u op Geavanceerd klikt, ziet u een tekstvak waarin u uitzonderingen kunt invoeren. Scheid de hierboven vermelde URL’s met jokertekens door puntkomma's, bijvoorbeeld:

*.microsoftonline.com; *.sharepoint.com

Nadat u uw proxy hebt omzeilt, moet u rechtstreeks gebruik kunnen maken van pingen of PsPing voor een URL van Office 365. De volgende stap is een test met het pingen van outlook.office365.com. Als u PsPing of een ander hulpprogramma gebruikt waarmee u een poortnummer aan de opdracht kunt toevoegen, gebruikt u PsPing voor portal.microsoftonline.com:443 als u de gemiddelde roundtrip (in milliseconden) wilt zien.

De roundtriptijd, of RTT, is een numerieke waarde voor de tijd die het kost om een HTTP-aanvraag te verzenden naar een server, zoals outlook.office365.com, en een reactie te krijgen waarin het verzenden van de aanvraag wordt bevestigd. Soms is dit afgekort tot RTT. Dit moet een relatief korte tijdsduur zijn.

U moet gebruikmaken van PsPing of een ander hulpprogramma dat geen gebruik maakt van ICMP-pakketten om deze test te kunnen uitvoeren. Deze pakketten worden namelijk door Office 365 geblokkeerd.

Het gebruik van PsPing rechtstreeks vanuit een Office 365-URL voor een algemene roundtriptijd (in milliseconden)

  1. Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:

    1. Klik op Start.

    2. Type de letters cmd in het vak Zoekopdracht starten en druk op CTRL+SHIFT+ENTER.

    3. Als het dialoogvenster Gebruikersaccountbeheer verschijnt, bevestigt u of de actie die wordt weergegeven klopt en klikt u vervolgens op Doorgaan.

  2. Ga naar de map met het hulpprogramma (in dit geval PsPing) en test deze Office 365-URL's:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      De opdracht PSPing die naar microsoft-my.sharepoint.com poort 443 gaat.

Zorg ervoor dat u het poortnummer 443 toevoegt. Houd er rekening mee dat Office 365 op een gecodeerde verbinding werkt. Als u PsPing zonder het poortnummer uitvoert, mislukt uw aanvraag. Nadat u uw lijst hebt gepingd, zoekt u de gemiddelde tijd in milliseconden (ms). Dit is de tijd die u moet noteren.

Graphic waarin een illustratie wordt weergegeven van client-naar-proxy PSPing met een retourtijd van 2,8 milliseconden.

Als u niet bekend bent met het overslaan van proxy en u liever stap voor stap te werk gaat, moet u eerst de naam weten van uw proxyserver. Ga in Internet Explorer naar Extra > Internetopties > Verbindingen > LAN-instellingen > Geavanceerd. De proxyserver staat weergegeven in het tabblad Geavanceerd. Ping de proxyserver met een opdrachtprompt door de volgende taak uit te voeren:

De proxyserver pingen en een roundtripwaarde krijgen (in milliseconden) voor fase 1 en 2

  1. Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:

    1. Klik op Start.

    2. Type de letters cmd in het vak Zoekopdracht starten en druk op CTRL+SHIFT+ENTER.

    3. Als het dialoogvenster Gebruikersaccountbeheer verschijnt, bevestigt u of de actie die wordt weergegeven klopt en klikt u vervolgens op Doorgaan.

  2. Typ ping <de naam van de proxyserver die door de browser wordt gebruikt of het IP-adres van de proxyserver> en druk op Enter. Als u over PsPing of een ander hulpprogramma beschikt, kunt u deze gebruiken.

    De opdracht kan er als een van deze voorbeelden uitzien:

    • ping onzeproxy.onsdomein.bedrijfstak.bedrijf.com

    • ping 155.55.121.55

    • ping onzeproxy

    • psping onzeproxy.onsdomein.bedrijfstak.bedrijf.com:80

    • psping 155.55.121.55:80

    • psping onzeproxy:80

  3. Als er geen testpakketten meer door de trace worden verzonden, ontvangt u een kort overzicht met de gemiddelde tijd in milliseconden. Deze waarde hebt u nodig. Maak een schermafbeelding van de prompt en sla deze op volgens de naamconventie. Op dit punt aangekomen is het ook handig de waarde in het diagram in te vullen.

Misschien hebt u ‘s morgens vroeg een trace gemaakt en is de tijd van client naar proxy (of een ander uitgangspunt van de server naar het internet) erg kort. In dat geval kunnen de getallen er zo uitzien:

Graphic met de retourtijd van een client naar een proxy (2,8 milliseconden).

Als uw clientcomputer een van de weinige is met toegang tot de proxyserver (of een andere uitgangsserver), dan kunt u de volgende fase van de test uitvoeren door op afstand verbinding te maken met die computer, en de opdrachtprompt voor PsPing naar een Office 365-URL van daaraf uitvoeren. Mocht u geen toegang tot die computer hebben, neemt u dan contact op met uw netwerkbeheerder voor hulp bij de volgende fase om de exacte tijdwaarden te kunnen krijgen. Als dat niet mogelijk is, kunt u een PsPing uitvoeren voor de betreffende Office 365-URL en deze vergelijken met de PsPing- of pingtijd voor uw proxyserver.

Als het bijvoorbeeld 51,84 milliseconden duurt van de client naar de Office 365-URL en 2,8 milliseconden van de client naar de proxy (of uitgangspunt), dan duurt het 49,04 milliseconden van het uitgangspunt naar Office 365. En als u midden op de dag een PsPing van 12,25 milliseconden vindt voor de tijd van de client naar de proxy en 62,01 milliseconden van de client naar de Office 365-URL, dan bedraagt de gemiddelde tijd van het uitgangspunt naar de proxy tot de Office 365-URL 49,76 milliseconden.

Aanvullende graphic met de ping in milliseconden van client naar proxy naast client naar Office 365 zodat de waarden kunnen worden afgetrokken.

Mogelijk vindt u voor uw oplossing al iets interessants als u deze basislijnen bekijkt. Als u bijvoorbeeld ziet dat u over het algemeen 40 tot 59 milliseconden latentie hebt van de proxy (of het uitgangspunt) naar de Office 365-URL en (afhankelijk van de hoeveelheid netwerkverkeer op dat tijdstip van de dag) een latentie van 3 tot 7 milliseconden van de client naar de proxy (of uitgangspunt), dan weet u dat er iets mis is als de laatste drie basislijnen voor de tijd van client naar proxy (of uitgangspunt) een latentie vertonen van 45 milliseconden.

Geavanceerde methoden

Als u echt wilt weten wat er gebeurt met uw internetaanvragen voor Office 365, moet u vertrouwd raken met netwerktraces. Het maakt niet uit welke hulpprogramma’s u voor deze traces wilt gebruiken, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard of een ander voldoen prima, zolang het programma maar netwerkverkeer kan opnemen en filteren. In deze sectie leest u dat het beter is meer dan één programma te gebruiken om een vollediger beeld van het probleem te krijgen. Tijdens het testen werken sommige van deze programma’s zelf als een proxy. De gebruikte hulpprogramma’s in het begeleidende artikel Prestatieproblemen oplossen met Office 365: planning, zijn Netmon 3.4, HTTPWatch of WireShark.

Het maken van een basislijn voor de prestaties is het eenvoudigste onderdeel van deze methode en veel van de stappen zijn dezelfde als bij het oplossen van een prestatieprobleem. Bij de meer geavanceerde methoden voor het maken van basislijnen moet u netwerktraces uitvoeren en opslaan. In de meeste voorbeelden in dit artikel is gebruikgemaakt van SharePoint Online (SPO), maar het is beter een lijst te maken met veelgebruikte acties in de Office 365-services waarop u bent geabonneerd en die u moet testen en registreren. Hier volgt een voorbeeld van een basislijn:

  • Lijst met basislijnen voor SPO - stap 1: Blader naar de startpagina van de SPO-website en voer een netwerktrace uit. Sla de trace op.

  • Lijst met basislijnen voor SPO - stap 2: Zoek naar een term (zoals de naam van uw bedrijf) via Enterprise Search en voer een netwerktrace uit. Sla de trace op.

  • Lijst met basislijnen voor SPO - stap 3: Upload een groot bestand naar een SharePoint Online-documentbibliotheek en voer een netwerktrace uit Sla de trace op.

  • Lijst met basislijnen voor SPO - stap 4: Blader naar de startpagina van de OneDrive-website en voer een netwerktrace uit. Sla de trace op.

Deze lijst moet de belangrijkste veelgebruikte acties bevatten die worden uitgevoerd op SharePoint Online. U ziet dat in de laatste stap, de trace naar OneDrive voor Bedrijven, een vergelijking wordt ingevoegd tussen de belasting van de SharePoint Online-startpagina (deze is vaak door bedrijven aangepast) en die van de OneDrive voor Bedrijven-startpagina, die zelden wordt aangepast. Dit is een zeer eenvoudige test als het gaat om een SharePoint Online-site die traag wordt geladen. U kunt een record met dit verschil in de test opnemen.

Als u al last hebt van een prestatieprobleem, zijn de meeste stappen die u moet nemen dezelfde als wanneer u een basislijn maakt. Netwerktraces zijn een essentieel onderdeel geworden. Hierna behandelen we hoe de belangrijke traces moeten worden gemaakt.

Als het noodzakelijk is om nu een prestatieprobleem aan te pakken, dan moet u een trace maken op het moment dat u last hebt van het probleem. U moet beschikken over de juiste hulpprogramma’s om logboeken vast te leggen en u moet een plan van aanpak hebben, d.w.z. een lijst met handelingen die u moet gaan uitvoeren zodat u over de juiste gegevens beschikt als u later het probleem gaat oplossen. Het eerste wat u moet doen is de datum en de tijd van de test vastleggen, zodat de bestanden kunnen worden opgeslagen in een daarvoor bestemde map. Vervolgens gaat u het aantal probleemstappen zelf terugbrengen. Dit zijn de stappen die u voor het testen gaat gebruiken. Vergeet de basisbeginselen niet: als het probleem zich alleen voordoet met Outlook, noteert u dan dat het probleem slechts in één Office 365-service optreedt. Door de omvang van het probleem te beperken, kunt u zich richten op iets wat u kunt oplossen.

Zie ook

Office 365-eindpunten beheren

Uw Office-vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Office Insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagents.

×