Migracja poczty do Exchange 2013 lub Office 365 – przygotowanie środowiska

Na co powinniśmy zwrócić uwagę, zanim uruchomimy proces migracji? Posiadanie odpowiednich serwerów, czy też odpowiednio wydajnych zasobów dyskowych jest ważne w przypadku wdrożenia Exchange on-premises, w przypadku wdrożenia Office 365 lokalne serwery nie są aż tak ważne (tylko w zakresie integracji posiadanego Active Directory z katalogiem użytkowników w Office 365). W obu przypadkach wąskim gardłem mogą stać się łącza sieci rozległej czy też internetowe, zwłaszcza przy rozszerzaniu funkcjonalności udostępnianej pracownikom. Przecież system Exchange to nie tylko serwer poczty elektronicznej ale scentralizowane zarządzanie kalendarzami, kontakty, wspólna książka adresowa, delegowanie zadań.

Kolejne kroki, które należy wykonać przygotowując Active Directory czy też istniejącą infrastrukturę serwerów do wdrożenia Exchange 2013 stosunkowo dokładnie opisuje dokumentacja produktu – zwłaszcza rozdział dokumentacji produktowej Planning and Deployment oraz narzędzię Exchange Server Deployment Assistant. W ciekawy sposób zagadnienia, na które musimy zwrócić uwagę ujął Krzysiek Kubicki na naszej konferencji preMTS 2013 – niestety nadal nie najlepiej opisane są zalecane konfiguracje sprzętowe dla Exchange 2013 na serwerach firmowych. Co warto policzyć, zanim zaplanujemy infrastrukturę sprzętową oraz rozłożenie fizyczne serwerów oraz jakie narzędzia będą pomocne szczegółowo opisuje Prabhat Nigam na  blogu MSExchangeGuru http://msexchangeguru.com/2013/07/30/exchange-2013-planning-and-design-guide/. W skrócie – przede wszystkim możemy wykorzystać kalkulatory do policzenia ilości serwerów i dysków potrzebnych dla serwerów Exchange – Exchange 2013 Server Role Calculator (warto zauważyć, że zalecane wartości RAM są dwa razy większe niż w przypadku Exchange 2010, może nam przydać się również Exchange Client Network Bandwidth Calculator. Zwłaszcza przy zmianie architektury lub struktury połączeń (centralizacja serwerów Exchange lub migracja do Office365). używając kalkulatorów warto również wiedzieć, ile maili i jakiej wielkości pracownicy generują w skali dnia czy miesiąca – te wielkości są nam potrzebne do wyliczeń.

Przy wdrażaniu Office 365 nie musimy zastanawiać się nad kwestiami skalowalności ani wydajności systemu – za to odpowiedzialny jest zespół Microsoftu nadzorujący centra danych Office 365, jest również dostępny zestaw dokumentów i narzędzi, wspomagających administratora/wdrożeniowca podczas migracji systemu pocztowego do chmury – najlepszym miejscem do rozpoczęcia przygotowań jest Office 365 deployment guide. Ciekawym narzędziem jest również OnRamp (wcześniejsza nazwa Office 365 Readiness Tool). Bardzo często używanym narzędziem, potrzebnym w przygotowaniu lokalnej domeny Active Directory do integracji z chmurą jest również IdFix (DirSync Error Remediation Tool) -  narzędzie do wykrywania i naprawiania problemów z atrybutami obiektów AD, które mogą sprawić problemy przy synchronizacji lokalnej lasu z usługą Office 365. Migrując z alternatywnych platform, takich jak Lotus Notes przydatnym narzędziem będzie również Online Notes Inspector (MONTI), który można pobrać lokalnie z tego miejsca - MONTI oraz dokumentacja.

Jednak wszystkie powyższe źródła niewiele powiedzą nam o przykrych niespodziankach, na które możemy natknąć się po stronie działających komputerów klientów naszej organizacji. Microsoft zakłada, że korzystamy z platform aktualnie wspieranych i umożliwiających obsługę Exchange 2013/Office365. Niestety wiele firm nadal wykorzystuje w swoim środowisku zarówno Outlooka 2003 jak i stacje robocze Windows XP, a nawet Windows Vista. Office 2013, dostarczany w ramach planów korporacyjnych E3 i E4 oraz planów dla większych organizacji SMB mogą być instalowane na komputerach z systemem Windows 7 lub nowszym, co automatycznie eliminuje prawie połowę rynku komputerów klienckich – mimo, że zegar tyka i za nieco ponad trzy miesiące definitywnie zakońćzy się wsparcie dla Windows XP, nadal co najmniej 30% rynku używa tego systemu. Oznacza to, że wykorzystanie wszystkich funkcjonalności Office365, bądź też Exchange 2013 nie w każdej firmie może być możliwe. Nawet Office 2007, wspierany przez Exchange 2013 nie wszystkie funkcjonalności pozwala nam wykorzystać tak samo skutecznie. jak dobrze widać na przykładzie obsługi kalendarza, o czym pisałem kilka miesięcy temu na tym blogu. Alternatywą pozostaje wykorzystanie przeglądarki internetowej – Outlook Web App posiada pełną funkcjonalność kliencką Exchange 2013, jednak znowu Microsoft w wydanym pod koniec listopada Cummulative Update 3 pokazał, że nie do końca zwraca uwagę na ograniczenia wbudowanego w Windows XP Internet Explorera 8, o czym świadczy artykuł KB 2871314.

Przygotowując migrację systemu pocztowego do Exchange 2013, niezależnie od tego, czy mamy zamiar wdrażać system lokalnie (on-premises) czy w chmurze (Office 365), należy przede wszystkim skupić się na analizie środowiska. Ale wbrew pozorom największe wyzwania czekają nas nie po stronie środowiska serwerowego, tylko stacji roboczych. Często okazuje się, że niezależnie od wielkości firmy nie do końca orientujemy się, jakie wersje systemu operacyjnego (w tym Service Packów), a także pakietów Microsoft Office mają zainstalowane stacje robocze. Część firm używa dedykowanego oprogramowania do zarządzania stacjami roboczymi (np. SCCM lub LanDesk), jednak możemy również użyć bezpłatnego oprogramowania, dostarczanego przez Microsoft – Microsoft Assesment and Planning Toolkit (MAP). Oprogramowanie to, od niedawna dostępne w wersji 9.0, zaktualizowane pod kątem najnowszych produktów, szybko zinwentaryzuje stacje robocze, oraz przygotuje raporty z informacjami, opisującymi stan przygotowania środowiska do konkretnych wersji systemu operacyjnego, pakietu Office czy też usługi Office365.

Korzystając z takich narzędzi stosunkowo prosto możemy sprawdzić jakie niespodzianki mogą nas spotkać w trakcie migracji. Oczywiście nie rozwiążemy w ten sposób wszystkich problemów, ale przynajmniej będziemy mieli rozeznanie, jaka część naszego środowiska nie jest gotowa współpracy z Exchange 2013 czy też Office 365.

UAG odchodzi do lamusa

Dopiero kilka dni temu pisałem o nowym Service Packu do UAG-a, a dzisiaj Microsoft ogłosił wycofanie UAG-a z oferty z dniem 1 lipca 2014. Co ciekawe wsparcie dla UAG-a skończy się niecały rok później – 14 kwietnia 2015 (pół roku wcześniej, niż wycofanego rok temu TMG). Wsparcie rozszerzone zostanie wstrzymane 14 kwietnia 2020 roku. Takie kroki można było podejrzewać kiedy w Release Notes do Service Packa 3 ogłoszono, że ulepszony Direct Access w Windows Server 2012 zastępuje tą część funkcjonalności UAG-a, a funkcjonalność Web Application Proxy w Windows Server 2012R2 była gwoździem do trumny. Na pocieszenie firmy z aktywnym 1 grudnia 2013 Software Assurance mogą instalować dodatkowe instancje i dodawać użytkowników UAG bez konieczności zamawiania dodatkowych licencji.

Kiedy w październiku na mojej sesji na preMTS wspominałem o tym, że roadmapa dla UAG-a jest opublikowana tylko do połowy 2014 roku mogłem przeczuwać, że tak to się skończy. I że to tylko kwestia czasu. No nic, trzeba poznawać kolejne rozwiązania sprzętowe, WAP i ARR, zobaczymy co przyniesie nowy rok.

Publikacja Exchange 2013 na load balancerze Barracudy

Przy okazji jednego z ostatnich projektów musiałem zapoznać się z możliwościami publikacji Exchange 2013, jakie dają load balancery firmy Barracuda. Można do tego użyć appliance’ów sprzętowych, jednak od niedawna są dostępne również maszyny wirtualne na platformę zarówno VMware, Citrix, Oracle jak i Hyper-V. Do testów w labie użyłem najprostszego modelu 340Vx.

Na stronie pomocy technicznej Barracudy jest dostępna instrukcja konfiguracji urządzenia do publikacji Exchange 2013. Jest ona stosunkowo prosta i łatwa do realizacji, jednak po krótkiej analizie zauważyłem, że konfiguracja HealthCheck’ów nie jest dostosowana do możliwości Exchange 2013 (indywidualna weryfikacja poszczególnych usług). Jednak po dyskusji z europejskim serwisem Barracudy, okazało się, że w najnowszej wersji firmware 4.2.2.007 (wsparcie dla Exchange 2013 i instrukcja jest dla firmware od wersji 3.6.1.009) można skonfigurować Load Balancer tak, żeby każdy komponent był weryfikowany indywidualnie. Poniżej zamieszczam krótką instrukcję, jak to przeprowadzić.

Początek jest taki sam jak w instrukcji. Przechodzimy na zakładkę Services i po przełączeniu widoku na Advanced View, dodajemy nowy wirtualny serwis.

Po wpisaniu nazwy wybieramy typ serwisu (Layer 7 – HTTPS), certyfikat z listy zainstalowanych wcześniej na balancerze, a następnie podajemy adres IP, na jakim wirtualny serwis będzie nasłuchiwał. Bardzo ważne jest wybranie odpowiedniego interface. Nawet w konfiguracji z pojedynczym interfacem (taka jest wstępna konfiguracja maszyny wirtualnej) skonfigurowanym w ustawieniach są dostępne dwa – WAN i LAN, co oczywiście nie ma odbicia w lokalizacji urządzenia w naszej sieci.

W kolejnym kroku instukcja każe nam dodać adresy IP serwerów Exchange (Real Server) i utworzyć usługę, my jednak bez konfgurowania serwerów klikamy na przycisk Add Service. Po utworzeniu serwisu w pierwszej kolejności dodajemy reguły publikacji dla poszczególnych wirtualnych katalogów Exchange, dopiero do których będziemy dodawać real serwery (tak jak to jest opisane w instrukcji publikacji Exchange dla urządzeń Kempa). Najpierw dodajemy regułę klikając z prawej strony serwisu w słowo Rule.

Pojawia nam się w tym momencie okienko kreatora, w którym podajemy naszą nazwę dla reguły oraz wirtualny katalog (zakończony gwiazdką), który reguła ma pozwalać publikować w ramach serwisu. Możemy także zmienić domyślne ustawienia rozkładania ruchu i kierowania połączeń.

Teraz dodajemy serwer rzeczywisty, powiązany z regułą, po prostu wpisując jego adres IP.

Po dodaniu wchodzimy w edycję właściwości serwera, włączamy korzystanie z HTTPS i zmieniamy sposób monitorowania na Simple HTTPS.

Teraz podająmy odpowiedni URL (w przypadku usługi ActiveSync będzie to /Microsoft-Server-ActiveSync/healthcheck.htm), odpowiedź jaką powinniśmy dostać (STATUS OK), oraz kod odpowiedzi (200). Czy serwer zwraca poprawną odpowiedź możemy sprawdzić, naciskając przycisk Test, pod definicją monitora. Na koniec zapamiętujemy zmiany, co zamyka okno kreatora.

To samo robimy dla kolejnych serwerów w farmie, a później dla kolejnych usług – Autodiscovera, ECP, EWS, OAB, OWA i RPC.

Finalnie konfiguracja reguł dla naszego wirtualnego serwera Exchange powinna wyglądać jak na ostatnim rysunku. Możemy również dodać przekierowanie ruchu HTTP.

Nadpisywanie ustawień Managed Availability

Po raz kolejny wraca do mnie kwestia Managed Availability. Chociaż nie jest to problem krytyczny, to jednak niektóre próbniki Managed Availability potrafią nieźle zwariować, dodając do logów stanu zarządzanych elementów mnóstwo błędów. Możemy taki denerwujący nas wskaźnik wyłaczyć. Procedurę jak wprowadzić takie nadpisanie dla konkretnego serwera lub globalnie podaje Microsoft w dokumentacji do Exchange, jest to opisane również na blogu zespołu produktowego, a ciekawy przykład zastosowania możemy znaleźć w artykule 2911802, opisującym problem z próbnikiem folderów publicznych, który to problem pojawił się po zainstalowaniu Cummulative Update 3. Poniżej załączony przykłąd globalnego nadpisania (override’a) dla próbnika, monitora i respondera, czyli trzech podstawowych elementów wykorzystywanych przez Managed Availability:

Add-GlobalMonitoringOverride -Identity "Publicfolders\PublicFolderLocalEWSLogonEscalate" -ItemType "Responder"-PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.775.38"

Add-GlobalMonitoringOverride -Identity "Publicfolders\PublicFolderLocalEWSLogonMonitor" -ItemType "Monitor" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.775.38"

Add-GlobalMonitoringOverride -Identity "Publicfolders\PublicFolderLocalEWSLogonProbe" -ItemType "Probe" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.775.38"

Problem z usuwaniem certyfikatu w Exchange 2013

Od czasu do czasu zdarzyć się nam może sytuacja, że chcemy usunąć przeterminowany lub niepoprawny certyfikat (np. po zmianie nazewnictwa usług webowych) z konsoli Exchange. Niestety, może zaskoczyć nas wtedy błąd:

A special Rpc error occurs on server SRV-EX1: The internal transport certificate cannot be removed because that would cause the Microsoft Exchange Transport service to stop. To replace the internal transport certificate, create a new certificate. The new certificate will automatically become the internal transport certificate. You can then remove the existing certificate.

Dlaczego tak się dzieje? Otóż certyfikat ten jest przypięty jako domyślny certyfikat do usługi transportowej, co możemy sprawdzić weryfikując domyślne certyfikaty dla usługi transportowej (oczywiście z poziomu Exchange Management Shella):

Żeby rozwiązać ten problem wystarczy przypisać (z PowerShella usługę SMTP do innego certyfikatu, dodatkowo potwierdzając opcję, że nowy certyfikat ma zastąpić domyśłny certyfikat SMTP).

Teraz Exchange pozwoli nam już usunąć wygasły/nieprawidłowy certyfikat.

Znikające załączniki wysłane z Outlooka 2003

Powiecie: Kto używa jeszcze Outlooka 2003? Niektóre firmy na pewno, a znajdą się również użytkownicy domowi, przyzwyczajeni do tej wersji produktu. Ostatnio kilkukrotnie natknąłem się na dziwny problem. Kiedy ktoś wysyła do nas maila, utworzonego w Outlooku 2003 (domyślne kodowanie HTML), do którego dołączył załączniki w treści wiadomości, a my mamy skrzynkę pocztową na Exchange 2013 lub Office365, to w Outlooku 2007, 2010 i 2013, a także w OWA widzimy tylko treść wiadomości. Kiedy ta sama wiadomość jest wysyłana jako ‘plain text’ z tymi samymi załącznikami, jest wyświetlana poprawnie. Okazało się, że w nagłówku wiadomości jest umieszczona informacja, że treść załącznika jest typu Multipart/related.

Niestety, taki załącznik (inline attachment) najczęściej nie jest poprawnie wyświetlany w programach Outlook 2007/2010/2013 (nie jest zgodny z RFC2387) - http://support.microsoft.com/kb/961940.

Standardowo załączniki są dodawane do maili jako multipart/mixed, a nie multipart/related – stąd całe zamieszanie.

No dobrze, ale o ile możemy ujednolicić wersję Outlooka w naszej firmie, a nawet centralnie wymusić stosowanie treści HTML lub plain text poprzez polisy GPO, to nie możemy do tego zmusić kontrahentów z innych firm, czy osoby prywatne, wysyłające do naszej firmy pisma, podania czy dokumenty. Co w takim wypadku powinniśmy zrobić?

Jak podaje artykuł http://support.microsoft.com/kb/954684, w Exchange 2007 po zainstalowaniu Service Packa 2 mogliśmy użyć komendy:

set-OrganizationConfig -ShowInlineAttachments:$true

a w Exchange 2010 Some mogliśmy dodać do pliku EdgeTransport.exe.config, w sekcji ustawień aplikacji wstawić pomiędzy znaczniki <appSettings> oraz </appSettings> dodatkowy klucz:

<add key="TreatInlineDispositionAsAttachment" value="true" />

Niestety, te opcje nie są dostępne w Exchange 2013 ani w Office365.

Żeby poradzić sobie z tym problemem, musimy utworzyć regułę transportową, która będzie nam modyfikować nagłówek przychodzącego maila, zamieniając niepoprawną definicję typu załącznika na rozumianą przez Exchange 2013. W tym celu tworzymy regułę jak na obrazku:

Ponieważ łatwo się pomylić przy przepisywaniu, można skorzystać z opcji importowania reguł w Exchange:

[Byte[]]$Data = Get-Content -Path "C:\Scripts\Rules.xml" -Encoding Byte -ReadCount 0
Import-TransportRuleCollection –FileData $Data

Gdzie w pliku rules.xml umieścimy definicję powyższej reguły:

<rule name="Edit Headers to make attachments visible" id="403270a3-82bb-4802-a6e4-5809df639c6e" format="cmdlet">
    <version requiredMinVersion="15.0.3.0">
      <commandBlock><![CDATA[New-TransportRule -Name 'Edit Headers to make attachments visible' -Comments '
' -Mode Enforce -HeaderMatchesMessageHeader 'Content-Type' -HeaderMatchesPatterns 'multipart/related' -SetHeaderName 'Content-Type' -SetHeaderValue 'multipart/mixed']]></commandBlock>
    </version>
</rule>

UWAGA: Import zestawu reguł transportowych kasuje istniejące definicje reguł, przed importem zatem musimy wyeksportować istniejące reguły transportowe, wykonując poniższe polecenia:

$file = Export-TransportRuleCollection
Set-Content -Path "C:\Scripts\Rules.xml" -Value $file.FileData -Encoding Byte

Następnie do pliku Rules.xml dodajemy definicję reguły widniejącą powyżej i po zapisaniu importujemy tak uzupełniony zestaw reguł. Jeżeli nasz Exchange 2013 nie ma jeszcze żadnych reguł można cały plik xml pobrać z tego miejsca.

Forefront UAG 2010 SP4 wydany

Wczoraj pojawił się kolejny, już czwarty Service Pack do UAG-a 2010, który oprócz usunięcia kilku problemów, dodaje wsparcie dla Windows 8.1 i Internet Explorera 11, w tym również możliwość konfiguracji połączeń z wbudowanego w Windows 8.1 klienta pocztowego Mail do Exchange Servera oraz wsparcie dla klienta RDC 8.1. Niestety instalacja jest jak zwykle skomplikowana. Poniżej krótka ścieżka kolejności instalacji UAG-a z SP4 od zera:

• Instalacja Forefront UAG z SP1. Szczegóły w artykule Installing Forefront UAG 2010.
• Instalacja Update 1 dla Forefront UAG SP1. Szczegóły w artykule Installing Update 1 for Forefront UAG SP1.
• Instalacja Forefront TMG SP2. Szczegóły w artykule Microsoft Forefront Threat Management Gateway (TMG) 2010 Service Pack 2.
• Instalacja Forefront UAG SP2. Szczegóły w artykule Installing SP2 for Forefront UAG 2010.
• Instalacja Forefront UAG SP3. Szczegóły w artykule Installing SP3 for Forefront UAG 2010.
• Instalacja Update 1 dla Forefront UAG SP3.
• Instalacja Forefront UAG SP4.

Jak na razie Release Notes nie zostały zaktualizowane, jednak na pewno za kilka dni dokumentacja produktu zostanie odświeżona.

Jak na razie, żeby nadążyć za zmianami w kolejnych numerach wersji UAG-a, dobrze jest skorzystać z artykułu na Technet Wiki, gdzie kolejne wersje są aktualizowane, poniżej kopia tej tabeli:

Build Number	KB Article ID	Comment
4.0.1101.0	n/a	Forefront Unified Access Gateway 2010 RTM
4.0.1101.052	2433585	Security Update MS10-089
4.0.1152.100	981323	Update 1
4.0.1152.110	981932	Update 1 Rollup 1
4.0.1152.150	2433584	Update 1+Security Update MS10-089
4.0.1269.200	2288900	Update 2
4.0.1269.250	2418933	Update 2+Security Update MS10-089
4.0.1575.10000	n/a	Service Pack 1 RC
4.0.1752.10000	2285712	Service Pack 1
4.0.1752.10020	2475733	Service Pack 1 Rollup 1
4.0.1752.10025	n/a	Service Pack 1 Rollup 2
4.0.1752.10073	2522485	Security Update MS11-079
4.0.1753.10076	2649261	Service Pack 1+Security Update MS12-026
4.0.1773.10100	2585140	Service Pack 1 Update 1
4.0.1773.10110	2647899	Service Pack 1 Update 1 Rollup 1
4.0.1773.10190	2649262	Service Pack 1 Update 1+Security Update MS12-026
4.0.1773.10220	n/a	Service Pack 1 Update 1 Rollup 2
4.0.2095.10000	2710791	Service Pack 2
4.0.3123.10000	2744025	Service Pack 3
4.0.3206.10100	2827350	Service Pack 3 Rollup 1
4.0.4083.10000	2861386	Service Pack 4

Stan komponentów serwerowych w Exchange 2013

Jedną z nowości w Exchange 2013 jest koncepcja stanu komponentów serwera (Server Component States), którą ciekawie opisano niedawno na blogu zespołu produktowego. Możemy również wyłączyć komponent w związku z jakimiś pracami serwisowymi, ale może to również zrobić sam system Exchange. Podstawowa kwestia, która może nas dotknąć w związku z tym jest możliwość wyłączenia komponentów przez setup Exchange przy instalacji pakietu poprawek CU. Na jednej z maszyn testowych sam ostatnio miałem okazję przetestować tą funkcjonalność. Po awarii instalatora na jednym z kroków konfiguracyjnych i ręcznym uruchomieniu serwisów Exchange się nie zgłaszał. Po weryfikacji stanu komponentów okazało się, że wszystkie są wyłączone:

Można oczywiście zdiagnozowaćzgłoszony przez setup błąd, powtórzyć setup i dobrowadzićaktualizację do poprawnego końca, ale można również spróbować włączyć ręcznie poszczególne komponenty:

Jak widać na powyższym rysunku, włączenie dwóch komponetów tak naprawdę powoduje uruchomienie dużo większej ilości powiązanych komponentów. Warto wiedzieć, że coś takiego jak komponenty serwera są dostępne do zarządzania i jak weryfikowaćich dostępność.

UPDATE

Przydatny skrypt do dokładniejszego weryfikowania stanu, zwłaszcza tych nieaktywnych komponentów, opublikował na swoim blogu Michael Van Horenbeeck. Wg. mnie bardzo przydatny – pokazuje jaki requestor wyłączył komponent, co jest bardzo przydatne, ponieważ musimy użyć tego samego requestora do przełączenia komponentu w stan Active:

Listopadowe poprawki do Exchange

Z pewnym opóźnieniem (kwartał skończył się przeszło miesiąc temu) Microsoft dzisiaj wydał trzeci pakiet poprawek do Exchange 2013 – CU3. Zgodnie z zapowiedziami zespołu produktowego, model serwisowania Exchange 2013 zakłada raz na kwartał wydanie zbiorczego pakietu poprawek, które zawierają pełne binaria Exchange, a ponadto łatki na problemy znalezione w poprzednim kwartale. CU2 zawierało kilka błędów, które wymagały cofnięcia pakietu i wydania go ponownie. Tym razem okres testów, także przy pomocy grupy MVP był znacznie intensywniejszy, co zaowocowało kilkoma dodatkowymi uzupełnieniami pakietu, ale i przedłużeniem okredu testowego. Cumulative Update 3 usuwa wiele usterek zgłaszanych przez użytkowników, szczególnie ważna dla klientów korzystających ze standardowych kopii zapasowych jest poprawka usuwająca błąd, mogący pojawiać się przy odtwarzaniu danych, opisana w artykule KB2888315. Cumulative Update 3 zawiera również sporą ilość usprawnień i rozszerzeń, które chociaż nie wprowadzają rewolucji, to jednak warto o nich wspomnieć:

• Usprawnienie przy dodawaniu członków do nowych i już istniejących grup z wykorzystaniem konsoli webowej Exchange Administration Console.
• Wsparcie dla Online RMS, nowej możliwości zbezpieczania poczty korporacyjnej (a nawet prywatnej) na firmowych serwerach Exchange.
• Rozszerzone możliwości audytowania działań administratora na serwerach Exchange (admin audit logging).
• Poprawiona współpraca z przeglądarką Internet Explorer 11/Windows 8.1 (dotychczas IE11 był rozpoznawany jako przeglądarka niekompatybilna z trybem OWA Premium).

Jednocześnie zespół produktowy zapowiedział, że kolejny pakiet poprawek (CU4) będzie wydany jako Exchange Server 2013 Service Pack 1.

Cumulative Update 3, podobnie jak CU2 rozszerza schemat Active Directory i ustawienia partycji konfiguracyjnej, co wymaga od administratorów dodatkowych kroków konfiguracyjnych i eskalacji uprawnień, zgodnie z zaleceniami dokumentacji TechNet. Podobnie jak przy instalacji poprzednich poprawek należy zweryfikować czy mamy zdefiniowane Windows PowerShell Script Execution Policy jako “Unrestricted” na serwerach Exchange. Jeżeli ustawienia naszych serwerów są inne, to należy postąpić zgodnie z zaleceniami artykułu KB981474.

Dokładny opis poprawek zawartych w CU3 znajduje się w artykule KB2892464., a pakiet można pobrać z tego miejsca. Należy pamiętać przy instalacji, że CU3 usuwa wszystkie binaria Exchange w trakcie instalacji, co uniemożliwia cofnięcie się w przypadku problemów instalacyjnych. Należy to uwzględnić przygotowując się do aktualizacji Exchange. Opcjonalnie można też zainstalować pakiet językowy UM.

W porównaniu do CU3 pakiet poprawek Update Rollup 3 dla Exchange 2010 SP3 nie jest tak rozbudowany, jednak również zawiera liczne poprawki do błędów zgłoszonych przez klientów, co ciekawe poprawki te nie dotyczą obszaru bezpieczeństwa Exchange. Szczegółowa lista usuniętych błędów znajduje się w artykule KB2891587. Na początku grudnia RU3 powinna być również dostępna przez Windows Update.

Windows – ile wynosi czas życia rekordów w DNS?

Ostatnio zmieniałem ustawienia DNS na pewnym serwerze i zauważyłem pewne rozbieżności w czasie życia rekordów DNS. Zweryfikowałem ten temat, przy okazji odświeżając sobie wiedzę dotyczącą ustawień DNS w różnych wersjach Windows. Tak naprawdę zmiany pomiędzy kolejnymi wersjami nie są duże. Pierwszym parametrem, jaki możemy ustawić, jest domyślny czas życia rekordu dla danej strefy DNS, ustawiając odpowiednią wartość w rekordzie opisującym strefę (SOA). Domyślnie jest to jedna godzina, co łatwo możemy zmienić z konsoli graficznej - HOW TO: Modify Time to Live on Domain Name System Records.

Jednakże ustawienie te, jak łatwo się przekonać weryfikując właściwości poszczególnych rekordów, dotyczy wyłącznie obiektów dodawanych statycznie przez administratora. Dla rekordów tworzonych dynamicznie wygląda to zupełnie inaczej - rekordy A i PTR rejestrowane przez usługę Net Logon (np. rekordy SRV usług udostępnianych przez kontrolery domeny) mają ustawiany czas życia (TTL) o wartości 10 minut. Rekordy rejestrowane przez usługę DHCP Client domyślnie mają TTL ustawiany na 15 minut. Rekordy tworzone przez usługę DNS Server service (w większości wypadków są to rekordy zgłaszane przez serwery/stacje robocze poprzez usługę DNS Client) mają domyślnie ustawiony TTL na 20 minut. I takich rekordów, w domenie ze stacjami roboczymi Windows 7/8 jest najwięcej. Oczywiście w większości wypadków takie ustawienia są wystarczające, jednak czasami chcemy zmienić domyślny czas dla niektórych hostów, np. dla wybranych serwerów. Można to zrobić poprzez klucz w rejestrze na wybranych hoście:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

Klucz jest typu REG_DWORD i domyślnie ma wartość 0x4B0 (1,200 sekund = 20 minut). Możemy to zmienić na dowolną wartość z zakresu: 0x0 - 0xFFFFFFFF sekund – np. 0xE10 (1 godzina), a nawet 0x15180 (24 godziny), choć jak dla mnie to już lekka przesada. Więcej ustawień modyfikujących parametry ustawień klienta DNS można znaleźć w artykule KB 246804.

Możemy to również zmienić poprzez GPO:

Wykorzystanie karmazynowego kanału do rozwiązywania problemów z Exchange 2013

Ale o co chodzi zapytacie? Sam byłem zaskoczony, kiedy po raz pierwszy spotkałem się z tym określeniem. Jednak pomimo nietypowej nazwy wygląda to całkiem przyjaźnie. Crimson channel event logging, to po prostu drugi obszar logów w systemie Windows – oprócz znanych od dawien dawna logów systemu Windows (System, Security i Application) od Windows 2008 można znaleźć w Event Viewerze kategorię logów Applications and Services, określane przez Microsoft właśnie jako ‘karmazynowy kanał’.

W Exchange 2013 obszar ten jest mocno rozbudowany, szczególnie w obszarze aktywnego monitorowania i dostępności usług (Managed Availability) – trochę informacji na ten temat niedawno publikowałem na tym blogu, ale MA to rozbudowany temat. Kilka artykułów, pokazujących jak wykorzystać tę funkcjonalność można znaleźć na blogu grupy produktowej, szczególnie polecam artykuły:

• http://blogs.technet.com/b/exchange/archive/2012/09/21/lessons-from-the-datacenter-managed-availability.aspx
• http://blogs.technet.com/b/exchange/archive/2013/07/16/managed-availability-monitors.aspx
• http://blogs.technet.com/b/exchange/archive/2013/06/13/what-did-managed-availability-just-do-to-this-service.aspx
• http://blogs.technet.com/b/exchange/archive/2013/08/13/customizing-managed-availability.aspx

Ogólnie logi aplikacyjne i serwisowe dzielą sie na cztery grupy - Admin, Operational, Analytic oraz Debug. Do rozwiązywania problemów szczególnie przydatne są logi operacyjne i administracyjne (jeżeli istnieją dla danej funkcjonalności), chociaż informacje w nich zawarte nie zawsze są prezentowane w sposób przejrzysty i zrozumiały. Na listopadowym spotkaniu PEPUG chciałbym nieco przybliżyć ten temat, serdecznie zapraszam na spotkanie. Teraz tylko sygnalizuję temat, ale mam nadzieję, że uda mi się znaleźć trochę czasu, żeby opisać kilka przykładowych scenariuszy diagnozowania problemów.

Poprawki ASP.Net dla Exchange 2013

Coś ostatnio dużo piszę o błędach, ale bynajmniej nie jest to złośliwe. Exchange 2013 używając intensywnie usług webowych do komunikacji z klientami stał sie nieco wrażliwy na błędy w ASP.Net 4.5, w którym niestety kilku takich błedów znaleziono. Dokumentacja do Exchange 2013 zaleca instalację poprawki, w zależności od wersji systemu operacyjnego – dla Windows Server 2008 R2, hotfix jest opisany w artykule KB2803754 i może być pobrany z tego odnośnika, używając Windows Server 2012 poprawka jest opisana w artykule KB2803755, a dostępna jest tutaj.

Dodatkowo po zainstalowaniu niezbędne jest ustawienie klucza rejestru

HKLM\Software\Microsoft\.NETFramework\DisableRetStructPinning=1 (REG_DWORD)

lub dodanie zmiennej środowiskowej systemu Windows COMPLUS_DisableRetStructPinning z wartością 1

Niestety,ostatnio się okazało, że w niektórych środowiskach Exchange 2013 restartuje się lub wyłącza usługa RPC Client Access Service, generując błąd 7031. Początkowo przetestowałem z sukcesem obejście problemu poprzez wyłączenie usługi Exchange Health Manager Service, jak opisano na blogu http://msexchangeguru.com/2013/05/22/rpc-client-access-restart.

Jednak w ostatnich dniach okazało się, że problem powoduje również ASP.Net 4.5, co Microsoft opisał w artukułach KB2862063 dla Windows Server 2008 R2 SP1 oraz KB286204 dla Windows Server 2012. Czekamy na udostępnienie publiczne poprawki. Na razie można je pobrać z tego miejsca.

Problem ze statusem ContentIndex’ów – warning 1009

I znowu natrafiłem na dosyć denerwujący problem, który zauważyłem w trakcie migracji skrzynek do Exchange 2013. Na jednym z serwerów w DAG, wszystkie indeksy zmieniły status na Failed, a typowa w takich sytuacjach akcja:

update-mailboxdatabasecopy –catalogonly

Nie pomagała, w logu aplikacyjnym pojawiał się za to Warning generowany przez MSExchangeFastSearch o numerze 1009. Dla dużych skrzynek w trakcie migracji problem ten powodował blokowanie procedu migracji – przy statusie migrowanej skrzynki pojawia się status “StalledduetoCI”. Jak się okazało rozwiązanie problemu tłumaczy artykuł KB http://support.microsoft.com/kb/2807668/pl. Problem wiąże się z odwołaniem do grupy, której Exchange 2013 nie dodaje przy instalacji – ContentSubmitters. W artykule są podane dwa rozwiązania – edycja plików konfiguracyjnych usługi Content Indexingu na serwerze, którego dotknął problem (usunięcie wiersza dodającego rolę Content Submitters) w czterech wystąpieniach pliku WcfConfigurator.xml, który  znajduje się w katalogach:

%ExchangeInstallPath%\Bin\Search\Ceres\HostController\Data\Nodes\Fsis\NODENAME\Configuration\Local, gdzie NODENAME to odpowiednio:

AdminNode1

ContentEngineNode1

IndexNode1

InteractionEngineNode1

Drugie rozwiązanie, mające wpływ na wszystkie serwery w DAG, zaleca utworzenie grupy ContentSubmitters w Active Directory i przypisanie jej praw dla grup administratorów i Network Service.

Postąpiłem zgodnie z drugą ścieżką, po utworzeniu grupy wykonałem polecenia,(nie ma tego w artykule, ale kierowałem się poradą z blogu):

Add-ADPermission -Id ContentSubmitters -User “Network Service” -AccessRights GenericAll
Add-ADPermission -Id ContentSubmitters -User “Administrators” -AccessRights GenericAll

i po restarcie usług:

• Microsoft Exchange Search 
• Microsoft Exchange Search Host Controller

kolejne sprawdzenie statusu replik baz danych pokazało dla indexów status “Healthy”. Hurra!

Program MVP w Polsce

Update

Okazało się, że Piotr Pawlik jednak po rozpoczęciu pracy w Microsofcie nie stracił tytułu.

Od kilku miesięcy działa nowy portal światowego programu Microsoft Most Valuable Professional. Niestety, nie wszyscy nagrodzeni publikują informacje o swojej specjalności i kraju pochodzenia, więc ciężko się zorientować jak sytuacja wygląda w Polsce. Jest co prawda strona msmvp.pl założona i utrzymywana przez jednego z MVP – Maćka Aniserowicza, przy mniejszej lub większej pomocy innych MVP, ale znowu nie wszyscy koledzy mają czas uzupełnić niezbędne informacje. Kiedy więc jeden z amerykańskich MVP z grupy Exchange zaczął dopytywać się o ilość MVP w kategoriach serwerów Office (Exchange, Lync, Sharepoint, Office365), postanowiłem z ciekawości sprawdzić, jak w tej chwili wygląda sytuacja w Polsce. Okazało się, że jest całkiem nieźle, jeżeli chodzi o łączną ilość MVP, jak na wielkość rynku IT w Polsce (aktualnie 39 MVP), jednak tylko dwóch MVP z kategorii Exchange i jeden w kategorii Sharepoint (a jeszcze niedawno było 3). Mam nadzieję, że ta sytuacja się poprawi. Poniżej aktualna lista polskich MVP (przynajmniej do takich danych udało mi się dotrzeć):

• Jakub Skałbania (Dynamics CRM)
• Pawel Pławiak (Directory Services)
• Jacek Światowiak (Directory Services)
• Jacek Doktór (Enterprise Client Management)
• Paula Januszkiewicz (Enterprise Security)
• Tomasz Onyszko (Enterprise Security)
• Grzegorz Tworek (Enterprise Security)
• Konrad Sagała (Exchange Server)
• Piotr Pawlik (Exchange Server)
• Marcin Iwanowski (Expression Blend)
• Marcin Borecki (Internet Explorer)
• Marcin Dembowski (Internet Explorer)
• Oskar Shon (Office System)
• Sebastian Wilczewski (Project)
• Bartosz Bielawski (PowerShell)
• Grzegorz Gałęzowski (PowerShell)
• Michal Gajda (PowerShell)
• Jakub Gutkowski (SharePoint Server)
• Bartłomiej Graczyk (SQL Server)
• Łukasz Grala (SQL Server)
• Tobiasz Janusz Koprowski (SQL Server)
• Grzegorz Stolecki (SQL Server)
• Marcin Szeliga (SQL Server)
• Damian Widera (SQL Server)
• Paweł Wilkosz (SQL Server)
• Karol Stilger (Software Packaging, Deployment & Servicing)
• Kamil Skalski (System Center Cloud and Datacenter Management)
• Joanna Subik (System Center Cloud and Datacenter Management)
• Łukasz Kałużny (Virtual Machine)
• Dariusz Porowski (Virtual Machine)
• Marek Pyka (Virtual Machine)
• Grzegorz Rycaj (Visual Studio ALM)
• Maciej Aniserowicz (Visual C#)
• Piotr Zieliński (Visual C#)
• Wojciech Poniatowski (Visual C#)
• Maciej Grabek (Windows Phone Development)
• Robert Stuczyński (Windows Expert IT Pro)
• Daniel Potyrała (Windows Expert-Consumer)
• Piotr Palusiński (Windows Expert-Consumer)

MTS 2013 – kilka słów refleksji

Jak co roku piszę kilka słów podsumowania po konferencji Microsoft Technology Summit. Emocje trochę opadły, człowiek wrócił do pracy i może spojrzeć wstecz. Konferencja była udana, z punktu widzenia spotkania bliższych i dalszych znajomych. Co do merytoryki konferencji, to było sporo ciekawych sesji, jednakże jak zwykle brakowało mi podstawowych ścieżek dla mojej specjalizacji – Exchange i Lync. Chociaż nie było w tym roku premier tych produktów, to jednak ich wyraźny brak w agendzie mógł lekko zaskakiwać (w porównaniu np. do europejskiego TechEdu). Podobnie jak brakowało sesji produktowych o rodzinie System Center 2012R2, które miały właśnie swoją premierę, a także o Windows Server 2012 R2, który był zaledwie zasygnalizowany. Większość czasu spędziłem na stoisku partnerskim APN Promise udzielając porad i obserwując uczestników konferencji, co dostarczyło mi wiele ciekawych przeżyć.

Po zeszłorocznej wpadce z cateringiem, w tym roku organizatorzy całkiem się pogubili. Rozumiem, że Polacy są przez niektórych traktowani jako cwaniacy i kombinatorzy, ale wydawanie kanapek na podstawie identyfikatora to lekka przesada. W końcu konferencja jest płatna i to wcale nie tak mało, jak na polskie realia (dwukrotnie droższa, niż odbywająca się za dwa tygodnie Microsoft Summit Romania). Dwie duże przydziałowe kanapki dla wielu osób były zbyt duża porcją jako dodatek do lunchu, brakowało za to jakichkolwiek przekąsek do napojów. W rezultacie tym razem nie można było uschnąć z głodu jak rok temu, jednak mnóstwo kanapek zostało. Ciekawym pomysłem, do którego wrócono po kilku latach były sesje warsztatowe, jednak całkowity brak stoisk ze specjalistami dziedzinowymi mógł zastanawiać. Czyżby nikt nie miał pytań merytorycznych? Ilość osób pytających mnie o Exchange i Lynca była całkiem spora. Ale nic to, za rok może będzie lepiej.

Problem z licznikami w Exchange 2013 - MSExchange Common error 106

Na kilku wdrożonych ostatnio serwerach Exchange 2013 zauważyłem błąd, jak na powyższym obrazku. Błąd powtarzał się dla kilku różnych liczników wydajnościowych. Okazało się, że podobne błędy mogą pojawić się również w Exchange 2010, o czym przeczytałem na tym blogu. Najprostszym rozwiązaniem jest ponowne zarejestrowanie liczników, na podstawie plików definicji po wykonaniu kilku komend w powershellu:

add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\RpcClientAccessPerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\AdminAuditPerfCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ResourceHealthPerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ThrottlingPerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\MiddleTierStoragePerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\IsMemberOfResolverPerfCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ADRecipientCachePerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ExchangeTopologyPerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ExSearchPerformanceCounters.xml”
New-PerfCounters -definitionfilename “$exinstall\Setup\Perf\ExSearchCatalogPerformanceCounters.xml”

Można również pobrać gotowy skrypcik.

Blokowanie OutlookAnywhere

Czasami spotykam się z pytaniem, czy można zablokować pracownikom dostęp do poczty po Outlook Anywhere? Zasadniczo w Exchange 2010 nie widać takiem możliwości w konsoli EMC – można tylko włączyć lub wyłączyć korzystanie z dostępu MAPI. Jednak przy okazji jednych z migracji do Exchange 2013 odkryłem, że jest taka możliwość, chociaż słabo udokumentowana. Otóż komenda set-casmailbox pozwala na zarządzanie dodatkowymi ustawieniami opcji dostępu dla różnych kanałów dostępu klienckiego – w szczególności również MAPI z wyszczególnieniem zarówno połączeń cache’owanych jak i RPC/HTTPS. Jeżeli dla skrzynki wykonamy komendę

Set-CASMailbox <id skrzynki> –MapiBlockOutlookRpcHttp $true

to zablokujemy dostęp poprzez Outlook Anywhere do konkretnej skrzynki.

Problem polega na tym, że w Exchange 2013 dostęp z Outlooków jest wyłącznie poprzez RPC/HTTPS, więc skrzynki z tym utawieniem po migracji nie będą mogły się połaczyć z wykorzystaniem Outlooka, nie pokazując żadnych konkretnych błędów.

Październikowe poprawki dla Lynca

Warto pamiętać o październikowych poprawkach dla serwera Lync, zarówno w wersji 2010 jak i 2013, a także dla telefonów LPE (build 4.0.7577.4411). Należy pamiętać po zaktualizowaniu serwera, że niezbędna jest aktualizacja struktur bazodanowych, zgodnie z treścią odpowiedniego artykułu. Co ciekawe, poprawka ta jest niezbędna, gdybyśmy chcieli uruchomić serwer Lync 2013 na Windows Server 2012R2.

Problemy z kartami sieciowymi w serwerach nie tylko Exchange

Kilka dni temu pojawiły się informacje serwisu VMware o problemach z kartami sieciowymi typu e1000e na platformie ESXi 5.0 lub 5.1 dla systemu Windows 2012 (ten sam problem dotyczy Windows 2012R2). Problem może powodować utratę danych przesyłanych między serwerami (np. w ramach DAG-a). Zalecana jest zmiana typu karty sieciowej na e1000 lub vmxnet3. Kolejny problem związany z domyślnym ustawieniem kart sieciowych wskazał Mike O'Neill na blogu zespołu produktowego Exchange – domyślnie włączone ustawienie, zezwalające serwerowi na wyłączenie karty sieciowej w celu zmniejszenia zużycia energii powoduje zanik heartbeatu między węzłami clustra (czyli serwerami w ramach DAG) i nieplanowane przełączenia węzłów w clustrze, nawet pomiędzy różnymi datacenter. Żeby tego uniknąć należy odkliknąć checkbox w ustawieniach karty sieciowej serwera/serwerów, jak na poniższym rysunku, można również użyć do tego skryptu, opublikowanego w TechNet Gallery. Można również użyć GPO i klucza w rejestrze, któy odpowiada za to ustawienie, zgodnie z artykułem http://support.microsoft.com/kb/2740020.

Monitorowanie stanu serwera Exchange 2013

Exchange 2013 wprowadził całkiem nowe mechanizmy monitorowania poprawnej pracy serwerów – tzw. Managed Availability. Jest to zestaw polis i reguł, które ustawicznie monitorują status poszczególnych komponentów serwera Exchange. Czasem niektóre z nich są zbyt czułe i powodują niepotrzebny niepokój administratorów (o jednym z takich fałszywych alarmów pisałem ostatnio), jednak większość testów jest bardzo pomocnych w diagnozowaniu pracy serwera. Najważniejsze są cmdlety Get-HealthReport oraz Get-ServerHealth, chociaż Get-ServiceHealth też jest pomocny. W skrócie możliwości ich wykorzystania opisuje wpis na blogu zespołu produktowego Exchange, ale warto też sięgnąć nieco głębiej.

W skrócie stan poprawności pracy usług serwera Exchange możemy sprawdzić uruchamiając cmdlet:

Get-HealthReport –Identity <ServerName>

Usług monitorowanych jest dużo (ponad 60 pozycji), więc wynik tej komendy może być niezbyt czytelny (bardzo dużo pozycji powinno mieć status ‘healthy’). Dlatego też lepiej odfiltrowaćsobie od razu wyniki, skupiając się na pozycjach o innym statusie:

get-healthreport -server srv-ex1 | where {$_.alertvalue -ne “healthy”} | ft –auto

Możemy również wyświetlić elementy składowe ‘niezdrowych’ usług, wymuszając wyświetlanie nieco bardziej granularne:

$test = get-healthreport -server srv-ex1 | where {$_.alertvalue -ne “healthy”}
foreach ($line in $test) {$line.entries | where {$_.alertvalue -ne “healthy”} | ft -auto}

Jeżeli widzimy, że jakiś serwis ma status ‘unhealthy’ możemy również użyć również użyć cmdletu Get-ServerHealth dla konkretnego Healtsetu:

Get-ServerHealth -Identity srv-ex1 -HealthSet ECP

lub wyświetlić rezultaty w trochę bardziej czytelny sposób:

Get-ServerHealth -Identity srv-ex1 -HealthSet ECP | ft -auto server, name, alertvalue

W tym momencie można zerknąć do sugerowanych w dokumentacji Management Packa dla Exchange 2013 zalecanych kroków naprawczych - Troubleshooting ECP Health Set.