Outlook 2016 implementering av Autodiscover

Sammanfattning

Automatisk upptäckt är den funktion som Outlook för att hämta konfigurationsinformation för servrar som den ansluter till. I Outlook 2016 med Exchange-servrar betraktas Automatisk upptäckt som den enda informationspunkten för konfigurationsinformation och måste konfigureras och fungera korrekt för att Outlook ska fungera fullt ut. I den här artikeln beskrivs implementeringen av Autodiscover i den aktuella kanalens Klicka-och-kör-version av Outlook 2016. Mer information om Office 365 kanalutgivningar finns på följande Microsoft-webbplatser:

Version och versionsnummer för uppdateringskanalers utgivningar för Office 365 klienter

Office 365 utgivningar av uppdateringskanaler för klienten

Mer information

Tidsinställningar för automatisk upptäckt

Automatisk upptäckt körs vid följande tillfällen:

När kontot skapas.
Samla in ändringar i URL:er som Exchange webbtjänstfunktioner (OOF, Tillgänglighetstjänst o.s.v.) regelbundet. Om den här processen lyckas görs ett nytt försök en timme senare. Om försöket inte lyckas görs nästa försök 5 minuter senare. Varje försök kan potentiellt fördelas upp till 25 procent, på grund av den bakgrundsinfrastruktur som används av alla Microsoft Office program.
Som ett svar på vissa anslutningsproblem. I olika fall, när ett anslutningsförsök misslyckas, startar Outlook en aktivitet för automatisk upptäckt för att hämta nya inställningar i ett försök att korrigera anslutningsproblemet.
När ett annat program anropar det genom att använda MAPI. Mer information om MAPI finns i följande MSDN-artikel: se Outlook MAPI-referens.

Autodiscover-effektivitet

Använd UPN (User Principal Name) för att underlätta processen för automatisk upptäckt.

På en domän ansluten dator Outlook ha UPN för en användare för att kunna starta processen för automatisk upptäckt. UPN kan ha använts för att logga Windows, och i så fall Outlook direkt åtkomst till UPN från inloggningsuppgifterna. Men om en användare använder domän\användarnamn för att logga in Windows Outlook bara samma autentiseringsuppgifter för användaren. För att skaffa UPN måste Outlook söka efter användaren i katalogen. Outlook kommer att begära att det här uppslaget ska dina mannahänvisningar. I komplexa miljöer kan det leda till att ett stort antal pc-datorer kontaktas innan ett resultat hittas. När Outlook identifierar UPN för användaren cachelagras värdet i profilen och uppslag ska inte hända igen för den här användaren.

För att undvika det här scenariot kan användaren logga in med ett UPN i stället för domän\användarnamn.

Att tänka på när det gäller ITAR

Microsoft Office 365 funktioner som kan stödja kunder med ITAR-skyldigheter. I samband med funktionen Autodiscover i Outlook innehåller den här funktionsuppsättningen principinställningar och -beteende som säkerställer att de tjänsteslutpunkter som används för Autodiscover följer nationella molnkrav. I de Office 365 specifika steg som listas i Processen för automatisk upptäckt (steg 4 och steg 11) finns principkontrollen tillgänglig för att säkerställa att lämpliga tjänsteslutpunkter används under processen för automatisk upptäckt.

Processen Automatisk upptäckt Varje gång Outlook behöver information om automatisk upptäckt används en uppsättning ordnade steg för att försöka hämta en XML-nyttolast som innehåller konfigurationsinställningar. Många av de här stegen kan kontrolleras med grupprincipobjekt (GPO), och GPO-värdet tas med i stegbeskrivningen.

Steg 1: Kontrollera om det finns omstartsscenarier

I vissa fall, till exempel när du lägger till ett andra konto medan Outlook körs, cachelagras nyttolasten för automatisk upptäckt till en lokal fil som ska användas vid en omstart av Outlook-klienten. Det första steget för Autodiscover är att söka i registret efter särskild "start"-information som talar om för Outlook att du befinner dig mitt i ett av dessa omstartsscenarier och att läsa den automatiska upptäckten av nyttolast från den särskilda lokala filen. Det här är ett sällsynta fall och vanligtvis inte orsaken till allmänna problem med automatisk upptäckt. För det här steget Outlook om du befinner dig i det här särskilda startscenariot och försöket att hämta XML-data för automatisk upptäckt misslyckas, misslyckas hela autodiscover-försöket. Inga ytterligare åtgärder försök görs.

Det finns ingen specifik principkontroll för det här steget.

Steg 2: Sök efter lokal datainställning

Outlook tillhandahåller ett GPO för att låta administratörer distribuera en specifik XML-fil för automatisk upptäckt som ska användas för konfigurationen. Om administratören har distribuerat det här registervärdet och i slutet av en autodiscover.xml, Outlook den automatiska upptäckten av nyttolast från den här filen. Detta är återigen ett ovanligt fall och vanligtvis inte orsaken till allmänna problem med automatisk upptäckt. Om det här steget inte hämtar någon nyttolast flyttas Outlook till steg 3.

Mer information om Autodiscover XML finns i följande TechNet-artikel: Planera att automatiskt konfigurera användarkonton i Outlook 2010Obs! Den här artikeln skapades

Outlook 2010. Den är dock fortfarande relevant för senare versioner av Outlook.

Principkontrollvärdet för det här steget är följande: PreferLocalXML.

Steg 3: Kontrollera senast kända data (LKG)

När automatisk upptäckt hämtar en XML-nyttolast utan fel i något steg kan nyttolasten cachelagras lokalt som den "senast kända bra"-konfigurationen. Den första vanliga metoden för att få en autodiscover-nyttolast är från den här senast kända filen. Sökvägen till den senast kända xml-filen kommer från den Outlook profil. LKG-steget används endast för att identifiera den primära postlådekonfigurationen. Om uppslagsposten för automatisk upptäckt är för en postlåda som inte är primär (alternativ, ombud, offentlig mapp, grupppostlåda och så vidare) hoppas LKG-steget över automatiskt. Om det här steget inte hämtar någon nyttolast flyttas Outlook till steg 4.

Principkontrollvärdet för det här steget är följande: ExcludeLastKnown Till ExempelURL.

Steg 4: Kontrollera prioritet för O365

Outlook använder en uppsättning heuristor för att avgöra om det angivna användarkontot kommer Office 365. Om Outlook anser att du är O365-användare görs ett försök att hämta den automatiska upptäckten av nyttolast från de kända O365-slutpunkterna (vanligtvis https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml eller https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Om det här steget inte hämtar någon nyttolast flyttas Outlook till steg 5.

Principkontrollvärdet för det här steget är följande:

ExcludeExplicitO365Endpoint.

ITAR-överväganden

Som standard Outlook den kända slutpunkten för att hämta den automatiska upptäckten av nyttolast. Den befintliga principen för att kringgå det här steget är fortfarande giltig och kan användas för att gå till steg 5 utan att prova slutpunkten. Alternativt finns det en ny princip som dirigerar Outlook till att fråga en central Office 365-konfigurationstjänst för att hämta lämpliga URL:er som du kan hämta den automatiska dataidentifieringsinläsningen från. Konceptuellt fungerar processen på följande sätt:

Du anger den nya principen.
I steg 4 i Autodiscover-processen Outlook frågan Office 365 konfigurationstjänsten.
Tjänsten avgör vilka (om några) särskilda ITAR-behov som används för den angivna användaren och returnerar lämpliga URL-adresser för den användaren med hjälp av domäninformationen för UPN.
Outlook försöker hämta den automatiska upptäckten från webbadresserna som tillhandahålls av tjänsten.

Principkontrollvärdet för den nya funktionen som använder konfigurationstjänsten Office 365 är EnableOffice365ConfigService.

Obs!: Från och med version 16.0.9327.1000används inte längre EnableOffice365ConfigService-principen.

Steg 5: Kontrollera om det finns SCP-data

Om datorn är domänkoppling utför Outlook en LDAP-fråga för att hämta data om tjänstanslutningspunkt som returnerar en sökväg till XML för automatisk upptäckt. Ett försök görs sedan till varje URL som returneras av SCP-uppslag för att försöka hämta autodiscover-nyttolasten. Om det här steget inte hämtar en nyttolast Outlook till steg 6.

Mer information om SCP finns i följande MSDN-artikel: Publicera med serviceanslutningspunkter.

Principkontrollvärdet för det här steget är följande: ExcludeScpLookup.

Steg 6: Kontrollera rotdomän

I det här steget skapar Outlook en URL-adress från domännamnet för den ursprungliga adressen i formatet https://<domän>/autodiscover/autodiscover.xml och försöker hämta nyttolasten från den resulterande URL:en. Eftersom många rotdomäner inte är konfigurerade för automatisk upptäckt kan Outlook stänga av eventuella certifikatfel som uppstår vid den försökna hämtningen. Om det här steget inte hämtar en nyttolast Outlook till steg 7.

Principkontrollvärdet för det här steget är följande: ExcludeHttpsRootDomain.

Steg 7: Kontrollera domänen För automatisk upptäckt

I det här steget skapar Outlook en URL från domännamnet för den ursprungliga adressen i formatet https://autodiscover.<domän>/autodiscover/autodiscover.xml och försöker hämta nyttolasten från den resulterande url:en. Eftersom det här är den primära URL:en som vanligtvis används för automatisk upptäckt av data Outlook att inte stänga av eventuella certifikatfel som uppstår vid den försökna hämtningen. Om det här steget inte hämtar någon nyttolast flyttas Outlook till steg 8.

Principkontrollvärdet för det här steget är följande: ExcludeHttpsAutoDiscoverDomain.

Steg 8: Sök efter lokala data

I steg 2 Outlook du om administratören hade distribuerat en princip för att specifikt söka efter nyttolasten för automatisk upptäckt som inställning. Om det inte finns någon princip, men de föregående stegen inte hämtade en nyttolast, försöker Outlook nu hämta en nyttolast från den lokala filen även utan att inställningen PreferLocalXML har gjorts. Om det här steget inte hämtar en nyttolast Outlook till steg 9.

Det finns ingen principkontroll för det här steget.

Steg 9: Sök efter HTTP-omdirigeringar

I det här steget skickar Outlook en begäran till URL:en för domänen Autodiscover (http://autodiscover.<domain>/autodiscover/autodiscover.xml) och söker efter omdirigeringssvar. Om en faktisk XML-nyttolast för automatisk upptäckt returneras och inte en omdirigering ignorerar Outlook det faktiska XML-svaret för automatisk upptäckt eftersom det hämtades utan säkerhet (http). Om svaret är en giltig omdirigerings-URL följer Outlook omdirigeringen och försöker hämta en nyttolast-XML från den nya URL:en. Outlook att utföra certifikatkontroller för att förhindra omdirigering till potentiellt skadliga URL:er i det här steget. Om det här steget inte hämtar en nyttolast Outlook till steg 10.

Principkontrollvärdet för det här steget är följande: ExcludeHttpRedirect.

Steg 10: Kontrollera om det finns SRV-data

I det här steget skapar Outlook en DNS-fråga för "_autodiscover._tcp.<domännamn>" och bläddrar igenom resultatet efter den första posten som använder https som protokoll. Outlook sedan försöka hämta nyttolasten från url:en. Om det här steget inte hämtar en nyttolast Outlook till steg 11.
Principkontrollvärdet för det här steget är följande: ExcludeSrvRecord.

Steg 11: Kontrollera om O365 är felsäkert

Om alla tidigare steg inte returnerade en nyttolast använder Outlook en mindre restriktiv uppsättning heuristisk för att avgöra om ett slutligt försök till O365-slutpunkterna kan vara användbart. Om det är värt att göra ett försök i Outlook bör du försöka med de kända O365-slutpunkterna för automatisk upptäckt om kontot är ett O365-konto. Det här försöket använder samma mål-URL:er som steg 4 och skiljer sig bara i det faktum att den används som en sista utväg och inte tidigare i processen för automatisk upptäckt.

Principkontrollvärdet för det här steget är följande: ExcludeExplicitO365Endpoint.

Att tänka på när det gäller ITAR

Om Outlook kommer till det här steget och inte har hämtat en automatisk upptäckt av nyttolast utförs två tester för att se om de välkända försöken Office 365-slutpunkterna ska försökas. Om postlådan är ett konsumentkonto (till exempel outlook.com) försöker den välkända slutpunkten. För det andra: om postlådan bestäms tillhöra en domän som inte har ITAR-krav, försöker den välkända slutpunkten. Om postlådan är kommersiellt och tillhör en domän som har ITAR-krav görs inget försök till de välkända Office 365 slutpunkterna. I kommande versioner kan steg 11 gå vidare till samma logik som i steg 4 och anropa Office 365 konfigurationstjänsten. När ändringen görs uppdateras den här artikeln så att den återspeglar det nya processsteget.

Omdirigering av hantering Steg 9 i avsnittet Autodiscover Process är ett explicit steg för att hantera icke-osäkra omdirigeringsdata. I de andra säkra stegen är ett möjligt svar från slutpunkten ett omdirigeringssvar för varje försök att hämta XML-nyttolasten för automatisk upptäckt. Det här svaret Outlook att omdirigera till en ny, annan URL som ska försöka hämta nyttolasten. Dessutom kan omdirigeringsdata innehålla en ny, annan e-postadress som ska användas som måladress för automatisk upptäckt-försöket. Outlook tre separata svar som "omdirigera svar":

En HTTP-statuskod (301, 302) med en ny URL
En HTTP-statuskod för 200, men med en nyttolast-XML som anger att Outlook omdirigera till en annan URL
En HTTP-statuskod för 200, men med ett XML för nyttolast som Outlook till att använda en annan smtp-adress som måladress.

I fall 1 och 2 försöker Outlook hämta XML för automatisk upptäckt från den nya URL:en, förutsatt att protokollet är https. Icke-osäkra URL:er (http) försöker inte. Även om protokollet i den nya URL:en är https så kontrollerar Outlook certifikatinformation för att tillhandahålla ytterligare ett säkerhetsmått.

För fall 3 Outlook hela processen för automatisk upptäckt från början. Om du försöker med alla steg (1–11) utan att lyckas med den nya e-postadressen återgår Outlook till den ursprungliga e-postadressen, går vidare till steg 5 och fortsätter försöket att hämta en XML-nyttolast med den ursprungliga adressen.

Undantag Stegen i avsnittet Autodiscover Process är de allmänna reglerna för hur Outlook försöker hämta den automatiska upptäckten av nyttolast. Det finns olika optimeringar och ovanliga försök som kan ändra processen något. När du skapar ett nytt konto hoppar Outlook till exempel över steg 3 internt (sök efter LKG-data) eftersom det ännu inte går att lägga till en senast känd post. På samma sätt om ett försök utlöstes på grund av ett fel genom att använda den aktuella konfigurationsinformationen vill Outlook medvetet åter kunna hitta information automatiskt och inte använda LKG-informationen eftersom den senast kända informationen ledde till ett fel.

Principkontroll De principvärden som definieras i avsnittet Automatisk upptäcktsprocess kan vara antingen principbaserade registervärden eller icke-principbaserade värden. När de distribueras via GPO, eller manuell konfiguration av principnyckeln, har inställningarna företräde framför icke-principnyckeln.

Icke-principnyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

Principnyckel: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

Varje värde är av typen DWORD.

PreferLocalXML skiljer sig från de andra kontrollvärdena eftersom inställningen 1 anger Outlook att aktivera det steget i processen. För de återstående värdena anger inställningen 1 att Outlook ska inaktivera eller hoppa över det associerade steget. Om du till exempel anger värdet ExcludeHttpsRootDomain till 1 Outlook inte att utföra steg 6 i processen.

Ytterligare registerkontroller

Outlook flera ytterligare registerbaserade konfigurationsalternativ som kan påverka processen för automatisk upptäckt:

Använda Office 365 konfigurationstjänst

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Värde: EnableOffice365ConfigService
Standard: 0
Data: Ställ in dessa DWORD-data på 1 för att tvinga Outlook att anropa Office 365-konfigurationstjänsten för att hämta lämpliga Autodiscover-URL:er.

INSTÄLLNINGAR för time out för HTTP

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Värde: Timeout
Standard: 25 sekunder
Minst: 10 sekunder
Max: 120 sekunder

Information: Angivna tidsgränser används som WinHttpSetTimeouts-inställningar. De angivna data skickas till alla fyra parametrarna i WinHttpSetTimeouts API. På så sätt kan en HTTP-begäran som inte kan nås nås snabbare, vilket förbättrar den övergripande prestandan. Inställningarna kan också tillåta att en HTTP-begäran som tar längre tid än standardvärdet på 25 sekunder lyckas genom att öka time out-inställningen till något större än 25 sekunder.
Mapi/http-protokollkontroll

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Exchange
Värde: MapiHttpDisabled
Standard: 0
Data: 1 = Protokollet är inaktiverat; 0 = Protokollet är aktiverat

Information: Det här värdet finns inte under nyckeln för automatisk upptäckt. Det här är en allmän inställning som styr Outlook kan försöka ansluta till Exchange med hjälp av mapi/http-protokollsstacken. Som standard Outlook 2016 det här protokollet inte inaktiveras. Då kan processen för automatisk upptäckt lägga till ett speciellt sidhuvud (X-MapiHttpCapability:1) i identifieringsprocessen så att inställningarna för Mapi/Http-protokollet kan utvärderas och bearbetas.
Kontroll för äldre autentiseringsförhandlingar

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Värde: AllowNegoCapabilityHeader
Standard: 0
Data: 1 = Rubriker läggs till; 0 = Rubriker läggs inte till

Information: Observera att det här värdet inte finns under nyckeln för automatisk upptäckt. Den här inställningen styr om en rubrik för autentiseringsförhandlingar läggs till i http-begäranden. Innehållet i sidhuvudet beror på klientdatorns autentiseringsfunktioner. Ett exempel på ett sidhuvud kan vara: "X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP". Det här registervärdet och rubriken som läggs till används sällan i någon hög med modern autentisering och det är mycket osannolikt att TAodiscover-processen påverkas på ett negativt eller positivt sätt.
Felhantering för certifikat

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Värde: ShowCertErrors
Standard: 0
Data: 1 = Visa certifikat varningar/fel; 0 = Visa inte certifikatvarningar

Information: Det här värdet styr Outlook hanterar certifikatfel och varningar som tas emot när http-uppgifter utförs. Outlook kan i vissa fall åsidosätta den här inställningen (steg 6 i avsnittet Process för automatisk upptäckt), men om den här inställningen är aktiverad visas en säkerhetsdialogruta i Outlook med felmeddelandet eller varningen och användaren tillåts att OK eller Avbryt http-begäran. Det finns tre specifika certifikatfel som användaren kan ignorera och Outlook på http-begäran:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – Det är ett problem med datumet i certifikategenskaperna
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – Det är ett problem med det gemensamma namnet i certifikategenskaperna
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – Det är ett problem med certifikatutfärdaren i certifikategenskaperna

Mer information om de här tre certifikatfel tillstånden finns WINHTTP_STATUS_CALLBACK anropa funktionen

Hantera proxyautentisering

Nyckel: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Värde: AllowOutlookhttpProxyAuthentication
Standard: 0
Data: 1 = tillåt Outlook att hantera autentiseringsutmaningar från proxyservrar; 0 = tyst misslyckas autentiseringsutmaningar från proxyservrar

Information: Med det här registervärdet kan du ta bort en säkerhetskonfiguration och beskrivs i detalj i följande artikel i Microsoft Knowledge Base: 3115474 MS16-099: Beskrivning av säkerhetsuppdateringen för

Outlook 2010: 9 augusti 2016

Autodiscover för andra protokoll

Automatisk upptäckt som en funktion används också av Outlook att upptäcka och konfigurera EAS-konton (Exchange ActiveSync). EAS-processen för automatisk upptäckt och beslut skiljer sig från stegen som beskrivs i den här artikeln. EAS-implementeringen implementerar till exempel inte O365-slutpunktslogiken och har inget steg som söker efter SCP-platser. Den här artikeln är begränsad till att beskriva de detaljerade Outlook används för autodiscover-försök att hämta MAPI-baserade protokoll från Exchange.

Referenser

Äldre information om autodiscover finns i följande artikel i Microsoft Knowledge Base:

2212902 Oväntat beteende för automatisk upptäckt när du har registerinställningar under \Autodiscover-nyckeln

Mer information om Autodiscover finns i följande Microsoft-artiklar:

Autodiscover för Exchange

Tjänsten Autodiscover