Implementering af ExpressRoute til Office 365

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

ExpressRoute til Office 365 leverer en alternativ routingsti til mange Office 365-tjenester på internettet. Arkitekturen i ExpressRoute til Office 365 er baseret på annoncering af offentlige IP-præfikser for Office 365-tjenester, der allerede er tilgængelige via internettet, over for dine klargjorte ExpressRoute-kredsløb til efterfølgende videredistribuering af disse IP-præfikser i dit netværk. Med ExpressRoute aktiverer du i realiteten flere forskellige routingstier via internettet og via ExpressRoute til mange Office 365-tjenester. Denne routingtilstand på dit netværk kan betyde en væsentlig ændring af, hvordan din interne netværkstopologi er designet.

Status: Komplet vejledning v2

Du skal nøje planlægge din implementering af ExpressRoute til Office 365 for at imødegå netværkskompleksiteterne i forbindelse med at have routing tilgængelig både via et dedikeret kredsløb med ruter, der tilføjes i kernenetværket og på internettet. Hvis du og dit team ikke udfører den detaljerede planlægning og testning i denne vejledning, er der en høj risiko for, at du vil miste forbindelsen til Office 365-tjenester periodisk eller fuldstændigt, når ExpressRoute-kredsløbet er aktiveret.

For at få en vellykket implementering skal du analysere dine krav til infrastruktur, gennemgå detaljeret netværksvurdering og -design, omhyggeligt planlægge implementeringen i faser og på kontrolleret vis samt opbygge en detaljeret plan for datavalidering og test. For et stort, distribueret miljø er det ikke ualmindeligt, at implementeringen strækker sig over flere måneder. Denne vejledning har til formål at hjælpe dig med at planlægge fremad.

Store vellykkede udrulninger kan tage seks måneders planlægning og omfatter ofte teammedlemmer fra mange områder i organisationen, herunder netværks-, firewall- og proxyserveradministratorer samt hjælp fra Office 365-administratorer, sikkerhedsafdelingen, slutbrugersupport, projektstyring og ledelsen. Din investering i planlægningsprocessen vil reducere sandsynligheden for, at du vil opleve mislykkede installationer, som medfører nedetid eller kompleks og dyr fejlfinding.

Vi forventer, at følgende er på plads, før denne implementeringsvejledning påbegyndes.

  1. Du har gennemført en netværksvurdering for at afgøre, om ExpressRoute er anbefalet og godkendt.

  2. Du har valgt en ExpressRoute-netværkstjenesteudbyder. Få mere at vide om ExpressRoute-partnere og peeringplaceringer.

  3. Du allerede har læst og forstå ExpressRoute dokumentation og dit interne netværk er i stand til at opfylde ExpressRoute forudsætninger start til slut.

  4. Dit team har læst alle offentlige vejledning og dokumentationen på https://aka.ms/expressrouteoffice365, https://aka.ms/ertog set Azure ExpressRoute til Office 365-kurser serien på kanal 9 for at få en forståelse af kritiske tekniske detaljer, herunder:

    • Internettets afhængigheder af SaaS-tjenester.

    • Hvordan man undgår asymmetriske ruter og håndterer kompleks routing.

    • Sådan inkorporere afskærmede sikkerhed, tilgængelighed og programmet niveau kontrolelementer.

Begynd med at indsamle krav

Start med at beslutte, hvilke funktioner og tjenester, du planlægger at indføre inden for organisationen. Du skal beslutte, hvilke funktioner fra de forskellige Office 365-tjenester, der skal bruges, og hvilke placeringer på dit netværk, der skal hoste personer, der bruger disse funktioner. Med kataloget af scenarier skal du tilføje netværksattributter, som hvert af disse scenarier kræver, såsom flows af indgående og udgående netværkstrafik samt hvorvidt Office 365-slutpunkterne er tilgængelige via ExpressRoute eller ej.

Sådan indsamler du organisationens krav:

  • Katalogiser indgående og udgående netværkstrafik for de Office 365-tjenester, din organisation bruger. Se Office 365-webadresser og siden med IP-adresseområder for at få en beskrivelse af flows, som de forskellige Office 365-scenarier kræver.

  • Indsaml dokumentation for eksisterende netværkstopologi, der viser oplysninger om din interne WAN-basis og -topologi, forbindelsen til satellitwebsteder, forbindelsesmuligheder for slutbrugere, routing til perimeternetværks udgangspunkter samt proxytjenester.

    • Identificer indgående tjenesteslutpunkterne på de netværksdiagrammer, som Office 365 og andre Microsoft-tjenester vil oprette forbindelse til, som viser både internetstier og foreslåede ExpressRoute-forbindelsesstier.

    • Identificer alle geografiske brugerplaceringer og WAN-forbindelser mellem placeringer, samt hvilke placeringer der aktuelt har et udgangspunkt til internettet, og hvilke placeringer der foreslås at skulle have et udgangspunkt til en ExpressRoute-peeringplacering.

    • Identificer alle grænseenheder som f.eks. proxyer, firewalls osv. og katalogiser deres relation til flows, der går over internettet og ExpressRoute.

    • Dokumenter, hvorvidt slutbrugere skal have adgang til Office 365-tjenester via direkte routing eller indirekte programproxy for både internet- og ExpressRoute-flows.

  • Føj placeringen af din lejer og meet-me-placeringer til dit netværksdiagram.

  • Anslå de forventede og observerede karakteristikker for netværksydeevne og ventetid fra de største brugerplaceringer for Office 365. Husk på, at Office 365 er et globalt og distribueret sæt af tjenester, og brugerne opretter forbindelse til placeringer, der kan være forskellige fra placeringen af deres lejer. Det anbefales derfor, at måle og optimere for ventetid mellem brugeren og den nærmeste grænse for Microsofts globale netværk via ExpressRoute og internetforbindelser. Du kan bruge dine resultater fra netværksvurderingen til at hjælpe med denne opgave.

  • Opstil krav til virksomhedens netværkssikkerhed og høje tilgængelighed, der skal være opfyldt med den nye ExpressRoute-forbindelse. Eksempelvis hvordan brugerne fortsat skal kunne få adgang til Office 365 i tilfælde af fejl i internetudgangspunktet eller ExpressRoute-kredsløbet.

  • Dokument, hvilket indgående og udgående Office 365 netværk flyder anvender Internet stien, og som anvender ExpressRoute. Specifikke oplysninger af geografiske placeringer af dine brugere og oplysninger i din lokale netværkstopologi kan kræve planen, skal være forskellige fra én brugerplacering til en anden.

For at minimere kompleksiteterne ved routing og andre netværk, anbefaler vi, at du kun bruger ExpressRoute til Office 365 til netværk trafik-flow, der kræves for at gå via en dedikeret forbindelse på grund af lovbestemmelser eller som resultat af netværk vurdering. Derudover anbefaler vi, at du fase omfanget af ExpressRoute routing og tilgang udgående og indgående netværk trafik-flow som forskellige og forskellige faser af projektet implementering. Installer ExpressRoute til Office 365 for kun brugerigangsatte udgående netværk trafik flyder og Forlad indgående netværk trafik flyder på internettet kan hjælpe med at styre stigningen i topologisk kompleksitet og risici i Introduktion til yderligere asymmetrisk routing muligheder.

Dit netværk trafik katalog skal indeholde lister over alle de indgående og udgående netværksforbindelser, du har mellem dit lokale netværk og Microsoft.

  • Udgående netværkstrafikflows er alle scenarier, hvor en forbindelse startes fra dit lokale miljø, f.eks. fra interne klienter eller servere, og destinationen er Microsoft-tjenesterne. Disse forbindelser kan være direkte til Office 365 eller indirekte, f.eks. når forbindelsen går gennem proxyservere, firewalls eller andre netværksenheder på stien til Office 365.

  • Indgående netværkstrafikflows er alle scenarier, hvor en forbindelse startes fra Microsoft-skyen til en vært i det lokale miljø. Disse forbindelser er typisk nødt til at gå gennem firewalls og anden sikkerhedsinfrastruktur, som kræves af kundens sikkerhedspolitik for flows, som kommer udefra.

Læs afsnittet Sikring af rutesymmetri i artiklen Routing med ExpressRoute til Office 365 for at bestemme, hvilke tjenester der sender indgående trafik, og se efter den kolonne, der er markeret ExpressRoute til Office 365, i referenceartiklen Office 365-slutpunkter for at bestemme resten af oplysningerne om forbindelsen.

For hver tjeneste, der kræver en udgående forbindelse, skal du beskrive de planlagte forbindelser for tjenesten, herunder netværksrouting, proxykonfiguration, pakkeinspektion og behov for båndbredde.

For hver tjeneste, der kræver en indgående forbindelse, skal du bruge nogle yderligere oplysninger. Servere i Microsoft-skyen opretter forbindelser til dit netværk i det lokale miljø. For at sikre, at forbindelserne oprettes korrekt, skal du beskrive alle aspekter af denne forbindelse, herunder de offentlige DNS-poster for de tjenester, der accepterer disse indgående forbindelser, de CIDR-formaterede IPv4 IP-adresser, hvilket udstyr fra internetudbyderen, der er involveret, og hvordan indgående NAT eller kilde-NAT håndteres for disse forbindelser.

Indgående forbindelser skal gennemgås, uanset om de opretter forbindelse via internettet eller ExpressRoute, for at sikre at routingen ikke er blevet asymmetrisk. I nogle tilfælde kan der også være behov for, at Microsoft-tjenester og ikke-Microsoft-tjenester kan få adgang til slutpunkter i det lokale miljø, som Office 365-tjenester, opretter indgående forbindelser til. Det er af afgørende betydning, at aktivering af ExpressRoute-routing til disse tjenester for Office 365 ikke ødelægger andre scenarier. I mange tilfælde kan kunderne være nødt til at implementere bestemte ændringer i deres interne netværk, f.eks. kildebaseret NAT, for at sikre, at indgående flows fra Microsoft forbliver symmetriske, når ExpressRoute er aktiveret.

Her er et eksempel på det detaljeniveau, der er påkrævet. I dette tilfælde ville Exchange Hybrid dirigere til det lokale system via ExpressRoute.

Forbindelsesegenskab

Værdi

Retning af netværkstrafik

Indgående

Tjeneste

Exchange Hybrid

Offentligt Office 365-slutpunkt (kilde)

Exchange Online (IP-adresser)

Offentligt slutpunkt i det lokale miljø (destination)

5.5.5.5

Offentlig (internet) DNS-post

Autodiscover.contoso.com

Vil dette slutpunkt i det lokale miljø blive anvendt til andre (ikke Office 365) Microsoft-tjenester

Nej

Vil dette slutpunkt i det lokale miljø blive anvendt af brugere/systemer på internettet

Ja

Interne systemer publiceret via offentlige slutpunkter

Exchange Server-klientadgangsrolle (lokalt miljø) 192.168.101, 192.168.102, 192.168.103

IP-annoncering af det offentlige slutpunkt

Til internet: 5.5.0.0/16

Til ExpressRoute: 5.5.5.0/24

Sikkerhed/perimeterkontrolelementer

Internetsti: DeviceID_002

ExpressRoute sti: DeviceID_003

Høj tilgængelighed

Aktiv/Aktiv på tværs af 2 geo-redundante

ExpressRoute-kredsløb – Chicago og Dallas

Kontrol af stiens symmetri

Metode: NAT fra kilden

Internetsti: kilde NAT indgående forbindelser til 192.168.5.5

ExpressRoute sti: kilde NAT forbindelser til 192.168.1.0 (Chicago) og 192.168.2.0 (Dallas)

Her er et eksempel på en tjeneste, der kun er udgående:

Forbindelsesegenskab

Værdi

Retning af netværkstrafik

Udgående

Tjeneste

SharePoint Online

Slutpunkt i det lokale miljø (kilde)

Bruger arbejdsstation

Offentligt Office 365-slutpunkt (destination)

SharePoint Online (IP-adresser)

Offentlig (internet) DNS-post

*. sharepoint.com (og yderligere FQDN'er)

CDN-henvisninger

cdn.sharepointonline.com (og yderligere FQDN'er) – IP-adresser, der vedligeholdes af CDN-udbydere)

IP-annoncering og NAT i brug

Internetsti/kilde-NAT: 1.1.1.0/24

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

Forbindelsesmetode

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

ExpressRoute: dirigere routing (ingen proxy)

Sikkerhed/perimeterkontrolelementer

Internetsti: DeviceID_002

ExpressRoute sti: DeviceID_003

Høj tilgængelighed

Internetsti: overflødige internet udgangspunkt

ExpressRoute sti: aktive 'varmt kartoffelstivelse' routing på tværs af 2 geografisk overflødige ExpressRoute kredsløb – Chicago og Dallas

Kontrol af stiens symmetri

Metode: kilde NAT for alle forbindelser

Når du forstår tjenesterne og deres tilknyttede netværkstrafikflows, kan du oprette et netværksdiagram, der inkorporerer disse nye krav til netværksmuligheder og viser de ændringer, du skal foretage for at bruge ExpressRoute til Office 365. Dit diagram bør omfatte:

  1. Alle brugerplaceringer, hvor Office 365 og andre tjenester tilgås fra.

  2. Alle internet- og ExpressRoute-udgangspunkter.

  3. Alle udgående og indgående enheder, der administrerer forbindelser ind og ud af netværket, herunder routere, firewalls, programproxyservere og registrering/forhindring af indtrængen.

  4. Interne destinationer for al indgående trafik, f.eks. interne ADFS-servere, der accepterer forbindelser fra proxyservere for ADFS-webprogrammer.

  5. Katalogiser alle IP-undernet, der bliver annonceret

  6. Identificer hver placering, hvorfra folk kan få adgang til Office 365, og angiv de meet me-placeringer, der skal bruges til ExpressRoute.

  7. Placeringer og dele af din interne netværkstopologi, hvor Microsoft IP-præfikser, som er indlært fra ExpressRoute, accepteres, filtreres og overføres til.

  8. Netværkstopologien bør illustrere den geografiske placering af hvert enkelt netværkssegment, og hvordan den opretter forbindelse til Microsoft-netværket over ExpressRoute og/eller internettet.

I nedenstående diagram vises hver placering, hvor personer skal bruge Office 365 fra, sammen med annonceringerne af indgående og udgående routing til Office 365.

ExpressRoute – regionalt geografisk mød-mig

For udgående trafik opretter folk adgang til Office 365 på en af tre måder:

  1. Gennem en meet me-placering i Nordamerika for personer i Californien.

  2. Gennem en meet me-placering i Hongkong for personer i Hongkong.

  3. Via internettet i Bangladesh, hvor der er færre personer og ingen ExpressRoute-kredsløb.

Udgående forbindelser til regionalt diagram

På samme måde returneres indgående netværkstrafik fra Office 365 på en af tre måder:

  1. Gennem en meet me-placering i Nordamerika for personer i Californien.

  2. Gennem en meet me-placering i Hongkong for personer i Hongkong.

  3. Via internettet i Bangladesh, hvor der er færre personer og ingen ExpressRoute-kredsløb.

Indgående forbindelser til regionalt diagram

Valget af meet me-placeringer, som er den fysiske placering, hvor dit ExpressRoute-kredsløb opretter forbindelse til Microsoft-netværket, påvirkes af de placeringer, hvor folk tilgår Office 365 fra. Som et SaaS-tilbud fungerer Office 365 ikke under den regionale IaaS- eller PaaS-model på samme måde, som Azure gør. I stedet er Office 365 et distribueret sæt samarbejdstjenester, hvor brugerne kan være nødt til at oprette forbindelse til slutpunkter på tværs af flere datacentre og områder, som ikke nødvendigvis er på den samme placering eller i det samme område, hvor brugerens lejer er hostet.

Det betyder, at de vigtigste overvejelser, du skal gøre dig, når du vælger meet me-placeringer til ExpressRoute til Office 365, er, hvor personerne i din organisation skal oprette forbindelse fra. Den generelle anbefaling for en optimal Office 365-forbindelse er at implementere routing, så brugerforespørgsler til Office 365-tjenester afleveres til Microsoft-netværket via den korteste netværkssti. Dette kaldes ofte for "hot potato"-routing. Hvis f.eks. de fleste Office 365-brugere er på én eller to placeringer, får du det optimale design, hvis du vælger meet me-placeringer, der findes tættest på disse brugeres placering. Hvis din virksomhed har et stort antal brugere i mange forskellige områder, kan du overveje at have flere ExpressRoute-kredsløb og meet me-placeringer. For nogle af dine brugerplaceringer er den korteste/mest optimale sti til Microsoft-netværket og Office 365 ikke nødvendigvis via dine meet me-punkter i det interne WAN og ExpressRoute, men via internettet.

Ofte er der flere meet me-placeringer, der kan vælges i et område i relativ nærhed til dine brugere. Udfyld følgende tabel for at blive hjulpet på vej med dine beslutninger.

Planlagte meet me-placeringer for ExpressRoute i Californien og New York

Placering

Antal personer

Forventet ventetid til Microsoft-netværk over internetudgangspunkt

Forventet ventetid til Microsoft-netværk over 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 netværksarkitektur, der viser Office 365-området, meet me-placeringer for ExpressRoute-netværkstjenesteudbyder og antallet af personer efter placering er blevet udviklet, kan det bruges til at finde ud af, om der kan udføres nogen optimeringer. Der kan også blive vist globale hairpin-netværksforbindelser, hvor trafik dirigeres til en fjern placering for at få meet me-placeringen. Hvis der opdages en hairpin på det globale netværk, skal dette afhjælpes, før du fortsætter. Find enten en anden meet me-placering, eller brug selektive internetudgangspunkter for at undgå denne hairpin.

Det første diagram viser et eksempel på en kunde med to fysiske placeringer i Nordamerika. Du kan se oplysningerne om kontoradresser, Office 365-lejerplaceringer og flere valgmuligheder for meet me-placeringer for ExpressRoute. I dette eksempel har kunden valgt meet me-placeringen baseret på to principper i rækkefølgen:

  1. Nærmeste afstand til personer i organisationen.

  2. Nærmeste i nærheden af en Microsoft-datacenter, hvor Office 365 er hostet.

ExpressRoute – Amerikansk geografisk mød-mig

Hvis dette koncept udvides en smule, viser det andet diagram et eksempel på en multinational kunde, som står over for lignende oplysninger og beslutninger. Denne kunde har et lille kontor i Bangladesh med et team bestående af ti personer, som har fokus på at blive større i deres område. Der er en Meet me-placering i Chennai og et Microsoft-datacenter med Office 365 hostet i Chennai, så det vil give mening at have en meet me-placering. Dog er de forholdsmæssige omkostninger til det ekstra kredsløb for stor en byrde, når de kun er ti personer. Når du ser på dit netværk, skal du afgøre, om ventetiden, der er involveret i forbindelse med at sende din netværkstrafik på tværs af netværket, er mere effektiv end at skulle bruge kapital på at få endnu et ExpressRoute-kredsløb.

Alternativt kan ti personer i Bangladesh opleve bedre ydeevne, når deres netværkstrafik sendes via internettet til Microsoft-netværket, end de ville ved routing på deres eget interne netværk, sådan som det også er vist i de indledningsvise diagrammer og er gengivet nedenfor.

Udgående forbindelser til regionalt diagram

Opret din implementeringsplan for ExpressRoute til Office 365

Din implementeringsplan bør omfatte både de tekniske detaljer til konfiguration af ExpressRoute samt detaljer om konfiguration af al anden infrastruktur på dit netværk, f.eks. følgende.

  • Planlæg, hvilke tjenester der er delt mellem ExpressRoute og internettet.

  • Planlæg båndbredde, sikkerhed, høj tilgængelighed og failover.

  • Design indgående og udgående routing, herunder de rette optimeringer af routingstier for forskellige placeringer

  • Beslut, hvor langt ExpressRoute-ruter skal annonceres ind i dit netværk, og hvad mekanismer er for kunderne til at vælge stier via internettet eller ExpressRoute, f.eks. direkte routing eller programproxy.

  • Planlæg DNS-postændringer, herunder SPF (Sender Policy Framework)-poster.

  • Planlægge NAT strategi, herunder udgående og indgående kilde NAT.

  • Ved installationsstart anbefales det at alle indgående tjenester, f.eks. indgående mail eller hybridforbindelser, benytter internettet.

  • Planlægge slutbrugerens klient LAN-routing, som konfigurerer filen PAC/WPAD, standardrute, proxyservere og BGP distribuere reklamer.

  • Planlæg perimeterrouting, herunder proxyservere, firewalls og skyproxyer.

Opret en plan til båndbredde, der kræves for hver større Office 365-arbejdsbyrde. Estimer kravene til båndbredde for Exchange Online, SharePoint Online og Skype for Business Online separat. Du kan bruge de programmer til beregning af skøn, vi har leveret til Exchange Online og Skype for Business, som et udgangspunkt, men der kræves en egentlig prøvekørsel med en repræsentativ prøve af brugerprofiler og placeringer for fuldt ud at forstå organisationens behov for båndbredde.

Tilføj i planen, hvordan sikkerhed håndteres på hver internet- og ExpressRoute-udgangsplacering. Husk, at alle ExpressRoute-forbindelser til Office 365 benytter offentlig peering og stadig skal være sikret i overensstemmelse med din virksomheds sikkerhedspolitikker for oprettelse af forbindelse til eksterne netværk.

Føj detaljer til din plan om, hvilke personer der påvirkes af hvilken type udfald, og hvordan disse personer på nemmeste vis vil kunne udføre deres arbejde for fuld kapacitet.

Planlæg krav til båndbredde, herunder Skype for Business-krav, m.h.t. rysten, ventetid, overbelastning og margin

Skype for Business Online har også bestemte yderligere netværkskrav, som er beskrevet i artiklen Mediekvalitet og ydeevne for netværksforbindelse i Skype for Business Online.

Læs afsnittet Planlægning af båndbredde for Azure ExpressRoute i Netværksplanlægning med ExpressRoute til Office 365.

Når du udfører en båndbreddevurdering med dine pilotbrugere, kan du bruge vores vejledning Justering af ydeevnen for Office 365 vha. grundlinjer og ydeevnehistorik.

Tag krav til høj tilgængelighed med i planlægningen

Opret en plan for høj tilgængelighed, der opfylder dine behov, og inkorporer dette i dit opdaterede diagram over netværkets topologi. Læs afsnittet Høj tilgængelighed og failover med Azure ExpressRoute i Netværksplanlægning med ExpressRoute til Office 365.

Planlægge i forhold til netværk sikkerhedskrav

Opret en plan, der opfylder kravene til høj tilgængelighed, og inkorporer dette i dit opdaterede diagram over netværkets topologi. Læs afsnittet Anvende sikkerhedskontrolelementer på Azure ExpressRoute til Office 365-scenarier i Netværksplanlægning med ExpressRoute til Office 365.

ExpressRoute til Office 365 har krav til udgående netværk, som der måske ikke er kendskab til. Specifikt skal de IP-adresser, der repræsenterer dine brugere og dit netværk for Office 365 og fungerer som kildeslutpunkterne for udgående netværksforbindelser til Microsoft, følge specifikke krav, der er beskrevet nedenfor.

  1. Slutpunkterne skal være offentlige IP-adresser, der er registreret for din virksomhed eller en udbyder, der leverer ExpressRoute-forbindelsen til dig.

  2. Slutpunkterne skal annonceres over for Microsoft og bekræftes/accepteres af ExpressRoute.

  3. Slutpunkterne må ikke annonceres over for internettet med den samme eller en foretrukken routingmetric.

  4. Slutpunkterne må bruges til forbindelsen til Microsoft-tjenester, der ikke er konfigureret over ExpressRoute.

Hvis dit netværksdesign ikke opfylder disse krav, er der en høj risiko for, at brugerne vil opleve forbindelsesfejl i Office 365 og andre Microsoft-tjenester på grund af sorte huller i routingen eller asymmetrisk routing. Dette sker, når anmodninger om Microsoft-tjenester routes over ExpressRoute, men svarene sendes tilbage via internettet eller omvendt, og svarene afbrydes af enheder med høj netværkssikkerhed som f.eks firewalls.

Den mest almindelige metode, du kan bruge til at opfylde ovenstående krav, er at bruge kilde-NAT, enten implementeret som en del af dit netværk eller leveret af din ExpressRoute-udbyder. Kilde-NAT gør det muligt at udtrække detaljerne og de private IP-adresser fra dit internetnetværk fra ExpressRoute og, i kombination med den rette IP-ruteannoncering, giver det nem mulighed for at sikre symmetri i stierne. Hvis du bruger sikkerhedsnetværksenheder, der er specifikke for ExpressRoute-peeringplaceringer, skal du implementere separate NAT-puljer for hver ExpressRoute-peering for at sikre symmetri i stierne.

Læs mere om ExpressRoute NAT-kravene.

Føj ændringerne for udgående forbindelser til diagrammet over netværkets topologi.

Størstedelen af Office 365-installationer til virksomheder antager en form for indgående forbindelse fra Office 365 til tjenester i det lokale miljø, f.eks. for hybride Exchange-, SharePoint- og Skype for Business-scenarier, postkasseoverførsler og godkendelse, der benytter ADFS-infrastruktur. Når du med ExpressRoute aktiverer en ekstra routingsti mellem dit netværk i det lokale miljø og Microsoft til udgående forbindelse, kan disse indgående forbindelser ved et uheld blive påvirket af asymmetrisk routing, også selvom du regner med at få disse strømme til at fortsætte vha. internettet. Nogle få forholdsregler, som er beskrevet nedenfor, anbefales for at sikre, at der ikke er nogen indvirkning på indgående internetbaserede flows fra Office 365 til systemer i det lokale miljø.

For at minimere risikoen for asymmetrisk routing for indgående netværkstrafikflows bør alle de indgående forbindelser benytte kilde-NAT, før de distribueres i segmenter af dit netværk, hvor der er routingsynlighed i ExpressRoute. Hvis de indgående forbindelser er tilladt i et netværkssegment med routingsynlighed i ExpressRoute uden kilde-NAT, vil anmodninger, der stammer fra Office 365, komme ind fra internettet, men det svar, der går tilbage til Office 365, vil foretrække ExpressRoute-netværksstien tilbage til Microsoft-netværket, hvilket medfører asymmetrisk routing.

Du kan overveje en af følgende implementeringsmønstre for at opfylde dette krav:

  1. Udfør kilde-NAT, før anmodninger routes til dit interne netværk ved hjælp af netværksudstyr til justering af belastning eller firewalls, på stien fra internettet til dine lokale systemer.

  2. Sørg for, at ExpressRoute-ruter ikke overføres til de netværkssegmenter, hvor indgående tjenester som f.eks. front-end-servere eller omvendte proxysystemer, der håndterer internetforbindelser, er placeret.

Hvis du specifikt tager højde for disse scenarier i dit netværk og holder alle indgående netværkstrafikflows på internettet, hjælper det dig med at minimere risikoen for asymmetrisk routing i forbindelse med udrulning eller driften.

Der kan være tilfælde, hvor du kan vælge at dirigere nogle indgående flows over ExpressRoute-forbindelser. For disse scenarier skal du tage følgende yderligere faktorer med i dine overvejelser.

  1. Office 365 kan kun målrette mod slutpunkter i det lokale miljø, som benytter offentlige IP-adresser. Det betyder, at selvom det indgående slutpunkt i det lokale miljø kun blotlægges for Office 365 via ExpressRoute, skal det stadig have den offentlige IP-adresse knyttet til sig.

  2. Alle fortolkninger af DNS-navne, som Office 365-tjenester udfører for at oversætte disse lokale slutpunkter, sker ved hjælp af offentlig DNS. Dette betyder, at du skal registrere indgående tjenesteslutpunkters FQDN IP-tilknytninger på internettet.

  3. For at kunne modtage indgående netværksforbindelser over ExpressRoute skal de offentlige IP-undernet for disse slutpunkter annonceres over for Microsoft over ExpressRoute.

  4. Evaluer omhyggeligt disse indgående netværkstrafikflows for at sikre, at de rette sikkerheds- og netværkskontrolelementer anvendes på dem i overensstemmelse din virksomheds sikkerheds- og netværkspolitikker.

  5. Når dine indgående slutpunkter i det lokale miljø annonceres over for Microsoft via ExpressRoute, bliver ExpressRoute den foretrukne routingsti til disse slutpunkter for alle Microsoft-tjenester, herunder Office 365. Det betyder, at disse slutpunktsundernet kun må bruges til kommunikation med Office 365-tjenester og ingen andre tjenester på Microsoft-netværket. Ellers vil dit design medføre asymmetrisk routing, hvor indgående forbindelser fra andre Microsoft-tjenester foretrækker at route indgående over ExpressRoute, mens returstien bruger internettet.

  6. I tilfælde af at et ExpressRoute-kredsløb eller en meet me-placering er nede, skal du sikre, at indgående slutpunkter i det lokale miljø stadig er tilgængelige med henblik på at acceptere anmodninger over en separat netværkssti. Det kan betyde annoncering af undernet for disse slutpunkter gennem flere ExpressRoute-kredsløb.

  7. Vi anbefaler at anvende kilde-NAT til alle indgående netværkstrafikflow, de kommer ind på dit netværk gennem ExpressRoute, især når flows skal igennem netværksenheder som f.eks. firewalls.

  8. Nogle tjenester i det lokale miljø, f.eks. ADFS-proxy eller Exchange Autodiscover, modtager muligvis indgående anmodninger fra både Office 365-tjenester og brugere fra internettet. For disse anmodninger målretter Office 365 det samme FQDN som brugerforespørgsler via internettet. Hvis du tillader indgående brugerforbindelser fra internettet til disse slutpunkter i det lokale miljø, mens du tvinger Office 365-forbindelser til at bruge ExpressRoute, udgør dette en betydelig routingkompleksitet. For størstedelen af kunder, der implementerer, anbefales et sådant komplekst scenarie over ExpressRoute ikke på grund af driftsmæssige hensyn. Disse ekstra omkostninger omfatter administration af risici ved asymmetrisk routing og kræver, at du nøje administrerer annoncering af og politikker for routing på tværs af flere dimensioner.

Du bør undgå asymmetrisk routing for at sikre, at personer i organisationen uden problemer kan bruge Office 365 samt andre vigtige tjenester på internettet. Der er to almindelige konfigurationer, som kunderne har, der medfører asymmetrisk routing. Nu er et godt tidspunkt at gennemgå den netværkskonfiguration, du planlægger at bruge, samt at kontrollere om et af disse scenarier med asymmetrisk routing findes.

Til at begynde med vil vi undersøge et par forskellige situationer, der er knyttet til følgende netværksdiagram. I dette diagram befinder alle servere, der modtager indgående anmodninger, f.eks. ADFS eller lokale hybridservere, sig i datacenteret i New Jersey og annonceres over for internettet.

  1. Mens perimeternetværket er sikkert, findes der ingen kilde-NAT til indgående anmodninger.

  2. Serverne i datacenteret i New Jersey kan se både internet- og ExpressRoute-ruter.

ExpressRoute – forbindelsesoversigt

Vi har også forslag til, hvordan du løser dem.

Problem 1: Forbindelse fra sky til lokalt miljø over internettet

Følgende diagram illustrerer den asymmetriske netværkssti, der tages, når din netværkskonfiguration ikke leverer NAT ved indgående anmodninger fra Microsoft-skyen via internettet.

  1. Den indgående anmodning fra Office 365 henter IP-adressen på slutpunktet i det lokale miljø fra offentlig DNS og sender anmodningen til dit perimeternetværk.

  2. I denne fejlbehæftede konfiguration, er der ikke nogen kilde-NAT konfigureret eller tilgængelig på perimeternetværket, hvor trafikken sendes til, hvilket medfører, at den faktiske kilde-IP-adresse bruges som returdestination.

    • Serveren på dit netværk ruter returtrafikken til Office 365 via en hvilken som helst tilgængelig ExpressRoute-netværksforbindelse.

    • Resultatet er en asymmetrisk sti for det pågældende flow til Office 365, hvilket resulterer i en ødelagt forbindelse.

ExpressRoute asymmetrisk routing – problem 1

Løsning 1a: Kilde-NAT

Hvis du blot føjer en kilde-NAT til den indgående anmodning, løses problemet med dette forkert konfigurerede netværk. I dette diagram:

  1. Den indgående anmodning fortsætter med at komme ind gennem New Jersey-datacenterets perimeternetværk. Denne gang er kilde-NAT tilgængelig.

  2. Svaret fra serveren rutes tilbage mod den IP-adresse, der er knyttet til den pågældende kilde-NAT, i stedet for den oprindelige IP-adresse, hvilket medfører, at svaret returneres langs den samme netværkssti.

ExpressRoute asymmetrisk routing – løsning 1

Løsning 1b: Styring af routing

Alternativt kan du vælge ikke at tillade, at ExpressRoute BGP-præfikser annonceres, hvilket fjerner den alternative netværkssti for disse computere. I dette diagram:

  1. Den indgående anmodning fortsætter med at komme ind gennem New Jersey-datacenterets perimeternetværk. Denne gang er de præfikser, der annonceres fra Microsoft via ExpressRoute-kredsløbet, ikke tilgængelige for New Jersey-datacenteret.

  2. Svaret fra serveren routes tilbage mod den IP-adresse, der er knyttet til den oprindelige IP-adresse via den eneste tilgængelige rute, hvilket medfører, at svaret returneres langs den samme netværkssti.

ExpressRoute asymmetrisk routing – løsning 2

Problem 2: Forbindelse fra sky til lokalt miljø over ExpressRoute

Følgende diagram illustrerer den asymmetriske netværkssti, der tages, når din netværkskonfiguration ikke leverer NAT ved indgående anmodninger fra Microsoft-skyen via ExpressRoute.

  1. Den indgående anmodning fra Office 365 henter IP-adressen fra DNS og sender anmodningen til dit perimeternetværk.

  2. I denne fejlbehæftede konfiguration, er der ikke nogen kilde-NAT konfigureret eller tilgængelig på perimeternetværket, hvor trafikken sendes til, hvilket medfører, at den faktiske kilde-IP-adresse bruges som returdestination.

    • Computeren på dit netværk ruter returtrafikken til Office 365 gennem en hvilken som helst tilgængelig ExpressRoute-netværksforbindelse.

    • Resultatet er en asymmetrisk forbindelse til Office 365.

ExpressRoute asymmetrisk routing – problem 2

Løsning 2: Kilde-NAT

Hvis du blot føjer en kilde-NAT til den indgående anmodning, løses problemet med dette forkert konfigurerede netværk. I dette diagram:

  1. Den indgående anmodning fortsætter med at komme ind gennem New York-datacenterets perimeternetværk. Denne gang er kilde-NAT tilgængelig.

  2. Svaret fra serveren rutes tilbage mod den IP-adresse, der er knyttet til den pågældende kilde-NAT, i stedet for den oprindelige IP-adresse, hvilket medfører, at svaret returneres langs den samme netværkssti.

ExpressRoute asymmetrisk routing – løsning 3

Kontroller på papir, at der er symmetri på netværksdesignets sti

På dette tidspunkt skal du kontrollere på papir, at din implementeringsplan har rutesymmetri for de forskellige scenarier, som du skal bruge Office 365 i. Du kan identificere den bestemte netværksrute, der forventes at blive taget, når en person bruger forskellige funktioner i tjenesten. Fra det lokale netværk og WAN-routing til perimeterenhederne til forbindelsesstien; ExpressRoute eller internettet, og videre til forbindelsen til online slutpunktet.

Du skal gøre dette for alle de Office 365-netværkstjenester, der tidligere blev identificeret som tjenester, din organisation vil indføre.

Det hjælper at foretage denne gennemgang af ruter på papir sammen med en anden person. Forklar vedkommende, hvor hvert netværkshop forventes at få sin næste rute fra, og sørg for, at du er bekendt med routingstierne. Husk, at ExpressRoute altid leverer en mere begrænset rute til Microsoft-servernes IP-adresser for at give lavere omkostninger til routing end en standardrute over internettet.

Udformning af konfiguration af klientforbindelse

Bruge PAC-filer med ExpressRoute

Hvis du bruger en proxyserver til internet bundet trafik, og du vil justere en hvilken som helst PAC eller klient konfigurationsfiler til at sikre klientcomputere på dit netværk er korrekt konfigureret til at sende ExpressRoute trafikken ønskede til Office 365 uden anbringes din proxyserver, og den resterende trafik, herunder nogle Office 365-trafik, der sendes til de relevante proxy. Læs vores vejledning under Administration af Office 365 slutpunkter for eksempel PAC-filer.

Bemærk: Slutpunkterne ændres ofte, så ofte som hver uge. Du bør kun foretage ændringer, der er baseret på de tjenester og funktioner, som din organisation har indført, for at reducere antallet af ændringer, du skal foretage for at holde dig opdateret. Vær opmærksom på Ikrafttrædelsesdato i det RSS-feed, hvor ændringerne offentliggøres, og hvor alle tidligere ændringer er registreret. IP-adresser der offentliggøres, annonceres muligvis ikke, eller de fjernes fra annonceringen, indtil ikrafttrædelsesdatoen er nået.

Opbyg dine udrulnings- og testprocedurer

Din implementeringsplan bør omfatte planlægning for både testing og annullering af opdatering. Hvis implementeringen ikke fungerer som forventet, skal planen være designet til at påvirke det mindst mulige antal personer, indtil problemerne opdages. De følgende er nogle principper på højt niveau, som din plan bør tage højde for.

  1. Inddel onboarding af brugertjenester og netværkssegment i faser for at minimere forstyrrelser.

  2. Planlæg test af ruter med traceroute og TCP-forbindelse fra en separat internetforbundet vært.

  3. Test af indgående og udgående tjenester skal helst, udføres på et netværk med isolerede test med en test Office 365-lejer.

    • Alternativt kan test udføres på et produktionsnetværk, hvis kunden endnu ikke bruger Office 365 eller deltager i et pilotprojekt.

    • Alternativt kan der udføres test i forbindelse med en driftsafbrydelse, som udelukkende er forbeholdt test og overvågning.

    • Alternativt kan der udføres test ved at kontrollere ruter for hver tjeneste i hver layer 3-routernode. Dette fallback bør kun bruges, hvis ingen anden test er mulig, da manglende fysiske tests introducerer risici.

Dine installationsprocedurer skal udrulles til mindre grupper af personer i faser, så det er muligt af udføre tests, før der udrulles til større grupper af personer. Herunder finder du flere metoder til at forberede udrulningen af ExpressRoute.

  1. Konfigurer ExpressRoute med Microsoft-peering, og få ruteannonceringerne videresendt til en enkelt vært udelukkende til faseinddelt testning.

  2. Annoncer ruter over for ExpressRoute-netværket til et enkelt netværkssegment til at starte med, og udvid ruteannonceringer efter netværkssegment eller område.

  3. Hvis du installerer Office 365 for første gang, skal du bruge ExpressRoute-netværksinstallation som et pilotprojekt for et lille antal brugere.

  4. Hvis du bruger proxyservere, kan du også konfigurere en PAC-testfil til at dirigere et lille antal personer til ExpressRoute med test og feedback, før du tilføjer flere.

Din implementeringsplan bør opstille hver enkelt af de installationsprocedurer, der skal følges, eller kommadoer, der skal bruges til at udrulle netværkskonfigurationen. Når tidspunktet for netværkets nedetid kommer, skal alle ændringerne fortages ud fra den nedskrevne implementeringsplan, som blev udarbejdet på forhånd og er blevet gennemgået af peers. Se vores vejledning til teknisk konfiguration af ExpressRoute.

  • Opdater dine SPF TXT-poster, hvis du har ændret IP-adresser for eventuelle lokale servere, som fortsætter med at sende mails.

  • Opdater eventuelle DNS-poster for lokale servere, hvis du har ændret IP-adresser for at give mulighed for en ny NAT-konfiguration.

  • Sørg for, at du abonnerer på RSS-feedet for Office 365-slutpunktsmeddelelser for at bevare eventuelle routing- eller proxykonfigurationer.

Fremgangsmåderne i testplanen skal udføres, når ExpressRoute installationen er fuldført. Resultater for hver procedure skal være logget. Du skal medtage procedurerne for at gå tilbage til den oprindelige produktionsmiljø i tilfælde af, at planlægge testresultater angiver implementeringen ikke blev fuldført.

Dine testprocedurer skal omfatte tests af hver enkelt udgående og indgående netværkstjeneste til Office 365 – både dem, der anvender ExpressRoute, og dem, der ikke gør. Procedurerne bør omfatte test fra hver entydige netværksplacering, herunder brugere, som ikke befinder sig lokalt i virksomhedens LAN.

Her er nogle eksempler på testaktiviteter.

  1. Ping fra din lokale router til dit netværk operator router.

  2. Valider, at der modtages flere end 500 annonceringer af Office 365- og CRM Online IP-adresser af routeren i det lokale miljø.

  3. Valider, at din indgående og udgående NAT fungerer mellem ExpressRoute og det interne netværk.

  4. Valider, omdirigerer til din NAT der meddeles fra din router.

  5. Valider, at ExpressRoute har accepteret dine annoncerede præfikser.

    • Brug følgende cmdlet til at bekræfte peering reklamer:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. Valider, at IP-området for din offentlige NAT ikke annonceres over for Microsoft via andre ExpressRoute-kredsløb eller kredsløb via offentlige internetnetværk, medmindre det er et specifikt delsæt af et større område som i det forrige eksempel.

  7. ExpressRoute-kredsløb parres, og du skal kontrollere, at begge BGP-sessioner kører.

  8. Konfigurer en enkelt vært inde i din NAT, og brug ping, tracert og tcpping til at teste forbindelsen på tværs af de nye kredsløb til værten outlook.office365.com. Alternativt kan du bruge et værktøj som f.eks. Wireshark eller Microsoft Network Monitor 3.4 på en spejlet port til MSEE til at validere, at du er i stand til at oprette forbindelse til den IP-adresse, der er knyttet til outlook.office365.com.

  9. Test funktionalitet på programniveau for Exchange Online.

    • Testversionen af Outlook kan oprette forbindelse til Exchange Online og sende/modtage mail.

    • Testversionen af Outlook kan anvende onlinetilstand.

    • Test af smartphoneforbindelse og send/modtag-funktion.

  10. Test af funktionalitet på programniveau for SharePoint Online.

    • Test af synkroniseringsklient til OneDrive for Business.

    • Test af webadgang til SharePoint Online.

  11. Test af funktionalitet på programniveau for Skype for Business-opkaldsscenarier:

    • Deltag i telefonmøde som godkendt bruger [indkaldelse påbegyndt af slutbruger].

    • Indkald brugere til telefonmøde [indkaldelse sendt fra MCU].

    • Deltag i telefonmøde som anonym bruger ved hjælp af Skype for Business-webprogrammet.

    • Deltag i opkald fra din pc-kabelforbindelse, IP-telefon og mobilenhed.

    • Ringe til medlem af organisationsnetværket bruger o opkaldet til PSTN validering: opkaldet er afsluttet, opkaldskvaliteten kan accepteres, blev oprettet forbindelse kan accepteres.

    • Bekræft, at kontaktens tilstedeværelsesstatus opdateres for begge medlemmer af lejeren og brugere i organisationsnetværket.

Asymmetrisk routing er det mest almindelige problem i forbindelse med implementering. Her er nogle almindelige kilder at holde øje med:

  • Brug af en åben eller flad routingtopologi uden kilde-NAT implementeret.

  • Manglende brug af SNAT til routing af indgående tjenester for både internet- og ExpressRoute-forbindelser.

  • Test ikke indgående tjenester på ExpressRoute på en test netværk før du anvender bredt.

Udrulning af ExpressRoute-forbindelse gennem dit netværk

Forbered din installation på ét segment af netværket ad gangen, og udrul gradvist forbindelsen til forskellige dele af netværket med en plan for at annullere hvert nye netværkssegment. Hvis din udrulning er justeret med en Office 365-installation, skal du starte med at udrulle for dine Office 365-pilotbrugere og senere udvide derfra.

Først for din test og derefter for produktionen:

  • Kør udrulningstrinnene for at aktivere ExpressRoute.

  • Kontroller, at netværksruterne ser ud som forventet.

  • Udfør tests på hver enkelt indgående og udgående tjeneste.

  • Annuller opdateringen, hvis du opdager problemer.

Nu hvor du har gennemført planen på papir, er det tid til at teste i mindre omfang. I denne test skal du oprette en enkelt ExpressRoute-forbindelse med Microsoft Peering til et testundernet på dit lokale netværk. Du kan konfigurere en prøveversion af en Office 365-lejer med forbindelse til og fra testundernettet og medtage alle udgående og indgående tjenester, som du skal bruge i produktionen, i testundernettet. Konfigurer DNS for testnetværkssegmentet og opret alle indgående og udgående tjenester. Udfør din testplan, og sørg for, at du er bekendt med routingen og ruteoverførslen for hver af tjenesterne.

Når du har gennemført ovenstående elementer, skal du afkrydse de fuldførte områder og sikre, at du og dine teammedlemmer har gennemført dem, før du udfører dine udrulnings- og testplaner.

  • Lav en liste over udgående og indgående tjenester, der er involveret i netværksændringen.

  • Diagram over global netværksarkitektur, der viser både internetudgangspunkter og meet me-placeringer for ExpressRoute.

  • Routingnetværksdiagram viser de forskellige netværksstier, der bruges til hver tjeneste, der er installeret.

  • En udrulningsplan med trin til at implementere ændringer samt annullering, hvis det er nødvendigt.

  • En testplan til test af hver Office 365-tjeneste og netværkstjeneste.

  • Fuldført papirvalidering af produktionsruter for indgående og udgående tjenester.

  • En gennemført test på tværs af et testnetværkssegment, herunder tilgængelighedstest.

Vælg et afbrydelsesinterval, der er langt nok til at køre gennem hele udrulningsplanen og testplanen, har noget tid afsat til fejlfinding og tid til annullering, hvis det er nødvendigt.

Advarsel: På grund af routingens komplekse karakter både via internettet og ExpressRoute anbefales det at føje yderligere buffertid til dette tidsinterval til håndtering af fejlfinding i forbindelse med kompleks routing.

Tjenestekvaliteten (QoS) er afgørende for at få fordel af tale og møder i Skype for Business Online. Du kan konfigurere tjenestekvalitet (QoS), når du har sikret dig, at ExpressRoute-netværksforbindelsen ikke blokerer adgangen til nogen af dine andre Office 365-tjenester. Konfiguration af tjenestekvalitet (QoS) er beskrevet i artiklen ExpressRoute og QoS i Skype for Business Online.

Fejlfinding i forbindelse med implementeringen

Det første sted at lede er i trinnene i denne implementeringsvejledning. Er der blevet sprunget nogen over i din implementeringsplan? Gå tilbage og kør yderligere test i et mindre netværk, hvis det er muligt, for at genskabe fejlen, og foretag fejlfinding af fejlen der.

Identificer, hvilke indgående eller udgående tjenester, der mislykkedes under testen. Få specifikke IP-adresser og undernet for hver af de tjenester, der opstod fejl i. Gå videre og gennemgå diagrammet over netværkstopologien på papir, og valider routingen. Valider specifikt, hvor ExpressRoute-routingen annonceres til, test denne routing under afbrydelsen – om muligt med sporing.

Kør PSPing med en netværkssporing til hver kunde slutpunkt og Evaluer kilde- og IP-adresser for at kontrollere, at de er som forventet. Køre telnet til en hvilken som helst mail-udbyder, som du fremvise på port 25 og bekræfte, at SNAT skjule den oprindelige kilde-IP-adresse, hvis det forventes.

Husk, at mens du installerer Office 365 med en ExpressRoute-forbindelse, skal du både sikre dig, at netværkskonfigurationen for ExpressRoute er designet optimalt, og at du også har optimeret de andre komponenter på dit netværk, f.eks. klientcomputere. Foruden denne planlægningsvejledning til at foretage fejlfinding af de trin, du måske har overset, har vi også skrevet en guide til Fejlfinding af ydeevne i forbindelse med planen for Office 365.

Her er et kort link, du kan bruge til at komme tilbage: https://aka.ms/implementexpressroute365

Relaterede emner

Netværk forbindelse til Office 365
Azure ExpressRoute til Office 365
Administrere ExpressRoute til Office 365 connectivity
Routing med ExpressRoute til Office 365
netværksplanlægning med ExpressRoute til Office 365
ved hjælp af BGP community'er i ExpressRoute til Office 365-scenarier (preview)
Media kvaliteten og netværk Connectivity ydeevnen i Skype for Business Online
optimering af dit netværk til Skype for Business Online
ExpressRoute og QoS i Skype for Business Online
ringe flow ved hjælp af ExpressRoute
justering af ydeevnen i Office 365 ved hjælp af grundlinjer og ydeevne historik
ydeevne Fejlfinding i forbindelse med planen for Office 365
Office 365 URL-adresser og IP-adresseområder
Office 365 Netværks- og justering af ydeevnen

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

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

Var disse oplysninger nyttige?

Tak for din feedback!

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

×