Csere 2013 együttélés | Autodiscover infrastruktúra | 2/2 rész | 12#23

A jelenlegi cikk középpontjában az Exchange Autodiscover infrastruktúra áll a belső/privát környezetben.

Jelen cikkünkben a következő témákat tekintjük át:

1. Az Exchange Autodiscover környezet általános áttekintése
2. Az Exchange Autodiscover infrastruktúra sajátos karakterei Exchange 2013 együttélési környezetben
3. Az „Autodiscover központosított modell” bevezetésének oka
4. Az Active Directory SCP (szolgáltatási kapcsolódási pont) és az Exchange Autodiscover névregisztrációs koncepciói és kezelése a PowerShell használatával.

A mostani cikk az előző cikk folytatása: Exchange 2013 együttélési környezet | Autodiscover infrastruktúra | rész 1/2

Az Autodiscover infrastruktúra általános fogalmai a belső hálózati környezetben

Mielőtt az Exchange belső Autodiscover leírásától kezdenénk az Exchange 2013 együttélési környezet forgatókönyvében, fontos áttekinteni az Autodiscover logikájának néhány alapfogalmát a belső Exchange környezetben, és csak ezután lépjünk tovább az Autodiscover leírására. Exchange 2013 együttélési környezetben.

1. forgatókönyv: A belső automatikus felfedezési folyamat az Exchange webhelyen

A „szabványos belső automatikus felismerési folyamat” egyetlen Exchange-helyi környezetben a következő módon valósul meg:

A csere-CAS-kiszolgáló regisztrálja magát az Active Directory SCP-ben (szolgáltatási csatlakozási pont).

Amikor az Exchange-ügyfeleknek (Autodiscover-ügyfélnek) meg kell találniuk az Autodiscover-végpontot (Exchange CAS-kiszolgáló), lekérdezi az Active Directory-t, megkapja a meglévő Exchange CAS-kiszolgálók listáját, és megkeresi az Exchange CAS-kiszolgálót, hogy megkapja a szükséges automatikus felfedezési információkat.

2. forgatókönyv: A belső automatikus felfedezési folyamat több Exchange-webhely környezetben

A „belső Autodiscover folyamat” több Exchange-helyes környezetben a következő módon valósul meg:

Mindegyik Exchange CAS-kiszolgáló regisztrálja magát az Active Directory SCP-ben (Service Connection Point).

Amikor az Exchange-kliensnek meg kell találnia az Autodiscover végpontot (Exchange CAS-kiszolgáló), lekérdezi az Active Directory-t, megkapja a meglévő Exchange CAS-kiszolgálók listáját, és kiválasztja a listából a legmegfelelőbb Exchange CAS-kiszolgálót az „Active Directory webhely” alapján. ingatlan.

Az Exchange-kliensek mindig szívesebben csatlakoznak a „helyi Exchange CAS-kiszolgálóhoz”, amely ugyanabban az Active Directoryban található, mint ő.
A mi forgatókönyvünk szerint a „piros Exchange-kliens” inkább az 1. helyen lévő Exchange CAS-kiszolgálóhoz csatlakozik. a szükséges automatikus felfedezés információinak megszerzése.
A mi forgatókönyvünk szerint a „Sárga Exchange-kliens” inkább a 2. helyen lévő Exchange CAS-kiszolgálóhoz csatlakozik, hogy megkapja a szükséges Autodiscover-információkat.

Belső Autodiscover infrastruktúra Exchange 2013 együttélési környezetben

Az Exchange 2013 együttélési környezet forgatókönyve megköveteli a belső Autodiscover infrastruktúra beállításainak végrehajtását.

Az együttélési környezetben a belső Autodiscover infrastruktúra legjobb gyakorlata azon a koncepción alapul, amelyben az Exchange 2013 CAS „Autodiscover fókuszpontként” szolgál.

A kifejezés jelentése az, hogy a több Exchange-helyen megvalósított alapértelmezett Autodiscover infrastruktúra helyett, amelyben mindegyik Exchange-helynek saját „saját” automatikus felfedezési végpontja van, egy Exchange 2013 együttélési környezetben, az Exchange CAS. A 2013 „felváltja” az „autodiscover információ másik forrását” (a régebbi Exchange CAS-szervereket), és a modell „központosított modellré” alakul, amelyben csak egyetlen forrás található az automatikus felfedezés információinak: az Exchange CAS 2013.

1. forgatókönyv: Exchange 2013 együttélési környezet |Egyetlen Exchange-webhely-környezet

Ennek a forgatókönyvnek az alapszabálya egyetlen Exchange-hely, amely az Exchange-kiszolgálók több verzióját tartalmazza. Technikailag mindegyik Exchange CAS kiszolgáló képes Autodiscover szolgáltatásokat nyújtani, de ahogy korábban említettük, a „régi Exchange CAS szerver” lehetősége korlátozott, hogy Autodiscover szolgáltatásokat nyújtson a „fejlettebb Exchange ügyfeleknek”.

Például az Exchange 2007 CAS nem fogja tudni biztosítani a szükséges automatikus felfedezési szolgáltatásokat az Exchange 2013 ügyfél számára.

Emiatt a megoldás az lesz, hogy az Exchange CAS 2013 kiszolgálót „koronázzuk meg” a különböző típusú Exchange-kliensek „Automatikus felfedezési fókuszpontjává”.

A következő ábrán láthatunk egy példát arra a koncepcióra, amelyben az Exchange CAS 2013 kiszolgáló válik az Autodiscover szolgáltatások fókuszpontjává a belső Exchange-ügyfelek számára egy adott Exchange-helyen.

A különböző Exchange-kliensek mindegyike, például: Exchange 2007, 2010 és 2013, az Exchange CAS 2013-as kiszolgálót keresi, amely Autodiscover szolgáltatásokat keres. Az Exchange CAS 2013 szerver „elég intelligens” ahhoz, hogy tudja, vagy megadja a szükséges „Autodiscover választ” az Exchange-ügyfeleknek a verziójuk alapján.

2. forgatókönyv: Exchange 2013 együttélési környezet | Több Exchange webhely környezet | Központosított Autodiscover modell

A jelenlegi forgatókönyv szerint a szervezet Exchange-infrastruktúrája több Exchange-helyes infrastruktúrán alapul.

Az Exchange 2013 együttélési környezetben az Exchange 2013 együttélési környezet válik az „autodiscover információk fő forrásává” még azon Exchange-kliensek számára is, amelyek fizikailag egy másik Exchange-helyen találhatók.

Ebben a forgatókönyvben az Autodiscover Exchange-ügyfelek minden egyes kelléke (az összes webhelyről származó Exchange-ügyfél) mindig az 1. helyen lévő Exchange CAS 2013 kiszolgálóhoz lesz címezve.

Amikor az Exchange CAS 2013 kiszolgáló az 1. helyszínen megkapja az automatikus felderítési kérelmet, azonosítja az Exchange-ügyfelet, lekérdezi az Active Directory-t az adott felhasználóról, és megtudja, hogy mi a pontos „Exchange-ügyfélverzió”.

Például abban az esetben, ha az Exchange-kliensek olyan kliensek, amelyek postaládáját az Exchange 2010 postafiók-kiszolgáló tárolja, az Exchange CAS 2013-kiszolgáló „megérti”, hogy meg kell adnia egy adott automatikus feltárási információt az adott Exchange 2010-es ügyfél számára.

Ebben a forgatókönyvben az Exchange CAS 2013 kiszolgáló proxyként küldi el a kérést az Exchange 2010 CAS kiszolgálóhoz (az Exchange 2010 CAS kiszolgáló ugyanabban az Active Directoryban van, mint az Exchange kliens), lekéri a szükséges Autodiscover információkat az Exchange 2010 CAS kiszolgálóról, és megadja ezeket az információkat. az Exchange 2010 klienshez.

Exchange 2013 együttélési környezetben elosztott Autodiscover modell | A tiltott modell

Az előző részben át kell tekintenünk az Autodiscover infrastruktúra legjobb gyakorlati konfigurációját az Exchange 2013 együttélési környezetben.

Technikailag a „legjobb gyakorlat” nem kötelező, és emellett nem ismerem a Microsoft hivatalos cikkét, amely leírja az Exchange 2013 együttélési környezetben az Autodiscover infrastruktúrára vonatkozó legjobb gyakorlati ajánlásokat.

Tegyük fel, hogy valamilyen oknál fogva nem hajlandó elfogadni a legjobb gyakorlat ajánlását, és inkább a „standard Autodiscover infrastruktúrát” használja.

Egy apró támpont: a következő részben bemutatjuk, milyen következményekkel járhat, ha nem használjuk a legjobban bevált Autodiscover modellt az Exchange 2013 együttélési környezetben.

Egy „nem Exchange 2013 együttélési környezetben” vagy homogén Exchange-környezetben több Exchange-helyet tartalmazó forgatókönyv esetén mindegyik Exchange-hely rendelkezik egy „helyi Exchange CAS-kiszolgálóval”, amely automatikus feltárási végpontként szolgál a helyi Exchange-ügyfelek számára.

Ennek a koncepciónak a bemutatásához használjuk a következő forgatókönyvet.

A szervezeten belül három Active Directory-hellyel és két Exchange-hellyel rendelkezik (az egyik vállalati webhely nem tartalmazza az Exchange infrastruktúrát).

• Az 1. oldal az Exchange 2013 infrastruktúrán alapul.
• A 2. oldal az Exchange 2007 infrastruktúrán alapul

A két Exchange CAS-kiszolgálóval kapcsolatos információk az SCP-nél (Service Connection Point) az Active Directoryban vannak regisztrálva.

A következő ábrán azt láthatjuk, hogy a mi forgatókönyvünkben az Active Directory SCP két különböző Exchange CAS-kiszolgálóról tartalmaz információkat.
Az Exchange CAS-kiszolgáló az 1. helyről és az Exchange CAS-kiszolgáló a 2. helyről.

Amikor a belső Exchange 2013-ügyfél az 1. webhelyről megkeresi az Autodiscover-végpontot, egy listát kap, amely tartalmazza az Exchange 2007 CAS és az Exchange 2013 CAS nevét. Mivel az „1. hely Exchange-ügyfél” és az Exchange 2013 CAS ugyanazon a helyen található, az 1. hely Exchange-ügyfele az Exchange 2013 CAS-t választja.

Ugyanez a logika kerül megvalósításra a belső Exchange 2007 kliensben is a 2. helyről. Amikor a „2. hely Exchange-ügyfél” lekérdezi az Active Directory-t, megkapja az elérhető Exchange CAS-kiszolgálók listáját, akkor inkább a helyi Exchange CAS-kiszolgálót fogja megszólítani: az Exchange 2007 CAS.

Az általunk áttekintett „elosztott” Autodiscover infrastruktúra azt a problémát okozhatja, hogy egy Exchange-kliens hozzáfér a „rossz Exchange CAS-kiszolgálóhoz”.

Amint már említettük, az Exchange CAS-szerver modernebb verziója ki tudja szolgálni a „natív Exchange-klienseket” (olyan Exchange-klienseket, amelyek verziója megegyezik az Exchange CAS-szerverével), valamint a régi Exchange-klienseket.

Például - Az Exchange 2013 CAS ki tudja szolgálni az Exchange 2013 kliens + Exchange 2007 ügyfél automatikus feltárási kérelmét.

Ez a szabály nem vonatkozik az Exchange CAS-kiszolgáló korábbi verzióira. Az Exchange 2007 CAS ki tudja szolgálni az Exchange 2007 kliens automatikus feltárási kérelmét, de nem tudja kiszolgálni az Exchange 2013 kliens automatikus feltárási kérelmét.

1. probléma: Exchange-webhely helyi Exchange CAS-kiszolgáló nélkül

A következő forgatókönyvben egy Exchange 2013 ügyfél az Active Directory 3. helyén található. Amikor az Exchange 2013 ügyfél lekérdezi az Active Directoryban az elérhető Exchange CAS-kiszolgálók listáját, megkapja az Exchange 2013 CAS + Exchange 2007 CAS nevét.

1. kérdés: Melyik Exchange CAS-kiszolgálót választja az Exchange-kliens a listáról?
V1: A válasz az, hogy ebben a forgatókönyvben az Exchange 2013-ügyfél véletlenszerűen választ ki egyet. az Exchange CAS-kiszolgáló nevéből.

• Abban az esetben, ha az Exchange 2013 ügyfél az Exchange 2013 CAS nevét választja, az automatikus felderítési folyamat sikeresen befejeződik.
• Abban az esetben, ha az Exchange 2013 ügyfél az Exchange 2007 CAS nevét választja, az automatikus felderítési folyamat nem fejeződik be sikeresen.

2. probléma: Más Active Directory-helyeken található Exchange-kliens.

A jelenlegi forgatókönyvek a következők: egy Exchange 2013 kliens, amely az 1. helyhez „tartozik”, felkeresi a másik vállalati webhelyet: a 2. webhelyet.
Az Exchange 2013 Autodiscover kliens használatakor hozzon létre egy lekérdezést, amely az elérhető Exchange CAS-kiszolgálók nevét keresi. , a „válasz” két nevet fog tartalmazni: az Exchange 2013 CAS az 1. helyen és az Exchange 2007 CAS a 2. helyen.

Ebben a forgatókönyvben az Exchange 2013 kliens az Exchange 2007 CAS címet választja, mert az ő szempontjából ez a „legközelebbi Exchange CAS-kiszolgáló”.

Ebben az esetben az automatikus feltárási folyamat nem fejeződik be sikeresen, mert az Exchange 2007 CAS nem tudja megadni a „helyes automatikus feltárási információkat” az Exchange 2013 ügyfélnek.

Exchange 2013 együttélési környezet | Az Active Directory SCP szükséges frissítései

Amint azt az előző szakaszokban említettük, az Exchange 2013 együttélési környezetben egy „centralizált Autodiscover modellt” kell megvalósítanunk, amelyben az Exchange CAS 2013 szolgál majd az Autodiscover információk „főforrásaként”.

Ennek a „központosított Autodiscover modellnek” a megvalósítása az Active Directory SCP-ben meglévő Autodiscover információk frissítésével valósul meg. A szükséges frissítések végrehajtása előtt az Active Directory SCP „mutatókat” fog tartalmazni a régebbi Exchange CAS-kiszolgálókra.

Alapértelmezés szerint minden Exchange CAS-kiszolgáló tudja, hogyan kell automatikusan regisztrálnia magát az Active Directoryban, egy speciális rendszermappában, melynek neve: SCP (Service Connection Point).

Az Exchange együttélési környezetben ez az „alapértelmezett viselkedés” problémás forgatókönyveket okoz, mivel amikor az Exchange kliens lekérdezi az Active Directoryban az elérhető Exchange CAS kiszolgáló(k) listáját, az Exchange CAS szerverek listája információkat fog tartalmazni az Exchange CAS szerverről/ s különböző szerververziókkal.

Például - egy Exchange 2013-as kliensnek be kell szereznie egy Autodiscover infrastruktúrát.
Az Exchange 2013-as kliens az Exchange webhelyen található, amely három különböző Exchange CAS-kiszolgálóval rendelkezik.

A következő ábrán az Exchange CAS-verziók három „generációját” tartalmazó Exchange infrastruktúra forgatókönyvét láthatjuk.

Az Exchange-kliens lekérdezi az Active Directory-t, és megkapja a három automatikus felderítési URL-címet tartalmazó listát.
A fő probléma az, hogy az Exchange 2013-as kliensnek most a következő a problémája: hogyan lehet eldönteni, hogy melyik Exchange CAS-kiszolgáló nevét válassza?

A sikeres Autodiscover események matematikai valószínűségének kiszámítására szolgáló képlet a nem sikeres Autodiscover eseményekhez képest meglehetősen bonyolult lehet.
Olyan konfigurációt kell megvalósítanunk, amelyben az Autodiscover folyamat az esetek 100%-ában sikeresen befejeződik!

Annak érdekében, hogy kiküszöbölhessük azt a forgatókönyvet, amelyben egy „újabb Exchange-kliens” egy „régebbi Exchange CAS-kiszolgálót” címez, el kell távolítanunk minden olyan mutatót az Active Directory SCP-ről, amely az Exchange-ügyfelet a régi Exchange-infrastruktúrára irányítja, és karban kell tartanunk az Autodiscover-mutatókat. csak az Exchange 2013 infrastruktúrára (mutató az Exchange 2013 CAS-kiszolgálókra).

A mi forgatókönyvünk szerint el kell távolítanunk a mutatót az Active Directory SCP-ből: Exchange 2010 CAS szerver: cas2010-01.o365info.com és az Exchange 2007 CAS szerver: cas2007-01.o365info.com

Amikor egy levelezőkliens (2007, 2010 vagy 2013) lekérdezi az Active Directory-t, az Active Directory „válasz” csak az Exchange 2013 CAS-kiszolgáló nevét fogja tartalmazni.

Az Exchange CAS 2013 szerver, az Autodiscover szolgáltatások kaméleonja

Érdekes metaforaként, amellyel leírhatjuk az Exchange CAS 2013 „viselkedését” az Autodiscover kliensek különböző verzióival kapcsolatban, lehet: egy Exchange CAS 2013 kaméleonként.

Ugyanúgy, ahogy a kaméleon megváltoztatja a bőrszínét az adott környezet alapján, amelyben tartózkodik, és „alkalmazkodni” az új infrastruktúrához, az Exchange CAS 2013 is hasonló módon működik.

Amikor az Exchange 2013 CAS „elfogadja” az Autodiscover kéréseket, addig nem válaszol az Autodiscover ügyfélnek, amíg nem ellenőrzi az Exchange-ügyfélverziót. Az Exchange-kliens verziója alapján az Exchange 2013 CAS egy „egyéni folyamatot” valósít meg, amely az Autodiscover válaszával végződik, amely az adott Exchange-ügyfélre szabott Autodiscover információkat tartalmaz.

Az Exchange CAS 2013 által használt Autodiscover információk forrása

Amint már említettük, az Exchange CAS 2013 tudja, hogyan biztosíthatja az egyes Exchange-kliensek Autodiscover-ügyfelei számára a szükséges Autodiscover-információkat.

Felmerülhet a kérdés: honnan tudja az Exchange CAS 2013, hogy mi a „megfelelő Autodiscover információ?

Vagy más szóval, milyen forrásokból származnak azok az információk, amelyeket az Exchange CAS 2013 használ a szükséges automatikus felderítéshez az Exchange-kliensek különböző típusaihoz (verzióihoz)?

A válasz az, hogy az Exchange CAS 2013 tudja, hogyan kezelje a további „forrásokat” a szükséges Autodiscover információk megszerzéséhez.

A következő diagramon láthatunk egy példát az Exchange 2013 CAS-kiszolgáló által az Exchange-kliensek különböző verzióinak kiszolgálására szolgáló különböző „Automatikus feltárási folyamatokra”.

Például: amikor az Exchange 2010-es ügyfél (olyan Exchange-ügyfél, amelynek postaládája az Exchange 2010-es postafiók-kiszolgálón található) csatlakozik az Exchange 2013-as CAS-kiszolgálóhoz, az Exchange 2013-as CAS-kiszolgáló az Exchange-ügyfelet „Exchange 2010-ügyfélként” ismeri fel.
A Emiatt a kérelmet az Exchange 2010 CAS-kiszolgálóhoz proxy-ként továbbítja, megkapja a szükséges Autodiscover információkat, és „elküldi” az információkat az Exchange 2010 kliensnek.

Kezelje az automatikus felderítési információkat az Active Directory SCP-ben

Annak ellenére a hivatalos nyilatkozat ellenére, hogy: „ez a cikk komolyan nem egy „hogyan kell” cikkek, hanem „általános koncepció és építészeti cikkek”, fontos, hogy „kis ízelítőt” kapjunk a „technikai rész” megvalósításában. szükséges Autodiscover infrastruktúra frissítések Exchange 2013 együttélési környezetben.

Frissítse az Active Directory SCP-t

Az Active Directory SCP-ben tárolt „belső automatikus felderítési információk” frissítésének módja egy PowerShell-parancs használatával történik.

Az általunk használt PowerShell-parancsok a következők:

• Get-ClientAccessServer - az Active Directory SCP-ben tárolt információk megtekintéséhez.
• Set-ClientAccessServer - az Active Directory SCP-ben tárolt információk frissítéséhez.

A szükséges Autodiscover konfigurációk Exchange 2013 együttélési környezetben való demonstrálásához használjuk a következő forgatókönyvet:

A szervezet három Exchange-verzióval rendelkezik Exchange 2013 együttélési környezetben.

Ahhoz, hogy az Exchange 2013 együttélési környezetben megvalósíthassuk az Autodiscover infrastruktúra legjobb gyakorlatát, meg kell valósítanunk a „központosított Autodiscover modellt”.

A „központosított Autodiscover modellt” a következőképpen hajtják végre: eltávolítanak minden Autodiscover-mutatót a régi Exchange 2007/2010 CAS-ra, és konfigurálják a belső Autodiscover infrastruktúrát az „új Exchange 2013 CAS”-ra.

A belső Autodiscover infrastruktúra névtere

A „belső Autodiscover infrastruktúra névtere” kiválasztásánál olyan modellt választhatunk, amelyben a belső Active Directory névtér nem azonos a külső Autodiscover névtérrel (disjunkt modul), vagy az azonos külső és belső Autodiscover névtér másik modelljével.

A jelenlegi forgatókönyv egy olyan modulon alapul, amelyben a belső Autodiscover névtér nem azonos a Nyilvános Autodiscover névtérrel.

A mi forgatókönyvünk szerint az Exchange CAS 2013-at központi automatikus felfedezési pontként „közzétesszük” az Exchange CAS 2013 FQDN-je (belső neve) használatával. Az általunk regisztrált automatikus felderítési URL az Exchange CAS 2013 gazdagépnevén alapul: sts.o365info.com

A következő diagramon láthatjuk a végrehajtandó feladatokat. Frissíteni fogjuk a régi Exchange CAS-kiszolgáló meglévő Autodiscover URL-címét, amelyek az Active Directory SCP-n vannak regisztrálva, hogy „mutassák” az Exchange 2013 CAS-t.

1. Belső Autodiscover információk megtekintése

Az Active Directory SCP-ben megjelenő Autodiscover Endpoint aktuális információinak megtekintéséhez a PowerShell parancsot használjuk:

Get-ClientAccessServer | FL auto*

A következő képernyőképen a három Exchange CAS-szerver (EX01, EX02 és STS) adatait láthatjuk.

Ha megvizsgáljuk a következő tulajdonságot: AutoDiscoverServiceInternalUri, láthatjuk, hogy az Exchange CAS-kiszolgálók mindegyike „regisztrálta magát” az Active Directory SCP-n.
Az Exchange CAS-kiszolgálók mindegyike „ kijelenti magát ” Autodiscover végpontként.

Mindegyik Exchange CAS-kiszolgáló PowerShell parancssori felületéről, de tapasztalataim szerint a legjobb gyakorlat az, ha ezt a parancsot az „újabb Exchange-verzió” PowerShell-konzoljáról hajtjuk végre.
A mi forgatókönyvünkben: az Exchange CAS 2013 szerver PowerShell-konzolja.

2. A belső automatikus felfedezés információinak frissítése

A régi Exchange CAS-kiszolgáló infrastruktúrával kapcsolatos „információk eltávolítása” feladat nem az adatok törlésével valósul meg az Active Directory SCP-ből, hanem a PowerShell Set-ClientAccessServer futtatásával, amely frissíti az Active Directory SCP-ben lévő információkat, így a Az automatikus felfedezés URL-címe az Exchange CAS 2013 szerverre mutat (sts.o365info.com).

A PowerShell parancs szintaxisa tartalmazza az Exchange CAS-kiszolgáló nevét, így elméletileg a szükséges Set-ClientAccessServer PowerShell parancsot bármelyik Exchange CAS-kiszolgáló PowerShell-konzoljáról futtathatjuk.

Tapasztalataim szerint a legjobb gyakorlat a PowerShell futtatása, amely frissíti egy adott Exchange CAS-kiszolgáló Autodiscover Endpoint URL-jét az Exchange CAS-kiszolgáló PowerShell-konzoljáról.

Például: abban az esetben, ha az Exchange CAS 2013 Server PowerShell konzolt használjuk a Set-ClientAccessServer parancs futtatásához, amelynek frissítenie kell az Exchange 2010 CAS-szerver Autodiscover URL-címét (EXO1), akkor a következő hibaüzenet jelenik meg Megjelenik:

Ezt a módosítást nem hajthatja végre, mert 'CN=EX01,CN=Servers,CN=Exchange Administrative Group.
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft
Exchange,CN= A Services,CN=Configuration,DC=o365info,DC=local' csak olvasható az Exchange jelenlegi verziójában.

CategoryInfo : InvalidOperation: (:) [Set-ClientAccessServer], CannotModifyCrossVersionObjectException

FullyQualifiedErrorId : [Server=STS,RequestId=b041d5d1-c2a3-4117-9dd3-061253859afc,TimeStamp=11/21/2014 2:11:03
PMDatego-CilurosmCionnotify Kivétel] 96B3710A,Microsoft.Exchange.Management .System
ConfigurationTasks.SetClientAccessServer

PSComputerName: sts.o365info.local

A „helyes út” az egyes meglévő Exchange CAS-kiszolgálók automatikus felismerésének URL-címének frissítéséhez a következő eljárás végrehajtásával:

Az Exchange 2010 CAS-kiszolgáló PowerShell-konzoljában (EX01) a következő PowerShell-parancsot fogjuk futtatni:

Set-ClientAccessServer -Identity EX01 -AutoDiscoverServiceInternalUri: "https://STS.o365info.local/Autodiscover/Autodiscover.xml"

Az Exchange 2007 CAS-kiszolgáló PowerShell-konzoljában (EX02) a következő PowerShell-parancsot fogjuk futtatni:

Set-ClientAccessServer -Identity EX02 -AutoDiscoverServiceInternalUri:"https://STS.o365info.local/Autodiscover/Autodiscover.xml"

A következő képernyőképen láthatjuk az eredményeket: a három Exchange CAS-szerver információi továbbra is megjelennek az Active Directory SCP-ben (STS, EX01 és EX02), de ha megnézzük az AutoDiscoverServiceInternalUri értéket, láthatjuk, hogy az FQDN név frissítve az Exchange CAS 2013 szerver FQDN-jére: sts.o365info.com