21 grudnia 2013

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.

MAP 9.0 Desktop Readiness

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.

17 grudnia 2013

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.

14 grudnia 2013

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.

image

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.

image

image

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.

image

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.

image

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ń.

image

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

image

image

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

image

image

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.

image

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.

image

12 grudnia 2013

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"

05 grudnia 2013

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:

image

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):

image

Ż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).

image

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.

image

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:

image

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.