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.