Microsoft Exchange

Přístup ke své emailové schránce odkudkoliv je dnes v podstatě nutností. Využívání POP3 nebo IMAP bez šifrování je nebezpečné a potřebuje mít na klientovi software a konfiguraci. Pro OWA nám stačí "libovolný" webový prohlížeč a pokud použijeme Internet Explorer 5.01 a výše, dostaneme komfortní prostředí. Zprovoznění na Exchange serveru je jednoduché, ale je třeba upravit nastavení pro větší bezpečnost.

Pokud máme k dispozici počítač a připojení k internetu, tak pro přístup ke své poště můžeme využít Outlook Web Access. Určitě však může nastat situace, kdy počítač k dispozici nemáme, a přesto si potřebujeme přečíst nějakou důležitou zprávu. V této situaci nám může pomoci Outlook Mobile Access. Pro využití OMA potřebujeme mobilní telefon s podporou WAPu (a většinou také HTTPS) a připojení k internetu (WAPu), což v dnešní době podporuje většina telefonů a všichni operátoři.

Uživatelé, kteří používají mobilní zařízení typu PDA nebo Smartphone vybavené operační systémem od firmy Microsoft bezpochyby znají a využívají aplikaci ActiveSync pro synchronizaci dat mezi počítačem a mobilním zařízením. Obdobnou funkcí je i Exchange ActiveSync, který běží na Exchange serveru a zajišťuje obdobné synchronizace, ale přes internet.

Testoval jsem teď Exchange 2007 a při tom jsem narazil na problém, který je docela běžný a ne jednoduše se na internetu najde odpověď. Většinou tato situace nastane při testování a ne ostrém provozu. Pokusím se popsat situaci, řešení a také důvody proč k tomu dochází.

Článek shrnuje řadu možných postupů, jak vyřešit jeden specifický problém. Jedná se však o značně obecné postupy, takže se dají využít i v řadě jiných situací. Problém spočívá v tom, že při každém zapnutí Outlooku se zobrazí okno Reminder, v kterém je stále jedna událost. Její čas provedení (Due in) je nyní (now). Tato událost nejde zrušit (Dismiss). Na tento problém jsem narazil nyní, na kombinaci Exchange server 2007 a Outlook 2007, ale již i dříve na Exchange server 2003 a Outlook 2003.

Hlavně pro synchronizaci kontaktů do mobilního telefonu se může hodit přenést některé firemní kontakty z GALu mezi své osobní kontakty. Navíc Outlook 2010 podporuje v GAL kontaktech informace z Active Directory, které mohou zahrnovat také fotografie uživatelů.

Na rozdíl od Active Directory se pro MS Exchange Server 2007 musel používat PowerShell pro řadu operací již od začátku. Některé operace byly časem doplněny do GUI Exchange Management Console, ale některé můžeme provést pouze přes PowerShell. Takže opět můj malý tahák užitečných PowerShell příkazů pro Exchange server (zatím ve verzi 2007 a 2010).

Pro práci s Exchange serverem máme k dispozici řadu cmdletů v PowerShellu a pro některé funkce GUI. Ale někdy se může hodit i trochu jiný způsob. Můžeme použít Exchange Web Services Managed API, což je .NET rozhranní k EWS, které využívá Web Services SOAP protokol a Autodiscover. A stejně jako jiné .NET rozrhaní jej můžeme použít rovnou z PowerShellu.

Článek rozebírá některé možnosti, jak centrálně konfigurovat aplikace z balíku MS Office se zvláštním zaměřením na Outlook (primárně se jedná o verzi 2010, ale většinou to není podstatné). Začít můžeme modifikací instalace (zde pouze zmínka), hlavní část provedeme pomocí Group Policy Administrative Templates pro Office, některé požadavky vyřešíme změnou registrů a pro složitější příklad z praxe využijeme PowerShell.

Zmínka možností, které poskytuje Exchange Server (nejen) 2007 pro správu mobilních zařízení. Jako mobilní zařízení budeme uvažovat přístroj, který se k Exchange serveru připojuje pomocí Exchange ActiveSync protokolu (tím není myšlena synchronizace s PC pomocí ActiveSync, ale synchronizace se serverem). Takových zařízení je dnes dlouhá řada a nemusí se jednat pouze o přístroje založené na Windows Mobile, ale klidně také Android, Apple iOS, Symbian a možná i další.

Microsoft Exchange Server 2010 přináší několik nových technik pro zajištění High Availability a Fault Tolerance. Dvě hlavní se zdají na první pohled jednoduché, a pokud si člověk vytvoří lab se dvěma servery v jedné AD Site, tak se jednoduše a funkčně nastaví. Ale pokud přejdeme do praxe, tak zjistíme, že vše není zas tak přímé, funkční a intuitivní. Podíváme se zde na nastavení Client Access Server Array (CAS Array) a Database Availability Group (DAG), pokud máme tři servery, kdy dva jsou umístěny v jedné Site a jeden je v jiné.

Z nějakého důvodu, třeba protože nám došlo místo na disku s logy a tudíž se odpojila databáze, potřebujeme přesunout umístění databáze nebo logových souborů na Exchange serveru na jiný disk (nebo do nové složky). Řešení nemusí být příliš složité a je na mnoha místech popsané. Zde uvádím pouze pro moji referenci, protože jsem to v poslední době několikrát řešil.

Přechod z Exchange Server 2003 na verzi 2007 nebyl úplně jednoduchý. Zato přechod z verze 2007 na 2010 by měl jít provést za provozu, pokud vycházíme z toho, že se Exchange instaluje na nový server. Jenže se mohou projevit vedlejší problémy, které celou věc trochu zkomplikují. Musím poznamenat, že jsem se ještě nesetkal s tak špatným instalátorem, jako u Exchange 2010. V této první části se podíváme hlavně na instalaci Exchange 2010 a řešení řady problémů, které mohou nastat. Příště budeme stručně řešit vlastní migraci.

V minulém díle jsme začali tím, že jsme nainstalovali nový Exchange Server 2010 do naší organizace, a snad vyřešili všechny problémy a komplikace. Dnes budeme pokračovat vlastní migrací z původního serveru s verzí 2007 na nový. Protože se nový server stal součástí existující Exchange organizace, tak převzal hlavní nastavení. Celý postup si uvedeme pouze bodově a podrobněji se budeme věnovat pouze pár oblastem.

Jednou z novinek, se kterou přišel Exchange Server 2010, je možnost synchronizace SMS zpráv pomocí ActiveSyncu (SMS Sync). Tato vlastnost by měla uložit příchozí SMS zprávy do Inboxu na Exchange serveru a nabídnout možnost napsat SMS zprávu v Oulooku nebo OWA, která se následně synchronizuje na telefon a odsud klasicky odešle. Připadá mi to jako zajímavá možnost, ale v praxi je bohužel funkčnost slabší.

Pokud chceme využít protokol SMTP a na Exchange server, nebo pomocí něho někam dále, odeslat zprávu, tak se na straně Exchange využívá logická brána, která se označuje jako Receive Connector. Tyto konektory zpracovávají příchozí komunikaci z internetu, ostatních poštovních serverů a klientů, kteří nepoužívají protokol MAPI. Variant, které v praxi potřebujeme nastavit, je velké množství, a ne vše je možno provést pomocí EMC.

Může se stát, většinou, když se něco porouchá, že nám dorazí do schránky stovky tisíc zpráv. Práce s takovou schránkou není jednoduchá a i hromadné mazání může být problém. Outlook si s takovým množstvím moc neporadí, můžeme zkusit Outlook Web Access. Pokud se nedaří, tak je tu jedna možnost, kterou může použít správce Exchange serveru.

Článek je aktualizován pro Exchange 2016! Myslím, že Exchange serveru chybí jedna zásadní věc, a to jsou různé statistiky o provozu. U konkurenčních produktů je běžné zobrazení řady informací, které Exchange přímo neobsahuje. Například hodinové, denní, týdenní a měsíční statistiky o odeslaných a přijatých emailech, jak interně tak z internetu. Statistiky pro různé konektory. Údaje o nedoručitelnosti, nejčastější příjemci a odesílatelé, populární domény. A když už mluvíme o různých informacích, tak by také mohl Exchange přehledně informovat o svém zdraví. Tento článek je malým navedením, jak některé informace získat.

Podíváme se na situace, kdy uživatel potřebuje mít více emailových adres, a odesílat z nich poštu. Bohužel to na Exchange serveru není dobře vyřešeno. Související je situace, kdy chceme odesílat za cizí schránku nebo distribuční skupinu. Navíc jsem narazil na problém, který považuji za bug, kdy odeslání nefunguje. Jako klienta bereme Microsoft Outlook.

Sdílená schránka (Shared Mailbox) je schránka, kterou využívá více uživatelů pro čtení a odesílání zpráv. Pro podobný účel slouží veřejné složky (Public Folders) nebo s trochu jiným chováním distribuční skupiny (Distribution Groups).

Řešil jsem různé chování plánování schůzek do Outlook kalendáře (s účtem na Exchange serveru) v různých prostředích. Nepřišel jsem na to, co tento problém způsobuje, ale shromáždil jsem různé informace ohledně fungování událostí a schůzek a využití formátu iCalendar. Uvedu zde tyto poznámky, které bohužel nejsou komplexní. Detailní informace o fungování a zpracování schůzek na straně Exchange serveru jsem nikde nenalezl.

Než začneme nasazovat Exchange server, nebo migrovat ze starší verze, tak je dobré naplánovat interní i externí adresy (jména) pro jednotlivé využívané služby. Dnes je nejlepší adresy co nejvíce zjednodušit a sjednotit, v extrému na jedno doménové jméno. Stejně tak bychom měli na začátku naplánovat, kolik budeme nasazovat Exchange serverů a jak budou rozděleny v lokalitách.

Je jedno, zda provádíme nové nasazení Exchange serveru nebo migraci ze starší verze, vždy provádíme čistou instalaci nového serveru. Musíme splnit nějaké předpoklady a požadavky. Vlastní instalace je pak jednoduchá pomocí průvodce. Ve verzi Exchange 2016 se vše opět zjednodušilo, protože máme pouze dvě role (a ta druhá je Edge server), takže instalace je dost jednotná.

Elektronická pošta je již dlouho pro firmy důležitým komunikačním kanálem. Proto potřebujeme zajistit vysokou dostupnost této služby. Řešením je nasadit více serverů a řešit jejich zástupnost, tedy vlastně vytvořit cluster. K tomu nám pomáhá technologie Database Availability Group, která se objevila s Exchange 2010. Tato technologie vytváří pasivní kopie databáze schránek, replikuje jejich obsah a umožňuje přepnout aktivitu na kopii.

Na Exchange Server 2016 je služba přístupu klientů (Client Access services) součástí Mailbox serveru (nejde již o samostatnou roli). Poskytuje služby ověřování a proxy pro interní i externí klientská připojení. Klient se může připojit k libovolnému Mailbox serveru a je zajištěn prostup požadavku (proxy) na server, kde je aktivní databáze pro jeho schránku. V některých případech může provést přesměrování (redirect) na jiný server. Přístup je možný různými způsoby a protokoly, například z Outlooku, mobilního zařízení či webového prohlížeče.

Pošta mezi servery v organizaci, ale také externě v rámci internetu a dalšími organizacemi, se přenáší pomocí protokolu SMTP (Simple Mail Transfer Protocol). Přenos a směrování pošty se označuje jako Mail Flow (tok pošty). Exchange pro něj využívá Transport Pipeline, což je kolekce služeb, spojení, komponent a front. Objekty, které musíme nakonfigurovat, aby se nám přenášela pošta, jsou primárně Receive Connectors a Send Connectors.

V praxi často potřebujeme potvrdit, že byla nějaká zpráva doručena, případně hledat problémy, proč doručena nebyla. Minule jsme nastavili logování Protocol Logging a Message Tracking. Nyní se podíváme, jak tyto logy využít pro sledování doručení zpráv a Troubleshooting. Bohužel již nemáme k dispozici nástroj Tracking Log Explorer, takže musíme využít Exchange Management Shell.

Pokud provádíme migraci z Exchange 2010 na Exchange 2016 a využíváme veřejné složky (Public Folders - PF), tak musíme před přesunem prvních schránek nastavit koexistenci veřejných složek. Jinak nebudou složky dostupné pro přesunuté uživatele.

Když provádíme migraci Exchange serveru ze starší verze, tak jeden ze zásadních kroků je přesun (či migrace) poštovních schránek z původního serveru na nový. Musíme mít zprovozněny služby na původním i novém Exchange serveru, které jsou členy stejné organizace. Pak můžeme provést přesun skupiny schránek do databáze na novém serveru.

Od Exchange 2013 máme modernizované veřejné složky (Modern Public Folders), které se ukládají do speciálních schránek uvnitř standardní Mailbox Database. Stručně si popíšeme vlastnosti těchto veřejných složek a dále se budeme věnovat migraci Legacy Public Folders ze starého serveru 2010 na nový.

Ve chvíli, kdy máme migrovány schránky, veřejné složky i služby na nové servery. Veškerý provoz je směrován na Exchange 2016 a provedli jsme dostatečné testování, že vše funguje. Můžeme přistoupit k rušení původních serverů Exchange 2010. Servery musí být korektně odstraněny, tzn. odinstalován Exchange.

V předchozích článcích jsme probrali jednotlivé oblasti migrace ze starší verze Exchange serveru na nový. Nyní vše shrneme dohromady pro ucelený (ale stručný) postup migrace. Základní myšlenka přechodu z Exchange Server 2010 na 2016 je docela jednoduchá, ale čím máme složitější prostředí, tím je i přechod náročnější. Nainstalujeme nové servery do existující organizace. Na nich vytvoříme databáze, nakonfiguruje služby a přesuneme poštovní schránky. Migrace se dá provádět za provozu, kdy nějakou dobu bude fungovat koexistence staré a nové verze.

Několikrát do roka vychází pro Exchange 2016 Cumulative Update (CU), který obsahuje souhrn aktuálních opravu a všech předchozích. Při instalaci CU dojde k uprgradu serveru a změní se číslo sestavení (Build number). Průběh instalace je podobný jako čistá instalace serveru a trvá delší dobu, kdy je server nedosupný.

Článek stručně popisuje propojení Exchange 2016 a Skype for Business 2015. Vychází ze situace, kdy již integrace byla nastavena pro Exchange 2010 a pak došlo k migraci na nové Exchange servery. Získáme tak IM (Instant Messaging) a Presence v Outlook on the web a hlasové funkce (hlasová schránka, hlasový přístup do schránky, automatický pomocník).

Webové rozhraní, pro přístup k poště na Exchange serveru, se dříve jmenovalo Outlook Web App (OWA) a ještě před tím Outlook Web Access. Od Exchange Server 2016 bylo přejmenováno na Outlook on the web, ale stále se běžně uživá zkratka OWA. Mělo by být intuitivní a shodné jako aplikace Outlook (asi záleží na úhlu pohledu). Řada věcí se změnila a nevím, zda v každém případě k lepšímu.

V aplikaci Outlook můžeme plánovat schůzky v místnostech, které vytvoříme jako speciální objekt (Resource). Můžeme také využít vyhledávání volných místností Room Finder. Na Exchange serveru můžeme připravit seznamy místností Room List.

Běžně spravuje distribuční skupiny administrátor pomocí Active Directory Users and Computers, PowerShell či Exchange Admin Center. U distribučních skupin můžeme nastavit jejich vlastníka a ten pak může přidávat či odebírat členy pomocí MS Outlook. Celé je to jednoduché, ale když to zkoušíme poprvé, tak můžeme dostat chybu. Je pak třeba udělat zásah (povolení) na Exchange serveru.

Různé drobnosti týkající se Exchange Server 2016. Jak k existující skupině přidáme emailovou adresu. Příkaz pro zobrazení statistik o schránkách již nezobrazuje stav limitu. Jak vytvořit a nastavit plánovací kalendář pro zasedačku. Informace o monitoringu systémových zdrojů. Využití sdílených schránek a ukládání odeslaných zpráv. Doplněn problém s nastavením delegáta na schránku.

Office Online Server je nástupce za Office Web Apps Server. Umožňuje webové prohlížení, a případně i editaci, dokumentů Microsoft Office. Nefunguje samostatně, ale skrze servery Exchange, Skype for Business nebo SharePoint. Zde se stručně podíváme na instalaci a propojení s Exchange Server 2016. Integruje se do webového rozhraní pošty Outlook on the web a umožní přímo na webu prohlížet a editovat Word, Excel, PowerPoint a OneNote přílohy.

Řada aplikací podporuje zobrazení fotky uživatele, kterou můžeme uložit do Active Directory Domain Services (AD DS) a od Exchange 2013 také na poštovní server. Fotografii v organizaci využije Outlook či OWA, Skype for Business, SharePoint, případně další. Kvůli nárokům na velikost se do AD DS ukládá pouze malá fotografie (náhled, low-resolution photo), kdežto na Exchange můžeme uložit větší fotku (high-resolution photo). Standardně si mohou fotku nahrát/změnit sami uživatelé pomocí OWA. Podíváme se na možnost, jak toto zablokovat pomocí politiky.

Mnoho let jsem používal Symantec Messaging Gateway (dříve Brightmail), bohužel se stále více objevoval problém, že SMG přestala filtrovat český Spam (třeba na období 3 měsíců). Ani dlouhé řešení s podporou Symantecu nevedlo k lepšímu výsledku. Proto jsem otestoval konkurenční řešení na fitlrování nevyžádané pošty, které Gartner řadí mezi Leaders, Cisco Email Security (dříve Ironport). Výsledek je velmi dobrý. Článek obsahuje stručný popis nastavení a provozu.

Použití řešení Cisco Email Security (dříve Ironport) na filtrování nevyžádané pošty. Článek popisuje některé činnosti a nastavení z běžné provozní správy, tedy co děláme průběžně po úvodní implementaci. Primárně jde o to, jak identifikovat zablokované zprávy a nastavení výjimek, aby se některé zprávy doručily, i když jsou identifikovány jako Spam.

Simple Mail Transfer Protocol (SMTP) protokol přenáší standardně poštovní zprávy v čistém textu. Pokud nějaký útočník zachytí komunikaci, tak může jednoduše číst obsah zpráv i zobrazovat přílohy. Řešením je využít klientské šifrování emailů (end-to-end encryption pomocí S/MIME, PGP, apod.), ale pak je třeba řešit správu a předávání šifrovacích klíčů / certifikátů. Druhá možnost je šifrování SMTP komunikace při přenosu (to ovšem nechrání zprávy na serveru) a to si zde popíšeme. Podíváme se na nastavení na Cisco Email Security (ESA) a Exchange Server 2016.

V dalším článku se podíváme na metody pro ověřování původu poštovních zpráv (SPF, DKIM). K tomu je důležité rozumět, jak SMTP protokol odesílá poštovní zprávy. Hlavně, jak se ukládají adresy odesílatele a jak je jednoduché je podvrhnout. SMTP transakce, když se používají SMTP příkazy, označujeme jako SMTP obálku (Envelope). Vlastní email se skládá z hlavních částí, což je hlavička (Header) a tělo (Body) zprávy.

Metody, pro ověřování původu poštovních zpráv, kontrolují poštovní servery, které se účastní odeslání (a možné modifikace) emailu. Cílem je ověřit, že byla zpráva zaslána autorizovaným odesílatelem (serverem). Kontroluje se doména odesílatele, ne přímo emailová adresa. Jedna z nejrozšířenějších technik je SPF (Sender Policy Framework). Její využití je velmi jednoduché. Ověřuje, zda poštovní zpráva přišla z IP adresy, které je v DNS uvedena, jako povolený odesílatel pro danou doménu.

Metody pro ověřování původu poštovních zpráv (Email Authentication) kontrolují poštovní servery, které se účastní odeslání (a možné modifikace) emailu. Cílem je ověřit, že byla zpráva zaslána autorizovaným odesílatelem (serverem). Kontroluje se doména odesílatele, ne přímo emailová adresa. Po SPF je druhá rozšířená technika je DKIM. Ta spočívá v podepisování zpráv privátním klíčem pro doménu. Veřejný klíč pro ověření je publikován v DNS. Podpis se vkládá jako položka hlavičky, takže neovlivňuje běžný provoz.

Metody pro ověřování původu poštovních zpráv (Email Authentication) kontrolují poštovní servery, které se účastní odeslání (a možné modifikace) emailu. Cílem je ověřit, že byla zpráva zaslána autorizovaným odesílatelem (serverem). Kontroluje se doména odesílatele, ne přímo emailová adresa. SPF a DKIM provádí ověření na úrovni domény. DMARC doplňuje politiky chování pro zprávy, které kontrolou neprojdou, a možnost zasílání zpětné vazby majiteli domény. Porovnává také doménu odesílatele v hlavičce.

Po přechodu na Exchange 2016 jsem dlouho řešil problém, že se občas MS Outlook 2016/2019 nemohl připojit na Exchange Server 2016 ve stejné lokální síti. Pokud se nechal běžet, tak se po určité době (odhadem 10 minut) připojil. Tento problém nastával, pokud Outlook korektně běžel, pak se opakovaně zavřel a znovu spustil. Nebo pokud uživatel přecházel mezi různými sítěmi (kabel a bezdrátová síť) s běžícím Outlookem. Nakonec jsem zjistil, že to patrně způsobuje limit RcaMaxConcurrency, který má defaultně hodnotu 40.

Než se pustíme do konfigurace hybridního Exchange, kdy využíváme servery v naší společnosti (On-Premises) dohromady s cloudovými servery Exchange Online (EXO), tak je potřeba vědět, jak to ovlivní směrování (Transport Routing) a tok pošty (Mail Flow). Co případně musíme upravit, aby se neobjevil problém s doručováním zpráv. Protože vzniknou dvě Exchange organizace, které sdílí stejnou doménu, tak musíme určit kam přichází pošta z internetu a jak odchází. S tím úzce souvisí přijímací a odesílací konektory (Connectors) v obou prostředích. A konfigurace našich veřejných domén (Accepted Domains). Hodně se věnujeme speciální situaci, kterou Microsoft nepopisuje v dokumentaci. Pokud z interních serverů odesíláme zprávu jiné organizaci, která je hostovaná na stejných EXO serverech, tak zprávu zpracuje náš Tenant Exchange Online a přepošle.

Pokud provozujeme ve své síti Exchange Server a využíváme (nebo se chystáme) také Microsoft cloudové služby (Office 365), tak se patrně dostaneme k tomu, že potřebujeme zprovoznit Exchange Hybrid. Tehdy spolu komunikuje naše On-Premises Exchange organizace a Exchange Online. Můžeme přesunout některé/všechny schránky do cloudu nebo jen využít napojení MS Teams a dalších služeb na interní schránky. V testovacím prostředí jsem narazil na řadu problémů (v produkci to bylo lepší).

Článek popisuje některé důležité principy fungování hybridní konfigurace Exchange. Jaké atributy se musí synchronizovat do Azure AD pro korektní funkčnost. Jak se řeší schránky v On-Premises organizaci versus v Exchange Online a jak můžeme zjistit, kde má určitý uživatel schránku. Jak se správně schránka vytváří a přesouvá. Popisuje všechny situace, které mohou v praxi vzniknout, z pohledu umístění schránky pro jednoho uživatele. Věnuje se opravě nefunkčních variant. Nejvíce je rozebírána situace, kdy má jeden uživatel schránku na interním serveru a zároveň schránku v cloudu (jedna z nich je v podstatě nefunkční). Řada věcí se musí provádět pomocí PowerShellu.

Pokud máte On-Premises Exchange, tak vás nový rok 2022 možná také přivítal dost špatně. A to tím, že nepřichází ani neodchází žádné zprávy. Vypadá to, že je chyba v Antimalware Scanning a rychlým řešením je jej vypnout.

Článek je stručné upozornění na vypršení platnosti certifikátu Microsoft Exchange Server Auth Certificate. Které může způsobit, že se uživatelé nepřihlásí do webového rozhraní pošty Outlook on the web (dříve Outlook Web App - OWA). Pravděpodobně v případě, když se provozuje Exchange Hybrid. Zobrazuje se chyba OAuthTokenRequestFailedException. Řešení je vytvořit a nastavit nový certifikát.