Dnešní díl samozřejmě nemůže popisovat všechny chyby, ke kterým mohlo dojít po instalaci SP1. Ale pokud jste postupovali podle tohoto seriálu, tak je velká pravděpodosbnost, že se u vás projeví stejné chyby, jako u mě. K tomu, aby se chyby projevily, je potřeba chvíli server používat.

Nejdřív otestujeme, jestli nám chodí pošta. Poslal jsem si e-mail na Atlas a z Atlasu zase zpět. E-mail dorazil bez problémů. Takže víme, že pošta nám chodí. Teď bychom měli otestovat, jestli se k poště dostaneme. Vyzkoušejte připojení Outlookem, pomocí OWA z lokální sítě, Outlook anywhere, OWA z internetu, Active sync z internetu. V mém případě všechno funguje. Pokud nejste schopní některé funkce ověřit, tak použijeme Microsoft Remote Connectivity Analyzer Nezapomeňte, že na některé testy je nutné použít prázdný mailbox. Popis testů najdete v 19. díle seriálu.

V 18. díle seriálu zase bylo pár příkazů powershellu pro otestování funkčnosti serveru. Není nutné si je pamatovat. Stačí v powershellu napsat test- a pak už jen mačkat tabelátor. Postupně se zobrazí všechny příkazy a je jen na nás, co použijeme.

Jdeme se podívat do logů. Nejdřív Application Log. Tam najdeme hned několikrát Error s EventId: 4113 od MSExchangeRpl.

Když se nad tím zamyslíte, tak tady vlastně není co řešit. Máme vytvořený DAG, ale odebrali jsme druhý server, takže existuje pouze jedna kopie databáze. (používáme termín kopie, i když je to vlastně původní databáze) Aby DAG plnil svoji funkci, tak potřebuje minimálně dvě kopie. Proto ta chyba. Můžeme zrušit DAG a pak to nebude strašit, ale na funkčnosti serveru se nic nezmění. Vzhledem k tomu, že bych s DAGem ještě v budoucnu chtěl blbnout, tak tuhle chybu nebudu vůbec řešit.

V Application Logu se nachází pár varování. Najdeme tam varování různých procesů, které ale mají stejný EventId a stejný Source. Jedná se o Warning s EventID: 2937 a zdroj je: MSExchange ADAccess. Text chyby zní například:

Tahle chyba souvisí s tím, jak jsme přidávali a odebírali exchange servery. V tuto chvíli mě nenapadá, jak by to mohlo ovlivňovat fungování pošty, ale to neznamená, že je to v pořádku. Tak to radši opravíme. K tomu budeme potřebovat Adsi Edit. Takže jej spustíme. Pokud jsme jej ještě nepoužívali, tak to bude chtít vybrat kam se chceme připojit. Pokud se otevře Adsi Edit rovnou do nějakého contextu, tak kliknutím pravého tlačítka na Adsi Edit můžeme vybrat Contect To a dostaneme se do stejného okna.

Potřebujeme do Configuration. Takže nastavíme Well known naming context a OK.

Musíme se dostat k CN=Microsoft MTA, takže použijte cestu jako na obázku. Pak klikneme pravým tlačítkem na Microsoft MTA a z menu vybereme Properties.

Zajímá nás distinguishedName. Vybereme a klikneme na View.

Celou hodnotu uložíme do clipboardu (schránky)... prostě CTRL + C. A teď potřebujeme do Default naming context. Takže pravým tlačítkem myši na ADSI Edit a vybrat Contect to ..

Najdeme si některého z uživatelů, u kterých nám to psalo Warning.

Opět pravé tlačítko myši a vybereme Properties.

Zajímá nás atribut Home MTA, takže jej najdeme a klikneme na Edit.

Místo současné hodnoty vložíme obsah clipboardu. Potvrdíme OK.

Můžeme kliknout na OK a pokračujeme u dalšího uživatele. Nezapomeňte, že můžete mít i účet v Buildin a Users OU. Například extest.

Další chyba, na kterou jsem narazil, pocházela od Active Sync. EventID 1033 a zněla:

Je to jen kosmetická vada, která se dá rychle napravit. Otevřeme soubor:

A tady nacházím pouze jednu chybu, ovšem několikrát. EventId je 36888, zdroj je schannel. Tahle chyba vzniká v logu, pokud se připojím k OWA pomocí Firefoxu, ve kterém nemám certifikát serveru uložený mezi certifikáty Firefoxu. Firefox nepoužívá stejné úložiště jako IE, resp. Windows OS. Pokud máte certifikát pro více jmen, tak můsí být uložen do certifikátů pro každé jméno zvlášť. Zkusím to vysvětlit na příkladu. Máme certifikát vydaný na jména server1, server2, server3. Firefox se přípojí pomocí SSL k server1. Oznámí, že se jedná o nedůvěryhodný certifikát a umožní vám přidat trvalou výjimku. Ta uloží certifikát do úložiště certifikátů firefoxu. Když půjdete příště na tento server, tak se žádná chyba neobjeví. Pokud ale použijete jméno server2, tak přestože je to stejný server a certifikát obsahuje i toto jméno, tak Firefox zobrazí varování, že se jedná o nedůvěryhodný certifikát a budete muset opět vytvořit výjimku. A totéž se bude opakovat pro server3. Teprve pak se přestanou objevovat chyby v logu.

A to je vše. Žádné další chyby v logu nemám, takže můžu jít přemýšlet o tom, jaký bude obsah dalšího dílu.