Implementere ExpressRoute for Office 365

Viktig: Denne artikkelen er maskinoversatt, se ansvarsfraskrivelsen. Du finner den engelske versjonen av artikkelen her som referanse.

ExpressRoute for Office 365 gir en alternativ rutingsbane til mange Internett-rettede Office 365-tjenester. Arkitekturen til ExpressRoute for Office 365 er basert på annonsering for offentlige IP-prefikser for Office 365-tjenester som allerede er tilgjengelig via Internett til de klargjorte ExpressRoute-kretsene, for etterfølgende videreformidling av disse IP-prefikser til nettverket. Med ExpressRoute aktiverer du effektivt flere forskjellige rutingsbaner for mange Office 365-tjenester, både gjennom Internett og gjennom ExpressRoute. Denne rutingstatusen på nettverket kan representere en betydelig endring i hvordan den interne nettverkstopologien er utformet.

Status: Fullført veiledningen v2

Du må planlegge nøye implementeringen av ExpressRoute for Office 365 for å tilpasse nettverketskompleksiteten slik at en ruting er tilgjengelig både via en dedikert krets med ruter satt inn i kjernenettverket, og via Internett. Hvis du og teamet ditt ikke utfører den detaljerte planleggingen og testingen i denne veiledningen, er det stor fare for at du vil oppleve periodisk eller fullstendig mangel på tilkobling til Office 365-tjenester når ExpressRoute-kretsen er aktivert.

Hvis du vil ha en vellykket implementering, må du analysere kravene til infrastruktur, gå gjennom en detaljert nettverksvurdering og -utforming, planlegge utrullingen på en trinnvis og kontrollert måte, og bygge en detaljert validerings- og testingsplan. For et stort, distribuert miljø er det ikke uvanlig å se implementeringer strekke seg over flere måneder. Denne veiledningen er utformet for å hjelpe deg med å planlegge fremover.

Store vellykkede distribusjoner kan ta seks måneder å planlegge, og inkluderer ofte gruppemedlemmer fra mange områder i organisasjonen. Det kan være nettverksbygging, brannmur- og Proxy-serveradministratorer, Office 365-administratorer, sikkerhet, sluttbruker-kundestøtte, prosjektstyring og ledelsesstøtte. Din investering i planleggingsprosessen vil redusere sannsynligheten for at du opplever distribusjonsfeil som resulterer i nedetid eller kompleks og dyr feilsøking.

Vi forventer at de følgende forhåndskrav er fullført før denne implementeringsveiledningen starter.

  1. Du har fullført en vurdering av nettverket for å fastslå om ExpressRoute er anbefalt og godkjent.

  2. Du har valgt en tjenesteleverandør for ExpressRoute-nettverket. Finn mer informasjon om ExpressRoute-partnere og nodenettplasseringer.

  3. Du har allerede lese og forstå ExpressRoute dokumentasjon og det lokale nettverket er kunne oppfyller ExpressRoute forhåndskrav gjennomgående.

  4. Gruppen har lest alle veiledningen og dokumentasjonen på https://aka.ms/expressrouteoffice365, https://aka.ms/ert, og skal overvåkes Azure ExpressRoute for Office 365 Opplæring serie på kanalen 9 for å få en forståelse av kritisk tekniske detaljer, inkludert:

    • Internett-avhengigheter til SaaS-tjenester.

    • Slik kan du unngå asymmetriske ruter og håndtere kompleks ruting.

    • Hvordan du kan inkludere perimetersikkerhet, tilgjengelighet og programmet nivå kontroller.

Begynn med å samle sammen krav

Start med å bestemme hvilke funksjoner og tjenester du planlegger å innføre i organisasjonen. Du må finne ut hvilke funksjoner i de ulike Office 365-tjenestene som skal brukes og hvilke plasseringer i nettverket som vil være verter for personer som bruker disse funksjonene. I katalogen over scenarier må du legge til nettverksattributtene som hver av disse scenariene krever, for eksempel inngående og utgående flyter i nettverkstrafikken, og om Office 365-endepunktene er tilgjengelig via ExpressRoute eller ikke.

Slik samler du inn organisasjonens krav:

  • Katalogiser inngående og utgående nettverkstrafikk for de Office 365-tjenestene organisasjonen din bruker. Søk på Office 365-nettadresser og siden for IP-adresseområder. Der finner du beskrivelsen av flyter som de ulike Office 365-scenariene krever.

  • Samle inn dokumentasjon av eksisterende nettverkstopologi som viser detaljer i den interne WAN-ryggraden og -topologien, tilkobling til satellittnettsteder, siste mil-brukertilkobling, ruting til punkter for utgående trafikk til perimeternettverk, og proxy-tjenester.

    • Identifiser inngående tjeneste-endepunkter på nettverksdiagrammer som Office 365 og andre Microsoft-tjenester vil koble deg til. De viser både Internett og foreslåtte ExpressRoute-tilkoblingsbaner.

    • Identifiser alle geografiske brukersteder og WAN-tilkobling mellom plasseringer sammen med hvilke plasseringer som for øyeblikket har en utgående trafikk til Internett, og hvilke steder som blir foreslått å ha en utgående trafikk til en ExpressRoute-nodenettplassering.

    • Identifiser alle edge-enheter, for eksempel proxyer, brannmurer og så videre, og deres relasjoner til flyter som går via Internett og ExpressRoute.

    • Dokumenter om sluttbrukerne får tilgang til Office 365-tjenester via direkte ruting eller indirekte programproxy for Internett- og ExpressRoute-flyter.

  • Legg til plasseringen for leieren og møt-meg-plasseringer i nettverksdiagrammet.

  • Beregn den forventede og observerte nettverksytelsen og kjennetegn for ventetid fra store brukerplasseringer til Office 365. Husk at Office 365 er et globalt og distribuert sett av tjenester og brukerne vil bli koblet til plasseringer som kan være forskjellige fra leierens plassering. Det anbefales derfor å måle og optimalisere for ventetid mellom brukeren og den nærmeste grensen til Microsofts globale nettverk over ExpressRoute og Internett-tilkoblinger. Du kan bruke resultatene fra nettverksvurderingen som hjelp til denne oppgaven.

  • Lag liste over firmaets nettverkssikkerhet og høye tilgjengelighetskrav som må være oppfylt med den nye ExpressRoute-tilkoblingen. Hvordan brukere for eksempel kan fortsette å få tilgang til Office 365 hvis det skulle være kretsfeil i den utgående trafikken til Internett eller ExpressRoute.

  • Hvilket Office 365 nettverk for innkommende og utgående flyter dokumentet skal bruke Internett-bane, og som bruker ExpressRoute. Detaljer om geografiske steder brukerne og detaljer om nettverkstopologi din lokale kan kreve planen skal være forskjellig fra én bruker plasseringen til en annen.

Vi anbefaler at du bare bruker ExpressRoute for Office 365 for nettverket trafikkflyt som kreves for å gå gjennom en dedikert tilkobling på grunn av forskriftsmessige krav eller som et resultat av vurdering av nettverket for å minimere ruting og andre nettverk kompleksiteten. I tillegg, anbefaler vi at du Faseegenskaper omfanget av ExpressRoute ruting og denne tilnærmingsmåten utgående og innkommende nettverket trafikkflyt som forskjellige og distinkte faser av prosjektet implementering. Distribuere ExpressRoute for Office 365 for bare brukerstartede utgående nettverket trafikkflyt og Forlat innkommende nettverket trafikkflyt over Internett kan hjelpe med å kontrollere økningen i topologisk kompleksitet og risikoer presentere flere asymmetrisk ruting muligheter.

Nettverket trafikk katalogen skal inneholde oppføringer over alle innkommende og utgående nettverks-tilkoblinger som du har mellom det lokale nettverket og Microsoft.

  • Utgående trafikkflyter for nettverket er alle scenarier der en tilkobling startes fra det lokale miljøet for eksempel fra interne klienter eller servere, med Microsoft-tjenester som mål. Disse tilkoblingene kan være direkte til Office 365 eller indirekte, for eksempel når tilkoblingen går gjennom proxy-servere, brannmurer, eller andre nettverksenheter i Office 365-banen.

  • Inngående trafikkflyter i nettverket er alle scenarier der en tilkobling startes fra Microsoft-skyen til en lokal vert. Disse tilkoblingene trenger vanligvis å gå gjennom brannmur og annen infrastruktur for sikkerhet som sikkerhetspolicyen for kunder krever for flyter med ekstern opprinnelse.

Les Sikre rutesymmetri-avsnittet i artikkelen Ruting med ExpressRoute for Office 365 for å bestemme hvilke tjenester som vil sende inngående trafikk, og se etter kolonnen som heter ExpressRoute for Office 365 i referanseartikkelenOffice 365 -endepunktene for å bestemme resten av tilkoblingsinformasjonen.

For hver tjeneste som krever utgående tilkobling, bør du beskrive de planlagte tilkoblingene for tjenesten, inkludert nettverksruting, proxy-konfigurasjon, pakkeinspeksjon og båndbreddebehov.

For hver tjeneste som krever en inngående tilkobling, vil du trenge noe tilleggsinformasjon. Servere i Microsoft-skyen vil etablere tilkoblinger til det lokale nettverket. For å sikre at tilkoblingene gjøres på riktig måte, bør du beskrive alle aspekter av denne tilkoblingen, inkludert de offentlige DNS-postene for tjenester som godtar disse inngående tilkoblingene, de CIDR-formaterte IPv4 IP-adressene, hvilket ISP-utstyr som er involvert, og hvordan inngående NAT eller kilde-NAT som håndteres for disse tilkoblingene.

Inngående tilkoblinger skal gjennomgås uavhengig av om de kobler til via Internett eller ExpressRoute, for å sikre at asymmetrisk ruting ikke har blitt introdusert. Lokale endepunkter som Office 365-tjenester starter inngående tilkoblinger til, trenger kanskje i noen tilfeller å åpnes av andre Microsoft- og ikke-Microsoft-tjenester. Det er avgjørende at aktivering av ExpressRoute-ruting til disse tjenestene for Office 365-formål ikke bryter andre scenarier. I mange tilfeller kan kunder trenge å implementere bestemte endringer i det interne nettverket, for eksempel kildebasert NAT, for å sikre at inngående flyter fra Microsoft fortsetter å være symmetrisk etter at ExpressRoute er aktivert.

Her er et eksempel på detaljnivået som kreves. I dette tilfellet vil Exchange-hybrid rute til det lokale systemet via ExpressRoute.

Tilkoblingsegenskap

Verdi

Nettverktrafikkens retning

Inngående

Tjeneste

Exchange-hybrid

Offentlig Office 365-endepunkt (kilde)

Exchange Online (IP-adresser)

Offentlig lokalt endepunkt (mål)

5.5.5.5

Offentlig (Internett) DNS-post

Autodiscover.contoso.com

Vil dette lokale endepunktet bli brukt av andre (ikke-Office 365) Microsoft-tjenester

Nei

Vil dette lokale endepunktet bli brukt av brukere/systemer på Internett

Ja

Interne systemer publisert gjennom offentlige endepunkter

Exchange serverklient (lokalt) 192.168.101, 192.168.102, 192.168.103

IP-annonsering for det offentlige endepunktet

Til Internett: 5.5.0.0/16

Til ExpressRoute: 5.5.5.0/24

Sikkerhets-/perimeterkontroller

Internettbane: DeviceID_002

ExpressRoute bane: DeviceID_003

Høy tilgjengelighet

Aktiv/aktiv på tvers av 2 geo-overflødige

ExpressRoute-kretser – Chicago og Dallas

Kontroll av banesymmetri

Metode: datakilden NAT

Internett-bane: kilde NAT innkommende tilkoblinger til 192.168.5.5

ExpressRoute bane: kilde NAT tilkoblinger til 192.168.1.0 (Chicago) og 192.168.2.0 (Dallas)

Her er et eksempel på en tjeneste som bare er utgående:

Tilkoblingsegenskap

Verdi

Nettverktrafikkens retning

Utgående

Tjeneste

SharePoint Online

Lokalt endepunkt (kilde)

Arbeidsstasjon for bruker

Offentlig Office 365-endepunkt (kilde)

SharePoint Online (IP-adresser)

Offentlig (Internett) DNS-post

*. sharepoint.com (og flere FQDN-er)

CDN-henvisninger

cdn.sharepointonline.com (og flere FQDN-er) – IP-adresser vedlikeholdes av CDN-leverandører)

IP-annonsering og NAT brukes

Internettbane/kilde-NAT: 1.1.1.0/24.

ExpressRoute bane kilde NAT: 1.1.2.0/24 (Chicago) og 1.1.3.0/24 (Dallas)

Tilkoblingsmetode

Internett: via lag 7 proxy (.pac-fil)

ExpressRoute: direkte ruting (ingen proxy)

Sikkerhets-/perimeterkontroller

Internettbane: DeviceID_002

ExpressRoute bane: DeviceID_003

Høy tilgjengelighet

Internett-bane: overflødige internet grensekontrolleren

ExpressRoute bane: aktiv/aktiv 'varmt Poteter' ruting på tvers av 2 geo overflødige ExpressRoute kretser – Chicago og Dallas

Kontroll av banesymmetri

Metode: kilde NAT før alle tilkoblinger

Når du forstår tjenestene og deres tilknyttede trafikkflyter for nettverk, kan du opprette et nettverksdiagram som integrerer disse nye tilkoblingskravene og illustrerer endringene du gjør for å bruke ExpressRoute for Office 365. Diagrammet skal inneholde:

  1. Alle brukerplasseringer Office 365 og andre tjenester skal være tilgjengelige fra.

  2. Alle Internett- og ExpressRoute-punkter for utgående trafikk.

  3. Alle utgående og inngående enheter som administrerer tilkobling inn og ut fra nettverket, inkludert rutere, brannmurer, proxy-serverprogrammer og oppdaging/forebygging av inntrenging.

  4. Interne bestemmelsessteder for all inngående trafikk, for eksempel interne ADFS-servere som godtar tilkoblinger fra ADFS proxy-servere for nettprogrammer.

  5. Katalog med alle IP-delnett som vil bli annonsert

  6. Identifiserer hver sted der personer får tilgang til Office 365 fra, og list opp møt-meg-plasseringer som skal brukes for ExpressRoute.

  7. Plasseringer og deler av den interne nettverkstopologien, der Microsoft IP-prefikser lært fra ExpressRoute blir godkjent, filtrert og overført til.

  8. Nettverkstopologien bør illustrere den geografiske plasseringen av hvert nettverkssegment, og hvordan det kobler til Microsoft-nettverket via ExpressRoute og/eller Internett.

Diagrammet nedenfor viser hver plassering som personer skal bruke Office 365 fra, sammen med de inngående og utgående rutingannonsene til Office 365.

ExpressRoute regionalt, geografiske møtesteder

For utgående trafikk får personene tilgang til Office 365 på en av tre måter:

  1. Gjennom en møt-meg-plassering i Nord-Amerika for personer i California.

  2. Gjennom en møt-meg-plassering i Hong Kong for personer i Hong Kong

  3. Via Internett i Bangladesh der det er færre personer og ingen ExpressRoute-krets er klargjort.

Utgående tilkoblinger for regionalt diagram

Likeledes, returnerer inngående nettverkstrafikk fra Office 365 på en av tre måter:

  1. Gjennom en møt-meg-plassering i Nord-Amerika for personer i California.

  2. Gjennom en møt-meg-plassering i Hong Kong for personer i Hong Kong

  3. Via Internett i Bangladesh der det er færre personer og ingen ExpressRoute-krets er klargjort.

Innkommende tilkoblinger for regionalt diagram

Valget av møt-meg-plasseringer, som er den fysiske plasseringen der din ExpressRoute-krets kobles til nettverket til Microsoft-nettverket, påvirkes av plasseringene som personene får tilgang til Office 365 fra. Som et SaaS-tilbud, opererer ikke Office 365 under de regionale modellene IaaS og PaaS på samme måte Azure gjør. Office 365 er i stedet et distribuert sett med samarbeidstjenester, der brukere kan trenge å koble til endepunktene på tvers av flere datasentere og regioner. Det er ikke nødvendigvis i samme plassering eller område som brukerens leier er driftet.

Dette betyr at det viktigste hensynet du må ta når du velger møt-meg-plasseringer for ExpressRoute for Office 365, er hvor personene i organisasjonen vil koble fra. Den generelle anbefalingen for optimal Office 365-tilkobling er implementeringsruting, slik at brukerforespørsler til Office 365-tjenester blir levert til Microsoft-nettverket via den korteste nettverksbanen. Dette blir ofte kalt «varm potet»-ruting. Hvis for eksempel de fleste Office 365-brukerne er i én eller to plasseringer, vil du få den optimale utformingen hvis du velger møt-meg-plasseringer som er nærmest mulig plasseringen til brukerne. Hvis firmaet har store brukergrupper i mange forskjellige områder, bør du vurdere å ha flere ExpressRoute-kretser og møt-meg-plasseringer. For noen av din brukerplasseringer kan det hende at den korteste/mest optimale banen til Microsoft-nettverk og Office 365 ikke er gjennom den interne WAN og ExpressRoute-møt-meg-punkt, men via Internett.

Ofte finnes det flere møt-meg-plasseringer som kan velges innenfor et område med relativ nærhet til brukerne. Fyll ut tabellen nedenfor for å få veiledning til dine beslutninger.

Planlagte ExpressRoute-møt-meg-plasseringer i California og New York

Plassering

Antall personer

Forventet ventetid til Microsoft-nettverket via utgående nettrafikk

Forventet ventetid til Microsoft-nettverket via ExpressRoute

Los Angeles

10 000

~15 ms

~10 ms (via Silicon Valley)

Washington DC

15 000

~20 ms

~10 ms (via New York)

Dallas

5 000

~15 ms

~40 ms (via New York)

Når den globale nettverksarkitekturen som viser Office 365-området, nettverksleverandøren for ExpressRoute møt-meg-plasseringer og antall personer etter sted er utviklet, kan det brukes til å identifisere om eventuelle optimaliseringer kan gjøres. Den kan også vise globale tilkoblinger av hårnålsnettverk, hvor trafikken rutes til en plassering langt unna, for å få møt-meg-plasseringen. Hvis en hårnål-tilkobling på det globale nettverket er oppdaget, bør det utbedres før du fortsetter. Du må enten finne en annen møt-meg-plassering, eller bruke selektive Internettpunkter for utgående trafikk, for å unngå hårnål-tilkoblingen.

Det første diagrammet viser et eksempel på en kunde med to fysiske plasseringer i Nord-Amerika. Du kan se informasjonen om kontorplasseringer, plasseringen til Office 365-leieren, og flere valg for ExpressRoute møt-meg-plasseringer. I dette eksemplet har kunden har valgt møt-meg-plasseringen basert på to prinsipper, i denne rekkefølgen:

  1. Nærmeste avstand til personene i organisasjonen.

  2. Nærmeste i nærheten av en Microsoft-datasenter som er vert for Office 365.

ExpressRoute USA geografisk møtested

Utvider du dette konseptet ytterligere, vil diagram nummer to som eksempel vise en flernasjonal kunde, stilt overfor lignende informasjon og beslutningstaking. Denne kunden har et lite kontor i Bangladesh med bare en liten gruppe på ti personer, fokusert på å sette spor etter seg i området. Det finnes en møt-meg-plassering i Chennai og et Microsoft-datasenter med Office 365 driftet i Chennai, så en møt-meg-plassering virker fornuftig. Utgiften med den ekstra kretsen for ti personer vil imidlertid bli tyngende. Når du ser på nettverket, må du avgjøre om ventetiden involvert i å sende nettverkstrafikken over nettverket er mer effektivt enn å bruke kapitalen til å skaffe en annen ExpressRoute-krets.

De ti personene i Bangladesh kan oppleve bedre ytelse med nettverkstrafikken sendt over Internett til Microsoft-nettverket, enn de ville gjort hvis de rutet til sitt interne nettverk. Dette viste vi i diagrammene innledningsvis, og viser dem igjen nedenfor.

Utgående tilkoblinger for regionalt diagram

Opprette din ExpressRoute for Office 365-implementeringsplan

Implementeringsplanen din bør omfatte både tekniske detaljer om hvordan du konfigurerer ExpressRoute, og detaljer om hvordan du konfigurerer alle de andre infrastrukturene i nettverket, for eksempel følgende:

  • Planlegg hvilke tjenester som skal deles mellom ExpressRoute og Internett.

  • Planlegg for båndbredde, sikkerhet, høy tilgjengelighet og failover.

  • Utform inngående og utgående ruting, inkludert riktige optimaliseringer for rutingsbaner til ulike plasseringer.

  • Avgjør hvor langt ExpressRoute-ruter vil bli annonsert inn i nettverket og hva slags mekanisme får klienter til å velge Internett- eller ExpressRoute-banen. Det kan for eksempel være direkteruting eller program-proxy.

  • Planlegg DNS-postendringer, inkludert Struktur for avsenderpolicy-oppføringer.

  • Planlegge NAT strategi inkludert utgående og innkommende kilde NAT.

  • Til den innledende distribusjonen blir alle inngående tjenester, for eksempel inngående e-post eller hybrid-tilkobling, anbefalt å bruke Internett.

  • Planlegge sluttbruker klient LAN Postruting, for eksempel konfigurerer en PAC/WPAD filen, standardrute, proxy-servere og BGP rute annonser.

  • Planlegg perimeterruting, inkludert proxy-servere, brannmurer og sky-proxyer.

Opprett en plan for båndbredden som kreves for hver større arbeidsmengde i Office 365. Beregn kravene for Exchange Online, SharePoint Online og Skype for Business hver for seg. Du kan bruke beregningskalkulatorene vi tilbyr i Exchange Online og Skype for Business som et utgangspunkt. En pilottest med et representativt utvalg av brukerprofiler og plasseringer kreves imidlertid for fullstendig forståelse av båndbreddebehovene i organisasjonen.

Legg til hvordan sikkerhet håndteres på hver Internett- og EkspressRoute-plassering for utgående trafikk i planen. Husk at alle ExpressRoute-tilkoblinger til Office 365 bruker offentlig nettverksnoding, og må fortsatt sikres i henhold til firmaets sikkerhetspolicy rundt det å koble til eksterne nettverk.

Legg til detaljer om hvilke personer som vil bli påvirket av hvilken type serverbrudd, og hvordan de på enkleste måte kan utføre arbeidet med full kapasitet.

Planlegg båndbreddekrav, inkludert Skype for Business-krav for skjelving, ventetid, rom for utvidelse

Skype for Business Online har også bestemte tilleggskrav for nettverket. Detaljer om disse kan du finne i artikkelen Mediekvalitet og tilkoblingsytelse til nettverk i Skype for Business Online.

Les delen Båndbreddeplanlegging for Azure ExpressRoute i Nettverksplanlegging med ExpressRoute for Office 365.

Når du utfører en båndbreddevurdering med dine pilotbrukere, kan du bruke veiledningen vår, Office 365-ytelsesjustering ved hjelp av referanseverdier og ytelseshistorikk.

Plan for høye tilgjengelighetskrav

Opprett en plan for høy tilgjengelighet som oppfyller dine behov og innlem dette i det oppdaterte topologiske nettverksdiagrammet. Les delen Høy tilgjengelighet og failover med Azure ExpressRoute i Nettverksplanlegging med ExpressRoute for Office 365.

Planlegge for nettverket sikkerhetskravene

Opprett en plan som oppfyller dine krav til nettverkssikkerhet, og innlem denne i det oppdaterte topologiske nettverksdiagrammet. Les delen Bruke sikkerhetskontrollene på Azure ExpressRoute for Office 365-scenarier i Nettverksplanlegging med ExpressRoute for Office 365.

ExpressRoute for Office 365 har utgående nettverkskrav som kan være ukjente. Spesielt IP-adressene som representerer brukerne og nettverkene til Office 365 og fungerer som kilde-endepunktene for utgående nettverkstilkoblinger til Microsoft, må følge spesifikke krav som er beskrevet nedenfor.

  1. Endepunktene må være offentlige IP-adresser som er registrert på firmaet eller en operatør som tilbyr deg ExpressRoute-tilkobling.

  2. Endepunktene må være annonsert til Microsoft og validert/godtatt av ExpressRoute.

  3. Endepunktene må ikke være annonsert til Internett med de samme eller mer foretrukne rutingtall.

  4. Endepunktene må ikke brukes til tilkobling til Microsoft-tjenester som ikke er konfigurert via ExpressRoute.

Hvis nettverksutformingen ikke oppfyller disse kravene, er det en høy risiko for at brukerne kommer til å oppleve mislykkede tilkoblingsforsøk til Office 365 og andre Microsoft-tjenester på grunn av «sort hull-ruting» eller asymmetrisk ruting. Dette oppstår når forespørsler om Microsoft-tjenester rutes via ExpressRoute, men svar rutes tilbake via Internett, eller omvendt, og svarene utelates av tilstandsfulle nettverksenheter slik som brannmurer.

Den vanligste metoden du kan bruke til å oppfylle kravene ovenfor, er å bruke kilde-NAT, enten implementert som en del av nettverket eller levert av ExpressRoute-operatøren. Med kilde-NAT kan du dra ut detaljene og den private IP-adresseringen til Internett-nettverket fra ExpressRoute. Når disse er kombinerte med riktig IP-ruteannonser, har du en enkel mekanisme for å sikre banesymmetrien. Hvis du bruker tilstandsfulle nettverksenheter som er spesifikke for nettverksnoding-plasseringer for ExpressRoute, må du implementere separate NAT-utvalg for hver ExpressRoute-nettverksnoding for å sikre banesymmetrien.

Les mer om ExpressRoute NAT-krav.

Legg til endringene for den utgående tilkoblingen i det topologiske nettverksdiagrammet.

De fleste Office 365-distribusjoner antar en slags inngående tilkobling fra Office 365 til lokale tjenester, som for Exchange, SharePoint og Skype for Business-hybridscenarier, postboksoverføringer og godkjenning ved hjelp av ADFS-infrastruktur. Når du aktiverer en ekstra rutingbane mellom det lokale nettverket og Microsoft for utgående tilkobling, kan disse inngående tilkoblingene utilsiktet bli påvirket av asymmetrisk ruting, selv om du har tenkt at disse flytene skal fortsette å bruke Internett. Noen forholdsregler beskrevet nedenfor anbefales for å sikre at det ikke er noen påvirkning på Internett-baserte inngående flyter fra Office 365 til lokale systemer.

Hvis du vil redusere risikoen for asymmetrisk ruting for inngående nettverktrafikkflyter, bør alle inngående tilkoblinger bruke kilde-NAT før de blir rutet til segmenter i nettverket som har rutingssynlighet i ExpressRoute. Hvis de innkommende tilkoblingene tillates på et nettverksegment med rutingssynlighet i ExpressRoute uten kilde-NAT, vil forespørsler som stammer fra Office 365 komme fra Internett, men svaret som går tilbake til Office 365 vil foretrekke ExpressRoute-nettverksbanen tilbake til Microsoft-nettverket. Dette vil sannsynligvis forårsake asymmetrisk ruting.

Du kan vurdere en av de følgende implementeringsmønstrene for å oppfylle dette kravet:

  1. Utføre kilde-NAT før forespørsler rutes til det interne nettverket, ved hjelp av nettverksutstyr for eksempel brannmurer eller belastningsfordelere langs banen fra Internett til dine lokale systemer.

  2. Forsikre deg om at ExpressRoute-ruter ikke spres til nettverkssegmenter der inngående tjenester, for eksempel frontservere eller reverserte proxy-systemer som håndterer Internett-tilkoblinger er lokalisert.

Hvis du holder nøye regnskap med disse scenariene i nettverket, og holder all inngående nettverktrafikkflyt over Internett, vil det hjelpe deg å minimere distribusjons- og operasjonsrisiko for asymmetrisk ruting.

Det kan være tilfeller der du kan velge å dirigere noen inngående flyter via ExpressRoute-tilkoblinger. For disse scenariene, kan du ta følgende ekstra hensyn.

  1. Office 365 kan bare rette seg mot lokale endepunkter som bruker offentlige IP-adresser. Dette betyr at selv om det lokale inngående endepunktet bare vises i Office 365 via ExpressRoute, vil det fortsatt trenge å være tilknyttet en offentlig IP-adresse.

  2. All DNS-navneløsing som Office 365-tjenester utfører for å løse lokale endepunkter skjer ved hjelp av offentlige DNS. Dette betyr at du må registrere inngående tjeneste-endepunktenes FQDN til IP-tilordninger på Internett.

  3. Hvis du vil motta inngående nettverkstilkoblinger via ExpressRoute, må de offentlige IP-delnettene for disse endepunktene være annonsert til Microsoft via ExpressRoute.

  4. Evaluer nøye disse inngående nettverktrafikkflytene for å sikre at riktige sikkerhets- og nettverkskontroller er brukt, i henhold til firmaet sikkerhets- og nettverkspolicyer.

  5. Når de lokale inngående endepunktene er annonsert til Microsoft via ExpressRoute, vil ExpressRoute effektivt bli den foretrukne rutingbanen til disse endepunktene for alle Microsoft-tjenester, inkludert Office 365. Dette betyr at disse endepunkt-delnettene bare skal brukes for kommunikasjon med Office 365-tjenester og ingen andre tjenester på Microsoft-nettverket. Ellers vil utformingen føre til en asymmetrisk ruting der inngående tilkoblinger fra andre Microsoft-tjenester foretrekker å rute inngående via ExpressRoute, mens returbanen vil bruke Internett.

  6. Hvis en ExpressRoute-krets eller møt-meg plassering er nede, må du forsikre deg om at de lokale inngående endepunktene fortsatt er tilgjengelige til å godta forespørsler via en separat nettverksbane. Dette kan bety å annonsere delnett for disse endepunktene gjennom flere ExpressRoute-kretser.

  7. Vi anbefaler å bruke kilde-NAT for alle inngående nettverktrafikkflyter som kommer inn i nettverket gjennom ExpressRoute, spesielt når disse flytene krysser tilstandsfulle nettverksenheter som brannmurer.

  8. Enkelte lokale tjenester, for eksempel ADFS proxy eller Exchange autosøk, kan motta inngående forespørsler fra både Office 365-tjenester og brukere fra Internett. Office 365 vil rette disse forespørslene til den samme FQDN som ved brukerforespørsler via Internett. Det å tillate inngående brukertilkoblinger fra Internett til de lokale endepunktene, samtidig som Office 365-tilkoblinger tvinges til å bruke ExpressRoute, utgjør en betydelig rutingkompleksitet. For de aller fleste kunder anbefales ikke implementering av slike komplekse scenarier via ExpressRoute, på grunn av operasjonelle vurderinger. Dette ekstra arbeidet inkluderer administrering av risikoer for asymmetrisk ruting og gjør at du nøye må behandle rutingannonser og policyer på tvers av flere dimensjoner.

Du bør unngå asymmetrisk ruting for å sikre at personer i organisasjonen sømløst kan bruke Office 365, samt andre viktige tjenester på Internett. Det er to vanlige konfigurasjoner kundene har som fører til asymmetrisk ruting. Nå er et bra tidspunkt for å se gjennom nettverkskonfigurasjonen du planlegger å bruke, og kontrollere om ett av disse asymmetriske rutingscenariene finnes.

Til å begynne med vil vi undersøke et par ulike situasjoner som er forbundet med nettverksdiagrammet nedenfor. I dette diagrammet alle serverne som mottar inngående forespørsler, for eksempel ADFS eller lokale hybridservere, i New Jersey-datasenteret og er annonsert til Internett.

  1. Selv om perimeternettverket er sikkert, er det ingen kilde-NAT tilgjengelig for inngående forespørsler.

  2. Serverne i datasenteret New Jersey, kan se både Internett- og ExpressRoute-ruter.

Oversikt over ExpressRoute-tillkoblinger

Vi har også forslag om hvordan du reparerer dem.

Problem 1: Sky-til-lokaltilkobling via Internett

Diagrammet nedenfor illustrerer den asymmetriske nettverksbanen som velges når din nettverkskonfigurasjon ikke tilbyr NAT for inngående forespørsler fra Microsoft-skyen via Internett.

  1. Den inngående forespørselen fra Office 365 henter IP-adressen til det lokale endepunktet fra offentlig DNS og sender forespørselen til ditt perimeternettverk.

  2. I denne defekte konfigurasjonen, er det ingen kilde-NAT som er konfigurert eller tilgjengelig i perimeternettverket hvor trafikken er sendt, og dette resulterer i at faktiske kilde-IP-adresser brukes som returmål.

    • Serveren i nettverket ruter returtrafikken til Office 365 via en hvilken som helst tilgjengelig ExpressRoute-nettverkstilkobling.

    • Resultatet er en asymmetrisk bane for den flyten til Office 365, noe som fører til en brutt kobling.

Asymmetrisk rutingproblem 1 med ExpressRoute

Løsning 1a: Kilde-NAT

Det å legge en kilde-NAT til den inngående forespørselen løser enkelt dette feilkonfigurerte nettverket. I dette diagrammet:

  1. Den inngående forespørselen fortsetter å komme inn gjennom New Jersey-datasenterets perimeternettverk. Denne gangen er kilde-NAT tilgjengelig.

  2. Svaret fra serveren rutes tilbake mot den IP-en som er tilknyttet kilde-NAT i stedet for den opprinnelige IP-adressen, noe som resulterer i svaret returnerer langs den samme nettverksbanen.

Løsning på asymmetrisk rutingproblem 1 med ExpressRoute

Løsning 1b: Registrere ruteomfang

Du kan eventuelt velge ikke å tillate ExpressRoute BGP-prefikser å bli annonsert, ved å fjerne den alternative nettverksbanen for disse datamaskinene. I dette diagrammet:

  1. Den inngående forespørselen fortsetter å komme inn gjennom New Jersey-datasenterets perimeternettverk. Denne gangen er ikke prefiksene som er annonsert fra Microsoft via ExpressRoute-kretsen tilgjengelige for New Jersey-datasenteret.

  2. Svaret fra serveren rutes tilbake mot den IP-en som er tilknyttet den opprinnelige IP-adressen via den eneste tilgjengelige ruten, noe som resulterer i at svaret returnerer langs den samme nettverksbanen.

Løsning på asymmetrisk rutingproblem 2 med ExpressRoute

Problem 2: Sky-til-lokaltilkobling via ExpressRoute

Diagrammet nedenfor illustrerer den asymmetriske nettverksbanen som velges når din nettverkskonfigurasjon ikke tilbyr NAT for inngående forespørsler fra Microsoft-skyen via ExpressRoute.

  1. Den inngående forespørselen fra Office 365 henter IP-adressen fra DNS og sender forespørselen til ditt perimeternettverk.

  2. I denne defekte konfigurasjonen, er det ingen kilde-NAT som er konfigurert eller tilgjengelig i perimeternettverket hvor trafikken er sendt, og dette resulterer i at faktiske kilde-IP-adresser brukes som returmål.

    • Serveren i nettverket ruter returtrafikken til Office 365 via en hvilken som helst tilgjengelig ExpressRoute-nettverkstilkobling.

    • Resultatet er en asymmetrisk tilkobling til Office 365.

Asymmetrisk rutingproblem 2 med ExpressRoute

Løsning 2: Kilde-NAT

Det å legge en kilde-NAT til den inngående forespørselen løser enkelt dette feilkonfigurerte nettverket. I dette diagrammet:

  1. Den inngående forespørselen fortsetter å komme inn gjennom New Jersey-datasenterets perimeternettverk. Denne gangen er kilde-NAT tilgjengelig.

  2. Svaret fra serveren rutes tilbake mot den IP-en som er tilknyttet kilde-NAT i stedet for den opprinnelige IP-adressen, noe som resulterer i svaret returnerer langs den samme nettverksbanen.

Løsning på asymmetrisk rutingproblem 3 med ExpressRoute

Bekreft på papir at nettverksutformingen har banesymmetri

På dette tidspunktet, må du bekrefte på papir at implementeringsplanen tilbyr rutesymmetri for de ulike scenarier der du skal bruke Office 365. Du kan identifisere bestemte nettverksruter som forventes å bli tatt når en person bruker andre funksjoner for tjenesten. Fra det lokale nettverket og WAN-ruting, til perimeterenhetene, til tilkoblingsbanen, som ExpressRoute eller Internett, og til tilkoblingen til nettendepunktet.

Du må gjøre dette for alle Office 365 nettverkstjenestene som tidligere ble identifisert som tjenester som organisasjonen vil ta i bruk.

Det hjelper for å gjøre denne papirgjennomgangen av ruter med en annen person. Forklar dem hvor hvert nettverkshopp er forventet å få den neste ruten fra, og forsikre deg om at du er kjent med rutingbanene. Husk at ExpressRoute alltid gir en mer omfangsrik rute til Microsoft-server IP-adresser og gi en lavere rutekostnad enn en Internett-standardrute.

Utform konfigurasjon for kundetilkobling

Bruke PAC-filer med ExpressRoute

Hvis du bruker en proxy-server for Internett bundet trafikk og du må justere noen PAC eller filer klientkonfigurasjon å sikre at klientdatamaskiner på nettverket er riktig konfigurert til å sende ExpressRoute trafikken du ønsker i Office 365 uten transiting proxy-serveren, og gjenstående trafikken, inkludert noen Office 365-trafikk, sendes til den aktuelle proxyen. Les vår guide på Administrere Office 365 endepunktene for eksempel PAC filer.

Merknad: Endepunktene endres ofte, så ofte som ukentlig. Du bør bare gjøre endringer som er basert på tjenester og funksjoner som organisasjonen har innført for å redusere antall endringer som du må gjøre for å holde deg oppdatert. Vær oppmerksom på Gyldig fra dato i RSS-feeden der endringene er kunngjort og en post med alle tidligere endringer beholdes. IP-adresser som er kunngjort, kan ikke være annonsert eller fjernet fra annonsering, før gyldig-fra-datoen er nådd.

Bygg din distribusjon og dine testingprosedyrer

Implementering av planen bør inneholde både testing og tilbakerullingsplanlegging. Hvis implementeringen ikke fungerer som forventet, bør planen utformes for å påvirke minst mulig antall personer før problemer blir oppdaget. Her er noen høy-nivåprinsipper planen din bør vurdere.

  1. Opprett nettverksegmentet og brukertjenesten for jobbintroduksjonen for å minimere avbrudd.

  2. Plan for testing av ruter med søkerute og TCP-tilkobling fra en separat tilkoblet Internett-vert.

  3. Helst bør testing av innkommende og utgående tjenester gjøres på en isolert test nettverket med en test Office 365-leier.

    • Du kan eventuelt utføre testing på et produksjonsnettverk, hvis kunden ennå ikke bruker Office 365 eller har en pilot.

    • Du kan eventuelt utføre testing i løpet av et produksjonsavbrudd som er satt av bare til test og overvåking.

    • Du kan eventuelt utføre testing ved å merke ruter for hver tjeneste på hvert lag av 3-ruternoden. Dette tilbakesteget bør bare brukes hvis ingen annen testing er mulig, fordi mangel på fysisk testing innebærer risiko.

Dine distribusjonsprosedyrer bør rulles ut til små grupper av personer i faser for testing før du distribuerer til større grupper av personer. Her er flere måter å opprette distribusjonen av ExpressRoute på.

  1. Konfigurer ExpressRoute med Microsoft nettverksnoding og få rute-annonser videresendt til en enkelt vert bare for testingformål.

  2. Annonser ruter til ExpressRoute-nettverket til et enkelt nettverksegment til å begynne med, og utvid ruteannonser etter nettverkssegment eller område.

  3. Hvis du distribuerer Office 365 for første gang, kan du bruke nettverksdistribusjonen for ExpressRoute som en utprøving for et lite antall personer.

  4. Hvis du bruker proxy-servere, kan du også konfigurere en PAC-testfil for å dirigere et lite antall personer til ExpressRoute med testing og tilbakemelding før du legger til mer.

Implementering av planen bør liste hver av de distribusjonsprosedyrene som må utføres, eller kommandoer som trenger å brukes til å distribuere nettverkskonfigurasjonen. Når tiden kommer for nettverksavbruddet, bør alle endringer som blir gjort være fra den skrevne distribusjonsplanen som er skrevet på forhånd og node-gjennomgått. Se vår veiledning for den tekniske konfigurasjonen av ExpressRoute.

  • Hvis du har endret IP-adresser for eventuelle lokale servere som vil fortsette å sende e-post, oppdaterer du SPF TXT-poster.

  • Oppdater DNS-poster for lokale servere hvis du har endret IP-adresser for å gi plass til en ny NAT-konfigurasjon.

  • Forsikre deg om du har abonnert på RSS-feeden for Office 365-endepunktsvarsler for å vedlikeholde ruting- eller proxy-konfigurasjoner.

Prosedyrene i testplan skal utføres etter ExpressRoute distribusjonen er fullført. Resultater for hver prosedyre skal være pålogget. Du må ta fremgangsmåter for å rulle tilbake til det opprinnelige produksjonsmiljøet i tilfelle planen testresultater angir implementeringen ikke var vellykket.

Dine testingsprosedyrer bør inneholde tester for hver utgående og inngående nettverkstjeneste for Office 365, både de som skal bruke ExpressRoute og de som ikke skal det. Fremgangsmåtene bør inneholde testing fra hver unike nettverksplassering, inkludert brukere som ikke er i firmaets lokale nettverk.

Noen eksempler på testaktiviteter omfatter følgende:

  1. Ping fra lokale ruteren til nettverket operatoren ruteren.

  2. Bekreft at de mer enn 500 Office 365- og CRM Online IP-adresseannonsene er mottatt av den lokale ruteren.

  3. Bekreft at din inngående og utgående NAT fungerer mellom ExpressRoute og interne nettverket.

  4. Valider at ruter til NAT blir ved hjelp av fra ruteren.

  5. Bekreft at ExpressRoute har godtatt de annonserte prefiksene.

    • Bruk følgende cmdlet til å kontrollere peering annonser:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. Bekreft at ditt offentlige NAT IP-område ikke er annonsert til Microsoft gjennom annen ExpressRoute- eller offentlig Internett-nettverkskrets, med mindre det er et bestemt delsett av et større område som i forrige eksempel.

  7. ExpressRoute-kretser er sammenkoblet, bekreft at begge BGP-økter kjører.

  8. Konfigurer en enkelt vert på innsiden av NAT, og bruke ping, tracert og tcpping til å teste tilkoblingen på tvers av den nye kretsen til verten outlook.office365.com. Du kan eventuelt bruke et verktøy som Wireshark eller Microsoft Network Monitor 3.4 på en speilet port til MSEE til å bekrefte at du er i stand til å koble til IP-adressen som er forbundet med outlook.office365.com.

  9. Test funksjonaliteten på applikasjonsnivået for Exchange Online.

    • Test at Outlook kan koble til Exchange Online og sende/motta e-post.

    • Test at Outlook kan bruke tilkoblet modus.

    • Test smarttelefon-tilkobling og sende/motta-egenskapen.

  10. Test funksjonaliteten på applikasjonsnivået for SharePoint Online

    • Test synkroniseringsklient for OneDrive for Business.

    • Test nettilgang for SharePoint Online.

  11. Test funksjonaliteten på applikasjonsnivået for anrops-scenarier for Skype for Business:

    • Bli med i telefonkonferanse som godkjent bruker [invitasjon initiert av sluttbruker].

    • Inviter bruker til telefonkonferanse [invitasjon sendt fra MCU].

    • Bli med i konferanse som anonym bruker ved hjelp av nettprogrammet for Skype for Business.

    • Bli med i samtalen fra det PC-tilkobling med kabel, IP-telefon og mobilenhet.

    • Ringe til bruker i forbund o kall til PSTN validering: anrop er fullført, anropskvaliteten kan godtas, godtas tidspunktet for tilkoblingen.

    • Bekreft at tilstedeværelsesstatus for kontakter er oppdatert for begge medlemmer av leieren, og brukere i forbundet.

Asymmetrisk ruting er det vanligste implementeringsproblemet. Her er noen vanlige kilder du bør se etter:

  • Bruke en åpen eller flat topologi for nettverksruting uten at kilde-NAT er på plass.

  • Ikke bruke SNAT til å rute til inngående tjenester både gjennom Internett- og ExpressRoute-tilkoblinger.

  • Ikke tester innkommende tjenester på ExpressRoute på en test nettverket før du distribuerer Generelt.

Distribuere ExpressRoute-tilkobling via nettverket.

Opprette distribusjonen til ett segment av nettverket om gangen, rull gradvis ut tilkoblingen til ulike deler av nettverket med en plan for å rulle tilbake for hvert nye nettverkssegment. Hvis distribusjonen er justert med en Office 365-distribusjon, distribuer til dine Office 365-pilotbrukere først, og utvid derfra.

Først for din test og deretter for produksjon:

  • Kjør distribusjonstrinnene for å aktivere ExpressRoute.

  • Test at du ser de nettverksrutene som er forventet.

  • Utfør testing på hver inngående og utgående tjeneste.

  • Rull tilbake hvis du oppdager eventuelle problemer.

Nå som du har fullført planen på papir, er det på tide å teste i liten skala. I denne testen vil du etablere en enkelt ExpressRoute-tilkobling med Microsoft nettverksnoding til et testdelnett på det lokale nettverket. Du kan konfigurere en prøveversjon av Office 365-leieren med tilkobling til og fra testdelnettet og inkludere alle utgående og inngående tjenester som du skal bruke i produksjon i testdelnettet. Konfigurer DNS for test-nettverkssegmentet og etabler alle inngående og utgående tjenester. Utfør testplanen og forsikre deg om at du er kjent med ruten for hver tjeneste og med ruteoverføringen.

Når du har fullført elementene som er beskrevet ovenfor, kryss av områdene du har fullført og forsikre deg om at du og teamet har gjennomgått dem før du utfører distribusjons- og testingplaner.

  • Liste over utgående og inngående tjenester som er involvert i nettverkesendringen.

  • Globalt nettverksdiagram for arkitektur som viser både utgående trafikk på Internett og ExpressRoute-møt-meg plasseringer.

  • Nettverksrutingdiagram demonstrerer de forskjellige nettverksbaner som brukes for hver distribuerte tjeneste.

  • En distribusjonsplan med trinn for å implementere endringene og tilbakerulling om nødvendig.

  • En testplan for testing av hver Office 365- og nettverkstjeneste.

  • Fullført papirbekreftelse av produksjonsruter for inngående og utgående tjenester.

  • En fullført test på tvers av et testnettverksegment, inkludert testing av tilgjengelighet.

Velg et avbrutt vindu som er langt nok til å kjøre gjennom hele distribusjonsplanen og testplanen, ha litt tilgjengelig tid til feilsøking og tid til å rulle tilbake om nødvendig.

Advarsel: På grunn av rutingens komplekse natur både via Internett og ExpressRoute, anbefales det at mer buffertid legges til dette vinduet for å håndtere feilsøking av kompleks ruting.

QoS er nødvendig å innhente tale- og møtefordeler for Skype for Business Online. Du kan konfigurere QoS etter at du har sikret at nettverkstilkoblingen for ExpressRoute ikke blokkerer noen av de andre Office 365-tjenestetilgangene. Konfigurasjonen for QoS er beskrevet i artikkelen ExpressRoute og QoS i Skype for Business Online .

Feilsøking implementeringen

Det første stedet du bør se på er trinnene i denne implementeringsveiledningen. Ble noe glemt i implementeringsplanen? Gå tilbake og kjør ytterligere testing for små nettverk for om mulig å kopiere feilen og feilsøke den der.

Identifisere hvilke inngående eller utgående tjenester som mislyktes under testingen. Få spesielt tak i IP-adressene og delnettene for hver av tjenestene som mislyktes. Få det topologiske nettverksdiagrammet ned på papiret og bekreft rutingen. Bekreft spesielt hvor ExpressRoute-rutingen er annonsert til, og test den rutingen under avbruddet, om mulig med sporer.

Kjør PSPing med en nettverkssporing til hvert kunde-endepunkt og Vurder kilde- og IP-adresser for å validere at de er som forventet. Kjøre telnet til e-post-vert du eksponere på port 25 og kontroller at SNAT er skjuler den opprinnelige kilde IP-adressen hvis dette er som forventet.

Husk at når du distribuerer Office 365 med en ExpressRoute-tilkobling må du både forsikre deg om nettverkskonfigurasjonen for ExpressRoute er optimalt utformet, og at du har optimalisert de andre komponentene i nettverket, for eksempel klientmaskiner. I tillegg til å bruke denne planleggingsveiledningen for å feilsøke trinne du kan ha glemt, har vi også skrevet en feilsøkingsplan for Office 365 .

Her er en kort kobling du kan bruke til å komme tilbake: https://aka.ms/implementexpressroute365

Beslektede emner

Nettverkstilkobling til Office 365
Azure ExpressRoute for Office 365
Administrere ExpressRoute for Office 365-tilkobling
ruting med ExpressRoute for Office 365
nettverket planlegging med ExpressRoute for Office 365
ved hjelp av BGP fellesskap i ExpressRoute for Office 365-scenarier (forhåndsversjon)
Media kvalitet og nettverksytelsen tilkobling i Skype for Business Online
Optimalisere nettverket for Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
ringe flyt ved hjelp av ExpressRoute
Office 365-ytelsesjustering ved hjelp av referanseverdier og ytelsen loggen
plan for Office 365 for feilsøking av ytelsen
Office 365-nettadresser og IP-adresseområder
Office 365-nettverket og ytelsesjustering

Merknad: Ansvarsfraskrivelse for maskinoversettelse: Denne artikkelen er oversatt av et datasystem i stedet for en oversetter. Microsoft tilbyr disse maskinoversettelsene slik at brukere som ikke snakker engelsk, får tilgang til innhold om Microsoft-produkter, -tjenester og –teknologier. Ettersom artikkelen er maskinoversatt, kan den inneholde feil i vokabular, syntaks eller grammatikk.

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Office Insiders

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×