Outlook 2016 automatikus észlelés implementációja

Összefoglalás

Az automatikus észlelés az a szolgáltatás, Outlook használatával konfigurációs adatokat szerezhet be azokkal a kiszolgálókkal, amelyekhez csatlakozik. Az Outlook 2016-kiszolgálókkal való Exchange esetén az automatikus észlelés a konfigurációs információk egyetlen pontjának számít, és úgy kell konfigurálni és megfelelően működni, hogy a Outlook működőképes legyen. Ez a cikk bemutatja az automatikus észlelés implementációját az aktuális csatornán az Outlook 2016. Az ügyfélcsatornák Office 365 az alábbi Microsoft-webhelyeken található további információkért:

A frissítési csatornák kiadásának verziószáma és buildszáma Office 365 ügyfélhez

Office 365 frissítési csatornák kiadásának frissítése

További információ

Automatikus észlelés időzítése

Az automatikus észlelés a következő időpontokban fut:

Fiók létrehozásakor.
A webszolgáltatást (OOF, rendelkezésre állási szolgáltatás stb.) Exchange adatgyűjtést végezni. Ha a folyamat sikeres, egy órával később próbálkozzon egy másikkal. Ha a kísérlet nem sikerül, a következő próbálkozás 5 perccel később történik meg. Minden kísérlet akár 25 százalékkal is eltoltható az összes alkalmazás által használt háttér-Microsoft Office miatt.
Bizonyos csatlakozási hibákra válaszul. Amikor a csatlakozási kísérlet meghiúsul, a Outlook elindít egy automatikus észlelési feladatot, hogy beolvassa az új beállításokat a kapcsolati probléma megoldásakor.
Amikor egy másik alkalmazás meghívja a MAPI segítségével. A MAPI-ről további információt a következő MSDN-cikkben talál: Outlook MAPI reference (MAPI Outlook.

Automatikus észlelési hatékonyság

Az egyszerű felhasználóneveket (UPN) használva gyorsíthatja az automatikus észlelési folyamatot.

Tartományhoz csatlakozott számítógépen Outlook felhasználó felhasználóhoz való felhasználóhoz való felhasználónevét ahhoz, hogy elindítsa az automatikus észlelési folyamatot. Előfordulhat, hogy az upn segítségével bejelentkeztek az Windows szolgáltatásba, ebben az esetben Outlook hozzáféréssel rendelkezik az upn-hez a bejelentkezési hitelesítő adatokból. Ha azonban egy felhasználó a tartomány\felhasználónév használatával jelentkezik be Windows, Outlook felhasználónak csak a felhasználóhoz ugyanaz a hitelesítő adatai vannak. Az upn-felhasználóhoz először Outlook felhasználónak kell keresnie a címtárban. Outlook a rendszer kérni fogja, hogy ez a keresés legyen a hivatkozásokra fog hivatkozni. Összetett környezetekben ez nagyszámú DCS-hez való kapcsolatfelvételt okozhat, mielőtt eredményt találna. Miután Outlook felhasználó upn-ját, a rendszer gyorsítótárba teszi az értéket a profilban, és a keresés nem fordul elő újra a felhasználónál.

Ennek elkerülése érdekében a felhasználó a domain\felhasználónév helyett egy upn használatával jelentkezhet be.

ItAR-szempontok

Microsoft Office 365 biztosít olyan szolgáltatásokat, amelyek támogatják az ITAR-kötelezettségeketaz ügyfelek számára. A Outlook automatikus észlelési funkciójának környezetében ez a szolgáltatáskészlet olyan házirend-beállításokat és viselkedést tartalmaz, amelyek biztosítják, hogy az automatikus észleléshez használt szolgáltatási végpontok betartsák a független felhőbeli követelményeket. Konkrétan az automatikus észlelési folyamat Office 365 lépéseinél (4. és 11. lépés) házirend-vezérlő érhető el annak biztosítására, hogy az automatikus észlelési folyamat során a megfelelő szolgáltatási végpontok használatosak.

Automatikus észlelési folyamat: Minden alkalommal, amikor Outlook az automatikus észlelési adatokra van szüksége, számos rendezett lépésből próbálja meg lekérni a konfigurációs beállításokat tartalmazó XML-terhelést. A lépések nagy része szabályozható csoportházirend-objektumok használatával, és a csoportházirend-objektum értéke szerepel a lépésleírásban.

1. lépés: Újraindítási esetek ellenőrzése

Bizonyos esetekben, például amikor egy második fiókot ad hozzá, miközben Outlook fut, az automatikus észlelési terhelés egy helyi fájlba van gyorsítótárazva, és azt a rendszer Outlook újraindításakor Outlook használni. Az első automatikus észlelési lépés az, hogy a beállításjegyzékben ellenőrizze a speciális "rendszerindítási" információkat, amelyekből megtudhatja, hogy a Outlook az ilyen újraindítási esetek egyikének közepén van, és hogy beolvassa az Automatikus észlelés hasznos terhelését a speciális helyi fájlból. Ez ritka eset, és általában nem az általános automatikus észlelési problémák oka. Ha ebben a lépésben Outlook, hogy Ön ilyen speciális indítási helyzetben van, és nem próbálja meg beolvasni az automatikus észlelési XML-adatokat, a teljes automatikus észlelési kísérlet meghiúsul. A rendszer nem kísérel meg további lépéseket.

Ehhez a lépéshez nincs külön házirend-szabályozás.

2. lépés: A Helyi adatok beállítás ellenőrzése

Outlook egy olyan GPO-t, amely lehetővé teszi a rendszergazdáknak egy adott automatikus észlelési XML-fájl telepítését a konfigurációhoz. Ha a rendszergazda telepítette ezt a beállításjegyzékbeli értéket, és autodiscover.xml egy Outlook fájlból olvassa fel az automatikus észlelési terhelést. Ez is szokatlan, és általában nem az általános automatikus észlelési problémák oka. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 3. lépésre.Az automatikus észlelési XML-ről további információt a következő TechNet-cikkben talál: Felhasználói fiókok automatikus konfigurálása az Outlook 2010-benMegjegyzés: Ez a cikk a Outlook 2010-hez készült. A cikk későbbi verzióira azonban továbbra is Outlook.Ennek a lépésnek a házirend-vezérlőértéke a következő: PreferLocalXML.

3. lépés: Az utolsó ismert jó (LKG) adatok ellenőrzése

Amikor az automatikus észlelés bármilyen lépéssel sikeresen beolvassa az XML-be való betöltést, előfordulhat, hogy a terhelést helyileg, az "utolsó ismert helyes" konfigurációként tárolja a program. Az automatikus észlelés első, gyakran sikeres terhelésének módszere az utolsó ismert jó fájlból származó. Az utolsó ismert helyes XML-fájl elérési útja a Outlook található. A LKG lépés csak az elsődleges postaláda konfigurációjának felderítésére használható. Ha az automatikus észlelési keresés nem elsődleges postaládához (másodlagos, meghatalmazotti, nyilvános mappához, csoportpostafiókhoz stb.) tartozik, akkor a LKG lépést a rendszer automatikusan kihagyja. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook 4. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeLastKnownGoodURL.

4. lépés: Az O365 prioritásának ellenőrzése

Outlook heurisztikus készletet használva határozza meg, hogy a megadott felhasználói fiók a Office 365. Ha Outlook felhasználóként azt határozzák meg, hogy Ön O365-felhasználó, akkor megkísérli lekérni az automatikus észlelés hasznos terhelését az ismert O365-végpontról (általában az https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml vagy https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook az 5. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő:

ExcludeExplicitO365Endpoint.

ITAR-szempont

Alapértelmezés szerint a Outlook lekérdezi az ismert végpontot az automatikus észlelés hasznos terhelésének beolvasása érdekében. Az ezt a lépést megkerülő meglévő házirend még érvényes, és a végpont kipróbálása nélkül használhatja az 5. lépésre. Másik lehetőségként egy új házirend arra irányítja a Outlook-t, hogy lekérdez egy központi Office 365 konfigurációs szolgáltatást az automatikus észlelési terhelés lekéréséhez szükséges megfelelő URL-címek lekéréséhez. A folyamat elvilag a következőképpen működik:

Az új házirendet Ön állíthatja be.
Az automatikus észlelési folyamat 4. lépésében a rendszer lekérdezi Outlook a Office 365 szolgáltatást.
A szolgáltatás meghatározza, hogy mely (ha vannak) speciális ITAR-igények vannak érvényben a megadott felhasználónál, és az upn tartományinformációit használva visszaküldi az adott felhasználónak megfelelő URL-címeket.
Outlook megpróbálja lekérni az automatikus észlelési hasznos adatokat a szolgáltatás által biztosított URL-címekből.

Az új szolgáltatás házirendvezérlő értéke az EnableOffice365ConfigService Office 365 konferencia-szolgáltatás.

Megjegyzés: A 16.0.9327.1000-esbuild óta már nem használjuk az EnableOffice365ConfigService házirendet.

5. lépés: SCP-adatok ellenőrzése

Ha a számítógép tartományhoz van csatlakozva, Outlook LDAP-lekérdezéssel lekéri a szolgáltatás csatlakozási pontjának adatait, amelyek az automatikus észlelési XML elérési útját adja vissza. Ezután a rendszer megkísérli az SCP-keresés által visszaadott összes URL-címet lekérni az automatikus észlelési terhelés lekéréséhez. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 6. lépésre.Az SCP-ről további információt az MSDN következő cikkében talál: Közzététel szolgáltatáskapcsolati pontokkal.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeScpLookup.

6. lépés: A legfelső szintű tartomány ellenőrzése

Ebben Outlook lépésben a Outlook a kezdeti cím tartománynevének URL-címét https://<tartománynév>/autodiscover/autodiscover.xml formátumban próbálja meg lekérni a hasznos adatokat az eredményül kapott URL-címből. Mivel számos gyökértartomány nincs beállítva az automatikus észleléshez, a Outlook szándékosan elnémít minden tanúsítványhibát, amely az lekérés során előfordul. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 7. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeHttpsRootDomain.

7. lépés: Az automatikus észlelési tartomány ellenőrzése

Ebben a lépésben az Outlook a kezdeti cím tartománynevének URL-címét https://autodiscover.<tartomány>/autodiscover/autodiscover.xml formátumban építi fel, és megpróbálja lekérni a hasznos adatokat az eredményül kapott URL-címből. Mivel ez általában az automatikus észlelési adatok elsődleges URL-címe, Outlook nem némít el semmilyen tanúsítványhibát, amely a beolvasás során előfordul. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 8. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeHttpsAutoDiscoverDomain.

8. lépés: Helyi adatok ellenőrzése

A 2. lépésben Outlook, hogy a rendszergazda telepített-e olyan házirendet, amely kifejezetten az automatikus észlelés hasznos terhelésének beállítását ellenőrzi. Ha nincs házirend a helyén, de az előző lépések nem szerezték be a hasznos adatokat, az Outlook most már anélkül kísérel meg beolvasni egy hasznos adatokat a helyi fájlból, hogy a PreferLocalXML be lenne anélkül, hogy a preferlocalXML be lenne anélkül. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 9. lépésre. Ehhez a lépéshez nincs házirend-szabályozás.

9. lépés: HTTP-átirányítások ellenőrzése

Ebben a lépésben az Outlook kérelmet küld az automatikus észlelési tartomány URL-címére (http://autodiscover.<domain>/autodiscover/autodiscover.xml), és teszteli, hogy nincs-e átirányítási válasz. Ha az alkalmazás egy tényleges automatikus észlelési XML-terhelést ad vissza, és nem átirányítást, a Outlook figyelmen kívül hagyja a tényleges automatikus észlelési XML-választ, mivel az biztonsági beállítás (http) nélkül lett beolvasva. Ha a válasz egy érvényes átirányítási URL-cím, az Outlook, és megpróbál beolvasni egy hasznos XML-t az új URL-címből. Outlook a lépés során tanúsítványellenőrzést is végez a potenciálisan káros URL-címekre való átirányítás megakadályozása érdekében. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook a 10. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeHttpRedirect.

10. lépés: SRV-adatok ellenőrzése

Ebben a lépésben az Outlook dns-lekérdezést hoz létre a "_autodiscover._tcp.<tartománynév>" rekordhoz, és végiglépked az eredményeken a https protokollt használó első rekord keresésével. Outlook majd megpróbálja lekérni a hasznos adatokat az ADOTT URL-címről. Ha ez a lépés nem olvassa be a hasznos adatokat, Outlook 11. lépésre.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeSrvRecord.

11. lépés: Az O365 mint failsafe ellenőrzése

Ha az összes előző lépés nem ad hasznos információt, az Outlook kevésbé szigorú heurisztikus készletet használva határozza meg, hogy hasznos-e az O365-végpontokkal való végső kísérlet. Ha az Outlook úgy dönt, hogy egy kísérlet értékes, próbálja meg az ismert O365-ös automatikus észlelési végpontokat arra az esetre, ha a fiók O365-fiók. Ez a kísérlet a 4. lépéssel azonos cél URL-címeket használ, és csak abban a különbségben különbözik, hogy az automatikus észlelési folyamat utolsó lehetőségként, nem pedig korábban kísérelte meg a próbálkozást.Ennek a lépésnek a házirend-vezérlőértéke a következő: ExcludeExplicitO365Endpoint.

ItAR-szempontok

Ha Outlook erre a lépésre, és nem sikerült lekérni az automatikus észlelés hasznos terhelését, két teszten végezzük, hogy meg kell-e próbálkozni a jól ismert Office 365 végpontokkal. Először is, ha a postaláda egy fogyasztói fiók (outlook.com), a jól ismert végpontot kísérel meg. Másodszor, ha a postaláda úgy van meghatározva, hogy olyan tartományba tartozik, amelyhez nem tartoznak ITAR-követelmények, a rendszer megpróbálk végrehajtani egy jól ismert végpontot. Ha a postaláda úgy van meghatározva, hogy kereskedelmi jellegű, és ITAR-követelményeknek megfelelő tartományhoz tartozik, akkor nem történik kísérlet a jól ismert Office 365 végpontokra. A jövőbeli kiadásokban a 11. lépés a 4. lépéssel azonos logikára ható, és a Office 365 konsigig szolgáltatást hívja. Ha ez a módosítás történik, a cikk frissül az új folyamatlépésnek megfelelően.

Az Automatikus észlelési folyamat szakasz 9. lépésének átirányítási lépése explicit lépés a nem biztonságos átirányítási adatok kezelésére. A többi biztonságos lépésben az automatikus észlelési XML-terhelés lekérése esetén az egyik lehetséges válasz a végponttól egy átirányítási válasz. Ez a válasz azt Outlook, hogy a rendszer egy új, másik URL-címre irányíthatja át, hogy megpróbálja beolvasni a hasznos adatokat. Ezenkívül az átirányítási adatok tartalmazhatnak egy új, másik e-mail-címet is, amely az automatikus észlelési kísérlet célcímeként használható. Outlook három különálló választ tekint "átirányítási válaszoknak":

Http-állapotkód (301,302) új URL-címekkel
Egy 200-as HTTP-állapotkód, amely azonban egy olyan hasznos XML-t tartalmaz, amely azt Outlook, hogy másik URL-címre kell átirányítani az átirányítást
Egy 200-as HTTP-állapotkód, amely azonban hasznos XML-t tartalmaz, amely azt Outlook, hogy másik SMTP-címet használjon célcímként.

Az 1. és a 2. Outlook próbálja meg lekérni az automatikus észlelési XML-t az új URL-címből, feltéve hogy a protokoll a https. Nem biztonságos (http) URL-címeket nem kísérel meg. Ezenkívül még ha az új URL-cím https protokollt is tartalmaz, Outlook tanúsítványadatokat ellenőrizve további biztonsági mértéket nyújt.A 3. eset esetén Outlook a teljes automatikus észlelési folyamatot az elejéről elindítja. Ha az összes lépést (1–11) az új e-mail-cím használata nélkül megkísérli, akkor az Outlook visszatér az eredeti e-mail-címre, az 5. lépésre lép, és folytatja egy XML-terhelés beolvasását az eredeti címmel.

Kivételek: Az Automatikus észlelési folyamat szakasz lépései azok az általános szabályok, amelyek azt szabályják, Outlook hogyan próbálhatja meg be szerezni az automatikus észlelési terhelést. Különféle optimalizálások és kiemelkedő kísérletek is segíthetnek a folyamat némileg megváltozatásában. Új fiók létrehozásakor például az Outlook belsőleg kihagyja a 3. lépést (az Utolsó ismert jó (LKG) adatok ellenőrzése), mert még nem lehet utolsó ismert helyes bejegyzése. Hasonlóképpen, ha egy kísérlet az aktuális konfigurációs adatokkal kapcsolatos hiba miatt lett elindítva, akkor céltudatosan újra automatikus észlelésre van szükség, és nem kívánja használni Outlook LKG-adatokat, mivel az utolsó ismert jó információ valószínűleg hibát eredményezett.

Házirend-szabályozás: Az Automatikus észlelési folyamat szakasz által meghatározott házirendértékek vagy házirendalapú beállításjegyzék-értékek, illetve nem házirendalapú értékek is lehetek. Ha a csoportházirend-objektumon keresztül vagy manuálisan konfigurálja a házirendkulcsot, a beállítások elsőbbséget élveznek a nem házirendkulcshoz képest.Nem házirendkulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Házirendkulcs: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover Minden érték DWORDtípusú.A PreferLocalXML eltér a többi vezérlőértéktől, mivel az 1 típusú Outlook a folyamat ezen lépésének bekapcsolható. A többi érték esetén az 1 érték azt jelzi az Outlooknak, hogy kapcsolja ki vagy hagyja ki a kapcsolódó lépést. Ha például az ExcludehttpsRootDomain értéket 1 értékre állítja Outlook nem végzi el a folyamat 6. lépését.

További beállításjegyzék-vezérlők

Outlook számos további beállításjegyzék-alapú konfigurációs beállítást is biztosít, amelyek hatással lehetnek az automatikus észlelési folyamatra:

A Office 365 konfigurációs szolgáltatás használata

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Érték: EnableOffice365ConfigService Alapértelmezett: 0 Adatok: Állítsa ezt a DWORD adatot 1-re, hogy Outlook az Office 365 konfigurációs szolgáltatását a megfelelő automatikus észlelési URL-címek lekéréséhez.

HTTP időkorrekáció beállításai

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Érték: Időtúllépés Alapértelmezett: 25 másodperc Minimum: 10 másodperc Maximum: 120 másodperc

Információs: A rendszer bizonyos időtúllépéseket használ WinhttpSetTimeouts-beállításokként. A megadott adatok a WinhttpSetTimeouts API mind a négy paraméterének át vannak adva. Ez potenciálisan olyan HTTP-kérést tesz lehetővé, amely nem érhető el gyorsabban időkorrekációhoz, ami javítja az általános teljesítményt. A beállítások lehetővé tehetik azt is, hogy egy 25 másodpercnél hosszabb HTTP-kérés sikeres legyen, ha az időkorceli beállítást egy 25 másodpercnél hosszabbra növeli.Mapi/Http Protocol Control

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Exchange Érték: MapihttpDisabled Alapértelmezett: 0 Adatok: 1 = A protokoll le van tiltva; 0 = A protokoll engedélyezve van

Információs: Ez az érték nem található az Automatikus észlelés kulcs alatt. Ez egy általános beállítás, amely meghatározza, hogy Outlook megpróbálhat-e csatlakozni Exchange Mapi/Http protokollhalom használatával. Alapértelmezés szerint Outlook 2016 protokoll nincs letiltva. Ez lehetővé teszi, hogy az automatikus észlelési folyamat egy speciális élőfejet (X-MapihttpCapability:1) vegyen fel a feltárási folyamatba a Mapi/Http protokoll beállításainak kiértékelése és feldolgozása érdekében.Régi típusú hitelesítés egyeztetésének szabályozása

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC Érték: AllowNegoCapabilityHeader Alapértelmezett: 0 Adatok: 1 = Fejlécek hozzáadása; 0 = A fejlécek nincsenek hozzáadva

Információs: Ez az érték nem található meg az Automatikus észlelés kulcs alatt. Ez a beállítás azt szabályozza, hogy a rendszer hozzáadja-e a hitelesítési egyeztetési fejlécet a http-kérelmekhez. A fejléc tartalma az ügyfélszámítógép hitelesítési képességeitől függ. Példa a fejlécre: "X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP". Ezt a beállításjegyzékbeli értéket és a hozzá adott fejlécet ritkán használják semmilyen modern hitelesítési kötegben, és nagyon valószínűtlen, hogy negatív vagy pozitív módon befolyásolná a tAodiscover folyamatot.Tanúsítvány hibakezelése

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Érték: ShowCertErrors Alapértelmezett: 0 Adatok: 1 = Tanúsítványra vonatkozó figyelmeztetések/hibák megjelenítése; 0 = Tanúsítványra vonatkozó figyelmeztetések megjelenítése

Információs: Ez az érték azt Outlook, hogy miként kezeli a http-feladatok végrehajtásakor kapott tanúsítványhibákat és figyelmeztetéseket. A Outlook bizonyos esetekben felülbírálhatja ezt a beállítást (az Automatikus észlelési folyamat szakasz 6. lépése), de általános esetben, ha ez a beállítás engedélyezve van, az Outlook egy biztonsági párbeszédpanelt jelenít meg, amely megjeleníti a tanúsítványra vonatkozó hibát vagy figyelmeztetést, és engedélyezi a felhasználónak az OK vagy a Http kérés megszakítását. A felhasználó három tanúsítványhibát figyelmen kívül hagyhat, és a Outlook újrapróbálkozást kérheti:

WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – Probléma van a tanúsítványtulajdonságok dátumával
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – Probléma van a tanúsítványtulajdonságok közös nevével
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – Probléma van a hitelesítésszolgáltatóval a tanúsítványtulajdonságok között A három tanúsítványhiba-államról további információt a visszahívási függvénynél WINHTTP_STATUS_CALLBACK talál.

Proxy Authentication Handling

Kulcs: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\ Érték: AllowOutlookhttpProxyAuthentication Alapértelmezett: 0 Data: 1 = Allow Outlook to handle authentication challenges from proxy servers; 0 = a proxykiszolgálók hitelesítésének csendes meghiúsulásán áteső kihívások

Információs: Ez a beállításjegyzékbeli érték lehetővé teszi a biztonsági konfigurációk használatát, és részletesen ismerteti a Microsoft tudásbázisának következő cikkében: 3115474 MS16-099: A Outlook 2010 biztonsági frissítésének leírása: 2016. augusztus 9.

Automatikus észlelés más protokollokhoz

A funkcióként való automatikus észlelést a Outlook is használja a Exchange ActiveSync protokoll (EAS) fiókok felderítése és konfigurálása. Az EAS automatikus észlelési folyamata és döntési folyamata független a jelen cikkben leírt lépésektől. Az EAS-implementáció például nem implementálja az O365-ös végpontlogikát, és nincs egy olyan lépése, amely ellenőrzi az SCP-helyeket. Ez a cikk azokat a részletes lépéseket ismerteti, Outlook az automatikus észlelési kísérletekhez a MAPI-alapú protokollok beszerzése a Exchange.

Hivatkozások

Az automatikus észlelés régi típusú információit a Microsoft Tudásbázis alábbi cikkében olvashatja:

2212902 Váratlan automatikus észlelési viselkedés, ha beállításjegyzék-beállításokat ad meg az \Autodiscover kulcs alatt

Az automatikus észlelésről az alábbi Microsoft-cikkekben talál további információt:

Automatikus észlelés a Exchange

Autodiscover szolgáltatás