KAPITOLA 6. Přenos zpráv a architektura směrování v Exchange 2007

Transkript

1 KAPITOLA 6 Správa serverové role V této kapitole: Přenos zpráv a architektura směrování v Exchange 2007 Správa serverové role Správa velikosti zpráv a limitu počtu příjemců Sledování zpráv v Exchange Serveru 2007 Prohlížeč Exchange 2007 Queue Viewer Nástroj Exchange Mail Flow Troubleshooter Nastavení Serveru jako transportního serveru do Internetu

2 236 Kapitola 6: Správa serverové role Úvod Serverovou roli Exchange 2007 je vhodné instalovat na server, jenž je členem domény, a vždy je nutné ji instalovat na vnitřní síti a nikoli v demilitarizované zóně, jak to možná někdo dělá. server nahrazuje předmostí (bridgehead server), které známe z Exchange 2000 a 2003, a stará se o veškerý vnitřní tok pošty v organizaci. Všechny vnitřní zprávy tečou přes server, i když jsou odesilatel a příjemce v tomtéž prostoru AD, a dokonce i tehdy, když se nacházejí na stejném poštovním serveru! Kromě zodpovědnosti za vnitřní tok pošty v organizaci má server množinu transportních agentů, které nám umožňují nakonfigurovat pravidla a nastavení, jež pak lze aplikovat na zprávy procházející serverem. server také umožňuje nastavit postupy a pravidla, jež vyhovují specifickým nařízením a prohlášením firmy. Jelikož server obvykle posílá a přijímá zprávy z Internetu skrze Edge Transport server v demilitarizované zóně, není nutné na něj instalovat žádné antispamové agenty a nepřijímá zprávy přicházející z neautentizovaných (nedůvěryhodných) ových serverů v Internetu alespoň ve výchozím nastavení. Protože ne všechny organizace mohou a ani nebudou moci nainstalovat do demilitarizované zóny Edge Transport server, ukážeme si, jak lze nastavit server, aby fungoval ve vaší organizaci jako transportní server vůči Internetu. Architektura přenosu zpráv a směrování v Exchange 2007 V oblasti architektury a směrování došlo v Exchange Serveru 2007 k výrazným změnám. V první řadě už Exchange nepoužívá oproti dřívějším verzím produktu protokol SMTP integrovaný v Internetové informační službě (IIS). Namísto toho přepsala produktová skupina Exchange balík transportu přes SMTP do řízeného kódu a výsledkem je mnohem stabilnější a bezpečnější protokol. Transportní balík například běží pod účtem síťové služby a používá několik nových mechanismů, které snižují rizika spojená s útokem Denial-of-Service a s dalšími bezpečnostními problémy. Nový transportní balík SMTP je nyní znám jako služba Microsoft Exchange Transport (MSExchangeTransport.exe), a protože již nezávisí na IIS, není již také v IIS Manageru. Ve skutečnosti ani nemusíte na server IIS instalovat, pokud jej nekombinujete se serverovou rolí Mailbox či Client Access na tomtéž hardwaru. Vytváříte-li svou topologii Exchange, není už nutné mezi směrovacími skupinami v organizaci Exchange nastavovat konektory směrovacích skupin, protože nic takového již v Exchange 2007 není. Už slyším nářky, Proč byl tento pohotový způsob směrování zpráv skrze organizaci Exchange odstraněn? Inu, směrovací skupiny měly také své nevýhody, včetně dlouhých prodlev v situaci, kdy se dva servery neshodly na stavu spojení, s případným vznikem směrovací smyčky. Další nevýhoda byla při sledování zprávy, kdy mohla vniknout velmi matoucí situace při zjišťování, proč daná zpráva šla v určitém okamžiku určitým směrem, protože tabulka stavu linek v topologii Exchange nebyla nikdy trvalá ani se neukládala. A poslední problém byl, že princip směrovacích skupin a konektorů

3 Architektura přenosu zpráv a směrování v Exchange směrovacích skupin nutil administrátory Exchange opětovně vytvářet a simulovat podkladovou síť, což může být časově velmi náročná a dokonce zbytečná práce. Jak se tedy nastavuje směrovací topologie v Exchange Serveru 2007? Prostě se nenastavuje! Exchange Server 2007 je aplikace, která zná svou pozici, což znamená, že dotazem do Active Directory umí najít své místo v síti Active Directory a také místa ostatních serverů. Namísto vlastní směrovací topologie používá Exchange topologii sítě služby Active Directory a s její pomocí určuje, jak zprávy prochází skrze organizaci. To znamená, že servery ve vaší organizaci Exchange načítají informace z Active Directory, aby stanovily, jak mají být zprávy směrovány mezi servery. Na každé místo, kde je Mailbox server, je třeba nainstalovat server, takže když uživatel A na jednom místě pošle zprávu uživateli B na jiném místě, poštovní server zkontaktuje server ve svém vlastním místě a pak nasměruje zprávy na server na místě uživatele B, které nakonec skončí na poštovním serveru se schránou uživatele B. Poznámka: Všechny servery používají při výměně zpráv v organizaci bezpečný protokol SMTP. Používají běžný průmyslový standard SMTP Transport Layer Security (TLS), takže veškerá komunikace mezi servery je autentizována a šifrována. Tím je vyloučena možnost vnitřního odposlechu. Kromě toho je šifrována také veškerá komunikace RPC mezi Hub Transport servery a poštovními servery. Na obrázku 6.1 jsem se pokusil načrtnout, jak probíhá směrování zpráv v základní organizaci Exchange Všimněte si, že servery Mailbox a používají pro základní komunikaci RPC, kdežto dva servery spolu hovoří při výměně zpráv skrze SMTP. 1. síť AD šifrované RPC zabezpečené SMTP 2. síť AD šifrované RPC KAPITOLA 6 Správa serverové role poštovní server server server poštovní server odesilatel příjemce Obrázek 6.1 Cesta zprávy od uživatele v jedné síti AD k uživateli v jiné síti AD

4 238 Kapitola 6: Správa serverové role Poznámka: Jestliže v konkrétní síti AD existuje více cest, server použije deterministický algoritmus a vybere jednu z nich. Protože bude vždy vybrána jedna z cest, je algoritmus deterministický. Více se o síti AD a algoritmu výběru spojení používaném pro směrování můžete dočíst v následujícím příspěvku v blogu týmu MSExchange: /09/15/ aspx. Když server ustanoví v síti AD spojení SMTP na server v jiné síti AD, aby mohl doručit zprávu, používá cyklický vyrovnávací mechanismus (round-robin load balancing). To znamená, že jestliže první zkontaktovaný server neodpoví na připojení, pokusí se přes SMTP založit spojení na další Hub Transport server v síti AD. Z uvedeného plyne, že servery jsou bez jakéhokoliv přičinění schopny vyrovnat se s chybou. Protože směrování vyplývá ze sítě Active Directory, funkce aktualizace stavu linek (Link State) v Exchange, která se používala v předchozích verzích Exchange, byla opuštěna. Funkce stavu linek ve starších verzích sloužila každé hlavní směrovací skupině k úpravám a udržování tabulek se stavy linek v aktuálním stavu a tato informace se šířila zpět na ostatní Exchange Servery v organizaci. Použití sítě AD v Exchange 2007 vytváří jednoznačnější směrovací topologii. Správa Serveru Veškerá nastavení pro celou organizaci se ukládají v Active Directory. To znamená, že všechny změny nebo konfigurace, kromě specifických nastavení přijímacího konektoru, se odrazí na všech serverech v organizaci. V následujících pasážích si projdeme všechny záložky, které se nacházejí v podřízeném uzlu Hub Transport na obrázku 6.2. Protože by bylo nesmyslné věnovat přijímacím konektorům vlastní oddělenou část, zahrneme je do tohoto oddílu také. Vzdálené domény První záložka se nazývá Remote Domain. Zde lze nastavit přenos zpráv mezi Exchange 2007 a externími doménami SMTP. Když nastavujete vzdálenou doménu, lze ovládat tok pošty přesněji, určovat formátování a pravidla pro poštu a zadat znakové sady, které mohou ve zprávách přijímaných a odesílaných ze vzdálené domény být. Jak je vidět na obrázku 6.2, je zde výchozí záznam vzdálené domény, nastavený po nainstalování serverové role. Adresní prostor domény je nakonfigurován jako *, což reprezentuje všechny externí domény. To znamená, že nastavení v tomto záznamu pro vzdálenou doménu se aplikuje na všechny odcházející zprávy. Máte-li specifické požadavky pro jedno či více externích SMTP doménových názvů, lze podle potřeby vložit další záznamy pro vzdálené domény. Jak se nový záznam pro vzdálenou doménu vytváří si ukážeme později, ale nyní se podívejme na nastavení výchozí vzdálené domény. Otevřete-li vlastnosti záznamu výchozí vzdálené domény, objeví se záložka General (viz obrázek 6.3). Zde můžete zadat, jak má server zpracovávat zprávy Mimo kancelář (OOF) přicházející do domén SMTP zadaných v tomto záznamu vzdálené domény. Máme na výběr ze čtyř možností:

5 Správa Serveru 239 Obrázek 6.2 Dostupné záložky v uzlu KAPITOLA 6 Správa serverové role Obrázek 6.3 Možnosti zprávy Mimo kancelář (Out-of-Office) Allow none Do této vzdálené domény nedojdou žádné zprávy Mimo kancelář. Allow external out-of-office messages only Pouze zprávy Mimo kancelář nastavené jako externí pomocí klientů Outlook 2007 a OWA 2007, a kde je odpovídající schránka uložena na poštovním serveru Exchange 2007, budou do této vzdálené domény doručeny.

6 240 Kapitola 6: Správa serverové role Allow external out-of-office messages, and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange Server 2003 or earlier servers Zprávy Mimo kancelář nastavené jako externí pomocí klientů Outlook 2007 a OWA 2007, a kde je odpovídající schránka uložena na poštovním serveru Exchange 2007, budou do této vzdálené domény doručeny. Kromě toho, zprávy Mimo kancelář nastavené v Outlooku 2003 a ve starších klientech, bez ohledu na serverovou verzi, kde je uložena schránka, budou do této vzdálené domény doručeny. Jinými slovy, zprávy Mimo kancelář odeslané prostřednictvím serveru Exchange 2003 či starší verze budou doručeny do této vzdálené domény, bez ohledu na verzi klienta, na němž byla zpráva Mimo kancelář nastavena. Allow internal out-of-office messages, and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange Server 2003 or earlier servers Pouze zprávy Mimo kancelář nastavené jako externí pomocí klientů Outlook 2007 a OWA 2007, a kde je odpovídající schránka uložena na poštovním serveru Exchange 2007, budou do této vzdálené domény doručeny. Kromě toho, zprávy Mimo kancelář nastavené v Outlooku 2003 a ve starších klientech, bez ohledu na serverovou verzi, kde je uložena schránka, budou do této vzdálené domény doručeny. Zprávy Mimo kancelář odeslané prostřednictvím serveru Exchange 2003 či starší verze budou doručeny do této vzdálené domény, bez ohledu na verzi klienta, na němž byla zpráva Mimo kancelář nastavena. Ve výchozím nastavení je zvolena možnost Allow external out-of-office messages. Pokročme na další záložku s názvem Message Format, kterou ukazuje obrázek 6.4. Vsadím se, že spoustě z vás je tato záložka povědomá, protože je velmi podobná té, kterou známe z Exchange 2003, nicméně Exchange 2007 nabízí několik nových možností. Obrázek 6.4 Možnosti formátování zprávy

7 Správa Serveru 241 Zde máte krátký popis všech možností na záložce Message Format: Allow automatic replies Tato volba umožňuje odesílání automatických odpovědí do vzdálené domény. Allow automatic forward Tato volba umožňuje automatické přeposílání do vzdálené domény. Allow delivery reports Tato volba umožňuje posílání zpráv o doručení všem příjemcům v libovolné vzdálené doméně. Allow non-delivery reports Tato volba umožňuje posílat zprávy o nedoručení (NDR) všem příjemcům v libovolné vzdálené doméně. Display sender s name on messages Tato volba umožňuje zobrazovat uživatelovo jméno příjemci zprávy. Use message text line wrap at column Chcete-li v textech odchozích zpráv používat zalamování řádků, měli byste tuto volbu povolit. Při povolení můžete zadat velikost řádku (od 0 do 132 znaků). Nemá-li být hodnota omezena, ponechte pole prázdné. Založení nového záznamu pro vzdálenou doménu Nový záznam pro vzdálenou doménu vytvoříte klepnutím na New Remote Domain v podokně Action. Otevře se průvodce New Remote Domain, který vidíte na obrázku 6.5. Zde je potřeba zadat název záznamu a externí doménu SMTP, na niž chcete nastavení aplikovat. Jestliže doména obsahuje poddomény, lze také zaškrtnout volbu Include all subdomains. Po vložení potřebných informací klepněte na tlačítko New a pak na závěrečné stránce na Finish. KAPITOLA 6 Správa serverové role Obrázek 6.5 Založení nové vzdálené domény

8 242 Kapitola 6: Správa serverové role Všimněte si, že nemusíte zadávat rozličná nastavení během zakládání záznamu vzdálené domény. K tomu slouží stránka vlastností vzdálené domény, kterou otevřete až po založení. Tip: Chcete-li vytvořit záznam pro vzdálenou doménu pomocí Exchange Management Shellu, musíte použít komandlet New-RemoteDomain. Například záznam vzdálené domény podobný nastavení na obrázku 6.5 vytvoříte tímto příkazem: New-RemoteDomain Name Syngress DomainName *.syngress.com Akceptované domény Na záložce Accepted Domains zadáváme domény SMTP, pro které má být naše organizace Exchange 2007 autoritou, má přenášet zprávy (relay) na ový server v jiné doménové struktuře Active Directory v organizaci nebo je přenášet na ový server vně příslušné organizace Exchange. Rozdíl mezi vnitřními a vnějšími přenosovými doménami je, že vnitřní přenos zkrátka posílá ové zprávy přímo na ový server v organizaci. Zprávy odeslané na vnější přenosovou doménu nejprve dorazí na Edge Transport server v demilitarizované zóně a odtud se přesměrovávají na odpovídající externí ový server v Internetu. Po nainstalování serveru do organizace Exchange 2007 se doménový název kořenové domény ve struktuře Active Directory nastaví automaticky jako autoritativní doména. Poněvadž server použitý jako příklad v této knize byl nainstalován do struktury Active Directory s názvem exchangedogfood.dk, je tento doménový název ve výchozím nastavení pro tuto organizaci Exchange 2007 autoritativní doménou (viz obr. 6.6). Protože používáme systém rozděleného DNS, kde si interní a externí doménové názvy odpovídají, nemusíme po instalaci serveru provádět žádné změny v nastavení. Mnoho organizací používá interní doménový název odlišný od externího názvu domény, který se mezi jinými používá také pro příchozí poštu. Běžně se například používá vnitřní doména domena.local. Je-li tomu tak i ve vaší organizaci, musíte ručně vytvořit akceptovanou doménu, která odpovídá externímu názvu vaší domény. Založení nové akceptované domény Vytvořit novou akceptovanou doménu je snadné. Klepněte v podokně Action na odkaz New Accepted Domain. V průvodci New Accepted Domain vložte bázev nového záznamu akceptované domény a doménu, pro niž chcete přijímat y. Poznámka: Každou akceptovanou doménu, která je na záložce Accepted Domains, lze spojit s pravidlem Address Policy (EAP), přičemž dojde k vygenerování ových adres příjemců pro akceptovanou doménu. Vlastně každé pravidlo EAP musí být spjato s nějakou akceptovanou doménou a ové zprávy odeslané na ové adesy zadané v EAP lze přesměrovat pomocí serverů v organizaci. Až za chvíli probereme pravidla pro ové adresy, bude vám vše jasné.

9 Správa Serveru 243 Obrázek 6.6 Stránka vlastností akceptované domény Jak jsme si již řekli, server umí zpracovat zprávy pro konkrétní doménu několika různými způsoby, což ukazuje obrázek 6.7. Zvolte požadovanou možnost, klepněte na tlačítko New a na další stránce na Finish. KAPITOLA 6 Správa serverové role Obrázek 6.7 Průvodce New Accepted Domain Tip: Novou akceptovanou doménu můžete také vytvořit v Exchange Management Shellu pomocí komandletu New-AcceptedDomain. Například záznam akceptované domény podobný tomu, který jsme založili na obrázku 6.7, vytvoříte tímto příkazem: New-AcceptedDomain Name Exchange-faq DomainName exchangefaq.dk Domain- Type Authoritative

10 244 Kapitola 6: Správa serverové role Pravidla pro ové adresy Pravidla pro ové adresy byla v Exchange 2000 a 2003 známá jako pravidla pro příjemce. Pravidla pro adresy v Exchange definují adresy proxy vložené do objektů příjemců v organizaci Exchange. V Exchange 2007 se pravidla pro příjemce rozdělila na dva typy: akceptované domény (o nichž jsme právě mluvili) a pravidla pro ové adresy. Ti z vás, kteří mají zkušenosti s Exchange 2000 či 2003, vědí, že pravidla pro příjemce také určovala, jaké jmenné prostory SMTP organizace Exchange akceptovala. Někteří z vás se patrně nad rozdělením těchto dvou vlastností pozastaví. Produktová skupina Exchange oddělila tyto vlastnosti ze tří hlavních důvodů. Nejprve proto, že když byla pro pravidlo pro ovou adresu příjemce zadána doména, ale nebyla nastavena jako autoritativní doména, odeslaný příjemcům s ovou adresou definovanou pravidlem nebyl přesměrován v organizaci Exchange pro tuto doménu. Ačkoliv je to neplatný scénář, System Manager v Exchange 2000 a 2003 tento typ nastavení umožňoval. Druhým faktem bylo, že autoritativní doména se skrývala v grafickém rozhraní pravidla pro ovou adresu příjemce, které nebylo pro administrátory příliš intuitivní. A za třetí, přenosové domény měly správu v grafickém rozhraní konektorů SMTP, tedy v prostoru zcela odlišném od místa, v němž se ovládaly autoritativní domény (pravidla pro příjemce). Praktická rada: Toto oddělení akceptovaných domén a pravidel pro ové adresy není jedinou změnou v oblasti pravidel pro ové adresy. Nechvalně známá služba Recipient Update Service (RUS), kterou většina z nás zná z Exchange 2000 a 2003, již také není součástí produktu Exchange Služba RUS odpovídala za vkládání ových adres, dále za členství v seznamech adres a za několik dalších věcí. Nefungovala však vždy podle očekávání a bylo velmi obtížné najít problém, když služba odpírala poslušnost. V Exchange 2007 byla služba RUS (a tedy asynchronní chování používané pro správu objektů) nahrazena novým synchronním procesem, komandletem AddressPolicy, který se používá na okamžité vložení ové adresy do objektů! Ano, již nemusíte čekat několik minut, než se ové adresy objeví na vašich objektech, což byla vlastnost zastaralé služby RUS. Podrobné vysvětlení zrušení služby RUS naleznete v blogu týmu MSExchange: com/archive/2006/10/02/ aspx. Pamatujte si tedy dobře, že než začnete vytvářet nové pravidlo pro ovou adresu, musíte nejprve přidat odpovídající doménový název na záložce Accepted Domains. Jak vidíte na obrázku 6.8, máme v naší organizaci Exchange 2007 několik pravidel pro ové adresy, vypsaných podle priority (čím menší číslo, tím vyšší priorita), což je stejné jako v Exchange 2000 a Chcete-li posunout nějaké pravidlo v seznamu nahoru, označte jej a klepněte v podokně Action na Change Priority. Aby byl odkaz Change Priority viditelný, musíte mít kromě výchozího pravidla alespoň dvě další EAP. Založení nového pravidla pro ové adresy Založení nového pravidla pro ové adresy je prosté, ale od Exchange 2000 a 2003 se velmi liší. Postupujte následovně: 1. V podokně Action klepněte na New Address Policy.

11 Správa Serveru 245 Obrázek 6.8 Seznam pravidel pro y v organizaci seřazený podle priorit 2. Na úvodní stránce průvodce New Address Policy vložte název nového pravidla a zadejte, jaké typy příjemců se mají zahrnout (obrázek 6.9). Poté klepněte na tlačítko Next. KAPITOLA 6 Správa serverové role Obrázek 6.9 Okno nového pravidla pro ové adresy

12 246 Kapitola 6: Správa serverové role 3. Nyní můžete selektivněji definovat cílovou skupinu pomocí filtru a volbou jedné či více podmínek (viz obr. 6.10). Máte-li potřebné podmínky, které chcete na pravidlo aplikovat, vybrané, klepněte na tlačítko Next. Obrázek 6.10 Stránka podmínek v průvodci New Address 4. Klepněte na Add a zaškrtněte address local part, kde vytvoříte část ové adresy se jménem uživatele. Pak zvolte ovou doménu z rozevíracího seznamu address domain, což ukazuje obrázek Pak klepněte na OK a Next. Jak vidíte na obrázku 6.11, můžete volit mezi sedmi typy lokální části ové adresy. Lokální část ové adresy je jméno, které se objevuje před znakem at (@). Jestliže žádný z těchto sedmi typů lokální části nevyhovuje potřebám vašeho pravidla pro ové adresy, můžete využít proměnné vypsané v tabulce 6.1. Tabulka 6.1 Dostupné parametry pro ové adresy Proměnná Popis %g Používá se pro křestní jméno (první jméno). %i Používá se pro prostřední iniciálu. %s Používá se pro příjmení. %d Používá se pro zobrazované jméno. %m Používá se pro alias v Exchange. %xs %xg Používá x písmen z příjmení. Je-li například x = 2, použijí se první dvě písmena z příjmení. Používá x písmen z křestního jména. Je-li například x = 2, použijí se první dvě písmena z křestního jména.

13 Správa Serveru 247 Obrázek 6.11 Zadání lokální části ové adresy a domény ové adresy 5. Na stránce Schedule zadejte, kdy se má pravidlo pro ové adresy aplikovat, a maximální čas, po jaký může běžet (obrázek 6.12). Pak klepněte na Next. KAPITOLA 6 Správa serverové role Obrázek 6.12 Stránka časového rozvrhu v průvodci New Address 6. Na stránce Configuration Summary klepněte na New. Jestliže jste zvolili okamžitou aplikaci pravidla, aplikuje se nyní adresa proxy na všechny příjemce vyhovující filtru. Po dokončení tohoto úkolu klepněte na stránce Completion na tlačítko Finish.

14 248 Kapitola 6: Správa serverové role Tip: Nové pravidlo pro ové adresy můžete také vytvořit v Exchange Management Shellu komandletem New- AddressPolicy. Například pravidlo podobné tomu, které jsme vytvořili v průvodci, založíte tímto příkazem: New- AddressPolicy -Name Exchangedogfood.dk - IncludedRecipients Mailbox Users -ConditionalCompany Exchange Dogfood Corporation -Priority Lowest Enabled AddressTemplates SMTP:%g.%s@exchangedogfood.dk Po vytvoření nového pravidla pro ové adresy a po jeho aplikaci na příjemce můžete u objektu příjemce na stránce vlastností na záložce Addresses ověřit, že na příslušný objekt uživatele byla vložena adresa proxy (viz obr. 6.13). Obrázek 6.13 Záložka Addresses na stránce vlastností uživatelské schránky Má-li uživatel povolenu možnost Automatically Update Addresses Based On AddressPolicy, všechny primární ové adresy (výchozí adresy pro odpověď) typů ových adres se vždy nastaví podle pravidla pro ové adresy. To znamená, že když upravíte primární adresu na jinou ovou adresu, vždy se vrátí zpět na adresu zadanou v příslušném pravidle pro ové adresy. Pravidla přenosu Se zvyšující se komplexností vládních a průmyslových regulací stále vzrůstá potřeba efektivní správy vnitřního směrování zpráv. Exchange 2007, či přesněji serverová role, nyní obsahuje nového agenta pro pravidla přenosu, který nabízí snadný a pružný způsob, jak nastavit pravidla pro vnitřní směrování zpráv a restrikci obsahu v organizaci Exchange. Můžeme nyní například přidat ke všem zprávám poslaným v organizaci firemní prohlášení nebo vytvořit etickou zeď mezi dvěma odděleními či skupinami, které si každodenně vyměňují důvěrná data. Etická zeď napomůže izolovat jedince či skupinu od informací, k nimž by neměli mít přístup.

15 Správa Serveru 249 Pravidla přenosu se skládají ze tří komponent: podmínky, výjimky a akce. Tato pravidla lze vytvořit na záložce Transport Rules. Podrobný výklad pravidel přenosu však není v této knize možný. Ukážeme si tedy například, jak je snadné přidat ke všem zprávám odesílaným v organizaci firemní prohlášení. Postupujte následovně: 1. Klepněte na záložku Transport Rules, kterou ukazuje obrázek V podokně Action klepněte na New Transport Rule. 3. Na úvodní stránce průvodce New Transport Rule napište Corporate Disclaimer a vložte příslušný komentář, který ukazuje obrázek Obrázek 6.14 Úvodní stránka průvodce New Transport Rule 4. Klepněte na tlačítko Next. 5. Na stránce Conditions zaškrtněte volbu from users inside or outside the organization (viz obr. 6.15) a klepněte na tlačítko Next. 6. Nyní zaškrtněte append disclaimer text using font, size, color, with separator and fallback to action if unable to apply. V sekci Step 2 klepněte na odkaz disclaimer text, což je vidět na obrázku V poli Disclaimer text napište prohlášení, které chcete připojit ke zprávám ve své organizaci. Poté klepněte na tlačítko OK (viz obrázek 6.17.) 8. Klepněte na tlačítko Next. 9. Na stránce Exceptions klepněte na tlačítko Next. 10. Na stránce Create Rule (Configuration Summary) klepněte na tlačítko New. 11. Na stránce Completion klepněte na tlačítko Finish. KAPITOLA 6 Správa serverové role

16 250 Kapitola 6: Správa serverové role Obrázek 6.15 Stránka podmínek v průvodci New Transport Rule Obrázek 6.16 Stránka akcí v průvodci New Transport Rule Obrázek 6.17 Textové pole Specify Disclaimer

17 Správa Serveru 251 Nyní budou všechny zprávy odeslané uživatelem v organizaci obsahovat připojené firemní prohlášení, jak vidíte na obrázku Obrázek 6.18 Testovací zpráva s připojeným firemním prohlášením Po vytvoření pravidla přenosu je můžete podle potřeby kdykoli změnit. Označíte pravidlo a v podokně Action klepnete na odkaz Edit Rule. Deník Tip: Chcete-li vytvořit nové pravidlo přenosu v Exchange Management Shellu, použijte komandlet New-TransportRule. Například pravidlo podobné tomu, které jsme vytvořili v grafickém průvodci (viz také obrázek 6.14), založíte následujícím příkazem: New-TransportRule Name Corporate Disclaimer Comments This corporate disclaimer is appended to all messages sent throughout the organization. Conditions Microsoft.Exchange.MessagingPolicies.Rules.Tasks.FromScopePredicate Actions Microsoft.Exchange.MessagingPolicies.Rules.Tasks.ApplyDisclaimerAction Exceptions Enabled $true Priority 0 Exchange Server 2003 nativně podporoval deník na úrovni úložiště poštovních schránek. Tato funkce je v Exchange Serveru 2007 také a nazývá se standardní deník. Standardní deník vám jakožto administrátorům Exchange umožňuje povolit deník na úrovni databáze poštovních schránek. O tomto standardním deníku není moc co říci jiného, než že jej lze povolit na stránce vlastností databáze poštovních schránek. Pak již prostě funguje. I když standardní deník může někomu postačovat, pro většinu dnešních organizací je příliš jednoduchý. Udržet krok s nárůstem regulací a nařízení vyžaduje mnohem vybavenější řešení pro archivaci. Exchange 2007 proto také obsahuje prémiový deník, jenž je součástí Hub Transport serveru, fungující na základě nového agenta deníku, kterého lze nastavit, aby vyhovoval specifickým potřebám organizace. Prémiový deník umožňuje vytvořit pravidla deníku pro jednotlivé příjemce s poštovními schránkami či pro celé skupiny v organizaci. KAPITOLA 6 Správa serverové role Poznámka: Prémiový deník, známý také jako deník pro jednotlivé příjemce, vyžaduje licenci Exchange Enterprise Client Access (CAL).

18 252 Kapitola 6: Správa serverové role Pravidla lze aplikovat na příchozí či odchozí zprávy či pro oba směry. Kromě toho lze pravidla aplikovat na globální, externí či interní zprávy. Zprávy lze archivovat na libovolnou adresu SMTP, což znamená, že již nejste nuceni archivovat do schránky Exchange, ale můžete archivaci provádět do řešení s archivem na Exchange. Můžete dokonce archivovat do řešení od jiného dodavatele. Pravidlo deníku vytvoříte následujícím postupem: 1. Na záložce Journaling klepněte na New Journal Rule. 2. V průvodci New Journal Rule (viz obr. 6.19) vložte popisný název. 3. Klepněte na Browse a zvolte příjemce, jenž má dostávat protokoly pro deník. 4. Zvolte oblast (Scope), na niž chcete pravidlo deníku aplikovat. 5. Má-li se pravidlo aplikovat na jedinou schránku, označte volbu Journal message for recipient, klepněte na Browse a zvolte příjemce. Poznámka: Jestliže nezaškrtnete volbu Journal message for recipient, pravidlo deníku bude archivovat všechny zprávy odeslané všemi uživateli v organizaci Exchange. 6. Klepnutím na New pravidlo vytvořte. Na stránce Completion klepněte na Finish. Obrázek 6.19 Průvodce New Journal Rule Tip: Nové pravidlo deníku lze také vytvořit v Exchange Management Shellu komandletem New- JournalRule. Například vytvořit pravidlo podobné tomu, které jsme založili v grafickém průvodci, je možné následujícím příkazem: New-JournalRule Name Journal all messages to and from Benjamin s mailbox Journal Address exchangedogfood.dk/users/archive Scope Global Enabled $True Recipient BWK@exchangedogfood.dk

19 Správa Serveru 253 Jestliže uživatel Benjamin pošle ovou zprávu, odešle se protokol do deníku na konkrétní ovou adresu pro protokoly, podobně jako na obrázku Lze tu vidět, že protokol v deníku obsahuje v příloze zprávu, kterou poslal Benjamin, a také informace o odesilateli, předmětu a ID-zprávy. Obrázek 6.20 Testovací zpráva v protokolu v deníku Odesílací konektory Odesílací konektory (Send Connector) se používají k řízení odesílání zpráv Hub Transport servery pomocí protokolu SMTP. Tedy, jak se server spojuje s ostatními ovými servery. To znamená, že má-li server úspěšně doručit zprávy do cílového místa, potřebuje odesílací konektor. Je nutno podotknout, že během instalace serveru se nevytváří explicitní odesílací konektor. Avšak interní servery používají při vzájemném posílání zpráv SMTP a ačkoliv se ve výchozí instalaci nevytvoří explicitní odesílací konektor, neznamená to, že interní servery nemohou doručovat zprávy do jiných serverů. Důvodem je, že na základě topologie sítě Active Directory se automaticky vypočítají implicitní, a tedy neviditelné, odesílací konektory, a na základě topologie jsou pak interní zprávy směrovány mezi Hub Transport servery v organizaci. Odesílací konektory se ukládají v Active Directory a jakmile takový konektor vznikne, je jeho platnost globální a nejen lokální, jako je tomu u přijímacích konektorů. Nemáte-li v demilitarizované zóně vaší organizace nainstalován Edge Transport server, nebo nebyl-li nastaven žádný proces Edge Subscription (který vytváří odesílací konektor automaticky), nelze odeslat zprávu na jiné poštovní servery mimo vaši organizaci. V takovém případě musíte vytvořit odesílací konektor ručně. K tomu je potřeba postupovat takto: KAPITOLA 6 Správa serverové role

20 254 Kapitola 6: Správa serverové role 1. Klepněte na záložku Send Connectors, zobrazenou na obrázku V podokně Action zvolte příkaz New Send Connector. 3. Objeví se stránka New SMTP Send Connector. Na stránce Introduction vložte popisný název konektoru (například To ISP) a poté v rozevíracím seznamu zvolte typ odesílacího konektoru, který chcete vytvořit. Vidíte, že lze volit ze čtyř odlišných typů odesílacích konektorů. Custom Tuto možnost zvolte, když chcete vytvořit vlastní konektor pro spojení s jinými servery než Exchange. Internal Interní odesílací konektory se používají na odesílání ů na servery ve vaší organizaci Exchange. Zvolíte-li tento typ, konektor bude nastaven na směrování ů na vaše interní Exchange servery jako servery smart host. Internet Internetové odesílací konektory slouží k posílání ů do Internetu. Zvolíte-li tento typ, konektor bude nastaven tak, aby při směrování e- mailů používal záznamy MX v DNS. Partner Partnerské odesílací konektory se používají na odesílání ů do partnerských domén. Zvolíte-li tento typ, konektor bude nastaven, aby povoloval spojení pouze na servery, které se autentizují certifikáty Transport Layer Security (TLS) pro domény SMTP, jež jsou na seznamu doménově bezpečných domén. Na tento seznam můžete domény přidávat příkazem Set-Transport- Config s parametrem TLSSendDomainSecureList. Obrázek 6.21 Volba požadovaného typu odesílacího konektoru 4. Na stránce Address space, kterou vidíte na obrázku 6.22, vložte doménu či domény, do nichž má odesílací konektor směrovat poštu. Má-li konektor sloužit ke směrování odchozích zpráv do Internetu, vložte hvězdičku (*). Poté klepněte na tlačítko Next.