Autodiscover forgatókönyvek vállalati környezetben | 16. rész #36

Az Exchange on-Premises infrastruktúrát úgy alakították ki, hogy egy kisvállalat igényeit szolgálja ki, ugyanakkor egy olyan vállalati vállalkozás igényeit is kielégítse, amelynek több ezer vagy akár több tízezer felhasználó számára kell levelezési szolgáltatásokat nyújtania.

A vállalati környezet főbb szereplői:

1. Több Exchange-kiszolgáló használata több Active Directory-helyen.
2. A terheléselosztási és magas rendelkezésre állási megoldások megvalósításának szükségessége az Exchange infrastruktúrához.

Az előző cikkben (Autodiscover flow Active Directory alapú környezetben | Part 15#36) áttekintjük az Autodiscover-ügyfél, például az Outlook és egy adott Exchange CAS-kiszolgáló közötti kommunikációs csatornát.

A mostani cikkben a vállalati környezetben megszokott fejlettebb vagy összetettebb forgatókönyvre szeretnék „továbblépni”.

Az Autodiscover egy nagyon „rugalmas lény”, amelyet egyszerű infrastruktúrához, ugyanakkor összetett és összetett infrastruktúrához terveztek.

A következő cikkben a lehetséges Exchange on-Premises forgatókönyvek egy részét „kóstoljuk meg” vállalati környezetben, így jobban megérthetjük, hogyan valósulnak meg az Autodiscover szolgáltatások több Active Directory és Exchange szerverkörnyezetben. .

Az Autodiscover szolgáltatások „viselkedésének” ismerete más Exchange infrastruktúrában és környezetekben segíthet az Autodiscover hibaelhárítási forgatókönyvében.

1. forgatókönyv: Több Exchange CAS-kiszolgáló ugyanazon az Active Directory-helyen

Az ugyanazon az Active Directory webhelyen található több Exchange CAS-kiszolgáló forgatókönyve népszerű forgatókönyv egy olyan nagy vagy vállalati szervezetben, amely olyan Exchange infrastruktúrát használ, amely egyszerre nagy mennyiségű Exchange-klienst tud kiszolgálni, és válaszokat tud adni olyan témákra, mint pl. - Magas rendelkezésre állás és optimalizálja a teljesítményt.

Technikailag nincs korlátozás az Exchange CAS-szerverek mennyiségére vonatkozóan, amelyeket egy adott Active Directory webhelyen használhatunk.

Ezenkívül semmit sem kell tennünk vagy konfigurálnunk ahhoz, hogy ezt az Exchange CAS-kiszolgálót elérhetővé tegyük az Exchange-ügyfél számára, mivel az Exchange CAS-kiszolgálók regisztrációja az Active Directory SCP-ben automatikusan megvalósul.

Minden alkalommal, amikor egy Autodiscover kliens lekérdezi az Active Directory SCP-t az elérhető Autodiscover végpontokról (Exchange CAS-kiszolgálókról), a válasz tartalmazza az URL-t és az FQDN-t az Exchange CAS-kiszolgálók mindegyikéhez.

A diagramon láthatjuk, hogy amikor az Autodiscover kliens lekérdezi az Active Directory-t, az Autodiscover kliens két „opcionális Autodiscover Endpoint” nevet kap. ”

Abban az esetben, ha az összes Autodiscover Endpoint „tartozik” ugyanahhoz az Active Directory webhelyhez, az Autodiscover kliens véletlenszerűen kiválasztja az Autodiscover Endpoint (Exchange CAS-kiszolgáló) nevét a listáról, és megpróbálja megszólítani.

Abban az esetben, ha az Autodiscover Endpoint nem válaszol, az Autodiscover Endpoint „továbblép” a listában a következő gazdagépre, amelyre választ kapott az Active Directory lekérdezéséből.

A leírt módszer, amelyben az Autodiscover kliens csak „kiválaszt” egy Exchange-kiszolgálónevet a listából, nem teszi szükségessé a terheléselosztást.

Az Exchange CAS-kiszolgálók terheléselosztási megoldásának témája gyökeresen megváltozott az Exchange 2013 architektúra és az Exchange 2010 architektúra között.

Nem térünk ki az Exchange környezet „terheléselosztási és magas rendelkezésre állási világának” konkrét részleteibe, hanem megelégszünk egy nagyon egyszerű magyarázattal.

Magas rendelkezésre állású megoldás megvalósítása Exchange környezetben, egy logikai Exchange szervernév használatával megvalósítva, amely két vagy több „fizikai Exchange” kiszolgálót reprezentál.

A terheléselosztás és a magas rendelkezésre állás megoldásának Exchange-környezetben való implementálásakor nem azt az alapértelmezett beállítást használjuk, hogy az Exchange CAS-szerverek automatikusan regisztrálják magukat az Active Directory SCP-ben, hanem manuálisan regisztráljuk a nevet, ha a logikai entitás, amely a meglévő Exchange CAS-kiszolgálókat képviseli.

Minden alkalommal, amikor egy Autodiscover kliens lekérdezi a helyi Active Directoryban a nevet (URL), ha az Autodiscover Endpoint, a válasz tartalmazza azt az URL-címet, amely a logikai entitás FQDN-jét használja, például azt az FQDN-t, amelyet a terheléselosztóhoz választott. képviseli ” a meglévő helyszíni Exchange CAS-kiszolgálókat.

Más szóval - az Autodiscover kliens nem csatlakozik közvetlenül egy adott Autodiscover végponthoz, hanem csatlakoztatja azt a logikai entitást (például a terheléselosztást), amely „továbbítja” a kérését egy adott Exchange CAS-kiszolgálóhoz.

2. forgatókönyv: Több Exchange CAS-kiszolgáló több Active Directory-helyen | Active Directory webhely helyi Exchange CAS-kiszolgáló nélkül

A következő forgatókönyvben a következő Active Directory és Exchange infrastruktúrára építünk:

Egy cégnek három fizikai telephelye van - New York-i telephelye, Los Angles-i telephelye és egy szál cég telephelye Bangkokban.

Az Exchange infrastruktúra a következőképpen valósul meg:

Exchange CAS server name

Helyszíni Active Directory webhely

ex01.o365info.local

NY

ex01.o365info.local

Bangkok

N/A

LA

A Los angles webhely nem tartalmaz Exchange infrastruktúrát.

A New York-i webhely Exchange szerverén található összes „Los Angles felhasználó” postafiókja.

A fő kérdés az, hogy abban az esetben, ha a „Los Angles oldalról érkező felhasználóknak” (az Exchange CAS-szerver közvetítésével) össze kell kapcsolniuk Exchange-postafiókjukat, akkor melyik Exchange CAS-kiszolgálóval kell kapcsolatba lépniük?

Első pillantásra a válasz egyértelműnek tűnik - a Los Angeles-i felhasználók valószínűleg a New York-i oldalon található Exchange CAS-szerverhez fognak fordulni, mivel a „New York Exchange CAS-szerver” földrajzilag közelebb van hozzájuk, mint a bangkoki webhely Exchange CAS-szervere. .

Nos, a valóságban a válasz nem ilyen egyszerű.
Technikai szempontból az Exchange-kliens nem tudja, ki a „megfelelő Exchange CAS-szerver”. Az Exchange-ügyfél számára az egyetlen mód a helyi Active Directory lekérdezése.

A mi forgatókönyvünkben a válasz két Exchange CAS-kiszolgálónév listát tartalmaz:

• ex01.o365info.local a New York Exchange CAS-szerver
• ex03.o365info.local a Bangkok Exchange CAS-szerver

Ami akut módon fog történni, az az, hogy a Los Angles Exchange-kliens véletlenszerűen kiválasztja az Exchange CAS-kiszolgálók nevét a listáról.

Statisztikailag a csatlakozási kérelmek 50%-a a New York Exchange CAS-kiszolgálóra (ex03.o365info.local), a csatlakozási kérelmek másik 50%-a pedig a Bangkok Exchange CAS-szerver (ex03.o365info.local).

A mögöttes feltételezés az, hogy szeretnénk elkerülni ezt a forgatókönyvet, mert nincs értelme annak, hogy a Los Angles felhasználók a „világ másik felén” található Bangkok Exchange CAS szerveren keresztül csatlakozzanak postafiókjukhoz.

A jó hír az, hogy létezik megoldás erre a „problémára”, melynek neve: Webhely-affinitás

A Webhely-affinitás opció lehetővé teszi számunkra, hogy egy adott Exchange CAS-kiszolgálót „megjelöljünk” egy vagy több Active Directory-webhely preferált szervereként.

A mi forgatókönyvünk szerint a New York Exchange CAS-kiszolgáló automatikusan regisztrálva lett a New York-i webhely Exchange CAS-kiszolgálójaként.

A mi forgatókönyvünkben szeretnénk „megmondani” a Los Angles Exchange-ügyfélnek, hogy előnyben részesítsék a New York Exchange CAS-szervert (ex01.o365info.local).

Ennek a követelménynek a megvalósításához „köthetünk” vagy „csatolhatunk” egy további Active Directory-webhelynevet a New York Exchange CAS-kiszolgálóhoz.

Ennek a „kötésnek” a megvalósítása, amelyben a New York Exchange CAS-kiszolgálót egy olyan szitaként határozzuk meg, amely előnyben részesíti az Exchange CAS-kiszolgálót a Los Angles-felhasználók számára, amelyet az Active Directoryban regisztrált adott Exchange-értékek szerkesztésével valósítanak meg - Kulcsszó

A feladat elvégzése után ettől a naptól kezdve a Los Angeles-i Exchange-kliens minden alkalommal lekérdezi az Active Directoryban elérhető Exchange CAS-szervereket, mivel a New York Exchange CAS-kiszolgáló (ex01.o365info. helyi) kulcsszóval rendelkezik, amely tartalmazza a webhely nevét (LA), akkor inkább ehhez az Exchange CAS-kiszolgálóhoz csatlakoznak.

3. forgatókönyv: Belső levelezőkliens „Külső” Autodiscover szolgáltatásokat keres

A következő részben egy olyan forgatókönyvet tekintünk át, amelyben egy szervezet magán/helyi vállalati hálózathoz csatlakozó felhasználója megpróbál új Outlook levelezési profilt létrehozni a nyilvános hálózaton található Exchange Online postafiókhoz való csatlakozáshoz.

Népszerű példa lehet az Office 365-felhasználók, akiket postaládája az Exchange Online-ban tárolt.

A szervezet Exchange on-Premises infrastruktúrát használ, de a mi forgatókönyvünk szerint az adott felhasználónak a „külső Exchange infrastruktúrához” (Exchange Online) kell csatlakoznia, nem pedig az Exchange on-Premises infrastruktúrához.

Vegye figyelembe, hogy a mi forgatókönyvünkben a felhasználó egy szervezet asztalát használja, amely hozzáférhet a helyszíni Active Directoryhoz.

Az Outlook-kliens alapfeltevése az, hogy - a helyi Active Directory képes megadni a szükséges információkat az elérhető Autodiscover végpontok Autodiscover Endpoint neveiről (URL-ekről, ha pontosabbak akarunk lenni).

Technikailag az Outlook-ügyfél nem tudja, hogy a csatlakozni kívánt postafiók nem egy helyszíni Exchange-kiszolgálón található.

Ahhoz, hogy a példa valós legyen, használjuk a következő forgatókönyvet:

• Az Active Directory domain neve -o365info.lcoal
• A nyilvános SMTP-domainnév: o365info.com
• A szervezetnek két Active Directory\ Exchange webhelye van: a New York-i webhely és a Los angels webhely. Az Active Directory-helyek mindegyike tartalmazza az Exchange CAS-kiszolgálót.
• A New York-i webhely Exchange CAS-szerverének neve: ex01.o365info.com
• Az Exchange CAS szerver neve a Los Angles webhelyen: ex02o365info.com
• A külső Exchange Online szerveren tárolt tartományfelhasználó e-mail címe: Bob@Ihaveaverysmallbrain.com
• Bob a cég New York-i telephelyén található.

1. fázis - a helyszíni Active Directory csatlakoztatása

Az Outlook-ügyfél csatlakozik a helyszíni Active Directoryhoz, és kéri az elérhető Exchange helyszíni kiszolgálók listáját.

Vegye figyelembe, hogy a helyi Active Directory tartománynév és az e-mail SMTP tartománynév között nincs „kapcsolat” vagy kapcsolat.

Az Active Directory elküldi az Autodiscover ügyfélnek a regisztrált SCP-objektumok (Exchange CAS-kiszolgálók) listáját.

Példánkban a lista két Exchange-kiszolgáló nevét tartalmazza:
ex01.o365info.local és ex03.o365info.local (1 szám a diagramon).

2. fázis - csatlakozás az egyes helyszíni Exchange CAS-kiszolgálókhoz

Az első automatikus felfedezési végpont, amelyhez az Outlook-ügyfél megpróbál csatlakozni, az ugyanazon az Active Directory-helyen található Exchange CAS-kiszolgáló.

A „furcsa” az, hogy az Autodiscover ügyfélnek (Outlook) sikerül megtalálnia és kommunikálnia az Exchange on-Premises szerverrel ex01.o365info.local

Amikor az Autodiscover kliens megpróbálja megszerezni a szükséges Autodiscover információkat (az autodiscover.xml választ), az Exchange CAS-kiszolgáló „negatív választ” küld, mivel az Exchange CAS-kiszolgáló (ex01.o365info.local) nem felelős, vagy ha pontosabbak akarunk lenni - nem mérvadó a Bob@Ihaveaverysmallbrain.com domain esetében (a diagramon a 2 szám ).

Megjegyzés - az Autodiscover kommunikációs folyamata sikeresen befejeződik, mert az Exchange CAS-szerver - ex01.o365info.local rendelkezik egy tanúsítvánnyal, amely tartalmazza a megadott FQDN-t, az Autodiscover kliens biztosíthatja a szükséges felhasználói hitelesítő adatokat. stb.

Annak ellenére, hogy az Autodiscover összes alapvető lépése sikeresen megtörtént, a folyamat nem fejeződhet be, mert az ex01.o365info.local nem felelős (hiteles) a névtérért - Ihaveaverysmallbrain.com

Az Autodiscover logaritmus azon a módszeren alapul, amelyben, ha a lista „első automatikus felfedezési végpontja” nem tudja megadni a szükséges információkat, az Autodiscover kliens „áthelyezi” a következő névre a listán (ha van ilyen név).

A mi forgatókönyvünk szerint az Active Directory által biztosított automatikus felfedezés végpontja a további nevet is tartalmazza - ex03.o365info.local

Az Outlook levelezőprogramja feltételezi, hogy ez a „megfelelő automatikus feltárási végpont”, amely biztosítja a szükséges automatikus felfedezési információkat.

Az Outlook az ex03.o365info.local Exchange CAS-kiszolgálót kezeli, és ismét az a feltételezés, hogy az Outlook megtalálja az ex03.o365info belső IP-címét. helyi, sikerül befejeznie a kölcsönös hitelesítési folyamatot, de a folyamat nem fejezhető be sikeresen, mert az ex03.o365info.local szintén nem felelős vagy nem mérvadó a domain névért - Ihaveaverysmallbrain.com (3 a diagramon).

3. fázis - az automatikus felfedezés végpontjának keresése az SMTP-tartománynév használatával

Ez az a fázis, amelyben az Autodiscover kliens megérti, hogy nem tudja továbbra is használni az „Active Directory Autodiscover módszert.

A „következő Autodiscover módszer” úgy valósul meg, hogy „kicsomagolja” az SMTP tartomány nevét a címzett e-mail címéből, és csatlakozik egy DNS-kiszolgálóhoz, amely megkeresi a „Gazdanév” IP-címét. ”

A mi forgatókönyvünk szerint az Outlook kibontja a tartománynevet - Ihaveaverysmallbrain.com , és bekéri a DNS-kiszolgálót ennek a tartománynak az IP-címéhez.

Abban az esetben, ha a DNS-kiszolgáló IP-címe a tartománynévhez van hozzárendelve, a DNS-szerver megadja a kliensnek (Outlook) az IP-címet (az ábrán a 4 szám).

4. fázis - csatlakozás a „külső” Exchange-kiszolgálóhoz

Az Outlook a következő URL használatával próbál csatlakozni az Autodiscover végponthoz - Https://Ihaveaverysmallbrain.com/Autodiscover/Autodiscover.xml

Az Outlook kliens lekérdezi a DNS-kiszolgálót. Tekintettel arra, hogy az összes szükséges konfigurációt előzetesen alkalmazták, a DNS olyan választ fog adni, amely tartalmazza az Exchange Online infrastruktúra IP-címét.

Az Autodiscover kliens befejezheti a folyamatot a „külső Exchange CAS-kiszolgálóval”.

Az Outlook-kliens megkeresi az Exchange Online-t, kiegészíti a kölcsönös hitelesítési folyamatot, és kérést küld az automatikus felfedezés információira.

Az Exchange Online elküldi az Outlooknak (az Autodiscover ügyfélnek) a szükséges automatikus felfedezési információkat.

Az Outlook-kliens az Autodiscover.xml fájlban található információkat használja fel egy új Outlook levelezési profil létrehozásához, és lehetővé teszi a felhasználó számára, hogy csatlakozzon „távoli” vagy „külső” Exchange Online postafiókjához.