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.

‘Usprawnienie’ procesu migracji skrzynek w Exchange 2013

Jakiś czas temu pisałem, jak można usprawnić proces migracji skrzynek pocztowych. W Exchange 2010 wystarczyło wyedytować plik konfiguracyjny usługi MRS, zrestartować ją i można było migrować dużo więcej skrzynek równolegle niż domyślne ustawienia pozwalały. Niestety w Exchange 2013 Microsoft usprawnił proces migracji tak, że stało się to w zasadzie niemożliwe. Sam serwer Exchange na podstawie obciążenia stwierdza, ile zasobów moze użyć usługa MRS. Nowa funkcjonalność Exchange 2013 – Workload Management, zamiast usprawnić ten proces blokuje szybkość migracji. Pomimo wielu zmian ustawień i testów nie udało mi się przekroczyć ilości dziesięciu równolegle migrowanych skrzynek do Exchange 2013, podczas gdy dla Exchange 2010 spokojnie można było uzyskać nawet pięćdziesiąt równolegle migrowanych skrzynek.

Rozumiem, że w przypadku migracji realizowanej w godzinach biurowych jest to przydatne, jednak gdy człowiek ma weekend, a czasem tylko noc na migrację, to taka zmiana jest frustrująca. Co zaleca Microsoft? Jak na razie, na etapie CU2 jedynym sugerowanym rozwiązaniem jest zmiana priotytetu (parametr –Priority w cmdlecie new-moverequest). Lista dostępnych priorytetów to : Emergency (najwyższy), Highest, Higher, High, Normal, Low, Lower, oraz Lowest.

MRS używa priorytetów porównując je z dostępnością zasobów serwerowych. Move request z priorytetem normal lub niższym używa domyślnej polisy obciążeniowej (workload policy) MailboxReplicationService, przy wyższych priorytetach  MRS używa MailboxReplicationServiceHighPriority workload policy, co powinno umożliwiać bardziej intensywne obciążenie serwerów.

Jednakże, jak napisałem wcześniej, róznice nie rzucają na kolana, ale mam nadzieję, że Microsoft usprawni to w kolejnych aktualizacjach.

MSExchange Mailbox Replication error 1121

Wczoraj diagnozowałem uciążliwy błąd na serwerze Exchange 2013. W systemie Exchange Server 2010 i Exchange Server 2013 Mailbox Replication Service (MRS) jest odpowiedzialny za przenoszenie skrzynek, importowanie i eksportowanie danych pomiędzy bazą i plikami .pst oraz za odzyskiwanie disable’owanych i usuniętych (soft-deleted) skrzynek. Operacje przenoszenia skrzynek są definiowane przez administratora jako move requesty i wrzucane do kolejki i przetwarzane przez MRS. Po zakończeniu przenoszenia możemy ręcznie wyczyścić kolejkę zleceń, najprościej sekwencją:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Jednak czasami, z różnych powodów, na serwerze pozostają śmieci, które mogą objawiać się generowaniem przez usługę MRS błędu 1121. Treść błędu może wyglądać różnie, jednak przeważnie powtarzają się w nim dwa parametry: Request GUID i Database GUID. Jeżeli wykonanie operacji:

Get-MoveRequest | Get-MoveRequestStatistics

nie pokazuje nic, czyli wg. systemu nie ma żadnych operacji przenoszenia w kolejkach, należy wtedy wykonanać następującą komendę:

Remove-MoveRequest -MoveRequestQueue 'd30f6568-2785-490e-97d5-4142a030e52c' -MailboxGuid ‘2bb0ac3e-0d79-4338-ab04-9ec728a077fe'

W powyższym poleceniu jako identyfikator kolejki wykorzystujemy pojawiający się w opisie błędu Database GUID. Błąd powinien przestać nas męczyć.

Exchange 2013 i błąd MSExchangeDiagnostics 1006

W logu aplikacyjnym serwera Exchange 2013 CU1, CU2, a nawet CU2v2 pojawia się denerwujący błąd, generowany przez usługę MSExchangeDiagnostics, jak na poniższym rysunku. Błąd jest generowany dla wszystkich wolumenów w systemie, więc pojawia się cyklicznie w grupach, zależnych od ilości dysków w danym serwerze Exchange.

 

Wynika ono ze źle ustawionego wyzwalacza, sprawdzającego ilość wolnego miejsca w systemie. Błąd powinien być naprawiony w kolejnym CU, ale póki co można się go pozbyć wyłączając wyzwalacz. W tym celu należy wyedytować plik konfiguracji usługi Microsoft.Exchange.Diagnostics.Service.exe (domyślnie w katalogu C:\Program Files\Microsoft\ExchangeServer\V15\Bin\).

Należy znaleźć licznik “ExchangeJobs.Triggers.DatabaseDriveSpaceTrigger” i zmienić jego wartość z “True” na “False”, jak widać na poniższym rysunku.

Oczywiście po zapisaniu zmian, musimy zrestartować usługę MS Exchange Diagnostics Service.

Exchange 2013 – forwardowanie maili na zewnątrz

Kilkukrotnie pytano mnie ostatnio o funkcję ustawiania forwardowania maili na zewnątrz w Exchange 2013. W poprzednich wersjach Exchange była ona dostępna, chociaż wymagała dodania obiektu typu kontakt lub mail user (reguły dostarczania wiadomości wymuszały wybór z listy dostępnych obiektów odbiorców poczty). Jednak w Exchange 2013, a konkretnie w konsoli webowej Exchange Admin Center taka funkcjonalność przestała działać.

Jednak na szczeście nie jest to problem permanentny, tylko jak się okazuje, jak zwykle Microsoft przerzucił funkcję do powłoki shellowej.

W tym celu wystarczy wykonać komendę.

Set-Mailbox -Identity "Jan Kowalski" -DeliverToMailboxAndForward $true -ForwardingSMTPAddress janek@hotmail.com

W ten sposób kopia wiadomości będzie wysyłana zarówno do skrzynki użytkownika, jak i na dodatkowe konto prywatne (oczywiście przy poufnych danych firmowych osobną kwestią jest sensowność takiego działania).

Żeby wyłączyć forwardowanie musimy wykonać tę samą komendę resetując ustawienia forwardowania:

Set-Mailbox -Identity “Jan Kowalski” -DeliverToMailboxandforward $False -ForwardingSMTPAddress $Null -ForwardingAddress $Null

Outlook 2007 a Exchange 2013

Po kilku migracjach systemu Exchange do wersji 2013 nasunęło mi się istotne pytanie - czy warto używać Outlooka 2007 z Exchange 2013? W zasadzie jest wspierany. Dokumentacja Exchange 2013 mówi, że minimalna wersja, która jest rekomendowana to Outlook 2007 Service Pack 3 z aktualizacją Outlook 2007 November 2012 (nr wersji 12.0.6665.5000). Po zainstalowaniu Outlooka 2007 SP3 i pobraniu wszystkich poprawek z Windows Update uzyskamy wersję nowszą (stan na koniec września 2013):

Czyli wszystko wygląda na pozór świetnie. Diabeł jak zwykle tkwi w szczegółach. Po pierwsze: bardzo wygodne podpowiedzi – Mail Tips i Policy Tips nie są dostępne w Outlooku 2007. Po drugie: Outlook 2007 jako pierwsza wersja wykorzystująca Web Services i usługę dostępności ma spore ograniczenia w podglądaniu (Calendar Permissions Differences in Outlook 2007, 2010 and 2013) i udostępnianiu (You can’t share your calendar in Outlook 2007) kalendarzy. No i kolejna diametralna (jak dla mnie) różnica – możliwość podłączania kilku różnych skrzynek z różnych organizacji Exchange, która pojawiła się w Outlooku 2010. W ramach tej samej oganizacji dodatkowe skrzynki podpinają nam się automatycznie.

Ciekawe porównanie funkcjonalności jest dostępne na Exchange Wiki – co prawda nie obejmuje Outlooka 2013, ale widać, że różnic jest na tyle dużo, że warto rozważyć aktualizację Office do nowszej wersji, zwłaszcza dla osób, które używają wielu kalendarzy, skrzynek współdzielonych i innych zaawansowanych funkcji.

Konferencja preMTS – 21 października w Warszawie

Ruszyła właśnie rejestracja na konferencję preMTS – spotkanie organizowane przez APN Promise przy współpracy Microsoft, Kempa, Veeama i Ciresona. Duża konferencja, jaką jest MTS to dobry pretekst, żeby spotkać się i porozmawiać na temat trochę zapomnianych w głównym nurcie MTS-u technologii.

Udało mi się namówić kilkoro świetnych specjalistów – znanych ze spotkań PEPUG i wcześniejszych konferencji MTS, jak i trochę mniej znanych (ale z dużym doświadczeniem), do podzielenia się wiedzą na temat wdrażania produktów takich jak Exchange 2013, Lync 2013, SCOM 2012, SCCM 2012 i SCSM 2012. Powiemy również o produktach powiązanych z aplikacjami Microsoftu – urządzeniach (telefony, Load Balancery) i oprogramowaniu innych dostawców rozszerzających funkcjonalność tych produktów. Serdecznie zapraszam na konferencję.

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.

Aktualizacja Exchange 2013 CU2

Microsoft wydał poprawioną wersję CU2 dla Exchange 2013 – oryginalna wersja pakietu czyściła uprawnienia folderów publicznych przy przeniesieniu skrzynki folderów publicznych między bazami.

Przy okazji Microsoft zmienił nazewnictwo pakietu – zamiast nic nie mówiącego Exchange-x64.exe, można odczytać teraz nr artykułu z opisem poprawki.

Exchange 2013 CU2 już dostępny

Dzisiaj pojawił się długo czekiwany i zapowiedziany na amerykańskim TechEdzie pakiet poprawek CU2 do Exchange 2013. Zmian jest dużo, niektórzy mogliby je nawet porównywaćz Service Packiem, ale jak na razie to tylko planowa paczka aktualizacji, udostępniona zgodnie z nowym modelem serwisowania.

Jednak oprócz usunięcia części problemów i błędów CU2 wprowadza szereg ulepszeń. Część z nich byłą dostępna już w Exchange 2010 SP2, jednak nie znalazły się w wersji 2013 RTM.

Dużo kontrowersji wywołało ograniczenie ilości baz danych w Exchange 2013 Enterprise RTM do 50, co zostało zmienione w CU2 – przywrócono maksymalną ilość 100 baz danych.

Kolejne usprawnienia wprowadzono w obszarach:

OWA Redirection - przekierowanie między site’ami, z SSO

High Availability – dodano nowy serwis DAG Management Service

Managed Availability – rozszerzono funkcjonalność responderów, mogą teraz obsługiwać całą grupę serwerową (DAG)

Cmdlet Help – na bierząco można zaktualizować pomoc dla cmdletów, nie czekając na kolejny pakiet poprawek

OWA Search Improvements – poprawiono prezentację wyników w ramach wątków konwersacyjnych

Malware Filter Rules – dodano cmdlety, pozwalające tworzyć polisy filtrujące dla grup i domen pocztowych.

Dokładniejsza lista poprawek znajduje się na blogu grupy produktowej.

Exchange 2013 RTM CU2 rozszerza schemat Active Directory. Przed instalacją pakietu należy uruchomić z odpowiednimi uprawnieniami polecenie setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms.

Exchange 2013 RTM CU2 zawiera również modyfikacje Active Directory (np. aktualizacje RBAC, uwzględniające nowe cmdlety). Czyli wykonanie polecenia setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms też może być pomocne.

Lipcowa poprawka dla Lync Server 2013

Pojawiła się kolejna poprawka do serwera Lync 2013. Zawiera całkiem sporo poprawionych komponentów, Oprócz ściągnięcia poprawki, po jej zainstalowaniu należy zaktualizować schemat baz danych, zgodnie z opisem w artykule KB2809243. Ponieważ poprawka również aktualizuje Unified Communications Web API, na koniec należy uruchomić Bootstrapera, który zweryfikuje konfigurację komponentów:

%ProgramFiles%\Microsoft Lync Server 2013\Deployment\Bootstrapper.exe

TechEd Europe 2013

W piątek wróciłem z tegorocznej edycji europejskiego TechEdu (TEE 2013) do domu, moja walizka dojechała dzisiaj,- ale jednak dojechała, więc nie ma co narzekać. W zeszłym roku nie uczestniczyłem w TEE, więc po nie najlepszych wspomnieniach z TEE 2010 w Berlinie byłem bardzo ciekawy tegorocznej edycji. Po dotarciu do centrum konferencyjnego, które jest ogromne, pewne zdziwienie wywołały skromne bilbordy, które nawet z bliska łatwo było przeoczyć. Jednak wnętrze centrum zrobiło na mnie wrażenie.

Konferencja przeleciała jak z bicza strzelił, widziałem dużo ciekawych sesji, włączając w to najnowsze wersje Windows Server 2012 R2 i System Center 2012 R2 (nawet z aktualnymi labami), uczestnicy dostali również pendrive z obrazem instalacyjnym Windows 8.1 (zainstalowany zaraz po powrocie do Polski). Organizatorzy zapewnili trzy ciekawe imprezy wieczorne – chociaż niektórzy narzekali, że Polska to reszta świata i nie miałą dedykowanego spotkania, to jednak było bardzo sympatycznie. Dobrą rzeczą jest dostępność sesji i slajdów na portalu Channel 9.

Trochę zdziwiła mnie ilość wystawców w pawilonie TechExpo – w tym roku było ich mniej niż poprzednio, chociaż cześć z nich była bardzo ciekawa, w tym stoisko polskiej firmy CodeTwo. Ciekawie prezentowały się też stoiska Microsoftu – zwłaszcza Lynca 2013 z szeroką gamą urządzeń, podobnie Windows Phone i rozwiązań chmury (Azure i Office365).

Podobno również uczestników w tym roku było mniej, choć w czasie lunchu nie było tego widać.

Zaskoczył mnie również brak osób z polskiego biura Microsoft, ale rozumiem, że koniec roku fiskalnego i duże zmiany personalne miały na to swój znaczący wpływ. Miejmy nadzieję, że nie wpłynie to negatywnie na tegoroczny MTS w Warszawie.

Bogatszy o nowe doświadczenia wróciłem do biura by z naładowanymi akumulatorami, ruszyć do testowania najświeższych produktów.