A tartománynév, az FQDN és az URL-cím alapjai | Csere infrastruktúra |Rész 09#36

Az Exchange kliens és az Exchange szerver közötti kommunikációs csatorna egy egyszerű koncepción alapul, amelyben az Exchange kliens az Exchange hosztnévvel vagy pontosabban az Exchange szerver FQDN-jével címzi meg az Exchange szervert.

Az Exchange-kiszolgáló által az Exchange webszolgáltatásokért könyörgő Exchange-ügyfelei számára kínált szolgáltatások sokféleségét, és a webmail kliens szolgáltatásaival, például az OWA-val befejezve, az Exchange-ügyfél valósítja meg, amely egy URL-cím használatával éri el ezt az Exchange-szolgáltatást.

Ami az Exchange-kiszolgáló és az Outlook-ügyfél közötti kapcsolatokat illeti, ezeket az információkat az Exchange-kiszolgáló által biztosított Autodiscover-válaszon keresztül csomagolják és szállítják egy Outlook-ügyfélbe.

Amint azt egy korábbi cikkben említettük, minden nyilvános Exchange-kiszolgálónak két azonosítója van - a privát és a nyilvános azonosítás.

Amikor az Exchange információkat nyújt az elérhető Exchange webszolgáltatásokról, az információ két különböző „formátumban” jelenik meg:

• A belső Outlook ügyfélre vonatkozó információk
• A külső Outlook ügyfélre vonatkozó információk

A fő különbség a belső és a külső Outlook-ügyfél számára biztosított információk között az Exchange webszolgáltatások URL-címe.

• A belső Outlook-ügyfélre vonatkozó információk közé tartozik az Exchange webszolgáltatások URL-címe, amely a belső Exchange FQDN-t használja.
• A külső Outlook-ügyfelekre vonatkozó információk közé tartozik az Exchange webszolgáltatások URL-címe, amely a külső Exchange FQDN-t használja.

URL cím koncepció és Exchange webszolgáltatások

Bár láthatóan ismerjük a webcím (URL) használatának fogalmát, szeretném a következő részt az Automatikus felfedezés és az URL-cím témakörének szentelni, mert ez a téma nem olyan egyszerű, mint amilyennek látszik.

Az „Autodiscover-szakemberré” vezető utunk során ismernünk kell

1. Az Exchange webszolgáltatások URL-címének szerkezete
2. A különböző rész, amely a cím webszolgáltatások URL-címét tartalmazza
3. Az Exchange által a belső és a külső levelezőkliensek számára biztosított eltérő URL-cím.

Ezenkívül a felmerülő kérdés a következő lehet:

1. Hogyan állítja be az Exchange CAS-kiszolgáló a webszolgáltatások URL-címét?
2. „Beavatkozzunk” az Exchange webszolgáltatások URL-címének alapértelmezett beállításaival?
3. Milyen forgatókönyvek esetén kell végrehajtanunk ezt a „beavatkozást”?
4. Vannak bevált módszerek az Exchange webszolgáltatások URL-címére vonatkozóan?

És szokás szerint erre a kérdésre nincs egyszerű válasz.
A jelenlegi cikkben az Exchange webszolgáltatások URL-címének „fizikai szerkezetére” fogunk összpontosítani.

Az URL-cím szerkezete | Magas szintű kilátás

Kezdjük egy nagyon egyszerű kérdéssel:
K. Tudod, mit jelent az URL?

V: Nos… nem foglak akadémiai vitákkal untatni, de azoknak, akik nem tudták a választ, az URL az -uniform Resource locator rövidítése.

A legtöbben az - " URL " kifejezést asszociatív módon kapcsolják össze olyan kifejezésekkel, mint a - böngésző, webhely stb.

A „böngésző” csak egy példa az „ügyfélre”, amely webalapú szolgáltatásokat fogyaszthat.

A valóságban sokféle „kliens” létezik, amely webalapú szolgáltatásokat vehet igénybe.
Az Outlook például olyan kliens, amely nagymértékben függ az Exchange webszolgáltatásaitól.

Az URL-cím szerkezete

Az URL-cím olyan, mint egy rejtvény, sok részből áll.

Az URL-cím „könyörgése” „kijelenti” azt a protokollt (a nyelvet), amelyen a kliens és a szerver használni fogja. Exchange alapú környezetben a webszolgáltatások a HTTP protokoll és a HTTPS protokoll (a HTTP protokoll titkosított változata) használatával biztosíthatók.

Az URL-cím „középső része” tartalmazzon információkat a gazdagépről vagy a webszolgáltatást biztosító „elem” nevét.

Legtöbbször azok az elnevezési konvenciók, amelyeket arra használunk, hogy „mutassunk” arra a gazdagépre, amely az FQDN (teljesen minősített tartománynév) elnevezési konvención alapuló konkrét webszolgáltatásokat nyújt.

Az URL-cím „utolsó része” vagy „jobb része” tartalmazza az adott webszolgáltatás elérési útját. Az „útvonal” nem kötelező része az URL-címnek.

A „way” opciót arra az esetre használjuk, ha az adott gazdagép néhány webszolgáltatást nyújtott, vagy a klienst egy adott mappára vagy fájlra szeretnénk irányítani.

Például az Exchange CAS-kiszolgáló sokféle webszolgáltatást biztosít. Ha az Exchange-ügyfeleknek egy adott webszolgáltatásra van szükségük az Exchange CAS-kiszolgálóról, az Exchange-ügyfeleknek az Exchange CAS-kiszolgáló nevét és az adott webszolgáltatás elérési útját tartalmazó URL-cím használatával kell megkeresniük az Exchange CAS-kiszolgálót.

Ebben a cikkben csak az Exchange webszolgáltatások URL-címének „középső részére” (a gazdagépnévre vagy az FQDN-névre) összpontosítunk, mert ha egy adott Exchange webszolgáltatás URL-címét kell konfigurálnunk vagy módosítanunk, frissítjük vagy beállítjuk az Exchange hosztnévhez kapcsolódó részt.

Az a forgatókönyv, amelyben frissítjük az Exchange webszolgáltatások URL-címének „útvonal” részét, nagyon ritka, és nem ajánlott.

Gazdanév és FQDN név

A gazdagépnév egy logikai név, amelyet egy adott hálózati „elem” megcímzésére használunk.
A gazdagépnév kifejezést „egyetlen névként” vagy „egyszavas névként” határozhatjuk meg.

Az FQDN kifejezés jelentése - Fully Qualified Domain Name.
Számomra az FQDN szó mindig furcsán hangzik.

A „Fullly Qualified Domain Name” kifejezés az elnevezési konvenciót határozza meg, de az FQDN kifejezés a „Teljes gazdagépnévre” vonatkozik, szemben a „Host” kifejezéssel, amely egyetlen gazdagépnévvel minősít.

Az FQDN a következő képlettel jön létre:

Ahhoz, hogy jobban megértsük a hosztnév és az FQDN név kifejezés közötti különbséget, egy szabványos „emberi címhez” viszonyulhatunk. ”

Amikor valakire a János nevet használjuk, ez a gazdagépnév kifejezés megfelelője. A „John” név nem tekinthető egyedi azonosítónak.

Abban az esetben, ha csomagot kell küldenünk Jánosnak, akkor olyan címet kell használnunk, amely egyedi azonosító lesz, és lehetővé teszi számunkra, hogy megbizonyosodjunk arról, hogy a csomag a kívánt célcímzetthez került-e el.

Ebben az esetben János „teljes” vagy „teljes” címét használjuk, amely tartalmazza a családnevét, utcacímét, városát és így tovább.

Azt mondhatjuk, hogy John „Teljes címe” megegyezik azzal a forgatókönyvvel, amelyben egy adott gazdagépet megszólítunk az FQDN használatával a hálózati környezetben.

Technikailag egy belső hálózatban meg tudunk szólítani egy adott „gazdagépet” csak a gazdagépnév használatával, de legtöbbször a „kiszolgálók” vagy a szolgáltatásokat nyújtó gazdagépek megszólításának előnyben részesített módja a gazdagép FQDN-jének használata.

Nyilvános hálózati környezetben a gazdagépek megszólításának egyetlen módja az FQDN használata.

Domain név

A domain név egy elnevezési konvenció is, amely egy adott struktúrán alapul.
A hivatalos domain név egy szervezet nevéből és a domain név utótagjából épül fel.

Domain utótag

Minden domain névnek van utótagja (mint minden felsorolásnak címe). A domain név besorolható privát vagy nyilvános.

Privát domain név utótagja

Nem nyilvános utótagon alapuló privát domain név utótag (és igen, tudom, hogy a mondat nem olyan egyértelmű).
Más szóval - a privát domain név utótagja nem publikálható a nyilvános hálózaton. Abban az esetben, ha privát domain név utótagot szeretnénk használni, technikailag bármilyen nevet ki tudunk találni, akinek szeretnénk.

Például a privát domain név utótagjának elérhető opciója lehet blabla, a teljes domain név pedig - o365info.blabla

A nyilvános domainnevek utótagja.

A nyilvános domain név utótagja nyilvános utótag alapján.
Amennyiben nyilvános domain név utótagot szeretnénk használni, meg kell vásárolnunk a domain nevet egy nyilvános szolgáltatótól, és korlátozott mennyiségű nyilvános domain név áll rendelkezésre utótag közül választhatunk.

A nyilvános domain név utótaggal rendelkező gazdagép közzétehető és elérhető a külső hálózaton lévő gazdagépek számára (és a belső\privát hálózat gazdagépei számára is).

A következő diagramon láthatunk egy példát egy domain névre privát domain név utótaggal - o365info.lcoal

És további példa nyilvános domain névre, például - o365info.com

Az Active Directory domain neve

Minden Active Directorynak rendelkeznie kell tartománynévvel.

Az első DC-kiszolgálót telepítő személy által védett Active Directory-tartománynév. Az Active Directory rendszergazdái eldönthetik, hogy milyen típusú tartományt válasszanak az Active Directory tartománynév utótagjaként.

Abban az esetben, ha az adminisztrátor inkább privát tartománynevet szeretne használni az Active Directory számára, a tartománynév általános utótagja - local

A „helyi” domainnév utótag nem kerül közzétételre a nyilvános hálózaton.

A következő diagramon láthatunk egy példát az Active Directory adminisztrátor számára elérhető lehetőségekre.

Az Active Directory rendszergazdája választhat „belső névteret” az Active Directory számára, például - o365info.lcoal vagy „külső névteret”, például - o365info.com .
A „com” utótag egy nyilvános domain név utótagja.

Active Directory tartománynév és Exchange infrastruktúra

Az Exchange-infrastruktúra „integrált” vagy „összefonódott” az Active Directory infrastruktúrába.

A csereinfrastruktúra nem „élhet” az Active Directoryn kívül, vagy más szavakkal; az Active Directory platformként szolgál az Exchange infrastruktúrához, és az Exchange infrastruktúra az Active Directory erdő határához van „kötve”.

Az egyes Exchange-kiszolgálók alapértelmezett teljes tartománynevű tartománya

Az Exchange gazdagépnévből + a helyi Active Directory tartománynévből felépült minden Exchange-kiszolgáló alapértelmezett teljes tartománynevét.

Abban az esetben, ha privát tartománynév-utótagot használunk az Active Directory tartományhoz, az Exchange „örökli” az Active Directory tartománynevet, és ennek eredményeként az összes Exchange-kiszolgáló FQDN-je az Active Directory privát tartománynév-utótaggal fog rendelkezni.

Elméletileg ebben a forgatókönyvben nincs „ártalom”, de a probléma az Active Directory infrastruktúra és az Exchange infrastruktúra eltérő természete miatt jött létre.

Amikor az Active Directory infrastruktúrához kapcsolódunk, az az alapfeltevés, hogy"""""""""""""""""""""""""""tavivetárral soha nem akarja lehetővé tenni a belső Active Directory elérését.

Az Exchange infrastruktúrával kapcsolatban nem valósítható meg az a koncepció, hogy „elrejtik” a belső gazdagépet, vagy megakadályozzák a külső gazdagépek hozzáférését a privát gazdagépekhez. Legtöbbször „le kell fednünk” az Exchange Server (nyilvános Exchange-kiszolgáló) egy részét, hogy a külső gazdagépek, például a külső Exchange-kliensek kommunikálni tudjanak az Exchange-kiszolgálóval.

Ahhoz, hogy teljesíthessük az „Exchange-erőforrások közzététele” követelményt, a nyilvános domain nevet kell használnunk a szükséges gazdagép közzétételéhez.

Például a külső Exchange-kliensek a nyilvános Exchange CAS-kiszolgálót FQDN-nel, például - mail.o365info.com

A nyilvános Exchange CAS-kiszolgáló két azonossága

Abban az esetben, ha az Exchange CAS-kiszolgáló egy „nyilvános Exchange-kiszolgáló”, és az Active Directory egy privát tartománynéven alapul, az eredmény a következő:
Az Exchange CAS-kiszolgálónak két különböző „identitása” lesz.

1. Belső - „Active Directory” identitás
2. Nyilvános identitás

Az „identitás” kifejezés az Exchange CAS-kiszolgáló által használt FQDN-t írja le.

• Ha egy Exchange-ügyfélnek meg kell címeznie egy Exchange CAS-kiszolgálót, az Exchange-ügyfél az Exchange CAS-kiszolgáló privát vagy nyilvános azonosítóját (FQDN) fogja megszólítani.
• Amikor az Exchange-ügyfeleknek egy adott Exchange-webszolgáltatást kell használniuk, az Exchange-ügyfél olyan URL-címet fog használni, amely tartalmazza az adott Exchange webszolgáltatást biztosító Exchange-kiszolgáló privát vagy nyilvános identitását (FQDN).

Exchange webszolgáltatás és URL-cím

Exchange-kiszolgáló, számos webszolgáltatást nyújt Exchange-ügyfeleinek.

Az Exchange CAS-kiszolgáló egy adott Exchange-webszolgáltatást az URL-cím használatával „mutat ki”. Más szóval - az Exchange-ügyfelek egy URL-cím használatával érik el az Exchange webszolgáltatást.

Ebben a részben az Exchange webszolgáltatásokhoz használt URL-cím egy nagyon specifikus részére - az FQDN-re - szeretnék összpontosítani.

Az előző részben egy olyan forgatókönyvet tárgyalunk, amelyben az Active Directory egy privát domain néven alapul, és egy további domain név használatának szükségességét is tárgyaljuk: egy nyilvános domain név, amelyet a nyilvános Exchange szerver használ, akinek kommunikálnia kell. külső Exchange-kliensekkel.

Ebben a forgatókönyvben meg kell valósítanunk egy olyan forgatókönyvet, amelyet „két különböző identitásként” írok le, és amelyeket a nyilvános Exchange-kiszolgálóhoz rendelnek. A külső identitás és a belső identitás.

1. példa - Outlook-kliens Exchange CAS-kiszolgálót keres

Amikor az Outlook-ügyfél megpróbálja megkeresni az elérhető Exchange CAS-kiszolgálót, a következő folyamat kerül végrehajtásra.

• Egy belső Outlook-kliens (az Outlook-kliens a belső vállalati hálózaton található) a „privát FQDN” használatával fogja megszólítani az Exchange CAS-kiszolgálót.
• Egy külső Outlook-kliens (az Outlook-kliens a belső vállalati hálózaton található) a „nyilvános FQDN-je” használatával fogja megszólítani az Exchange CAS-kiszolgálót.

2. példa - információk közzététele az Exchange webszolgáltatásról

Amikor az Exchange CAS-kiszolgáló válaszol egy automatikus feltárási kérésre, az automatikus felfedezés kétféle információt tartalmaz az Exchange webszolgáltatásairól:

• Információk a belső Autodiscover kliensek számára, amelyek az adott Exchange webszolgáltatást biztosító Exchange szerver privát FQDN-jét tartalmazó URL-címen alapulnak.
• Információk a külső Autodiscover kliensek számára, amelyek az adott Exchange webszolgáltatást biztosító Exchange-kiszolgáló nyilvános FQDN-jét tartalmazó URL-címen alapulnak.

Exchange webszolgáltatások és URL-címstruktúra

Exchange szerver, számos webalapú szolgáltatást nyújt. A különböző Exchange webszolgáltatások mindegyikét egy dedikált URL-cím „képviseli”.

Annak ellenére, hogy a különböző Exchange webszolgáltatásokhoz dedikált URL-címet használunk, az általunk használt URL-cím egy alapvető struktúrán alapul, amely az Exchange webszolgáltatások összes URL-címében használatos.

A „standard” Exchange webszolgáltatás URL-címe négy részből áll:

1. Protokoll neve

Az URL-cím első része a protokoll neve.
A HTTP vagy a HTTPS protokoll használatával megvalósított webszolgáltatások cseréje.
Az Exchange szerver és kliensei közötti kommunikáció legtöbbször a protokoll használatával történik. HTTPS protokoll.

2. FQDN név

Az FQDN név a „Teljes gazdagépnév”, amely tartalmazza a gazdagépnevet + a tartománynevet.

Abban az esetben, ha az Exchange-kiszolgáló nincs nyilvános hálózatnak kitéve, az Exchange CAS-kiszolgáló FQDN-je a „helyes kiszolgálónév” (a kiszolgáló NetBIOS neve) + a belső Active Directory tartománynévből épül fel.

Abban az esetben, ha az Exchange CAS-szerver „nyilvános Exchange-kiszolgálóként” van konfigurálva, az Exchange CAS-szerver nyilvános FQDN használatával „felfedte” magát, és emellett legtöbbször rendelkezhet és lesz is néhány FQDN-név.

Egynél több „nyilvános FQDN” szükségessége a „nyilvános Exchange-kiszolgáló” által nyújtott szolgáltatásoktól függ.

3. Mappa neve

Az Exchange által nyújtott minden webszolgáltatáshoz tartozik egy „dedikált virtuális mappa”.

Például az Exchange-kiszolgáló automatikus felfedezési szolgáltatása egy dedikált - Autodiscover nevű mappa használatával valósul meg.

Amikor az Exchange-ügyfeleknek egy adott szolgáltatást kell igénybe venniük, az Exchange-ügyfélnek ismernie kell és használnia kell azt az URL-címet, amely egy adott „mappanevet” tartalmaz, amely az általa igényelt szolgáltatásokat képviseli.

4. A fájl neve

Az URL-cím utolsó része tartalmazhat fájlnevet. Például az Autodiscover szolgáltatások forgatókönyvében az URL-cím, amelyet az Autodiscover kliens használ, tartalmazza annak a fájlnak a nevét, amelyet az ügyfél kér a kiszolgálótól.
Az Autodiscover kliens egy - autodiscover.xml

Példa a belső és a külső automatikus felismerés URL-címére

Az Exchange CAS-kiszolgáló „kettős identitásának” fogalmának bemutatása érdekében tekintsük át a belső Exchange-kliensek által használt Autodiscover URL-címet, illetve a külső Exchange-kliensek által használt Autodiscover URL-címet.

Forgatókönyvi charták:

Egy szervezet privát tartománynevet használ Active Directory tartománynévként.
Az Active Directory tartománynév: o365info.local

A szervező nyilvános domain név - o365info.com

Az Exchange CAS-kiszolgáló neve - exo1

Egy forgatókönyv szerint az Exchange CAS-kiszolgáló kiszolgálja a belső Exchange-ügyfeleket, valamint segít a nyilvános vagy külső Exchange-ügyfeleknek.

A következő diagramon az Autodiscover webszolgáltatás URL-címének alapstruktúráját láthatjuk.

URL-cím automatikus felfedezése | belső Exchange-kliensek

Példánkban az Exchange CAS-kiszolgáló automatikusan regisztrálja magát az Active Directory SCP-jében a következő gazdagépnév használatával - ex01.o365info.local

Ha pontosabbak akarunk lenni, az Exchange CAS-szerver a következő URL-címen regisztrálja az Autodiscover URL-címet az Active Directory SCP-jében:
https://ex01.o365info.local /autodiscover/autodiscover.xml

Amikor a belső Outlook-kliens elindítja az automatikus felfedezési folyamatot, az Outlook-ügyfél a Helyszíni Active Directoryból megkapja az Exchange Autodiscover szolgáltatás URL-címét, és az URL-címből „kivonja” az Exchange CAS-kiszolgáló gazdagépnevét - ex01.o365info.local, és kérdezze le a belső DNS-t ehhez a gazdagépnévhez.
A DNS „válasz ” tartalmazza az Exchange CAS-szerver belső\privát IP-címét.

URL-cím automatikus felfedezése | külső Exchange-kliensek

Példánkban, amikor egy külső levelezőkliensnek, például az Outlooknak új Outlook-levélprofilt kell létrehoznia a John@o365info.com címhez, az Outlook „feltételezi”, hogy az Automatikus felderítés URL-címe kövesse: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

Ahhoz, hogy csatlakozhasson a nyilvános Exchange-kiszolgálóhoz, az Outlook „kivonja” az Exchange-kiszolgáló FQDN-nevét a nyilvános automatikus felderítési címből.

A mi forgatókönyvünk szerint - autodiscover.o365info.com

Az Outlook-kliens megszólítja a nyilvános DNS-kiszolgálót, és lekérdezést küld a gazdagép nyilvános IP-címére vonatkozóan.

A kettős identitás cseréje | azonos vagy eltérő FQDN-t használ?

Az Exchange rendszergazdák egyik legalapvetőbb és legfontosabb döntése az Exchange névtér infrastruktúrájával kapcsolatos döntés.

Az alapfeltevésünk az, hogy az Exchange infrastruktúrájának egy része nyilvános felületként lesz konfigurálva, és emiatt az Exchange-nek belső + külső Exchange-klienseket kell kiszolgálnia.

Más szavakkal, a nyilvános Exchange-kiszolgálónak két különböző felülete lesz.

1. lehetőség - elválasztott névtér használata

Ebben az esetben a nyilvános Exchange-kiszolgálók mindegyike más névteret használ minden egyes „identitása” számára.

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

• A belső Active Directory tartománynév - o365info.local
• A szervezet nyilvános domain neve - o365info.com

Például

• Az Exchange-szerver „belső identitását” a gazdagép neve fogja képviselni - ex01.o365info.local
• Az Exchange-szerver „külső identitását” a gazdagép neve fogja képviselni - mail.o365info.com és autodiscover.o365info.com

Egy belső Exchange-ügyfél, amelynek meg kell címeznie az Exchange-kiszolgálót, és az Autodiscover infrastruktúrát keresi, a gazdagépnév - ex01.o365info.local használatával fogja megszólítani az Exchange-kiszolgálót.

Egy külső Exchange-kliens, amelynek meg kell szólítania az Exchange-kiszolgálót, és az Autodiscover infrastruktúrát keresi, az Exchange-kiszolgálót a következő gazdagépnévvel fogja megkeresni: autodiscover.o365info.com

2. lehetőség - egységes névtér használata

Ebben az esetben ugyanazt a névteret fogjuk használni az Exchange szerver minden egyes „identitása” esetében.

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

• A belső Active Directory tartománynév - o365info.local
• A szervezet nyilvános domain neve - o365info.com

A fő különbség az, hogy ebben a forgatókönyvben nem használjuk a helyi Active Directory tartománynevet az Exchange gazdagépnév részeként.

Az általam egységes névtérként leírt forgatókönyvben az Exchange-kiszolgáló „közzétételre kerül” a belső + külső Exchange-kliens számára a nyilvános domain névtér használatával.

• Az Exchange szerver „belső identitását” a gazdagép nevek képviselik - mail.o365info.com és autodiscover.o365info.com
• Az Exchange-kiszolgáló „külső identitását” a gazdagép nevek képviselik - mail.o365info.com és autodiscover.o365info.com

Egy belső Exchange-ügyfél, amelynek meg kell címeznie az Exchange-kiszolgálót, és az Autodiscover infrastruktúrát keresi, az Exchange-kiszolgálót a gazdagépnév használatával fogja megszólítani - autodiscover.o365info.com

Egy külső Exchange-kliens, amelynek meg kell szólítania az Exchange-kiszolgálót, és az Autodiscover infrastruktúrát keresi, az Exchange-kiszolgálót a következő gazdagépnévvel fogja megkeresni: autodiscover.o365info.com

A múltban a „trend” az volt, hogy hangsúlyozzák a „belső Exchange környezetek” és a „külső Exchange környezetek” közötti különbséget. ”

Ennek a tendenciának az az oka, hogy az elválasztott névtér használata biztonságosabb, mivel az „elválasztás” megvédi a belső Exchange infrastruktúrát a külső gazdagépek nem kívánt hozzáférésétől.

Az a véleményem, hogy a „logikai szétválasztás” valójában nem védi a belső Exchange infrastruktúrát, mert a valóságban a védelmet és a szétválasztást különböző megoldások valósítják meg.

Az elválasztott névtér fogalmának használata bonyolultabbá teszi az Exchange rendszergazdák életét, és megzavarja a felhasználókat.