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.

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