Exchange Server 2016 Namespaces - adresy služeb

Tento článek patří do série, která vychází z mých poznámek při migraci Exchange organizace z verze 2010 na 2016. Nejde o kompletní postup, ale o popis hlavních bodů a oblastí. Příklady se týkají určitého daného designu, ale většinou se dají zobecnit. Stejně tak, i když jde o popis přechodu na novou verzi, tak se informace hodí i pro novou instalaci či správu.

Oficiální dokumentace k Exchange Server 2016. Na TechNetu vyšel článek (odkazovaný i z oficiální dokumentace) k tomuto tématu Namespace Planning in Exchange 2016. Případně se mohou hodit další články Exchange Server 2016 Migration - Reviewing Client Access Namespaces, Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2013, Site resilience.

Client Access Namespaces

Nejprve upřesnění. V tomto článku, i jinde, používám záměně (možná ne úplně přesně) termíny adresa a doménové jméno (či DNS jméno nebo jen jméno), příkladem je třeba www.firma.cz. Něco jiného je IP adresa, příklad 80.0.0.1.

Termín Namespace, česky jmenný prostor (v některých případech i adresní prostor), se v souvislosti s Exchange Serverem 2016 používá trochu jinak, než jsem zvyklý. V praxi se nejčastěji potkáváme s Domain Namespace, tedy prostor doménových jmen. V souvislosti s DNS, kde máme třeba Namespace firma.cz a v rámci této domény vytváříme jednotlivé záznamy (jména - adresy). To platí také pro AD DS, které je na DNS založené, máme například AD DS doménu firma.local. Jiný příklad jsou třeba MAC adresy, kdy mají výrobci přiřazený nějaký Namespace (příklad 00:15:5d má Microsoft) a v rámci něj mohou vytvářet adresy.

V popisu Exchange serveru se všude uvádí, že různé služby pro připojení klientů, používají nějaký Namespace. Třeba Autodiscover Namespace nebo Exchange ActiveSync Namespace. Jde o DNS jména, ke kterým se klient připojuje pomocí Outlooku, mobilního zařízení či webového prohlížeče. Tedy běžné adresy, jako je mail.firma.cz a autodiscover.firma.cz. Takže celé plánování jmenných prostorů znamená přiřazení jednoho nebo více doménových jmen ke službám (různé služby mohou sdílet stejné jméno).

Microsoft uvádí, že pro Exchange 2010 byla třeba řada samostatných adres (článek odkazovaný výše píše o 7-mi, ale ten seznam mi přijde podivný) a pokud jsme používali více lokalit (Site), tak pro každou musely být samostatné adresy. Naproti tomu Exchange 2016 situaci velmi zjednodušuje a můžeme využívat společnou adresu pro většinu služeb (uvádí se, že stačí 2, s tím souhlasím, ale jiné než uvádí článek).

Interní a externí jména a Split-Brain DNS

Při plánování adres záleží na tom, zda máme stejnou doménu externí (v internetu) i interní (AD DS), například firma.cz. Pak můžeme mít stejná jména pro připojení ve firmě i z internetu. Nebo interně používáme nějakou neveřejnou doménu (případně jinou než v internetu), třeba firma.local. Kdysi se doporučovalo mít interně neveřejnou doménu, dnes naopak využívat společně veřejnou.

Split-Brain DNS

Dále můžeme využívat Split-Brain DNS (označuje se také Split DNS nebo Split-Horizon DNS). To znamená, že existují dvě verze jedné DNS zóny (domény) a ty mohou poskytovat různé informace. Typicky jedna verze zóny pro interní uživatele (při připojení z interních adres) a druhá v rámci internetu (připojení z veřejných adres). Teoreticky může jít o jeden DNS server, který vrací odpovědi podle připojení. Ale spíše jde o různé DNS servery, interní je dostupný pouze uvnitř firmy, externí standardně spravuje naši veřejnou doménu.

Interně veřejná doména

Pokud máme stejnou interní AD DS doménu jako doménu veřejnou, tak Split DNS (pravděpodobně) využíváme vždy. Interní zóna nám může vracet interní IP adresy pro stejná jména, která jsou na externím DNS serveru přeložena na veřejné IP adresy. Na externím DNS vůbec nebudeme mít řadu interních doménových jmen a záznamů, které se třeba týkají AD DS domény.

Důležité je, že pokud vytvoříme na (interním) DNS serveru nějakou zónu (třeba firma.cz), tak nám tento server odpovídá pouze svými záznamy pro celý zadaný Namespace (doménu, tedy *.firma.cz). Pokud nějaké DNS jméno interně neexistuje, tak nedojde k přesměrování na externí DNS server, kde by se mohlo nacházet. Musíme tedy vytvořit všechny záznamy, které se nachází na externím DNS serveru (pokud mají být interně dostupné).

Interně neveřejná doména

V případě, kdy máme interní AD DS doménu jinou než externí, tak většinou interní DNS obsahuje zónu pouze pro interní jméno a překlad veřejné domény provádí veřejné DNS (dochází k přeposlání dotazu). Pokud potřebujeme některá jména, aby interně vracela jinou IP adresu než externě, tak můžeme využít Split-brain DNS. Udržovat všechna doménová jména dvakrát může být zbytečně náročné. Lze využít (za určitých podmínek) malou fintu a vytvořit pouze vybrané záznamy Jiná IP adresa z DNS interně a externě.

Adresy služeb

Popis výše jsme si uváděli proto, že u Exchange služeb pro připojení klientů můžeme konfigurovat interní adresu (internal host name / URL) a externí adresu (external host name / URL).

Používaná doménová jména a služby

Většina klientských připojení na Exchange server je dnes pomocí protokolu HTTPS (i když je v něm třeba zapouzdřené MAPI). To znamená zjednodušení prostupů, spojení, standardizaci protokolů, ale také potřebu správně řešit certifikáty. Nyní by měl Outlook zvládat změny sítě (třeba LAN na WiFi) a start z hibernace. Další klientské protokoly jsou POP3 a IMAP4, které nemusíme používat. Spíše serverový je pak protokol SMTP. Plánování doménových jmen potřebujeme i pro plánování SAN (Subject Alternative Name) v certifikátu.

Dnes se doporučuje nepoužívat v nastavení služeb přímo jména serverů, ale DNS aliasy nebo samostatné Host záznamy, budu to označovat jako virtuální jméno. Díky tomu při změně serverů (migraci) není třeba měnit nastavení klientů (a případně jim oznamovat nové URL), ale pouze k virtuálnímu jménu přiřadit jiný server. Může se také využívat rozvažování zátěže (Load Balancing).

Virtuální FQDN (Fully-Qualified Domain Name) jméno může mít přiřazeny adresy všech Exchange serverů. Uživatelé znají pouze jednu adresu a klienti se připojují (rozváženě) ke všem serverům. Na Exchange 2010 takto pracovalo CAS Array, které již na Exchange 2016 neexistuje, ale můžeme nativně využít (díky protokolu HTTP) DNS Load Balancing (Round-robin DNS). V principu mi to přijde pořád stejné, jen nekonfigurujeme CAS Array.

Příklad adres:

• Exchange Sever 1: FQDN mail1.firma.local, IP 10.0.0.100
• Exchange Sever 2: FQDN mail2.firma.local, IP 10.0.0.110
• Exchange virtuální jméno: FQDN mail.firma.local, IP 10.0.0.100, 10.0.0.110

Důležitá je vlastnost Exchange Server 2016, kdy se klient může připojit k libovolnému serveru a komunikace se proxuje na server, kde má schránku.

Připojení z internetu (externí)

Na Exchange 2010 jsem používal různá veřejná doménová jména a veřejné IP adresy. Jeden z důvodů byl také různé způsoby autentizace (pro různé služby), které probíhaly na firewallu.

Na Exchange 2016 je obecně doporučení použít pouze jednu veřejnou IP adresu (pokud neřešíme na této úrovni redundanci) a k ní jeden Ačkový DNS záznam a jeden alias (CNAME). Příklad je doménové jméno mail.firma.cz s veřejnou IP adresou 80.0.0.10 a alias autodiscover.firma.cz pro stejné jméno (případně se i bez něj můžeme obejít a využijeme SRV záznam). Toto jméno použijeme pro všechny klientské služby i pro SMTP protokol. Na venkovním firewallu publikujeme SMTP protokol na AntiSPAM bránu v DMZ a HTTPS přes Reverse Proxy na Exchange server.

Připojení uvnitř firmy (interní)

Jeden server

Interně je situace složitější, záleží na tom, kolik máme serverů a kolik lokalit. Jak jsme si popsali výše, tak i v případě jednoho Exchange serveru se doporučuje změnit defaultní nastavení klientských služeb, kde se nastaví vždy přímo jeho doménové jméno, za virtuální jméno.

Více serverů

Pokud máme více serverů, tak platí to samé, na všech serverech nastavíme pro všechny služby společné virtuální jméno (DNS A záznam s IP adresami všech Exchange serverů). Klienti budou rozváženi na servery a komunikace se proxuje na mailbox server se schránkou.

Více lokalit

Nejsložitější je situace, když máme více lokalit (Site) a v nich Exchange servery. Microsoft to nepopisuje úplně jednoznačně, ale pochopil jsem to tak, že nejlepší je také použít jedno společné virtuální jméno a k němu přiřadit adresy všech serverů ve všech lokalitách. Exchange 2016 zvládá Site resilience, takže to není problém.

Podle mých testů to funguje tak, že třeba klient z pobočky dostane adresu serveru v centrále, k němu se připojí, interně se provoz přeposílá na server na pobočce (kde má schránku). Sice se klient dostane k poště, ale session nejde přímo na server, který má na pobočce, ale skrze centrálu. To je zbytečné zatížení a zpomalení. Výhoda je, pokud máme DAG a dojde k pádu některého serveru, tak připojení klientů stále funguje (DB kopie se aktivuje na jiném serveru a klienti jsou směrování na něj, pomocí DNS se připojí na běžící server). Škoda, že nedochází k přesměrování (aby se navázala přímá session) na server, kde má klient schránku, místo přeposílání komunikace.

Pokud to takto nechceme, tak musíme na serveru na pobočce použít speciální virtuální jméno, kde budou pouze servery na dané pobočce. Autodiscover zařídí, že klient dostane vždy adresu ve své lokalitě.

Plánování adres pro služby

Měli bychom mít zdokumentovaný aktuální stav s Exchange 2010 a nyní si připravit plán na nový stav s Exchange 2016. Vytvořit si tabulky (a případně i schémata) se seznamem serverů (jména a IP adresy) a plánované služby (FQDN interně a externě) a pro jejich FQDN interní a externí IP adresy.

Pozn.: Pokud nyní využíváme DAG a CAS Array, tak máme DAG VIP a doménová jména pro DAG i CAS Array. DAG nyní můžeme konfigurovat bez nich a CAS Array se vůbec nepoužívá.

Příklad seznamu poštovních serverů

• FQDN mail1.firma.local, IP 10.0.0.100, Site Praha
• FQDN mail2.firma.local, IP 10.0.0.110, Site Praha
• FQDN mail3.firma.local, IP 10.10.0.100, Site Brno

Příklad seznamu poštovních služeb

Pozn.: Místo seznamu může být přehlednější tabulka. Zapsat si stačí FQDN (jako mail.firma.cz), pro zajímavost si uvedeme také celá URL.

• primární SMTP doména
  • firma.cz
• MAPI over HTTP
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/mapi
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/mapi
• Outlook Anywhere
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/rpc
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/rpc
• Outlook on the web (OWA)
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/owa
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/owa
• Exchange Web Services (EWS)
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/EWS/Exchange.asmx
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/EWS/Exchange.asmx
• Exchange Control Panel (ECP)
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/ecp
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/ecp
• Offline Address Book (OAB)
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/OAB
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/OAB
• Exchange ActiveSync (EAS)
  • Internal: mail.firma.local
  • Internal URL: https://mail.firma.local/Microsoft-Server-ActiveSync
  • External: mail.firma.cz
  • External URL: https://mail.firma.cz/Microsoft-Server-ActiveSync
• Autodiscover
  • AutoDiscoverServiceInternalUri: https://mail.firma.local/Autodiscover/Autodiscover.xml
  • External: autodiscover.firma.cz
  • External URL: https://autodiscover.firma.cz/Autodiscover/Autodiscover.xml

Pozn.: Pro připojení z Outlooku interně se dříve používal protokol MAPI/RPC a připojení z internetu Outlook Anywhere (MAPI/RPC over HTTP - to je MAPI uvnitř RPC uvnitř HTTP). Nyní je hlavní protokol MAPI over HTTP (MAPI zapouzdřené v HTTP), pokud jej klient nepodporuje, tak využije Outlook Anywhere.

Doménová jména a IP adresy

• FQDN mail.firma.local, IP 10.0.0.100, 10.0.0.110, 10.10.0.100
• FQDN mail.firma.cz, IP 80.0.0.10
• FQDN autodiscover.firma.cz, alias mail.firma.cz - IP 80.0.0.10

Pozn.: I v případě, kdy máme neveřejnou interní doménu, můžeme využít Split-Brain DNS a všude používat pouze veřejné doménové jméno.

Zjištění aktuálního nastavení

Když si chceme vypsat aktuální nastavení, tak můžeme něco hledat v GUI, lépe si vypsat nastavení jednotlivých služeb pomocí PowerShellu nebo třeba použít připravený skript, který vypíše vše najednou GetExchangeURLs.ps1. Můžeme tak i zkontrolovat nastavení všech serverů, zda jsme někde nezapomněli změnit adresu.

Pokud využíváme protokoly POP a IMAP, tak si můžeme vypsat důležité údaje.

Get-PopSettings | FT *ConnectionSettings,X509*
Get-ImapSettings | FT *ConnectionSettings,X509*