Migracja do Exchange 2013 w trybie hybrydowym

Jeżeli organizacja Exchange w firmie jest w konfiguracji hybrydowej (współdzielenie przestrzeni adresowej z usługą Office365), to przy próbie rozszerzenia schematu do wersji Exchange 2013 otrzymamy błąd:

A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: "Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML". Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows "/TenantOrganizationConfig MyTenantOrganizationConfig.XML". If you continue to see this this message then it indicates that either the XML file specified is corrupt, or you are attempting to upgrade your on-premises Exchange installation to a build that isn't compatible with the Exchange version of your Office 365 tenant. Your Office 365 tenant must be upgraded to a compatible version of Exchange before upgrading you r on-premises Exchange installation. For more information, see: http://go.microsoft.com/fwlink/?LinkId=262888

For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DidTenantSettingCreatedAnException.aspx

Jak widać, rozwiązanie problemu jest proste i wystarczy przeczytać powyższy tekst. Oczywiście należy również sprawdzić, czy nasz tenant został zaktualizowany do wersji 2013 (nadal jest jeszcze sporo organizacji z Exchange 2010), czyli atrybut AdminDisplayVersion musi być nie niższy niż 15.0.620.28 – aktualna wersja to 15.0.702.21 (dla tenantów z Exchange 2010 ostatnio miał on wartość 14.16.175.8).

Czyli na nowym serwerze, który przygotowaliśmy pod Exchange 2013 uruchamiamy z PoweShella sekwencję poleceń:

setup.exe /preparead /IAcceptExchangeServerLicenseTerms

$LiveCred = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Get-OrganizationConfig | Export-Clixml -path c:\install\MyTenant.xml

setup.exe /preparead /IAcceptExchangeServerLicenseTerms /TenantOrganizationConfig:c:\install\MyTenant.xml

Tym razem rozszerzenie schematu powinno powieść się bez problemów i będziemy mogli kontynuować instalację. W przykładzie podałem opcję /preparead, ponieważ /prepareschema w wersji CU1 nie działało poprawnie.

Problem z aktualizacją Antimalware w Exchange 2013

Jedną z zalet Exchange 2013 jest wbudowany silnik antimalware (de facto okrojona wersja Forefront Protection for Exchange 2010). W trakcie instalacji Exchange 2013 instalator domyślnie podpowiada opcję włączenia silnika, co jeżeli klient nie używa innego produktu antywirusowego przeważnie akceptuję. Oczywiście można nie włączać w trakcie instalacji, ale zrobić to później, wykonując skrypt Enable-antimalwareScanning.ps1, który znajduje się w folderze Scripts katalogu instalacyjnego Exchange 2013.

Dzisiaj kolega prosił mnie o pomoc w rozwiązaniu problemu z brakiem aktualizacji silnika, na który natrafił. Sprawdziłem kilka wdrożonych przeze mnie serwerów i faktycznie na niektórych znalazłem pojawiający się okresowo (co 30 minut, tak jak domyślnie skonfigurowana jest aktualizacja silnika) błąd 6027, jak na poniższym rysunku:

Jak okazało się, problem ten pojawia się na wielu serwerach i pytania o ten problem wiszą na wielu forach tematycznych. W niektórych miejscach znalazłem informację, że problem został rozwiązany po aktualizacji do Exchange 2013 CU1, choć tylko w części przypadków, ale problem pojawił się również na serwerach, które były instalowane od początku na wersji Exchange 2013 CU2. Można spróbować ręcznie zaktualizować silnik, zgodnie z procedurą opisaną w dokumentacji Exchange, ale niestety nie rozwiązało to problemu. Żeby sprawdzić, czy nasz serwer pobiera (lub pobierał) poprawki antymalware, poza szukaniem w logu aplikacyjnym powyższego błędu, warto sprawdzić status aktualizacji poprawek, przy pomocy komendy Get-EngineUpdateInformation. Żeby jednak było trudniej, ten cmdlet nie jest dostępny domyślnie w Exchange Management Shell (!). Musimy ręcznie załadować bibliotekę cmdletów Forefrontowych:

Add-PSSnapin -Name Microsoft.Forefront.Filtering.Management.PowerShell

Teraz już komenda zadziała, jednak na diagnozowanym serwerze, jak widać nigdy nie udało się pobrać aktualizacji:

Po różnych próbach i testach, zaaplikowałem procedurę opisaną w artykule dotyczącym problemów z aktualizacją manifestów dla nieaktualnych silników antywirusowych - http://support.microsoft.com/kb/929074/pl.

Po ręcznym pobraniu pliku manifestu ze strony Microsoft http://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/manifest.cab sprawdziłem w przeglądarce aktualną wersję silnika (w tym przypadku był to numer 1308200001), a następnie również ręcznie pobrałem pełen pakiet aktualizacji wpisując url (oczywiście już jutro będzie to inny numerek) http://forefrontdl.microsoft.com/server/scanengineupdate/x86/Microsoft/Package/1308200001/Microsoft_fullpkg.cab

zgodnie z podanym w artykule 929074 wzorcem dla silnika Microsoft http://forefrontdl.microsoft.com/server/scanengineupdate/x86/scanengine_name/Package/version_number/scanengine_name_fullpkg.cab.

Po rozpakowaniu pliku do tymczasowego katalogu zaktualizowałem zawartość folderu Bin silnika (domyślnie jest to katalog C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin) i zrestartowałem usługę Microsoft Filtering Management Service. Po ponownym uruchomieniu usługi i chwili odczekania w logach pojawiła się informacja o poprawnym pobraniu aktualizacji. Ponowne wykonanie cmdleta get-engineupdateinformation pokazało informację o aktualnej wersji silnika i poprawnym wykonaniu aktualizacji:

Problemy z poprawkami Microsoft – MS13-061

Dopiero co zespół Exchange musiał modyfikowaćpoprawkę CU2 dla Exchange 2013, a w zeszłym tygodniu pojawił się kolejny babol. Krytyczna poprawka bezpieczeństwa MS13-061 dla Exchange 2013 CU1 i CU2 skutecznie rozwala indeksowanie na serwerze skrzynkowym Exchange 2013. Nie jest to błąd, który widać od razu z poziomu klienta (choć w logu aplikacyjnym serwera robi się czerwono), więc nie wszyscy administratorzy, którzy pobrali  i zainstalowali tę poprawkę na serwerach Exchange zauważyli problem, jednakże sprawdza się teza, że dobrze jest sprawdzić kanały RSS, blogi i grupy dyskusyjne przez aplikacją nowych poprawek.

Co prawda zespół Exchange szybko problem zauważył, a nawet wydany został artykuł KB 2879739, co zostało opisane na blogu produktowym - Exchange 2013 Security Update MS13-061 Status Update, ale jednak mleko się wylało. Procedura naprawcza nie jest skomplikowana, a nawet dla leniwych Michel de Rooij opublikował na TechNet Gallery skrypt, który wyręcza nas w ręcznym grzebaniu w rejestrach, warto jednak mieć świadomość, że taki problem istnieje.

Na szczęście paczki poprawek dla starszych wersji Exchange, które zawierają poprawkę MS13-061, nie powodują takich problemów:

Update Rollup 11 for Exchange Server 2007 SP3

Update Rollup 7 for Exchange Server 2010 SP2

Update Rollup 2 for Exchange Server 2010 SP3

Problemy z poprawkami Microsoft - WAS

Ostatnio Microsoft nieźle namieszał w kwestii poprawek. Ku pamięci i przestrodze dla innych zapiszę kilka uwag w tym temacie.

Jednym z niemiłych faktów, jaki mnie ostatnio zaskoczył był problem z Office Web Apps Serverem 2013 (WAS). Skonfigurowaliśmy serwer, po jakimś czasie zostały zainstalowane poprawki z Windows Update, między innymi do WAS-a, no i zaczęło sypać błędami (przeważnie 1000 i 1026 – obrazki poniżej).

Utylizacja procesorów serwera WAS skoczyła na 100%, z czego większość zasobożernych procesów była związana z obsługą błędów.

Okazało się, że automatyczna instalacja poprawek skutecznie rozwaliła konfigurację Office Web Apps Servera 2013. Na szczęście jest ona stosunkowo prosta. Niestety, poprawka KB2760445 nie ma opcji odinstalowania, co powoduje konieczność odinstalowania WAS, zainstalowania go ponownie, wgrania poprawek i dopiero w tym momencie ponownego skonfigurowania farmy WAS (lub dodania danego serwera do farmy składającej się z kilku serwerów (Remove-OfficeWebAppsMachine). Procedura instalacji poprawek do WAS opisana jest na stronach dokumentacji produktu.

Tylko dlaczego te poprawki są dostępne przez Windows Update?

Integracja Exchange 2013 i Lync Server 2013 - OWA

W poprzednim poście pisałem o podstawach integracji pomiędzy Lync 2013 i Exchange 2013, teraz pójdę kawałek dalej – do integracji z poziomu OWA. W Exchange 2010 trzeba było dodatkowo instalować moduły odpowiadające za integrację, poprawki, a teraz wystarczy kilka komend i po sprawie. Pierwszym krokiem jest włączenie funkcjonalności na poziomie witryny OWA.

Robimy to dwuetapowo (przy założeniu, że role Mailbox i CAS mamy na tym samym serwerze) – najpierw wskazujemy, że integracja jest włączona i jaki jest jej typ:

Get-OwaVirtualDirectory "SRV-EX1\owa (Default Web Site)" | Set-OwaVirtualDirectory -InstantMessagingType OCS -InstantMessagingEnabled $true

Następnie musimy wyedytować plik web.config, znajdujący się w katalogu C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa (przy wybranej domyślnej ścieżce instalacji). W sekcji <appSettings> musimy dodać dwa klucze – wskazujący na certyfikat, wykorzystywany dla witryny OWA – musimy podać jego Thumbprint, oraz FQDN serwera FrontEnd (lub puli) Lynca.

Thumprint kopiujemy sobie z właściwości certyfikatu podpiętego do usług IIS w konsoli EAC:

Kolejnym krokiem jest dodanie zaufanej aplikacji po stronie serwera Lync – w tym celu musimy w Topology Builderze dodać serwer Exchange do puli zaufanych serwerów:

Po zaznaczeniu w ostatnim kroku kreatora puli Lyncowej, wystarczy opublikować zmiany w bazie konfiguracyjnej. Jeżeli włączamy tylko integrację dla OWA, to możemy dodatkowo wyłączyć replikację danych konfiguracyjnych do zdefiniowanej właśnie puli

W tym momencie po zalogowaniu się do OWA powinniśmy zobaczyć status naszego użytkownika:

Jednakże, dla świętego spokoju i prawidłowej konfiguracji powinniśmy dodać również zaufaną aplikację na serwerze Lyncowym:

new-CsTrustedApplication -ApplicationId "SRV-EX1" -TrustedApplicationPoolFqdn srv-ex1.pepug.org -port 5070

Port oczywiście możemy wybrać dowolny, nieprzypisany na serwerze  Exchange do innych usług. Ciekawą instrukcję, trochę bardziej rozbudowanej konfiguracji z oddzielnymi serwerami CAS i Mailbox pokazał na swoim blogu Oliver Moazzezi.

Integracja Exchange 2013 i Lync Server 2013

Na pierwszy rzut oka integracja Exchange 2013 i Lync Servera 2013 wygląda prosto, ale trzeba uwzględnić kilka istotnych elementów. Pierwszym z nich są certyfikaty, wykorzystywane do wzajemnego uwierzytelnienia serwerów. Dla serwera Lync Server 2013 można użyć wygenerowanego na potrzeby usług Front End certyfikatu, można również wygenerować oddzielny certyfikat, korzystając z Lync Server Deploymnet Wizarda – gdzie w kroku 3 konfiguracji serwera możemy uruchomić kreator, który pomoże nam wygenerować odpowiedni certyfikat typu OAuthTokenIssuer certificate. Jednakże do usług wzajemnego uwierzytelniania serwerów można przypisać dowolny inny certyfikat webowy, pod warunkiem, że:

• Certyfikat zawiera nazwę domeny SIP w polu Subject.
• Ten sam certyfikat jest przypisany jako OAuthTokenIssuer na każdym serwerze Front End.
• Certyfikat ma długość co najmniej 2048 bitów.

Kolejnym krokiem jest wskazanie Lyncowi, pod jakim URL dostępna jest exchange’owa usługa autodiscover – klient lincowy wykorzystywać ją będzie do sprawdzania dostępności kalendarzy innych użytkowników. W tym celu musimy na serwerze Lync 2013 wykonać komendę:

Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl "https://autodiscover.pepug.org/autodiscover/autodiscover.svc”

lub po prostu

Set-CsOAuthConfiguration -ExchangeAutodiscoverUrl "https://autodiscover.pepug.org/autodiscover/autodiscover.svc”

Oczywiście musimy się najpierw upewnić, jaką postać ma wewnętrzny URL usługi autodiscover. Możemy to łatwo sprawdzić z poziomu serwera Exchange komendą:

Get-ClientAccessServer | select name,AutoDiscoverServiceInternalUri

Kolejnym krokiem jest wskazanie serwerowi Exchange serwera Lynca jako aplikacji partnerskiej i vice-versa. W tym celu musimy wykonać na serwerze Exchange skrypt Configure-EnterprisePartnerApplication.ps1, który znajduje się w domyślnym katalogu Scripts binarek Exchange (domyślnie c:\Program Files\Microsoft\Exchange Server\V15\Scripts)

Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl 'https://lyncfe.pepug.org/metadata/json/1' -ApplicationType Lync

Po tej operacji musimy zrestartować IIS na serwerze Exchange komendą iisreset.

Analogicznie postepujemy po stronie serwera Lync 2013, tym razem wykorzystując standardowy cmdlet:

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.pepug.org/autodiscover/metadata/json/1

Jeżeli wszystko wykonaliśmy poprawnie, to wykonanie testu

Test-CsExStorageConnectivity -SipUri "sip:konrad.sagala@pepug.org"

zwróci nam wynik poprawny.

Więcej w dokumentacji - http://technet.microsoft.com/en-us/library/jj688098.aspx

W ten sposób mamy włączony Unified Contact Store. Teraz tylko trzeba zmigrować kontakty użytkowników z bazy Lyncowej do Exchange.

Automatyczne przekierowanie strony startowej OWA w Exchange 2013

Jakiś czas temu pisałem o ciekawym skrypcie do automatyzacji przekierowywania strony głównej hosta na stronę logowania OWA. W Exchange 2013 Microsoft dodał do konfiguracji serwerów dodatkową bibliotekę, która automatycznie realizuje takie przekierowanie – OWAUrlModule. Po zainstalowaniu serwera Exchange, jeżeli wpiszemy jego nazwę – np. https://owa.contoso.com, to moduł automatycznie przekieruje nas na stronę https://owa.contoso.com/owa, czyli uprości użytkownikom życie. W kolejnych Cumulative Update’ach moduł jest coraz bardziej rozbudowywany – w CU2 potrafi przekierowywać użytkownika również do skrzynki na starym serwerze Exchange 2010, jednak nie każda konfiguracja działa optymalnie. W przypadkach, gdy np. mamy kilka serwerów w load balancingu, wykorzystujemy jakieś niestandardowe mechanizmy czy adresy URL, lepiej jest jednak jak na razie wyłączyć moduł i zrobić przekierowanie po staremu. W tym celu trzeba wyedytować plik %systemdrive%\inetpub\wwwroot\web.config i zakomentować definicję modułu:

<system.webServer>
<modules>
<add name="OwaUrlModule" type="Microsoft.Exchange.HttpProxy.OwaUrlModule,Microsoft.Exchange.OwaUrlModule,Version=15.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules>
</system.webServer>

W tym celu trzeba wstawić komentarz:

<system.webServer>
<!-- <modules>
<add name="OwaUrlModule" type="Microsoft.Exchange.HttpProxy.OwaUrlModule,Microsoft.Exchange.OwaUrlModule,Version=15.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35" preCondition="" />
</modules> -->
</system.webServer>

Następnie należy w tym samym katalogu utworzyć plik default.htm o treści:

<html><meta http-equiv="REFRESH" content="0;url=/owa"></HEAD></html>

Dobrze jest również dodać definicję błędu, przekierowującą stronę:

Sprawdzałem w konfiguracji HLB z kilkoma serwerami Exchange 2013 CU2 – działa. Poradę znalazłem na blogu Jeffa Guilleta.

Problem z automapowaniem dodatkowych skrzynek w Outlooku

Kojarzycie, jak działa automapowanie dodatkowych skrzynek w Outlooku? Począwszy od wersji Exchange 2010 SP1, jeżeli dodajemy uprawnienia do skrzynki innym użytkownikom, automatycznie jest włączane mapowanie skrzynki, tak że w Outlooku pojawia się nam dodatkowa skrzynka. Najprościej dodać uprawnienia z konsoli graficznej (EMC w Exchange 2010 lub EAC w Exchange 2013), jednak wykorzystując PowerShell jest prawie tak samo łatwo. Jeżeli chcemy dodać koledze Jankowi pełne prawa do skrzynki np. sekretariatu, to jest to bardzo proste:

Add-MailboxPermission –Identity Sekretariat –User pepug\jankowalski –AccessRights FullAccess

Opcja automapowania ustawiana jest automatycznie i w Outlooku 2007 lub nowszym powinno zadziałać po krótkiej chwili. Jeżeli jednak tego nie chcemy (ktoś ma dostęp do kilkunastu czy nawet kilkudziesięciu skrzynek i otwieranie outlooka i jego synchronizacja mogłaby trwać zbyt długo), to możemy opcję wyłączyć (ta możliwość pojawiła się w Exchange 2010 Service Pack 2):

Add-MailboxPermission –Identity Sekretariat –User pepug\jankowalski –AccessRights FullAccess –Automapping $false

Jeżeli zabieramy użytkownikowi Exchange uprawnienia do dodatkowej skrzynki, mapowanie jest automatycznie zdejmowane, jednak opcja ta niestety nie zawsze działa. I tak można dorobić się kilku folderów “widm”, które tylko niepotrzebnie generują nam błędy synchronizacji (nie można ich zamknąć z poziomu Outlooka). Żeby pozbyć się takich problemów, musimy wejść w atrybuty konta (sekretariatu, nawiązując do powyższego przykładu) i usunąć nazwę problematycznej skrzynki z listy delegatów konta (jak na poniższym rusynku):

Więcej na temat automappingu w Exchange 2010 można przeczytać w artykule Neila Hobsona.