Outlook 2016 implementering av Autosøk

Sammendrag

Autosøk er funksjonen som Outlook til å hente konfigurasjonsinformasjon for servere den kobler til. I Outlook 2016 med Exchange-servere regnes Autosøk som det eneste punktet i sannhet for konfigurasjonsinformasjon og må konfigureres og fungere riktig for at Outlook skal fungere fullstendig. Denne artikkelen beskriver implementeringen av Autosøk i den gjeldende kanalen Klikk og bruk-utgivelsen av Outlook 2016. Hvis du vil ha mer informasjon om Office 365 klientkanalutgivelser, kan du se følgende Microsoft-nettsteder:

Versjons- og byggnumre for utgivelser av oppdateringskanaler for Office 365 klienter

Office 365 utgivelser av klientoppdateringskanaler

Mer informasjon

Tidsberegning for autosøk

Autosøk kjører på følgende tidspunkt:

Under oppretting av konto.
Med angitte intervaller for å samle inn endringer i nettadresser som gir Exchange webtjenestefunksjoner (OOF, Tilgjengelighetstjeneste og så videre). Hvis denne prosessen er vellykket, utføres et nytt forsøk én time senere. Hvis forsøket ikke lykkes, gjøres neste forsøk fem minutter senere. Hvert forsøk kan potensielt bli forskjøvet med så mye som 25 prosent på grunn av infrastrukturen for bakgrunnsoppgaver som brukes av alle Microsoft Office programmer.
Som svar på visse tilkoblingsfeil. Når et tilkoblingsforsøk mislykkes i ulike scenarioer, starter Outlook en autosøkoppgave for å hente nye innstillinger i ethvert forsøk på å løse tilkoblingsproblemet.
Når et annet program starter det ved hjelp av MAPI. Hvis du vil ha mer informasjon om MAPI, kan du se følgende MSDN-artikkel: Outlook MAPI Reference.

Autosøkeffektivitet

Bruk UPN (User Principal Name) til å fremskynde Autosøk-prosessen.

På en domenekrets datamaskin må Outlook å kjenne UPN for en bruker for å starte Autosøk-prosessen. UPN-en kan ha blitt brukt til å logge på Windows, og Outlook har direkte tilgang til UPN fra påloggingslegitimasjonen. Men hvis en bruker bruker domene\brukernavn til å logge Windows, Outlook bare den samme legitimasjonen for brukeren. Hvis du vil hente UPN, må Outlook først slå opp brukeren i katalogen. Outlook vil be om at dette oppslaget skal forfølge henvisninger. I komplekse miljøer kan dette føre til at et stort antall DCer kontaktes før et resultat blir funnet. Når Outlook oppdager UPN for brukeren, bufres verdien i profilen, og oppslaget skal ikke skje igjen for denne brukeren.

For å unngå dette scenarioet kan brukeren logge på ved hjelp av et UPN-navn i stedet for domene\brukernavn.

ITAR-hensyn

Microsoft Office 365 inneholder funksjoner som kan støtte kunder med ITAR-forpliktelser. I sammenheng med Autosøk-funksjonen i Outlook inneholder dette funksjonssettet policyinnstillinger og virkemåte som sikrer at tjenesteendepunktene som brukes for Autosøk, overholder suverene skykrav. I de Office 365 trinnene som er oppført i Autosøk-prosessen ( trinn 4 og trinn 11), er policykontroll tilgjengelig for å sikre at riktige tjenesteendepunkter brukes under autosøkprosessen.

Autosøkprosess Hver gang Outlook trenger autosøkinformasjon, bruker den et sett med ordnede trinn for å prøve å hente en XML-nyttelast som inneholder konfigurasjonsinnstillinger. Mange av disse trinnene kan kontrolleres ved hjelp av gruppepolicyobjekter (GPO), og gruppepolicyobjektverdien er inkludert i trinnbeskrivelsen.

Trinn 1: Se etter omstartsscenarioer

I noen tilfeller, for eksempel når du legger til en ekstra konto mens Outlook kjører, bufres Autosøk-nyttelasten til en lokal fil som skal brukes under en omstart av Outlook klienten. Det aller første Autosøk-trinnet er å kontrollere registeret for å få spesiell oppstartsinformasjon som forteller Outlook at du er midt i et av disse omstartsscenarioene og lese autosøk-nyttelasten fra den spesielle lokale filen. Dette er et sjeldent tilfelle, og vanligvis ikke årsaken til generelle autosøkproblemer. I dette trinnet Outlook du er i dette spesielle oppstartsscenarioet og forsøket på å hente XML-dataene for autosøk mislykkes, mislykkes hele autosøkforsøket. Ingen flere trinn er forsøkt.

Det finnes ingen spesifikk policykontroll for dette trinnet.

Trinn 2: Se etter innstillinger for lokale data

Outlook inneholder et gruppepolicyobjekt for å la administratorer distribuere en bestemt Autosøk-XML-fil som skal brukes til konfigurasjon. Hvis administratoren har distribuert denne registerverdien og autodiscover.xml en Outlook, leser Outlook Autosøk-nyttelasten fra denne filen. Dette igjen er et uvanlig tilfelle, og vanligvis ikke årsaken til generelle autosøkproblemer. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 3.

Hvis du vil ha mer informasjon om Autosøk-XML, kan du se følgende TechNet-artikkel: Planlegge automatisk konfigurasjon av brukerkontoer i Outlook 2010Obs! Denne artikkelen ble opprettet

for Outlook 2010. Det er imidlertid fortsatt relevant for senere versjoner av Outlook.

Policykontrollverdien for dette trinnet er som følger: PreferLocalXML.

Trinn 3: Se etter LKG-data (Last Known Known Good)

Når Autosøk henter en XML-nyttelast gjennom et trinn, kan nyttelasten bufres lokalt som den siste fungerende konfigurasjonen. Den første metoden som vanligvis lykkes med å få en Autosøk-nyttelast, er fra denne sist kjente filen. Banen til den siste kjente, gode XML-filen kommer fra Outlook profilen. LKG-trinnet brukes bare til å oppdage den primære postbokskonfigurasjonen. Hvis Autosøk-oppslaget er for en ikke-primær postboks (alternativ, representant, fellesmappe, gruppepostboks og så videre), hoppes LKG-trinnet automatisk over. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 4.

Policykontrollverdien for dette trinnet er som følger: ExcludeLastKnownGoodURL.

Trinn 4: Se etter O365 som prioritet

Outlook bruker et sett med heuristikker til å avgjøre om den angitte brukerkontoen kommer fra Office 365. Hvis Outlook finner ut at du er en O365-bruker, gjøres det et forsøk på å hente Autosøk-nyttelasten fra de kjente O365-endepunktene (vanligvis https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml eller https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 5.

Policykontrollverdien for dette trinnet er som følger:

ExcludeExplicitO365Endpoint.

ITAR-vurdering

Som standard Outlook det kjente endepunktet for å hente Autosøk-nyttelasten. Den eksisterende policyen for å hoppe over dette trinnet er fortsatt gyldig og kan brukes til å gå til trinn 5 uten å prøve endepunktet. Alternativt finnes det en ny policy som ber Outlook å spørre en sentral Office 365 Konfigurasjonstjeneste for å hente aktuelle nettadresser som du kan hente nyttelasten for Autosøk fra. Begrepsmessig fungerer prosessen som følger:

Du angir den nye policyen.
I trinn 4 i Autosøk-prosessen Outlook spørringene Office 365 konfigurasjonstjenesten.
Tjenesten bestemmer hvilke (hvis noen) spesielle ITAR-behov som gjelder for den angitte brukeren, og returnerer de aktuelle nettadressene for denne brukeren ved hjelp av domeneinformasjonen for UPN.
Outlook prøver å hente autosøk-nyttelasten fra nettadressene som leveres av tjenesten.

Policykontrollverdien for den nye funksjonen for å bruke Office 365 Config Service er EnableOffice365ConfigService.

Obs!: Fra og med bygg 16.0.9327.1000brukes policyen EnableOffice365ConfigService ikke lenger.

Trinn 5: Se etter SCP-data

Hvis datamaskinen er domeneføyd, utfører Outlook en LDAP-spørring for å hente servicetilkoblingspunktdata som returnerer en bane for Autosøk-XML. Deretter blir det gjort et forsøk på hver nettadresse som returneres av SCP-oppslaget, for å prøve å hente Autosøk-nyttelasten. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 6.

Hvis du vil ha mer informasjon om SCP, kan du se følgende MSDN-artikkel: Publisere med tjenestetilkoblingspunkter.

Policykontrollverdien for dette trinnet er som følger: ExcludeScpLookup.

Trinn 6: Kontrollere rotdomene

I dette trinnet bygger Outlook en nettadresse fra domenenavnet til den opprinnelige adressen i formatet https://<-domene>/autosøk/autodiscover.xml og prøver å hente nyttelasten fra den resulterende nettadressen. Fordi mange rotdomener ikke er konfigurert for Autosøk, vil Outlook med hensikt dempe eventuelle sertifikatfeil som oppstår under forsøket på henting. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 7.

Policykontrollverdien for dette trinnet er som følger: UtelatHttpsRootDomain.

Trinn 7: Kontrollere autosøkdomene

I dette trinnet bygger Outlook en nettadresse fra domenenavnet til den opprinnelige adressen i formatet https://autodiscover.<-domene>/autosøk/autodiscover.xml og prøver å hente nyttelasten fra den resulterende nettadressen. Siden dette er den primære nettadressen vanligvis for Autosøk-data, Outlook ingen sertifikatfeil som oppstår under forsøket på henting. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 8.

Policykontrollverdien for dette trinnet er som følger: UtelatHttpsAutoDiscoverDomain.

Trinn 8: Se etter lokale data

I trinn 2 Outlook om administratoren hadde distribuert en policy for å spesifikt se etter Autosøk-nyttelasten som en preferanse. Hvis det ikke er noen policy på plass, men de forrige trinnene ikke hentet en nyttelast, prøver Outlook nå å hente en nyttelast fra den lokale filen selv uten PreferLocalXML-innstillingen på plass. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 9.

Det finnes ingen policykontroll for dette trinnet.

Trinn 9: Se etter HTTP-omadresseringer

I dette trinnet sender Outlook en forespørsel til url-adressen til autosøkdomenet (http://autodiscover.<domene>/autosøk/autodiscover.xml) og teste for omadresseringssvar. Hvis en faktisk Autosøk XML-nyttelast returneres og ikke en omadressering, ignorerer Outlook det faktiske Autosøk-XML-svaret fordi den ble hentet uten sikkerhet (http). Hvis svaret er en gyldig url-adresse for omadressering, Outlook følger omdirigering og prøver å hente en XML-adresse for nyttelast fra den nye nettadressen. Outlook vil også utføre sertifikatkontroller for å hindre omadressering til potensielt skadelige nettadresser i dette trinnet. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 10.

Policykontrollverdien for dette trinnet er som følger: UtelatHttpRedirect.

Trinn 10: Se etter SRV-data

I dette trinnet Outlook en DNS-spørring for «_autodiscover._tcp.<domenenavn>», og går gjennom resultatene på jakt etter den første posten som bruker https som protokoll. Outlook prøver deretter å hente nyttelasten fra nettadressen. Hvis dette trinnet ikke henter en nyttelast, Outlook til trinn 11.
Policykontrollverdien for dette trinnet er som følger: ExcludeSrvRecord.

Trinn 11: Se etter O365 som failsafe

Hvis alle de forrige trinnene ikke returnerte en nyttelast, bruker Outlook et mindre restriktivt sett med heuristikker til å avgjøre om et endelig forsøk på O365-endepunktene er potensielt nyttig. Hvis Outlook finner ut at et forsøk er verdt, prøver den de kjente O365 Autosøk-endepunktene i tilfelle kontoen er en O365-konto. Dette forsøket bruker samme måladresser som trinn 4, og er bare forskjellig i det faktum at det er prøvd som en siste utvei og ikke tidligere i Autosøk-prosessen.

Policykontrollverdien for dette trinnet er som følger: ExcludeExplicitO365Endpoint.

ITAR-hensyn

Hvis Outlook kommer til dette trinnet og ikke har hentet en Autosøk-nyttelast, utføres to tester for å se om de velkjente Office 365 endepunktene skal forsøkes. Hvis postboksen er en forbrukerkonto (for eksempel outlook.com), forsøkes det velkjente endepunktet. Hvis postboksen fastslås å tilhøre et domene som ikke har ITAR-krav, forsøkes det velkjente endepunktet. Hvis postboksen fastslås å være kommersiell og tilhører et domene som har ITAR-krav, gjøres det ingen forsøk på de velkjente Office 365 endepunktene. I fremtidige versjoner kan trinn 11 gå til samme logikk som trinn 4 og Office 365 Konfigurasjonstjeneste. Når denne endringen er gjort, oppdateres denne artikkelen for å gjenspeile det nye prosesstrinnet.

Omdirigering av trinn 9 i delen Autosøkprosess er et eksplisitt trinn for å håndtere usikre omadresseringsdata. I en av de andre sikre trinnene er et mulig svar fra endepunktet et omadresseringssvar for ethvert forsøk på å hente XML-nyttelasten for Autosøk. Dette svaret ber Outlook omdirigere til en ny, annen nettadresse for å prøve å hente nyttelasten. I tillegg kan omadresseringsdataene inneholde en ny, annen e-postadresse som skal brukes som måladresse for autosøkforsøket. Outlook vurderer tre separate svar som «omdirigeringssvar»:

En HTTP-statuskode (301, 302) med en ny nettadresse
En HTTP-statuskode på 200, men med en nyttelast-XML som ber Outlook omdirigere til en annen nettadresse
En HTTP-statuskode på 200, men med en nyttelast-XML som ber Outlook å bruke en annen SMTP-adresse som måladresse.

I tilfelle 1 og 2 prøver Outlook å hente XML-filen for autosøk fra den nye nettadressen, forutsatt at protokollen er https. Url-adresser som ikke er usikre (http), blir ikke forsøkt. Selv om protokollen i den nye nettadressen er https, kontrollerer Outlook sertifikatinformasjon for å gi et ekstra sikkerhetstiltak.

I tilfelle 3 starter Outlook hele autosøkprosessen fra begynnelsen. Hvis alle trinnene (1-11) prøves uten å lykkes ved hjelp av den nye e-postadressen, går Outlook tilbake til den opprinnelige e-postadressen, går til trinn 5 og fortsetter forsøket på å hente en XML-nyttelast med den opprinnelige adressen.

Unntak Trinnene i delen Autosøkprosess er de generelle reglene for hvordan Outlook prøver å få autosøk-nyttelasten. Det finnes ulike optimaliseringer og eksepsjonelle forsøk som kan endre prosessen litt. Når du for eksempel gjør en ny kontoopprettelse, hopper Outlook internt trinn 3 (se etter LKG-data (Last Known Good), fordi den ennå ikke har en siste fungerende oppføring. Likeledes, hvis et forsøk ble utløst på grunn av en feil ved hjelp av gjeldende konfigurasjonsinformasjon, ønsker Outlook å autosøke på nytt og ikke bruke LKG-informasjonen fordi antagelig den siste kjente gode informasjonen resulterte i en feil.

Policykontroll Policyverdiene som defineres under Autosøkprosess, kan enten være policybaserte registerverdier eller ikke-policybaserte verdier. Når de distribueres via gruppepolicyobjektet eller manuell konfigurasjon av policynøkkelen, har innstillingene forrang over ikke-policynøkkelen.

Ikke-policynøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

Policynøkkel: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

Hver verdi er av typen DWORD.

PreferLocalXML er forskjellig fra de andre kontrollverdiene som en innstilling på 1 sett Outlook for å aktivere dette trinnet i prosessen. For de gjenstående verdiene angir en innstilling på 1 at Outlook skal slå av eller hoppe over det tilknyttede trinnet. Du kan for eksempel angi verdien UtelatHttpsRootDomain til 1 sett Outlook ikke skal utføre trinn 6 i prosessen.

Flere registerkontroller

Outlook inneholder flere flere registerbaserte konfigurasjonsalternativer som kan påvirke Autosøk-prosessen:

Bruke Office 365 Config Service

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Verdi: EnableOffice365ConfigService
Standard: 0
Data: Sett disse DWORD-dataene til 1 for å tvinge Outlook til å Office 365 konfigurasjonstjenesten for å hente riktige url-adresser for autosøk.

Innstillinger for HTTP-tidsbrudd

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Verdi: Tidsavbrudd
Standard: 25 sekunder
Minimum: 10 sekunder
Maksimum: 120 sekunder

Informasjon: Angitte tidsavbrudd brukes som WinHttpSetTimeouts-innstillinger. De angitte dataene sendes til alle fire parameterne i WinHttpSetTimeouts API. Dette gjør det mulig for en HTTP-forespørsel som ikke kan nås raskere, å gå raskere, noe som vil forbedre den generelle ytelsen. Innstillingene kan også tillate en HTTP-forespørsel som tar lengre tid enn 25 sekunder å lykkes ved å øke tids ut-innstillingen til noe som er større enn 25 sekunder.
Mapi/Http Protocol Control

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Exchange
Verdi: MapiHttpDisabled
Standard: 0
Data: 1 = Protokollen er deaktivert. 0 = Protokoll er aktivert

Informasjon: Denne verdien er ikke plassert under Autosøk-nøkkelen. Dette er en generell innstilling som styrer om Outlook kan prøve å koble til Exchange ved hjelp av Mapi/Http-protokollstakken. Standardinnstillingen i Outlook 2016 at denne protokollen ikke skal være deaktivert. Dette gjør at Autosøk-prosessen legger til en spesiell topptekst (X-MapiHttpCapability:1) i oppdagingsprosessen, slik at Mapi/Http-protokollinnstillingene kan evalueres og behandles.
Eldre godkjenningsforhandlingskontroll

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Verdi: AllowNegoCapabilityHeader
Standard: 0
Data: 1 = Overskrifter legges til. 0 = Topptekster legges ikke til

Informasjon: Vær oppmerksom på at denne verdien ikke er under Autosøk-nøkkelen. Denne innstillingen kontrollerer om et forhandlingshode for godkjenning er lagt til i http-forespørsler. Innholdet i toppteksten avhenger av godkjenningsfunksjonene til klientdatamaskinen. Et eksempel på topptekst kan være: «X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP». Denne registerverdien og overskriften som legges til, brukes sjelden i moderne godkjenningsstakken og vil svært usannsynlig påvirke tAodiscover-prosessen på en negativ eller positiv måte.
Sertifikatfeilbehandling

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Verdi: ShowCertErrors
Standard: 0
Data: 1 = Vis sertifikatadvarsler/-feil; 0 = Ikke vis sertifikatadvarsler

Informasjon: Denne verdien styrer hvordan Outlook håndterer sertifikatfeil og advarsler som mottas når den utfører http-oppgaver. Outlook kan overstyre denne innstillingen i noen tilfeller (trinn 6 i delen Autosøkprosess), men hvis denne innstillingen er aktivert, vil Outlook be om en sikkerhetsdialogboks som viser sertifikatfeilen eller advarselen, og tillate brukeren å OK eller Avbryte Http-forespørselen. Det er tre spesifikke sertifikatfeil som brukeren kan velge å ignorere, og Outlook å gjøre et nytt forsøk på http-forespørselen:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – Det er et problem med datoen i sertifikategenskapene
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – Det er et problem med det vanlige navnet i sertifikategenskapene
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – Det er et problem med sertifiseringsinstansen i sertifikategenskapene

Du finner mer informasjon om disse tre feiltilstandene for sertifikater WINHTTP_STATUS_CALLBACK tilbakeringingsfunksjonen

Behandling av proxy-godkjenning

Nøkkel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Verdi: AllowOutlookHttpProxyAuthentication
Standard: 0
Data: 1 = Tillat Outlook å håndtere godkjenningsutfordringer fra proxy-servere; 0 = stille mislykkes godkjenningsutfordringer fra proxy-servere

Informasjon: Denne registerverdien gjør det mulig å slappe av en sikkerhetskonfigurasjon og dekkes i detalj i følgende artikkel i Microsoft Knowledge Base:

3115474 MS16-099: Beskrivelse av sikkerhetsoppdateringen for Outlook 2010: 9. august 2016

Autosøk for andre protokoller

Autosøk som en funksjon brukes også av Outlook å oppdage og konfigurere Exchange ActiveSync (EAS)-kontoer. EAS Autosøk-prosessen og beslutningsprosessen er atskilt fra trinnene som er beskrevet i denne artikkelen. EAS-implementeringen implementerer for eksempel ikke O365-endepunktlogikken og har ikke et trinn som kontrollerer SCP-plasseringer. Denne artikkelen er begrenset til å beskrive de detaljerte trinnene Outlook bruker for Autosøk-forsøk på å hente de MAPI-baserte protokollene fra Exchange.

Referanser

Eldre informasjon om autosøk finnes i følgende artikkel i Microsoft Knowledge Base:

2212902 Uventet virkemåte for autosøk når du har registerinnstillinger under \Autosøk-nøkkelen

Hvis du vil ha mer informasjon om Autosøk, kan du se følgende Microsoft-artikler:

Autosøk for Exchange

Autosøktjeneste