Exchange Server 2010 seriál – Instalace (část I.)

První část desetidílného seriálu na téma Exchange Serveru 2010 vám přináší popis instalace a konfigurace nového Exchange serveru. V dalších devíti dílech se posléze dozvíte vše o návazných krocích vedoucích k úspěšnému nasazení Exchange do produkčního prostředí.

Microsoft Exchange Server 2010 je hned po své instalaci téměř připraven na nasazení do produkčního prostředí. Nicméně i tak je potřeba několika dalších konfiguračních zásahů ze strany administrátora, aby prostředí Exchange splňovalo naše představy o kvalitním poštovním serveru, který pomáhá zvyšovat produktivitu jeho uživatelů. Cílem tohoto článku je popsat konfigurační kroky doporučené pro základní nastavení Exchange Server 2010. Většina kroků popsaných dále se dá s úspěchem použít na jakékoli Exchange instalaci, v jakékoli firmě – nezáleží tedy na tom kolika Exchange servery disponujete, doporučení jsou univerzální. Své si v dokumentu tedy jistě najde nejen správce Exchange v malé firmě, ale také administrátor spravující vysoce dostupné prostředí. Pro toho, kdo se zajímá o nastavení vysoké dostupnosti je pro tyto účely v dokumentu speciální část, které se právě této problematice věnuje.

Obsah tohoto seriálu čerpá z dokumentu, který pro společnost Microsoft napsali externí autoři - Microsoft MVP – Martin Pavlis a Miroslav Knotek. Na tento dokument ve formátu PDF se můžete těšit na samý závěr, kdy si jej ze stránek TechnetBlogu CZ/SK budete moci stáhnout.

1. Instalace Exchange Server 2010

Instalace Exchange Server 2010 je poměrně jednoduchá a její popis není součástí tohoto dokumentu. Nicméně na internetových stánkách Microsoftu existuje celá řada velmi mocných pomocníků. Nejedná se pouze o nápovědu Exchange jako v minulosti, ale také o velmi kvalitní interaktivní nástroje, které vás celým krok po kroku provedou procesem instalace Exchange do vašeho prostředí.

 

• Exchange Server Deployment Assistant
   

  
   

  • Jedná se o nejmodernější online nástroj z dílny Microsoftu, který na základě několika otázek vygeneruje postup, kterým postupujete krok po kroku a splňujete tak nejprve nezbytné podmínky pro instalaci Exchange Server 2010 a následně i samotné instalace Exchange
     

  • Link: http://technet.microsoft.com/en-us/exdeploy2010/default.aspx

  
   

• Nápověda Exchange Server 2010, instalační část
   

  
   

  • Link: http://technet.microsoft.com/en-us/library/dd351084.aspx

  
   

• MSTV.cz – video s komentářem v češtině „Exchange Server 2010 - instalace rolí"
   

  
   

  • Link: http://www.mstv.cz/it/videos/275/Exchange-Server-2010---instalace-roli-a-emulatoru-WM

2. Vložení čísla Product Key

Po instalaci Exchange serveru 2010 není server zalicencován. Toto slouží k využití instalace např. na zkušební/testovací server. Zkušební verze vyprší 120 dnů od data instalace. Takovýto server je vždy v edici Standard a nelze u něj požadovat podporu služeb společnosti Microsoft. Máte-li v Exchange organizaci servery, které nemají vložen Product Key, vždy při spuštění Exchange Management konzoly vám bude zobrazen seznam všech Exchange 2010 serverů bez licence a počet dní, které zbývají do vypršení zkušební verze. Pokud zkušební lhůta již vypršela, zobrazuje se varování pro každý takový server.

Obrázek 1: Seznam nezalicencovaných serverů

Vložení Product Key provedeme pomocí následujícího postupu:

 

1. Exchange Management konzola (dále EMC): sekce Server Configuration
    

2. Vybereme server, který nemá vložen Product Key (má odlišnou ikonu)
    

3. Spustíme průvodce pro vložení Product Key a vložíme licenční číslo

Obrázek 2: Vložení Product Key

Po dokončení průvodce je nutné restartovat službu Microsoft Exchange Information Store. V závislosti na Product Key, který jste zadali, bude provedena změna edice serveru buď na Standard Edition, nebo na Enterprise Edition a jsou aktualizována veškerá potřebná nastavení.

Exchange Server 2010 seriál – Založení databází pro poštovní schránky a jejich konfigurace (část II.)

Hned po instalaci Exchange Serveru v roli Mailbox Server máme na tomto serveru k dispozici jednu databázi pro poštovní schránky. Zdali na něm máme i databázi pro veřejné složky záleží na tom, zdali jsme při instalaci vybrali podporu pro klienty starší než Outlook 2007, či nikoli. Pokud ano, je databáze s Veřejnými složkami nezbytná – starší klienti ji potřebují ke svému chodu. V edici Standard máme možnost pro poštovní schránky založit 5 databází, v edici Enterprise potom až 100. Databáze nemají žádnou pevně omezenou velikost ( jak tomu bylo u verze Exchange Server 2003 a starší). Databáze zakládáme podle následujících pravidel:

 

• Potřebujeme sjednotit více schránek se stejným nastavením (např. velikost schránky) – každá databáze má své vlastnosti a tyto se automaticky aplikují na všechny schránky, které se v databázi nacházejí
   

• Více databází znamená možnost tyto databáze uložit na různé disky a tím optimalizovat výkon a bezpečnost dat
   

• V případě poškození databáze, není mimo provoz cela firma, ale jen ta část uživatelů, která v ní měla schránku
   

• Je doporučeno, aby velikost databází nepřesáhla určitou rozumnou velikost vzhledem k následné správě, zálohování, atd. Je jistě lepší mít více menších databází, než jednu obrovskou, se kterou je problém cokoli udělat. Jako příklad může posloužit situace, kdy chceme databázi obnovit ze zálohy – 50GB se obnovuje rychleji a jednodušeji, než např. 500GB.

Různých doporučení je mnoho a v zásadě platí, že správci Exchange se většinou řídí vlastními zkušenostmi, případně jsou omezeni hardwarovými možnostmi serveru. Pokud chcete postupovat podle doporučení společnosti Microsoft, doporučuji používat následující Excel aplikaci, která vám s rozdělením a návrhem databází pomůže.

Exchange 2010 Mailbox Server Role Requirements Calculator

 

• Link: http://msexchangeteam.com/files/12/attachments/entry453145.aspx

Založení nové databáze pro poštovní schránky

Založení nové databáze pro poštovní schránky provedeme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Mailbox -> New Mailbox Database
    

2. V průvodci vyplníme jméno databáze (nově musí být unikátní v celé Exchange organizaci), Mailbox server na kterém se budu nacházet a umístění databáze a transakčních logů na disku 
   
   

 

Založení nové databáze pro poštovní schránky

Konfigurace databáze pro poštovní schránky

Konfigurace databáze pro poštovní schránky provedeme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Mailbox -> vybereme databázi, kterou chceme nastavit a vyvoláme její vlastnosti
    

2. Na záložce Maintenance zvolíme čas, kdy se má dělat údržba databáze tak, aby tento čas nebyl shodný s dobou, v níž probíhá zálohování, nebo skenování antivirem
    

3. Na záložce Limits nastavíme požadované limity schránek, které budou v této databázi umístěny. Kromě toho také nastavíme to, jak dlouho bude databáze držet smazané položky v Dumpsteru - odkud si je uživatelé mohou sami obnovit (v programu Outlook volba „Obnovit odstraněné položky“) 
   
     
   Konfigurace databáze pro poštovní schránky

Přesun schránek mezi databázemi Exchange

Po vytvoření požadovaných databází, je možné poštovní schránky uživatelů mezi těmito databázemi libovolně přesouvat a tím optimalizovat rozložení schránek napříč celou organizací. Od verze Exchange Server 2010 je díky online přesunu dat tuto operaci možné dělat i během pracovní doby, schránka je po celou dobu přesunu pro uživatele dostupná. Po dokončení přesunu je uživatel pouze vyzván k tomu, aby restartoval aplikaci Microsoft Office Outlook.

 

1. EMC: Recipient Configuration -> Mailbox -> Označíme schránku, kterou chceme přesouvat a spustíme průvodce „New Local Move Request“
    

2. Vybereme databázi, do které má být schránka přesunuta, a rozhodujeme o tom, zdali se má schránka přesunout i v případě, že v ní jsou obsažena poškozená data (zastavit přesun, nepřesouvat pouze chybné položky)
    

3. V sekci Recipient Configuration -> Move Request můžeme sledovat stav přesouvaných schránek 
   
     
   Přesun poštovní schránky

Exchange Server 2010 seriál – Doménová jména a práce s nimi (část III.)

Jakmile máme připraveny databáze a v nich rozmístěné uživatelské schránky, je potřeba začít přemýšlet o posílání a přijímání poštovních zpráv. Protože Exchange server přijímá skrze SMTP protokol všechno, co se mu snaží kdokoli z internetu doručit (!), je potřeba toto přijímání omezit pouze na ty domény, které chceme ve firmě používat.

Akceptované domény

Nastavení domén, za které chceme, aby náš Exchange server přijímal poštovní zprávy, provedeme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Hub Transport -> Accepted Domains -> spustíme průvodce „New Accepted Domain“
    

2. Zadáme doménové jméno a vybereme, zdali emaily budou v Exchange serveru končit, nebo se budou předávat na další poštovní server (uvnitř – internal relay, nebo externet – external relay)

Akceptované domény

Domén můžeme přidat tolik, kolik jich naše společnost vlastní (bez omezení) – v případě více domén dochází k přijímání poštovních zpráv do všech vyjmenovaných.

Automatické nastavení SMTP adres na poštovních schránkách

Abychom nemuseli na každé schránce ručně nastavovat SMTP alias (poštovní adresu), můžeme jejich vytváření zautomatizovat pomocí adresních politik, které se aplikují na poštovní schránky a automaticky na nich vytváří potřebné adresy. Nastavení adres, které chceme aplikovat na naše schránky, provedeme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Hub Transport -> E-mail Address Policies -> spustíme průvodce „New E-mail Address Policy“
    

2. Vybereme, na které schránky chceme tuto politiku aplikovat. Filtrování schránek může být na základě konkrétního atributu, či v jaké organizační jednotce, či doméně Active Directory se uživatel nachází
    

3. Následně vybíráme, jaké adresy chceme na schránky aplikovat. Průvodce nám pomůže vybrat z nejčastějších typů adres a domén, které jsme již dříve v Exchange organizaci vydefinovali. Adres může být na schránku aplikováno víc, ale jen jedna je označena jako primární – uživatel může na všech adresách zprávy přijímat, ale odesílat pouze z té, která je nastavena jako primární („Set at Reply“)

E-mail Address Policy

Ruční nastavení SMTP adres na poštovních schránkách

Při správně adres na poštovních schránkách dochází i k tomu, že je potřeba na konkrétní schránce nastavit adresu jinou, než je uvedeno v adresních politikách – výjimku. Vytvoření výjimky provedeme pomocí následujícího postupu:

 

1. EMC: Recipient Configuration -> Mailbox -> Označíme schránku, které chceme nastavit speciální adresu a vyvoláme její vlastnosti
    

2. Na záložce „E-mail Addresses“ nejprve v dolní části vypneme aplikování centrálních politik a následně přidáme, smažeme, či jakkoli jinak upravíme adresy dle požadavku

Ruční zadání emailové adresy

Nezapomeňte za každou doménu, kterou vlastníte, přidat na jednu schránku alias postmaster – tato adresa je používána v situacích, kdy vás např. externí subjekt chce upozornit, že váš poštovní server byl umístěn na black list, atd. Tato adresa je tedy důležitá a měla by být monitorována.

Exchange Server 2010 seriál – Nastavení odesílání a přijímání poštovních zpráv (část IV.)

Abychom mohli v rámci Exchange organizace posílat a přijímat poštovní zprávy, je potřeba provést několik nastavení.

Odesílání poštovních zpráv

Pro odesílání poštovních zpráv je nutné, aby ve firmě existoval jeden, nebo více konektorů (Send Connector). Pokud je v Exchange organizaci nainstalována role Edge, není nutné konektory zakládat – k tomu dojde automaticky, pouze je nakonfigurovat. Pokud se v  organizaci žádný Exchange v roli Edge nenalézá, je nezbytné potřebný konektor vytvořit ručně. Vytvoření konektoru pro odesílání zpráv provedeme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Hub Transport -> Send Connectors a zde spustíme průvodce „New Send Connector“
    

2. Konektor pojmenujeme, vybereme jeho určení (Internet) a na další obrazovce nastavíme domény, do kterých bude tento konektor doručovat zprávy. Pokud budeme tímto konektorem odesílat zprávy do celého intetnetu, uvedeme v sekci SMTP znak * (hvězdička)
    

3. Nastavíme, jakým způsobem bude Exchange vyhledávat cílový sever (pravděpodobně pomocí DNS)
    

4. V posledním kroku vybereme, který Exchange server v naší organizaci bude díky tomuto konektoru emaily odesílat do internetu. Pokud serverů vybereme víc, použije se vždy ten, který je při odesílání nejvýhodnější (nejmenší počet zprávy předání mezi servery)

Nový Send konektor

Pokud je ve vaší organizaci více Exchange serverů, které mohou odesílat poštovní zprávy, může v organizaci existovat také více konektorů. Jejich priorita se určuje váhou (cost) – čím nižší číslo, tím vyšší priorita. Dá se tím docílit např. toho, že když je primární server zodpovědný za odesílání zpráv do internetu nedostupný, zpráva se automaticky pošle přes další sever.

Konektory je po vytvoření nutné vždy správně nastavit, jinak riskujeme odmítání poštovních zpráv antispamovými filtry. Konektory pro odesílání zpráv nastavíme pomocí následujícího postupu:

 

1. EMC: Organization Configuration -> Hub Transport -> Send Connectors a zde vyvoláme jeho vlastnosti
    

2. Na záložce „General“ zapneme logování SMTP (pokud o něj máme zájem – doporučuji) a následně vyplníme jméno, kterým se bude Exchange při předávání zpráv tímto konektorem hlásit, případně maximální velikost přijímané zprávy

Nastavení Send konektoru

Vyplnění správného jména je klíčové pro správné fungování odesílání zpráv. Musí zde být uvedeno jméno, které se shoduje se jménem, které nám při překladu vrací DNS PTR záznam. Jako příklad uvedu adresu 88.86.110.159, pod kterou je vidět odchozí SMTP komunikace. Tato IP adresa má k sobě navázán DNS PTR záznam „email.exchange4u.cz“, tedy přesně to samé jméno, které mám uvedeno v konektoru. Pokud by se toto neshodovalo, potom se jedná o problém, který bývá dost často antispamovými nástroji vyhodnocován jako potencionální problém a zprávy z vašich serverů budou mnohem častěji končit v antispam karanténách. Typickým příkladem je situace, kdy je k IP adrese přiřazeno servisní jméno poskytovatele připojení. Nezapomínejte na to, že zatímco DNS jméno si můžete koupit a patří vám, IP adresu máte vždy pronajatu od poskytovatele připojení. Takže to on musí na základě vaší žádosti vytvořit DNS PTR záznam požadovaného tvaru.

Přijímání poštovních zpráv

Pro správné přijímání poštovních zpráv je nejprve nutné v každé DNS zóně za kterou chcete zprávy přijímat vytvořit DNS MX záznam. Tento musí být nasměrován na ten Exchange, který je vypublikován - má otevřenu SMTP komunikaci do internetu. O přijímání emailů v Exchange se starají Receive konektory, které se nastavují na každém serveru. Konektory pro přijímání zpráv nastavíme pomocí následujícího postupu:

 

1. EMC: Server Configuration -> Hub Transport -> kde nejprve v horní části označíme server, který přijímá zprávy z internetu, a následně v dolní části vyberme vlastnosti konektoru, který chceme nastavit
    

2. Pokud nemáme klienty POP/IMAP, kteří pro odesílání zpráv používají SMTP, můžeme konektor „Client XXX“ smazat
    

3. Na záložce „General“ opět vyplňujeme jméno z DNS PTR záznamu, pod kterým je tento Exchange server vidět z internetu a případně nastavíme možnosti logování komunikace a omezení maximální velikosti příchozích zpráv
    

4. Pro příjem zpráv z internetu je nutné na záložce „Permission Groups“ zapnout volbu „Anonymous Users“

Nastavení Receive konektoru

Doporučené nastavení pro DNS zónu a Exchange Server:

Z tabulky je možné vyčíst:

 

• Emaily mají být posílány díky MX záznamu na adresu SMTP serveru „email.exchange4u.cz“
   

• Antispam ochrana SenderID je nastavena tak, že emaily z domény „kpcs.cz“ může odesílat pouze IP adresa 88.86.110.159 a jméno serveru email.exchange4u.cz. Více se dozvíte na této stránce, kde je i průvodce vytvořením tohoto záznamu: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
   

• Klienti, kteří podporují automatickou konfiguraci pomocí Autodiscover (Outlook 2007 SP1 a vyšší, Windows Mobile 6.1 a vyšší) si mohou na serveru „email.exchange4u.cz“ stáhnout potřebnou konfiguraci klienta

Exchange Server 2010 seriál – Nastavení antispamových funkcí (část V.)

Microsoft Exchange Server 2010 obsahuje širokou škálu antispamových funkcí. Správným nastavením těchto technologií organizace všech velikostí získávají velmi mocný nástroj v boji s nevyžádanou poštou, což se odráží ve vyšší produktivitě práce uživatelů elektronické pošty.

Podmínky pro využití antispamových funkcí

Ochrana proti nevyžádané poště je rozdělena podle způsobu fungování do jednotlivých, tzv. antispam agentů. Každý agent má své vlastní unikátní nastavení, každý antispamový agent může být také bez ohledu na stav ostatních agentů vypnut či naopak zapnut. Antispamoví agenti jsou ve výchozím nastavení automaticky instalováni pouze v rámci volitelné role Edge. Pokud v Exchange organizaci tato role chybí, je možné a podporované doinstalování agentů na serveru v roli Hub Transport pomocí následujícího postupu:

 

1. Přihlásíme se na Hub Transport server
    

2. Start -> Programy -> Microsoft Exchange Server 2010 -> Exchange Management Shell (EMS)
    

3. Spustíme příkaz Install-AntispamAgents.ps1
    

4. Provedeme restart služby "Microsoft Exchange Transport"

Filtrování dle připojení (Connection filtering)

Tento způsob ochrany je založen na důvěryhodnosti IP adresy serveru, který elektronickou poštu odesílá. Nastavení se skládá z následujících kroků:

Konfigurace IP adres interních SMTP serverů

V případě, že před Exchange serverem s instalovaným Connection filtering nebo Sender ID agentem existují další interní SMTP servery, je potřeba IP adresy těchto serverů uvést v nastavení:

 

1. EMC (Exchange Management Console): Organization Configuration -> Hub Transport -> Global Settings -> Transport Settings -> Message Delivery

Konfigurace interních SMTP serverů

Konfigurace RBL (real-time block list)

Na Internetu existuje celá řada placených i neplacených služeb, které vedou evidenci důvěryhodných či naopak rizikových IP adres z hlediska rozesílání spamu. Tuto službu může náš Exchange Server dotazovat pro ověření IP adresy příchozího SMTP připojení. Je doporučeno vybrat 2-3 poskytovatele s vysokou reputací a garantovaným SLA. Pokud počet dotazů nepřesáhne 300 000 dotazů denně, je možné pro úvodní nastavení použít například široce využívaný RBL zen.spamhaus.org.

Vlastní nastavení pak provedeme:

 

1. V EMC: Organization Configuration -> Hub Transport -> Anti-Spam -> IP Block List Providers dle následujícího obrázku:

Nastavení RBL

Konfigurace IP Allow List

Pro snížení rizika zablokování pošty v případě, že se například obchodní partner ocitne se svým poštovním serverem na některém z RBL, je doporučeno IP adresy SMTP serverů klíčových partnerů přidat do IP allow listu dle následujícího návodu:

 

1. EMC: Server Configuration -> Hub transport -> ServerName -> Anti-spam -> IP Allow List

Konfigurace IP Allow List

Služba Sender Reputation

Tato kontrola IP adres má dva zdroje dat:

 

• Pomocí MU/WSUS získáváme aktuální seznam IP a jejich reputací na základě dat ze služby Hotmail
   

• Server vytváří vlastní hodnocení IP na základě průměrného SCL zpráv přijatých z této IP, sledování anomálií v rámci SMTP relace atd.

Můžeme nastavit jak hodně restriktivně se má tato ochrana chovat a na jak dlouho zablokovat IP adresu se špatnou reputací. Protože například freemaily mívají běžně vysoké průměrné SCL, doporučuji nastavit tento typ ochrany ze začátku málo restriktivně a blokovat IP třeba jen na 4h. Pokud je vše v pořádku, můžete zkusit postupné zpřísnění nastavení.

Nastavení Sender Reputation

Filtrování dle odesílatele (Sender filtering)

Tato ochrana je založena na testování e-mailové adresy odesílatele uvedené v hlavičce zprávy. Pokud chci globálně zakázat příjem zpráv z konkrétních e-mailových adres či celých domén, mohu je uvést zde:

 

1. EMC: Organization Configuration -> Hub transport -> Anti-spam -> Sender Filtering

Minimálně je doporučeno filtrovat zprávy, které nemají uvedenou adresu odesílatele vůbec.

Konfigurace Sender Filteringu

Filtrování dle příjemce (Recipient filtering)

Tato ochrana je založena na testování e-mailové adresy příjemce uvedené v hlavičce zprávy. Pokud je požadováno zakázat příjem zpráv z Internetu pro konkrétní e-mailové adresy interních uživatelů, mohu je uvést zde:

 

1. EMC: Organization Configuration -> Hub transport -> Antispam -> Recipient Filtering

Velmi důležitou volbou je zde “Block messages sent to recipients not listed in the Global Address List”. Rozesílatelé spamu se totiž často pokouší posílat poštu na sice existující doménu, ale neexistující e-mailové adresy. Exchange server samozřejmě takovouto zprávu nedoručí, ale přesto je jejím zpracováním zbytečně zatěžován včetně zodpovědnosti za odeslání NDR.

Řešením je kontrola existujících e-mailových adres ještě před vlastním přijetím zprávy. Tuto volbu tedy rozhodně nastavíme.

Blokování zpráv na neexistující adresy

Filtrování dle Sender ID (SenderID filtering)

Sender ID filtering kontroluje odchozí IP adresu SMTP serveru oproti seznamu schválených IP adres pro odesílání v doméně odesílatele. Tyto adresy jsou volitelně zveřejněny v DNS pomocí tzv. Sender ID TXT záznamu.

Pokud se zjistí, že e-mail je odeslán z neautorizované IP adresy, jedná se s vysokou pravděpodobností o nevyžádanou poštu a mohu s ní tak provést dvě akce:

 

• Odmítnout (není doporučeno)
   

• Smazat (není doporučeno)
   

• Označit a znevýhodnit v rámci content filteringu a výsledného skóre SCL

Nastavení reakce na Sender ID kontrolu

Filtrování dle obsahu (Content filtering)

Filtrování dle vlastního obsahu zprávy je velmi důležitou součástí ochrany proti nevyžádané poště. Pokročilý algoritmus se snaží ohodnotit na základě rozpoznaných charakteristických znaků nevyžádané pošty nebo známých spamových kampaní číslem SCL (Spam Confidence Level) pravděpodobnost toho, zda se jedná o korektní e-mailovou zprávu či naopak spam. SCL = 0 znamená korektní zprávu, SCL = 9 naopak značí v podstatě 100% pravděpodobnost, že se jedná o zprávu nevyžádanou. Správce pak pro jednotlivé úrovně SCL určuje akci, která se má provést. Na výběr je z následujících možností:

 

• Zprávu smazat bez NDR
   

• Zprávu odmítnout
   

• Zprávu umístit do karantény
   

• Zprávu doručit uživateli, ale do zvláštní složky „Nevyžádaná pošta”

Nastavení akce

Dle praktických zkušeností je pro většinu firem nejvýhodnější následující seznam akcí, které uvádím včetně doporučených úrovní SCL:

 

• Zprávu smazat bez NDR – SCL = 9
   

• Zprávu odmítnout – SCL = 7, 8
   

• Zprávu doručit uživateli, ale do zvláštní složky „Nevyžádaná pošta” – SCL = 4, 5, 6

Karanténu je doporučeno nepoužívat, pokud to není nezbytně nutné. Používání karantény totiž značně zatěžuje správce systému údržbou karanténní schránky, kterou je nutné pravidelně kontrolovat a také čistit.

První dvě akce nastavíme v EMC: Organization Configuration -> Hub transport -> Anti-spam -> Content Filtering.

Reakce filtrování obsahu dle SCL

SCL pro doručování do složky Nevyžádaná pošta se pak nastavuje pomocí EMS příkazem: 
Set-OrganizationConfig -SCLJunkThreshold 4

Konfigurace povolených a blokovaných slov

Pomocí nastavení povolených slov je možné dramaticky snížit tzv. false-positive (chybné zablokování korektní zprávy). Každá organizace by se měla zamyslet s ohledem na její předmět podnikání a vydefinovat si často používaná povolená slova. Pro firmu prodávající razítka to může být: razítko, razítka, objednávka atp.

Pokud je ve zprávě nalezené povolené slovo, SCL je automaticky nastaveno na hodnotu 0. Naopak pokud zpráva obsahuje blokované slovo, SCL bude stanoveno na úrovni 9.

Vše nastavíme v EMC: Organization Configuration -> Hub transport -> Antispam -> Content Filtering -> Custom Words

Určení povolených slov

Specifikace výjimek pro konkrétní uživatele

V případě potřeby mohu také nastavit seznam příjemců pošty, pro které se bude filtrování obsahu zcela ignorovat.

Výjimky pro filtrování obsahu

Nastavení vlastního textu NDR při zamítnutí zprávy

Zajímavou možností je také nastavení vlastního textu pro NDR, který se posílá odesílateli při zamítnutí na základě obsahu.

Vlastní text nastavíme pomocí EMS příkazem: 
Set-ContentFilterConfig -RejectionResponse "Zprava byla vyhodnocena diky svemu obsahu jako spam"

Vybrané tipy pro optimalizaci antispamu

V předcházejících kapitolkách jsme popsali základní nastavení antispamu, které je nutné provést víceméně vždy. V závěrečné části se zaměříme na rozšiřující nastavení, která nám pomohou využít všechny výhody Exchange 2010 antispamu opravdu na maximum.

Premium Antispam

Pokud má firma k dispozici pro své uživatele Exchange Enterprise CAL nebo Forefront Protection 2010 for Exchange Server, může využívat tzv. Premium Antispam, což zahrnuje následující výhody:

 

• Denní aktualizace IMF content filteru (standardně jen 1x za 14 dní)
   

• Několikrát denně IP reputation aktualizace
   

• Několikrát denně aktualizace spamových kampaní

Jak premium antispam zapnout? V EMC najdeme v sekci Server Configuration -> Hub transport -> ServerName příkaz kontextového menu: Enable Anti-spam Updates. Dále nás již vede průvodce viz obrázek.

Aktivace Premium antispamu

SafeList Aggregation

Uživatel rozhraní Outlook Web Acces či Microsoft Office Outlook má možnost vytvořit si seznamy důvěryhodných odesílatelů (Safe Senders). Klient pak zprávy z těchto adres uživateli doručí vždy přímo do Doručené pošty. Jako uživatel tak mám možnost razantně ovlivňovat, jaké zprávy dojdou do Doručené pošty a jaké ne. Důležité je také vysvětlit, že bezpeční odesílatelé Uživatele A nejsou bezpečnými odesílateli pro uživatele B.

Na rozdíl od předchozí verze, v Exchange Server 2010 dochází automaticky pomocí Mailbox Assistant službě k publikování těchto seznamů z uživatelských schránek do Active Directory a následně tedy i do Exchange organizace.

Individuální nastavení SCL akcí pro konkrétní schránku

V některých případech je požadováno nastavit jiné hranice SCL pro určené schránky. Nejen, že to je možné, ale dokonce můžeme pro konkrétního uživatele i jednotlivé typy filtrování zapnout/vypnout. Nastavení se provádí výhradně pomocí EMS. Uvedeme si 2 příklady:

 

• Set-mailbox id "Miroslav Knotek" –SCLRejectEnabled $false –SCLQuarantineEnabled $false –SCLDeleteEnabled $false – žádná zpráva pro Miroslava Knotka nebude ani smazána, ani odmítnuta ani předána do karantény
   

• Set-mailbox id "Miroslav Knotek" –SCLRejectThreshold 5 – zprávy pro Miroslava Knotka se budou odmítat již proSCL = 5

Whitelisting domény nebo adresy odesílatele

Pokud chci vynechat z filtrování obsahu konkrétní e-mailové adresy odesílatele či celé domény, mohu toto nastavit v EMS pomocí příkazů

• Set-contentfilterconfig -BypassedSenderDomains microsoft.com 
• Set-contentfilterconfig -BypassedSenders knotek@kpcs.cz

Exchange Server 2010 seriál – Certifikáty a práce s nimi (část VI.)

Každý Exchange Server 2010 hned po instalaci disponuje certifikátem, který je vystaven na externí jméno, které jste zadali během instalace. Tento certifikát sice obsahuje správná jména a je vystaven na 5 let, ale jedná se o tzv. SelfSigned certifikát. To v praxi znamená, že takovému certifikátu nikdo nedůvěřuje, protože nezná certifikační autoritu, která jej vystavila (ani nemůže, byl to sám Exchange Server). Díky tomu, ale s tímto Exchange serverem nebude schopen korektně komunikovat jak Microsoft Office Outlook, tak také většina mobilních klientů prostřednictvím ActiveSync. Proto je ve většině případů potřeba vystavit certifikát nový – buď od komerční a důvěryhodné certifikační autority, nebo od autority interní.

Certifikát musí splňovat následující tři kritéria:

 

• Musí být platný (certifikáty jsou vydávány na konkrétní dobu, např. 1 rok)
   

• Jméno uvedené v certifikátu se musí shodovat se jménem, které volá klient
   

• Certifikační autorita, která certifikát vydala, musí být pro klienta důvěryhodná

Hlavně v posledním bodě narazíte na mnoho problémů. Pokud si certifikát necháte vystavit např. vaší vlastní, interní certifikační autoritou, připravte se na to, že budete muset do každého zařízení, které bude komunikovat s Exchange, nejprve naimportovat certifikát certifikační autority. U klientů Windows, kteří jsou členy domény, to půjde snadno pomocí Group Policy. U jiných klientů to bude složitější…

na většině mobilních přístrojů to jde, ale je to ruční a poměrně nepříjemná práce. Obzvlášť v případě, že máte ve firmě desítky, stovky, nebo tisíce různých zařízení. V takovém případě bych vám raději doporučil si zakoupit certifikát od nějaké komerční a uznávané certifikační autority, která bude klientovi známa. To tedy znamená, že jako správce Exchange serveru bych měl nejprve zvážit, jaké mobilní klienty budeme ve firmě provozovat, ověřit si u každého přístroje které certifikační autority podporuje a teprve potom provést nákup certifikátu u takové certifikační autority, která je pokud možno podporována všemi klienty. Osobně mám vynikající zkušenosti s certifikační autoritou Thawte, je podporována skoro na všech přístrojích a její ceny za roční certifikát jsou pro české firmy přijatelné (např. zde – ceny jsou kolem 5.000,- Kč za 1 rok).

Vraťme se ale k vytvoření samotné žádosti o certifikát, kterou vytvoříme pomocí:

 

1. EMC: Server Configuration -> vybereme server, se kterým chceme pracovat a spustíme průvodce „New Exchange Certificate“
    

2. V tomto skvělém pomocníkovi vyplníme jméno nového certifikátu, rozhodneme se, zdali se bude jednat o wildcard certifikát a následně v sekci „Exchange Configuration“ vyplníme jména, která bude náš Exchange server používat na jednotlivých službách (jedno ze jmen musí být primární – většinou se jedná o FQDN daného serveru)

Žádost o nový Exchange certifikát

3. Vyplníme informace o naší společnosti, žádost uložíme na disk a posléze doručíme certifikační autoritě

4. Jakmile certifikační autorita žádost schválí, pošle nám finální certifikát, který zasociujeme s žádostí v Exchange konzole klepnutím na žádost a volbou „Complete Pending Request“

5. Pokud vše dopadlo v pořádku, máme certifikát připraven k nasazení. Pomocí volby „Assign Services to Certificate“ zasociujeme certifikát se službami Exchange. Službám je mimo jiné nastaveno jméno, na kterém budou naslouchat podle toho, co jsme nastavili v předchozím průvodci.

Nastavení služeb Client Access Server role

Autodiscover

Jako poslední kamínek zapadl do mozaiky různých Exchange technologií Autodiscover. Podporují jej sice jen ty nejnovější klienti, ale je to něco, co nám zde vždy chybělo. Autodiscover se na klientovi stará o to, že po zadání jeho emailové adresy a hesla nastaví celý přístroj tak, aby správně fungoval s Exchange serverem. Odpadá tedy nutnost pro klienta znát informace o infrastruktuře a nastavení klienta, stačí si pamatovat svůj vlastní email a heslo. Autodiscover se kontroluje opakovaně a v případě rozsáhlých změn ve vaší Exchange infrastruktuře (např. při migracích) se postará o opakovanou a správnou rekonfiguraci klienta.

Jak funguje Autodiscover:

 

1. Klient si z emailové adresy bere jméno domény – tedy to, co je za „@“, zavináčem. Pokud je tedy moje adresa pavlis@kpcs.cz, ví, že dále bude pracovat s doménou „kpcs.cz“
    

2. Skrze DNS překlad se pokouší najít autodiscover záznam. Ten může být ve třech tvarech:
    

   
    

   1. A záznam kpcs.cz domény
       

   2. A záznam „autodiscover“ v zóně „kpcs.cz“. Tedy „autodiscover.kpcs.cz“
       

   3. SRV záznam „_autodiscover“

   
    

3. Jakmile se mu podaří jednu ze tří voleb přeložit na IP adresu (tedy záznam existuje), otevírá klient HTTP spojení na Exchange server do virtuální cesty „<jméno serveru>/autodiscover/autodiscover.xml“.
    

4. Po nezbytné autentizaci klient od serveru dostává XML soubor, který webová služba na základě požadavku pro klienta vytvořila. Tímto XML souborem si klient sám službu ActiveSync nakonfiguruje

Služba Autodiscover se sama o sobě nekonfiguruje. Nastavení, které posílá klientovi, si bere z nastavení ostatních relevantních služeb. Přesto je nezbytné aby to, co Autodiscover klientům vrací zkontrolovat, protože jinak klient nebude moci nalézt některé služby a nebude korektně fungovat. Toto docílíme pomocí klienta Outlook:

 

1. Na hlavní liště Windows, vedle systémových hodin klepneme s přidrženou klávesou CTRL pravým tlačítkem na ikonu Outlook a vybereme volbu „Test E-mail AutoConfiguration“
    

2. Zadáme emailovou adresu a heslo

Test E-mail AutoConfiguration

Ověříme, že adresy, na kterých jsou klientům poskytovány jednotlivé služby, jsou v pořádku a platné. V případě, že nalezneme chybu, je nutné ji v dané služně opravit.

Outlook Web App (OWA)

Outlook Web App je rozhraním uzpůsobeném pro internetové prohlížeče. Nově nejen pro Internet Explorer, ale i další. Je tedy ideální pro přístup v momentě, kdy uživatel nemůže používat svůj vlastní počítač (např. na dovolené).

Pro správné fungování OWA, je potřeba provést několik konfiguračních kroků:

 

1. EMC: Server Configuration -> Client Access -> označíme server, se kterým chceme pracovat a volíme záložku „Outlook Web App“, na které voláme vlastnosti virtuálního adresáře OWA
    

2. Na záložce „General“ zadáme jméno, které bude použito při interním a externím přístupu – pokud jsme již dříve prošli průvodcem vystavení certifikátu a jeho následném nasazení do systému, budou jména nastavena podle tohoto průvodce
    

3. Na záložce „Authentication“ vybíráme typ požadované autentizace¨
    

4. Případně na dalších záložkách nastavujeme požadované chování OWA (např. režim chování při přístupu z veřejného a privátního počítače (Public přístup k přílohám jen pomocí WebReady, Private přístup ke všemu), atd.)

Nastavení OWA

Pokud požadujete zjednodušení přístupu k OWA pro vaše uživatele tak, aby místo složitého psaní adresy https://email.exchange4u.cz/owamohli psát pouze http://email.exchange4u.cz, řiďte se doporučením na této stránce: http://technet.microsoft.com/en-us/library/aa998359.aspx

Nastavení Exchange ActiveSync

ActiveSync umí kromě synchronizace dat – typicky emaily, kontakty a kalendář – synchronizovat na klienta i další, hlavně bezpečnostní nastavení. Jedná o velmi důležitou komponentu ActiveSyncu - v poštovních schránkách se dnes nachází celé množství velmi citlivých dat a je zcela nezbytné zajistit, aby tato data nemohla být zneužita jen tím, že je vám ukraden váš mobilní telefon. Typickým a velmi používaným příkladem je politika hesel – tedy to, po jak dlouhé době nečinnosti se má mobilní klient zamknout, jaké heslo má po klientovi požadovat a pokud je to ze strany zařízení podporováno, tak i to, po kolika špatně zadaných heslech se má telefon zrestartovat a vrátit do továrního nastavení (tedy vlastně vymazat). Pokud klient podporuje i datové úložiště pro ukládání dat (např. různé micro/mini SD karty), můžeme díky politice vynutit i šifrování těchto dat. Tím pádem i zcizení telefonu a přendání datové karty neumožní útočníkovi získat žádná data.

Pro správné a požadované fungování synchronizace mobilních klientů s Exchange serverem pomocí ActiveSync je potřeba nastavit politiky, jejichž nastavení se budou na klienty aplikovat:

 

1. Organization Configuration -> Client Access -> záložka „Exchange ActiveSync Mailbox Policies“
    

2. Vybíráme výchozí politiku „default“, případně zakládáme novou a měníme její vlastnosti dle požadavků (politik samozřejmě může být v Exchange serveru víc a není problém tak na různé uživatele aplikovat různé politiky a zajistit tak potřebná nastavení napříč všemi klienty)

Politika ActiveSync

Dalšími zajímavými volbami může být blokování WiFi, Bluetooth, nebo vestavěného fotoaparátu/videokamery. Velmi užitečná je i možnost blokování přístupu k datovým službám v momentě, kdy se klient nachází na roamingu. Zabráníte tak nepříjemnému překvapení v podobě vysokého účtu za telefon v momentě, kdy se pohybujete v zahraničí. Pouze si dovolím upozornit na to, že většina z možností uvedených v tomto odstavci vyžaduje pro klienta rozšířenou, tedy Enterprise CAL licenci.

Více se o ActiveSync můžete dozvědět zde: http://technet.microsoft.com/cs-cz/ee958098.aspx

Nastavení Outlook Anywhere

Pokud chceme, aby naši klienti mohli Outlook komunikovat s Exchange serverem odkudkoli pomocí komunikace zabalené do HTTPS, je potřeba povolit Outlook Anywhere. Toho docílíme následovně:

 

1. Zkontrolujeme na serveru, že máme nainstalovánu komponentu „RPC over HTTP"
    

2. EMC: Server Configuration -> Client Access -> označíme server, se kterým chceme pracovat a voláme průvodce „Enable Outlook Anywhere“
    

3. V rámci něho vyplníme jméno, na kterém bude tato služba z internetu dostupná

Zapnutí Outlook Anywhere

Pozor na volbu klientské autentizace. V případě použití Basic autentizace máte sice 100% jistotu jejího fungování, ale klient bude při použití Outlook Anywhere vždy (!) dotázán na heslo, bez možnosti jej uložit. Pokud vyberete autzentizaci pomocí NTLM, jde sice heslo na klientovi uložit a uživatel tak nebude na heslo opakovaně dotazován, nicméně pozor, NTLM autentizace neprochází mnoha síťovými prvky a tak je možné, že nebude fungovat všude.

Exchange Server 2010 seriál – Vybrané novinky Exchange 2010 (část VII.)

Některé z novinek Exchange 2010 se nám do tohoto dokumentu nevejdou, přesto jsem si dovolil vybrat dvě novinky, které jsou ze strany uživatelů velmi pozitivně přijímány.

MailTips

MailTips jsou různé tipy, které uživatele již při psaní zprávy upozorňují na to, že zpráva – pokud ji na danou adresu odešlou – bude doručena se zpožděním, nebo vůbec, atd. Jedná se tedy o pomocníka, který se snaží snížit počet zpráv a zamezit některým typům omylů. Typicky tedy oceníte informaci o tom, že uživatel schránky, které se právě chystáte poslat zprávu je na dovolené, nebo že adresa směřuje mimo organizaci. Možností je samozřejmě mnoho, uvádím pouze ty z nich, které sám používám. Toto nastavíme pomocí EMS:

 

• Set-OrganizationConfig -MailTipsLargeAudienceThreshold 25
   

• Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true
   

• Set-OrganizationConfig -MailTipsMailboxSourcedTipsEnabled $true
   

• Set-OrganizationConfig -MailTipsGroupMetricsEnabled $true
   

• Set-MailboxServer <jmenoseveru> -GroupMetricsGenerationEnabled $true
   

• Set-MailboxServer <jmenoseveru> -GroupMetricsGenerationTime 03:00

MailTips

Nastavení obrázků pro Exchange schránky

Pokud používáte klienty Microsoft Office Outlook 2010 a vyšší, můžete využít možnost nahrát do Active Directory pro každého uživatele/schránku obrázek, který je následně uživatelům v klientovi zobrazován. Jedinou podmínkou je to, že obrázek nesmí být větší než 10KB a musí se jednat o formát JPG. Import obrázků do Active Directory provedeme pomocí příkazu v Exchange Management Shellu následovně:

 

1. EMS: Import-RecipientDataProperty -Identity “Martin Pavlis” -Picture -FileData ([Byte[]]$(Get-Content -path “C:\Photo\Pavlis.jpg” -Encoding Byte -ReadCount 0))

Obrázek v Outlooku 2010

Zprávy jsou následně zobracovány uživatelům jak při náhledu v GALu, tak také na dalších místech.

Nastavení kompatibility s klienty Microsoft Office Outlook 2003

Pokud používáte klienty Microsoft Office Outlook 2003, můžete se setkat s problémem, kdy tito klienti nejsou schopni s Exchange servery 2010 komunikovat. Důvodem je, že CAS server hned po instalaci vyžaduje šifrovanou MAPI/RPC komunikaci mezi Exchange a klienty. Což starší klienti nemají standardně zapnuto. Pokud se s tímto problémem setkáte, jsou v podstatě dvě varianty, jak problém vyřešit:

 

1. Ve všech Outlook 2003 je nutné nastavit v profilu šifrování MAPI/RPC komunikace. Buď ručně, nebo vynutit na klientech (ideálně ještě před samotnou migrací) pomocí Group Policy
    

2. Vypnout vynucené šifrování MAPI/RCP na Exchange Server, s CAS roli pomocí EMS: Set-RpcClientAccess –identity <jmenoseveru> –EncryptionRequired $false

Outlook RPC Encrypted

Import/Export dat z/do PST souborů

Tento velmi historický způsob migrace dat je nejen u nás pořád velmi populární a mnoho správců jej má velmi rádo. Mezi hlavní pozitivum se řadí to, že obsah schránky je vyexportován do PST a přenesen do zcela nového prostředí – většinou do nové Active Directory, do nové Exchange organizace a umožňuje tak postavit Exchange na “zelené louce” - shodit vše, co bylo doteď a začít znovu. Pozor - v PST se přenesou jen emaily a ztratí se mnoho vlastností schránek (pohledy, formátovaní a nastavení, pravidla, atd.). Pomocí PST se opravdu přenášejí jen a jen položky ve schránce, nic víc. Pokud vám ale tyto limity nevadí a jste v situaci, kdy export/import skrze PST je přesně to co chcete, postupujte následovně.

Buď přímo na server, nebo na správcovskou stanici (musí být x64 architektura a členem domény, kde se nachází Exchange Server 2010) instalujeme postupně:

 

• Powershell 2.0
   

• .NET Framework 3.51
   

• Office Outlook 2010 64bit
   

• Exchange Server 2010 správcovské nástroje (pustíme instalátor serveru a vybereme jen Management Tools)

Nyní je potřeba se k Exchange serveru přihlásit jako někdo, kdo má plná oprávnění nad Exchange organizací (typicky tedy Administrator) a právo importu/exportu oddelegovat na pověřenou osobu, či skupinu. Zde bych chtěl zdůraznit, že toto právo po instalaci nemá nikdo a protože Exchange Server 2010 dodržuje striktně přiřazování rolí (pomocí Role Base Access Control), bez tohoto práva se dál nedostanete.

 

• New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “<username>”
   

• New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “<usergroup>”

V prvním příkladu jsme právo importu/export delegovali na jeden konkrétní účet, v případě druhém potom na celou skupinu.

Jakmile se nyní ke správcovské stanici přihlásíme pod účtem, kterému jsme v předchozím kroku přiřadili potřebné právo, můžeme v rámci Powershellu začít používat CMDlety “import-mailbox” a “export-mailox”.

Export Mailbox

Výhodou v rámci Exchange Server 2010 je to, že můžeme spustit i konzolu "Exchange Management Console”, kde se nám po klepnutí pravým tlačítkem myši objeví i možnost vyvolání grafického průvodce importem a exportem. Tím se celá akce stává velmi jednoduchou.

Microsoft Exchange Best Practices Analyzer

Protože je Exchange server závislý na celé řadě dalších služeb (např. DNS a Active Directory), je doporučeno, aby při kontrole prostředí Exchange správce nezůstal jen u kontroly jeho služeb, ale aby kontrola probíhala komplexně, nad celým prostředím. Pro tyto účely najdeme přímo v EMC konzole nástroj „Exchange Best Practices Analyzer“. Ten si může při každém spuštění stáhnout z internetu aktualizované testy, kterými následně celou infrastrukturu společnosti prověří a v případě nesrovnalostí nabídne doporučená řešení.

Exchange Best Practices Analyzer

Tento nástroj doporučuji spouštět cca 1x měsíčně a kontrolovat tak celou Exchange infrastrukturu, včetně návazných služeb.

Microsoft Exchange Remote Connectivity Analyzer

Jakmile jste nastavili vše ve vaší Exchange organizaci podle výše uvedených postupů, jistě byste chtěli míst jistotu, že přístup k vašim Exchange serverům vypublikovaným do internetu bude fungovat korektně a podle vašich představ. Přesně pro tyto účely vytvořil Microsoft online nástroj, který je schopen z internetu otestovat vše podstatné – např. DNS, SMTP, Outlook Anywhere, Exchange ActiveSync, atd. Jedná se o vynikající nástroj!

Exchange Remote Connectivity Analyzer

Tento nástroj naleznete na této adrese: https://www.testexchangeconnectivity.com

Exchange Server 2010 seriál – Vysoká dostupnost v Exchange Serveru 2010 (část VIII.)

Pokud máte obavu, že při výpadku Exchange serverů dojde díky nedostupnosti poštovního systému k finančním ztrátám ve vaší společnosti, je jistě na čase začít přemýšlet o zajištění vysoké dostupnosti. Tato oblast se dá velmi jednoduše rozdělit do dvou oblastí – vysoká dostupnost dat, která jsou uložena v Exchange databázích a vysoká dostupnost na úrovni sítě, kdy je klientský přenos směřován na nejvýhodnější/nejdostupnější server. V obou případech platí, že serverů bude potřeba více – minimální scénář počítá se dvěma servery, v rozsáhlých sítích u větších společností se ale může jednat o desítky serverů.

Database Availability Group

Data v Exchange serveru jsou uložena na v databázích, o které se starají servery s nainstalovanou Mailbox rolí. Tyto servery je možné včlenit do skupiny, v rámci které je možné zajistit repliku dat na všechny její členy. Této skupině se říká Database Availability Group (DAG). Abychom mohli Exchange servery do DAG přidat, je potřeba splnit následující:

• Operační systém Windows musí být ve verzi Enteprise, případně Datacenter – důvodem je spolupráce DAG se službou Windows Failover Cluster, která je součástí právě jen těchto edicí
   

• Exchange Server může být ve verzi Standard (jedná se o významnou novinku!), pokud vám stačí práce s pouze pěti databázemi
   

• Dále je doporučeno, aby Exchange servery v DAG měly dvě síťová rozhraní – jednu síť na komunikaci s klienty a jednu na synchronizaci dat
   

• V rámci DAG je možné replikovat pouze data Mailbox databází, není možné skrze DAG replikovat data v Public Folder (Veřejné složky) databázích

Založení DAG je velmi jednoduché:

1. EMC: Organization Configuration -> Mailbox -> záložka Database Availability Group 
    
          Database Availability Group 
   Zde volíme příkaz „New Database Availability Group a vyplňujeme vlastnosti budoucí DAG skupiny:
    

   1. Jméno DAG – jedná se o jméno, které bude použito ke správě DAG, a proto musí být v rámci vaší sítě unikátní (podobně jako jméno Exchange serveru). Po založení DAG vzniká v Active Directory účet počítače s tímto jménem
       

   2. Server (a složka), který bude použit jako svědek – pokud máte v síti další HUB servery, bude jako svědek automaticky použit některý z nich a není nutné zde nic vyplňovat. Pokud takové servery v síti nemáte, je potřeba vybrat jakýkoli dostupný Windows server. Na tomto serveru je ale potřeba nejprve vytvořit a vysdílet složku tak, aby ji DAG mohl používat. Přesný postup naleznete zde: http://technet.microsoft.com/en-us/library/dd298065.aspx 
      
       
            Založení nové DAG

Tím je DAG i s jeho vlastnostmi vytvořen v Exchange organizaci, ale fyzicky se stále nic neděje. Můžete se proto zamyslet nad tím, zdali nechcete změnit některé z dalších vlastností DAG tak, aby plně vyhovoval vašim potřebám:

• Standardně se data v rámci DAG mezi Exchange servery replikují protokolem využívajícím TCP na portu 64327. Tento port je při vkládání serverů do DAG automaticky povolen v rámci vestavěného Windows Firewallu. Pokud chcete, můžete tento port změnit, nicméně je potřeba následně tento port manuálně povolit i ve Windows Firewall. Změnu proveďete pomocí následujícího příkazu v EMS:
   

  • Set-DatabaseAvailabilityGroup -Identity DAG -ReplicationPort 12345

   

• DAG ke svému fungování potřebuje nejen jméno, ale také IP adresu. Protože v EMC nemáte možnost tuto IP adresu měnit a protože ne každému bude vyhovovat, že se IP automaticky bere z DHCP serveru, můžete IP adresu nastavit na konkrétní, statickou hodnotu. Pro tyto účely proveďte následující příkaz v EMS:
   

  • Set-DatabaseAvailabilityGroup -Identity DAG -DatabaseAvailabilityGroupIPAddresses 10.0.0.1

Jakmile máte dokončeny úpravy vlastností DAG, můžete do DAG začít přidávat jednotlivé Mailbox servery. Postupujte následovně:

1. EMC: Organization Configuration -> Mailbox -> záložka Database Availability Group
    

2. Voláme příkaz „Manage Database Availability Group Membership“
    

3. Tlačítkem „Add“ přidáváme do DAG všechny patřičné Mailbox servery 
   
    
          Přidání serverů do DAG 
   
   Teprve v momentě, kdy stiskneme tlačítko „Manage“ dochází k fyzickému založení DAG a přidání jednotlivých serverů do DAG skupiny. Průvodce je velmi inteligentní a dokáže většinu nezbytných požadavků na straně Mailbox serveru zajistit sám. Např. zkontroluje, zdali se jedná o systém správné edice, zdali je na požadovaném Mailbox serveru nainstalována komponenta Windows Failover Cluster – tu si případně i sám doinstaluje – a celou řadu dalších kroků. Je normální, že dokončení tohoto kroku na každém Mailbox serveru trvá i několik desítek vteřin. 
   
    
          Dokončení založení DAG 
   
   Nyní máme DAG vytvořen a můžeme si zpětně prohlédnout jeho vlastnosti a to, které Mailbox servery jsou aktuálně členy DAG. V dolní části máme možnost provádět další změny, např. v oblasti sítí (např. to, po které síti se budou replikovat data mezi Mailbox servery a na které síti bude Exchange komunikovat s klienty) 
   
    
          Vlastnosti DAG 
   
    

4. V tomto okamžiku můžeme v rámci DAG zajistit replikaci dat jednotlivých databází. Jedná se o vlastnost databáze, proto je potřeba postupovat následovně:
    

   1. EMC: Organization Configuration -> Mailbox -> záložka Database Management
       

   2. Označíme databázi, kterou chceme replikovat na další Mailbox servery a voláme příkaz „Add Mailbox Database Copy“
       

   3. V rámci průvodce vybíráme, které Mailbox servery budou tuto databázi replikovat 
      
       
             Vytvoření repliky databáze v rámci DAG 
       

5. Jakmile dokončíme průvodce pro přidání repliky databáze, máme možnost v management nástrojích sledovat, které servery aktuálně replikují danou databázi, který server drží aktivní repliku (mounted - tu se kterou se aktuálně pracuje), které servery mají další repliky a v jakém stavu tyto repliky jsou (healthy, initializing, failed, atd.). Pro lepší orientaci jsou jednotlivé situace zvýrazněny použitými barvami (zelená, červená, atd.). Stejnou informaci můžeme získat i v EMS pomocí příkazu: Get-MailboxDatabaseCopyStatus –identity DAG 
   
    
          Stav replikace v rámci DAG 
   
    

6. Po označení konkrétní databáze v EMC je možné v dolní části konzoly provést Failover databáze – tedy ruční změnu, který server v rámci DAG bude držet aktivní repliku
    

7. Podobně lze provést také Failover celého serveru – v tu chvíli se všechny aktivní databáze na zvoleném serveru budou aktivovat na dalších serverech v rámci DAG 
   
    
          Aktivní práce s replikami databází v DAG

V rámci DAG je samozřejmě možné nastavit celou řadu dalších vlastností, které se vám mohou hodit v konkrétních situacích, pro další dokumentaci pokračujte zde: http://technet.microsoft.com/en-us/library/dd638215.aspx.

Síťový rozklad zátěže

V případě, že jste se rozhodli zajistit vysokou dostupnost Exchange na úrovni dat v databázích pomocí DAG, je pravděpodobné, že budete chtít zajistit také vysokou dostupnost na úrovni sítě. Připomínám, že v Exchange serveru 2010 klient nikdy nekomunikuje s databázovým serverem napřímo, ale vždy skrze Client Access Server (CAS). Je tedy nutné zajistit vysokou dostupnost této role instalací minimálně dvou CAS serverů a následně vyřešit rozklad protokolů, kterými budou klienti s CAS servery komunikovat. Tedy protokoly jako např. RPC, HTTP, IMAP, POP, atd.

• Hardware Load Balancer – pokud nechcete problematiku rozkladu síťových protokolů řešit softwarově, můžete sáhnout po partnerském řešení na úrovni hardware load balancerů. Existuje celá řada partnerských řešení jako např. od společností F5 (BIGIP), nebo Barracuda. Hardwarový load balancing musíte (!) použít také v případě, že budou ve vaší organizaci pouze dva Exchange servery. Platí zde jednoduché pravidlo – v případě, že je server členem DAG, není možné na něm provozovat Network Load Balancing, který je obsažen přímo v systému Windows. Toto je důležité hlavně u menších řešení pouze o dvou Exchange serverech – zde je nutné počítat s nákupem dalšího zařízení, které hardwarový load balancing podporuje
   

• Microsoft Network Load Balancing – technologie, která je součástí všech edicí Windows Serveru může zajistit vytvoření síťového clusteru, tedy situace, kdy má více serverů společnou IP a MAC adresu. Toto řešení nelze použít na serverech, které jsou členy DAG (!).

Ať již vyberete jakoukoli technologii síťové vysoké dostupnosti, je potřeba počítat s nastavením rozkladu patřičných protokolů (např. RPC, HTTP, IMAP, POP, atd.) na jednotlivé CAS servery. I zde existuje celá řada možností – např. směřovat vše na jeden CAS (pokud je dostupný), teprve v případě jeho nedostupnosti směřovat komunikaci na další CAS server; nebo je možné komunikaci rozkládat rovnoměrně. Toto již zcela záleží na vašich konkrétních požadavcích.

Exchange Server 2010 seriál – Vybrané novinky Exchange 2010 (část VII.)

Některé z novinek Exchange 2010 se nám do tohoto dokumentu nevejdou, přesto jsem si dovolil vybrat dvě novinky, které jsou ze strany uživatelů velmi pozitivně přijímány.

MailTips

MailTips jsou různé tipy, které uživatele již při psaní zprávy upozorňují na to, že zpráva – pokud ji na danou adresu odešlou – bude doručena se zpožděním, nebo vůbec, atd. Jedná se tedy o pomocníka, který se snaží snížit počet zpráv a zamezit některým typům omylů. Typicky tedy oceníte informaci o tom, že uživatel schránky, které se právě chystáte poslat zprávu je na dovolené, nebo že adresa směřuje mimo organizaci. Možností je samozřejmě mnoho, uvádím pouze ty z nich, které sám používám. Toto nastavíme pomocí EMS:

• Set-OrganizationConfig -MailTipsLargeAudienceThreshold 25
   

• Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true
   

• Set-OrganizationConfig -MailTipsMailboxSourcedTipsEnabled $true
   

• Set-OrganizationConfig -MailTipsGroupMetricsEnabled $true
   

• Set-MailboxServer <jmenoseveru> -GroupMetricsGenerationEnabled $true
   

• Set-MailboxServer <jmenoseveru> -GroupMetricsGenerationTime 03:00

MailTips

Nastavení obrázků pro Exchange schránky

Pokud používáte klienty Microsoft Office Outlook 2010 a vyšší, můžete využít možnost nahrát do Active Directory pro každého uživatele/schránku obrázek, který je následně uživatelům v klientovi zobrazován. Jedinou podmínkou je to, že obrázek nesmí být větší než 10KB a musí se jednat o formát JPG. Import obrázků do Active Directory provedeme pomocí příkazu v Exchange Management Shellu následovně:

 

1. EMS: Import-RecipientDataProperty -Identity “Martin Pavlis” -Picture -FileData ([Byte[]]$(Get-Content -path “C:\Photo\Pavlis.jpg” -Encoding Byte -ReadCount 0))

Obrázek v Outlooku 2010

Zprávy jsou následně zobracovány uživatelům jak při náhledu v GALu, tak také na dalších místech.

Nastavení kompatibility s klienty Microsoft Office Outlook 2003

Pokud používáte klienty Microsoft Office Outlook 2003, můžete se setkat s problémem, kdy tito klienti nejsou schopni s Exchange servery 2010 komunikovat. Důvodem je, že CAS server hned po instalaci vyžaduje šifrovanou MAPI/RPC komunikaci mezi Exchange a klienty. Což starší klienti nemají standardně zapnuto. Pokud se s tímto problémem setkáte, jsou v podstatě dvě varianty, jak problém vyřešit:

 

1. Ve všech Outlook 2003 je nutné nastavit v profilu šifrování MAPI/RPC komunikace. Buď ručně, nebo vynutit na klientech (ideálně ještě před samotnou migrací) pomocí Group Policy
    

2. Vypnout vynucené šifrování MAPI/RCP na Exchange Server, s CAS roli pomocí EMS: Set-RpcClientAccess –identity <jmenoseveru> –EncryptionRequired $false

Outlook RPC Encrypted

Import/Export dat z/do PST souborů

Tento velmi historický způsob migrace dat je nejen u nás pořád velmi populární a mnoho správců jej má velmi rádo. Mezi hlavní pozitivum se řadí to, že obsah schránky je vyexportován do PST a přenesen do zcela nového prostředí – většinou do nové Active Directory, do nové Exchange organizace a umožňuje tak postavit Exchange na “zelené louce” - shodit vše, co bylo doteď a začít znovu. Pozor - v PST se přenesou jen emaily a ztratí se mnoho vlastností schránek (pohledy, formátovaní a nastavení, pravidla, atd.). Pomocí PST se opravdu přenášejí jen a jen položky ve schránce, nic víc. Pokud vám ale tyto limity nevadí a jste v situaci, kdy export/import skrze PST je přesně to co chcete, postupujte následovně.

Buď přímo na server, nebo na správcovskou stanici (musí být x64 architektura a členem domény, kde se nachází Exchange Server 2010) instalujeme postupně:

 

• Powershell 2.0
   

• .NET Framework 3.51
   

• Office Outlook 2010 64bit
   

• Exchange Server 2010 správcovské nástroje (pustíme instalátor serveru a vybereme jen Management Tools)

Nyní je potřeba se k Exchange serveru přihlásit jako někdo, kdo má plná oprávnění nad Exchange organizací (typicky tedy Administrator) a právo importu/exportu oddelegovat na pověřenou osobu, či skupinu. Zde bych chtěl zdůraznit, že toto právo po instalaci nemá nikdo a protože Exchange Server 2010 dodržuje striktně přiřazování rolí (pomocí Role Base Access Control), bez tohoto práva se dál nedostanete.

 

• New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “<username>”
   

• New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “<usergroup>”

V prvním příkladu jsme právo importu/export delegovali na jeden konkrétní účet, v případě druhém potom na celou skupinu.

Jakmile se nyní ke správcovské stanici přihlásíme pod účtem, kterému jsme v předchozím kroku přiřadili potřebné právo, můžeme v rámci Powershellu začít používat CMDlety “import-mailbox” a “export-mailox”.

Export Mailbox

Výhodou v rámci Exchange Server 2010 je to, že můžeme spustit i konzolu "Exchange Management Console”, kde se nám po klepnutí pravým tlačítkem myši objeví i možnost vyvolání grafického průvodce importem a exportem. Tím se celá akce stává velmi jednoduchou.

Microsoft Exchange Best Practices Analyzer

Protože je Exchange server závislý na celé řadě dalších služeb (např. DNS a Active Directory), je doporučeno, aby při kontrole prostředí Exchange správce nezůstal jen u kontroly jeho služeb, ale aby kontrola probíhala komplexně, nad celým prostředím. Pro tyto účely najdeme přímo v EMC konzole nástroj „Exchange Best Practices Analyzer“. Ten si může při každém spuštění stáhnout z internetu aktualizované testy, kterými následně celou infrastrukturu společnosti prověří a v případě nesrovnalostí nabídne doporučená řešení.

Exchange Best Practices Analyzer

Tento nástroj doporučuji spouštět cca 1x měsíčně a kontrolovat tak celou Exchange infrastrukturu, včetně návazných služeb.

Microsoft Exchange Remote Connectivity Analyzer

Jakmile jste nastavili vše ve vaší Exchange organizaci podle výše uvedených postupů, jistě byste chtěli míst jistotu, že přístup k vašim Exchange serverům vypublikovaným do internetu bude fungovat korektně a podle vašich představ. Přesně pro tyto účely vytvořil Microsoft online nástroj, který je schopen z internetu otestovat vše podstatné – např. DNS, SMTP, Outlook Anywhere, Exchange ActiveSync, atd. Jedná se o vynikající nástroj!

Exchange Remote Connectivity Analyzer

Tento nástroj naleznete na této adrese: https://www.testexchangeconnectivity.com

Exchange Server 2010 seriál – Vysoká dostupnost v Exchange Serveru 2010 (část VIII.)

Pokud máte obavu, že při výpadku Exchange serverů dojde díky nedostupnosti poštovního systému k finančním ztrátám ve vaší společnosti, je jistě na čase začít přemýšlet o zajištění vysoké dostupnosti. Tato oblast se dá velmi jednoduše rozdělit do dvou oblastí – vysoká dostupnost dat, která jsou uložena v Exchange databázích a vysoká dostupnost na úrovni sítě, kdy je klientský přenos směřován na nejvýhodnější/nejdostupnější server. V obou případech platí, že serverů bude potřeba více – minimální scénář počítá se dvěma servery, v rozsáhlých sítích u větších společností se ale může jednat o desítky serverů.

Database Availability Group

Data v Exchange serveru jsou uložena na v databázích, o které se starají servery s nainstalovanou Mailbox rolí. Tyto servery je možné včlenit do skupiny, v rámci které je možné zajistit repliku dat na všechny její členy. Této skupině se říká Database Availability Group (DAG). Abychom mohli Exchange servery do DAG přidat, je potřeba splnit následující:

• Operační systém Windows musí být ve verzi Enteprise, případně Datacenter – důvodem je spolupráce DAG se službou Windows Failover Cluster, která je součástí právě jen těchto edicí
   

• Exchange Server může být ve verzi Standard (jedná se o významnou novinku!), pokud vám stačí práce s pouze pěti databázemi
   

• Dále je doporučeno, aby Exchange servery v DAG měly dvě síťová rozhraní – jednu síť na komunikaci s klienty a jednu na synchronizaci dat
   

• V rámci DAG je možné replikovat pouze data Mailbox databází, není možné skrze DAG replikovat data v Public Folder (Veřejné složky) databázích

Založení DAG je velmi jednoduché:

1. EMC: Organization Configuration -> Mailbox -> záložka Database Availability Group 
    
          Database Availability Group 
    

2. Zde volíme příkaz „New Database Availability Group a vyplňujeme vlastnosti budoucí DAG skupiny:
    

   1. Jméno DAG – jedná se o jméno, které bude použito ke správě DAG, a proto musí být v rámci vaší sítě unikátní (podobně jako jméno Exchange serveru). Po založení DAG vzniká v Active Directory účet počítače s tímto jménem
       

   2. Server (a složka), který bude použit jako svědek – pokud máte v síti další HUB servery, bude jako svědek automaticky použit některý z nich a není nutné zde nic vyplňovat. Pokud takové servery v síti nemáte, je potřeba vybrat jakýkoli dostupný Windows server. Na tomto serveru je ale potřeba nejprve vytvořit a vysdílet složku tak, aby ji DAG mohl používat. Přesný postup naleznete zde: http://technet.microsoft.com/en-us/library/dd298065.aspx 
      
       
            Založení nové DAG

Tím je DAG i s jeho vlastnostmi vytvořen v Exchange organizaci, ale fyzicky se stále nic neděje. Můžete se proto zamyslet nad tím, zdali nechcete změnit některé z dalších vlastností DAG tak, aby plně vyhovoval vašim potřebám:

 

• Standardně se data v rámci DAG mezi Exchange servery replikují protokolem využívajícím TCP na portu 64327. Tento port je při vkládání serverů do DAG automaticky povolen v rámci vestavěného Windows Firewallu. Pokud chcete, můžete tento port změnit, nicméně je potřeba následně tento port manuálně povolit i ve Windows Firewall. Změnu proveďete pomocí následujícího příkazu v EMS:
   

   

  • Set-DatabaseAvailabilityGroup -Identity DAG -ReplicationPort 12345

  
   

• DAG ke svému fungování potřebuje nejen jméno, ale také IP adresu. Protože v EMC nemáte možnost tuto IP adresu měnit a protože ne každému bude vyhovovat, že se IP automaticky bere z DHCP serveru, můžete IP adresu nastavit na konkrétní, statickou hodnotu. Pro tyto účely proveďte následující příkaz v EMS:
   

   

  • Set-DatabaseAvailabilityGroup -Identity DAG -DatabaseAvailabilityGroupIPAddresses 10.0.0.1

Jakmile máte dokončeny úpravy vlastností DAG, můžete do DAG začít přidávat jednotlivé Mailbox servery. Postupujte následovně:

 

1. EMC: Organization Configuration -> Mailbox -> záložka Database Availability Group
    

2. Voláme příkaz „Manage Database Availability Group Membership“
    

3. Tlačítkem „Add“ přidáváme do DAG všechny patřičné Mailbox servery 
   
    
          Přidání serverů do DAG 
    

4. Teprve v momentě, kdy stiskneme tlačítko „Manage“ dochází k fyzickému založení DAG a přidání jednotlivých serverů do DAG skupiny. Průvodce je velmi inteligentní a dokáže většinu nezbytných požadavků na straně Mailbox serveru zajistit sám. Např. zkontroluje, zdali se jedná o systém správné edice, zdali je na požadovaném Mailbox serveru nainstalována komponenta Windows Failover Cluster – tu si případně i sám doinstaluje – a celou řadu dalších kroků. Je normální, že dokončení tohoto kroku na každém Mailbox serveru trvá i několik desítek vteřin. 
   
    
          Dokončení založení DAG 
   
   Nyní máme DAG vytvořen a můžeme si zpětně prohlédnout jeho vlastnosti a to, které Mailbox servery jsou aktuálně členy DAG. V dolní části máme možnost provádět další změny, např. v oblasti sítí (např. to, po které síti se budou replikovat data mezi Mailbox servery a na které síti bude Exchange komunikovat s klienty) 
   
    
          Vlastnosti DAG 
   
    

5. V tomto okamžiku můžeme v rámci DAG zajistit replikaci dat jednotlivých databází. Jedná se o vlastnost databáze, proto je potřeba postupovat následovně:
    

    

   1. EMC: Organization Configuration -> Mailbox -> záložka Database Management
       

   2. Označíme databázi, kterou chceme replikovat na další Mailbox servery a voláme příkaz „Add Mailbox Database Copy“
       

   3. V rámci průvodce vybíráme, které Mailbox servery budou tuto databázi replikovat 
      
       
             Vytvoření repliky databáze v rámci DAG 
       

6. Jakmile dokončíme průvodce pro přidání repliky databáze, máme možnost v management nástrojích sledovat, které servery aktuálně replikují danou databázi, který server drží aktivní repliku (mounted - tu se kterou se aktuálně pracuje), které servery mají další repliky a v jakém stavu tyto repliky jsou (healthy, initializing, failed, atd.). Pro lepší orientaci jsou jednotlivé situace zvýrazněny použitými barvami (zelená, červená, atd.). Stejnou informaci můžeme získat i v EMS pomocí příkazu: Get-MailboxDatabaseCopyStatus –identity DAG 
   
    
          Stav replikace v rámci DAG 
   
    

7. Po označení konkrétní databáze v EMC je možné v dolní části konzoly provést Failover databáze – tedy ruční změnu, který server v rámci DAG bude držet aktivní repliku
    

8. Podobně lze provést také Failover celého serveru – v tu chvíli se všechny aktivní databáze na zvoleném serveru budou aktivovat na dalších serverech v rámci DAG 
   
    
          Aktivní práce s replikami databází v DAG

V rámci DAG je samozřejmě možné nastavit celou řadu dalších vlastností, které se vám mohou hodit v konkrétních situacích, pro další dokumentaci pokračujte zde: http://technet.microsoft.com/en-us/library/dd638215.aspx.

Síťový rozklad zátěže

V případě, že jste se rozhodli zajistit vysokou dostupnost Exchange na úrovni dat v databázích pomocí DAG, je pravděpodobné, že budete chtít zajistit také vysokou dostupnost na úrovni sítě. Připomínám, že v Exchange serveru 2010 klient nikdy nekomunikuje s databázovým serverem napřímo, ale vždy skrze Client Access Server (CAS). Je tedy nutné zajistit vysokou dostupnost této role instalací minimálně dvou CAS serverů a následně vyřešit rozklad protokolů, kterými budou klienti s CAS servery komunikovat. Tedy protokoly jako např. RPC, HTTP, IMAP, POP, atd.

• Hardware Load Balancer – pokud nechcete problematiku rozkladu síťových protokolů řešit softwarově, můžete sáhnout po partnerském řešení na úrovni hardware load balancerů. Existuje celá řada partnerských řešení jako např. od společností F5 (BIGIP), nebo Barracuda. Hardwarový load balancing musíte (!) použít také v případě, že budou ve vaší organizaci pouze dva Exchange servery. Platí zde jednoduché pravidlo – v případě, že je server členem DAG, není možné na něm provozovat Network Load Balancing, který je obsažen přímo v systému Windows. Toto je důležité hlavně u menších řešení pouze o dvou Exchange serverech – zde je nutné počítat s nákupem dalšího zařízení, které hardwarový load balancing podporuje
   

• Microsoft Network Load Balancing – technologie, která je součástí všech edicí Windows Serveru může zajistit vytvoření síťového clusteru, tedy situace, kdy má více serverů společnou IP a MAC adresu. Toto řešení nelze použít na serverech, které jsou členy DAG (!).

Ať již vyberete jakoukoli technologii síťové vysoké dostupnosti, je potřeba počítat s nastavením rozkladu patřičných protokolů (např. RPC, HTTP, IMAP, POP, atd.) na jednotlivé CAS servery. I zde existuje celá řada možností – např. směřovat vše na jeden CAS (pokud je dostupný), teprve v případě jeho nedostupnosti směřovat komunikaci na další CAS server; nebo je možné komunikaci rozkládat rovnoměrně. Toto již zcela záleží na vašich konkrétních požadavcích.