Exchange - Pytania i odpowiedzi: Odtwarzanie sklastrowanych serwerów skrzynek pocztowych, problemy z książką adresową trybu offline i inne

Autor: Henrik Walther

Opublikowano: 7 sierpnia 2009 | Zaktualizowano: 7 sierpnia 2009

Zawartość strony

	Błąd podczas próby odtworzenia serwera CMS na klastrze zapasowym
	Przełączenie serwerów Exchange Server 2007 SP1 z podstawowego do zapasowego centrum danych a różne wersje programu Microsoft Outlook
	Cmdlet Enable-ContinuousReplicationHostName a replikacja typu SCR
	Błąd po aktualizacji książki adresowej trybu offline nowymi obiektami pocztowymi

Błąd podczas próby odtworzenia serwera CMS na klastrze zapasowym

Nasza infrastruktura poczty elektronicznej oparta jest na oprogramowaniu Exchange 2007 SP1. Wszystkie serwery Exchange 2007 SP1 zostały zainstalowane na komputerach z systemem Windows Server 2008. Posiadamy też dwa centra danych - podstawowe oraz zapasowe, które może przejąć funkcje centrum podstawowego w razie jego całkowitego zniszczenia. W podstawowym centrum danych wszystkie serwery skrzynek pocztowych (Mailbox) oparte są na mechanizmie ciągłej replikacji klastra (CCR - Cluster Continuous Replication) w celu zapewnienia lokalnie wysokiej dostępności rozwiązania. Dla potrzeb awaryjnego przenoszenia serwerów skrzynek pocztowych z podstawowego centrum danych do centrum zapasowego stosowany jest mechanizm ciągłej replikacji zapasowej (SCR - Standby Continuous Replication). Oznacza to, że wszystkie serwery skrzynek pocztowych oparte na mechanizmie replikacji CCR i znajdujące się w podstawowym centrum danych (serwery te oznaczać będziemy skrótem CMS, od słów „CCR-based clustered Mailbox Server) pełnią rolę źródła danych dla replikacji SCR. Każde źródło replikacji SCR ma odpowiadające mu miejsce docelowe replikacji SCR, znajdujące się w zapasowym centrum danych i mające postać zapasowego klastra, na którym zainstalowana została jedynie pasywna rola serwera skrzynek pocztowych.

Ostatnio przeprowadziliśmy test awaryjnego przełączania pomiędzy centrami danych, ale niestety podczas próby otworzenia serwerów CMS na klastrach zapasowych spotkaliśmy się z pewnym problemem. Po uruchomieniu programu Setup.com z opcją /RecoverCMS otrzymaliśmy komunikat błędu pokazany na Rysunku 1 .

Rysunek 1: Błąd programu Setup, otrzymany podczas próby odtworzenia serwera CMS na klastrze zapasowym.

Zastanawiam się, czy spotkał się już Pan z takim błędem podczas próby odtworzenia serwera CMS na klastrze zapasowym, a co ważniejsze, czy może Pan zaproponować jakieś rozwiązanie tego problemu.

Odp.
Tak, miałem już okazję spotkać się z tym błędem podczas próby odtworzenia serwera CMS na klastrze zapasowym. Na szczęście błąd ten wystąpił również podczas testu procedury awaryjnego przełączania lokacji. (Czy trzeba jeszcze komuś wyjaśniać, dlaczego testowanie rozwiązań przełączania awaryjnego jest takie ważne?)

Zastanowił mnie wówczas fakt, że przed wystąpieniem tego problemu testowałem już wielokrotnie taką samą konfigurację. We wszystkich poprzednich testach miałem jednak do czynienia z oprogramowaniem Exchange 2007 SP1 zainstalowanym na serwerach z systemem Windows Server 2003, a nie Windows Server 2008, jak to miało miejsce w tym przypadku.

To spostrzeżenie doprowadziło mnie do odkrycia różnicy w sposobie awaryjnego przełączania klastra opartego na systemie Windows Server 2008, w porównaniu z klastrem opartym na systemie Windows Server 2003. W systemie Windows Server 2003 tworzone jest konto usługi klastra, które następnie zostaje dedykowane do obsługi tego klastra. W systemie Windows Server 2008 nie wykonuje się już tej czynności. Zamiast tego, klaster awaryjny działa przy użyciu konta „ System lokalny ”. Po zbadaniu dziennika aplikacji i dziennika systemu na zapasowym klastrze, na którym próbowałem odtworzyć serwer CMS, natrafiłem na błąd pokazany na Rysunku 2.

Rysunek 2: Błąd odtwarzania będący rezultatem niewystarczających uprawnień.

Błąd ten wyjaśnia, że awaryjny klaster systemu Windows nie ma uprawnień koniecznych do zaktualizowania w kartotece Active Directory konta komputera dla serwera CMS. W opisie błędu wymienione zostały także trzy możliwe przyczyny. Ponieważ błąd wystąpił podczas próby odtwarzania na klastrze zapasowym istniejącego serwera CMS, więc pierwszą z sugestii możemy zignorować. Drugą sugestię również można zignorować, ponieważ nie przekroczyliśmy jeszcze żadnego limitu liczby obiektów typu komputer. Ostatnia z sugestii jest już jednak całkiem interesująca. Mówi ona, by sprawdzić, czy zapasowy klaster systemu Windows, na którym chcemy odtworzyć serwer CMS, posiada uprawnienie typu „ Pełna kontrola ” wobec obiektu typu konto komputera, reprezentującego odtwarzany serwer CMS.

Otwarcie za pomocą konsoli Użytkownicy i komputery usługi Active Directory okna z właściwościami obiektu komputera reprezentującego serwer CMS i przejście na zakładkę Zabezpieczenia ujawnia, że klaster zapasowy nie ma uprawnień typu „ Pełna kontrola ” (Rysunek 3).

Rysunek 3: Klaster zapasowy nie posiada uprawnienia typu “Pełna kontrola”.

W moim przypadku rozwiązanie problemu polegało na dodaniu dla klastra zapasowego uprawnienia typu „ Pełna kontrola ” wobec konta komputera reprezentującego serwer CMS i to samo rozwiązanie powinno również zadziałać w opisywanym przypadku.

W chwili pisania tego artykułu (koniec lutego) nie było jeszcze żadnych informacji o tym problemie w takich miejscach publicznych, jak np. biuletyn TechNet, ani w żadnym artykule z bazy wiedzy firmy Microsoft (KnowledgeBase). Mój dobry przyjaciel, Tim McMichael z działu Microsoft Customer Support Services, zamieścił jednak na swoim blogu notatkę opisującą ten problem w znacznie bardziej szczegółowy sposób. Tak więc osoby zainteresowane bardziej szczegółowymi informacjami na ten temat powinny odwiedzić blog Tima (" Permissions recommended for the CNO (Cluster Name Object) in Windows 2008 for Exchange 2007 SP1 setup operations ").

Przełączenie serwerów Exchange Server 2007 SP1 z podstawowego do zapasowego centrum danych a różne wersje programu Microsoft Outlook

Nasza firma aktualnie jest w trakcie tworzenia rozwiązania przełączania awaryjnego na poziomie lokacji. Jako rozwiązanie odtwarzania po całkowitej katastrofie, pozwalające na przeniesienie naszej istniejącej infrastruktury poczty elektronicznej opartej na oprogramowaniu Exchange 2007 SP1 z podstawowego centrum danych do centrum zapasowego, chcemy wykorzystać mechanizm ciągłej replikacji zapasowej (SCR - Standby Continuous Replication). Ponieważ tylko część naszych użytkowników dokonała aktualizacji pakietu Office i korzysta z programu Outlook 2007, a pozostali nadal używają programu Outlook 2003, mam pewne pytanie. Czy po awaryjnym przełączeniu wszystkich serwerów Exchange Server 2007 SP1 z podstawowego do zapasowego centrum danych i przeprowadzeniu wszystkich kroków wymaganych do awaryjnego przełączenia lokacji SCR zmiana ta zostanie automatycznie dostrzeżona przez obie wersje programu Outlook?

Odp.
To bardzo dobre pytanie, ale odpowiedź na nie zależy od tego, czy do awaryjnego przeniesienia serwerów skrzynek pocztowych do zapasowego centrum danych użyta została opcja RecoverCMS, czy opcja przenośności bazy danych. Jeśli w podstawowym centrum danych znajdują się autonomiczne serwery skrzynek pocztowych, które są replikowane na autonomiczne serwery skrzynek pocztowych z zapasowego centrum danych przy użyciu replikacji SCR, to do awaryjnego przełączenia baz danych ze skrzynkami pocztowymi można wykorzystać opcję przenośności bazy danych. Jeśli natomiast w podstawowym centrum danych znajduje się klaster złożony z jednej kopii (SCC - Single Copy Claster) lub klaster serwerów skrzynek pocztowych oparty na ciągłej replikacji CCR, a w zapasowym centrum danych znajdują się takie same klastry zapasowe, to do odtworzenia w zapasowym centrum danych całego serwera CMS można użyć opcji RecoverCMS. Używając jako mechanizmu przełączania awaryjnego opcji RecoverCMS zwykle nie trzeba się przejmować tym, czy po przeprowadzeniu przełączania awaryjnego klienci z programem Outlook będą mogli połączyć się z właściwym serwerem. Należy wiedzieć, że adres IP serwera CMS ulegnie wówczas zmianie. Jeśli zgodnie z zaleceniami praktycznymi czas życia rekordów DNS (TTL - Time To Live) został skonfigurowany jako 5 minut, to użytkownicy mogą jednak zaobserwować niewielkie opóźnienie przed ponownym połączeniem się programu Outlook z serwerem CMS.

Jeśli jednak jako mechanizm odtwarzania użyta zostanie opcja przenośności bazy danych, to sytuacja wygląda nieco inaczej, w zależności od używanej wersji programu Outlook. Klienci używający wersji Outlook 2007 odnotują zmianę w sposób automatyczny, dzięki usłudze Autodiscover działającej na serwerach dostępu klientów (Client Access). Oznacza to, że korzystając z tej wersji programu Outlook nie ma potrzeby ręcznego wykonywania jakichkolwiek zmian. Nie musi to jednak być prawdą w przypadku klientów używających wersji Outlook 2003. Po odtworzeniu skrzynki pocztowej na innym serwerze, nazwa serwera, na którym znajduje się baza danych skrzynek pocztowych, będzie oczywiście inna.

Można się zastanawiać, czy ma to jakieś znaczenie, jeśli po przełączeniu awaryjnym użyty zostanie cmdlet Move-Mailbox z opcją –ConfigurationOnly ? Odpowiedź brzmi: tak, ma to znaczenie, ponieważ program Outlook 2003 nie obsługuje usługi Autodiscover. Oznacza to, że oryginalny serwer, na którym znajdowały się skrzynki pocztowe przed wykonaniem przełączenia awaryjnego, musi być w stanie online, aby można było uaktualnić nazwę serwera w profilu MAPI programu Outlook. Jeśli oryginalny serwer będzie w stanie offline, to nazwa serwera nie będzie mogła zostać uaktualniona w sposób automatyczny.

Tak więc, w przypadku wystąpienia katastrofy, w trakcie której wszystkie serwery z podstawowego centrum danych będą w stanie offline, odzwierciedlenie zaistniałych zmian wymagać będzie rekonfiguracji profili MAPI programu Outlook 2003 przy użyciu takiego narzędzia, jak np. Microsoft Exchange Server Profile Redirector (ExProfre), użytego w połączeniu ze skryptem logowania. Warto w tym miejscu zauważyć, że jeśli wszyscy klienci znajdowali się w podstawowym centrum danych, to i tak konieczne będzie ich odtworzenie.

Cmdlet Enable-ContinuousReplicationHostName a replikacja typu SCR

W naszej infrastrukturze poczty elektronicznej opartej na oprogramowaniu Exchange 2007 SP1, na wszystkich serwerach skrzynek pocztowych włączona została ciągła replikacja klastra (CCR - Cluster Continuous Replication). W każdym węźle klastra zainstalowane zostały cztery karty sieciowe. Dwie karty zostały ze sobą sparowane i podłączone do sieci publicznej, z której akceptowane są połączenia klientów programu Outlook, itp. Trzecia karta sieciowa używana jest w sieci łączącej dwa węzły klastra uczestniczące w replikacji CCR (tzw. sieć pulsu -ang. heartbeat network). Czwarta karta sieciowa służy wyłącznie do celów wysyłania rejestrowanych komunikatów. Korzystając z polecenia typu cmdlet Enable-ContinuousReplicationHostName, wprowadzonego w wersji Exchange 2007 SP1, określiliśmy (w celu zapewnienia nadmiarowości wysyłania rejestrowanych komunikatów), że do przesyłania plików dzienników z węzła aktywnego na węzeł pasywny może być używana zarówno dedykowana sieć dla rejestrowanych komunikatów, jak i sieć pulsu (ang. heartbeat network). Rozwiązanie to sprawdza się znakomicie i naprawdę pozwala zmniejszyć ruch w sieci publicznej, zwłaszcza wówczas, gdy konieczne jest ponowne zainicjowanie jednej lub kilku baz danych ze skrzynkami pocztowymi (choć taka potrzeba pojawia się raczej dość rzadko).

Pomiędzy tymi serwerami skrzynek pocztowych, opartymi na replikacji CCR i znajdującymi się w podstawowym centrum danych, a ich odpowiednikami z zapasowego centrum danych została również włączona replikacja SCR. W tym miejscu dochodzimy do naszego pytania. Czy cmdlet Enable-ContinuousReplicationHostName można stosować również dla replikacji typu SCR?

Odp.
Cieszę się, że cmdlet EnableContinuousReplicationName jest dla Państwa tak użyteczny. Został on jednak stworzony specjalnie dla potrzeb rozwiązań opartych na replikacji typu CCR i odpowiedź na Państwa pytanie niestety brzmi - nie, aktualnie polecenie to nie obsługuje rozwiązań z replikacją typu SCR.

Błąd po aktualizacji książki adresowej tr ybu offline nowymi obiektami pocztowymi

Nasza firma przeszła właśnie z wersji Exchange 2003 na wersję Exchange 2007 SP1. Wszystkie role serwerów Exchange 2007 SP1 działają na komputerach pracujących z systemem Windows Server 2008, a nasze serwery Exchange 2007 Mailbox oparte zostały na ciągłej replikacji klastra typu CCR.

Dotychczas wszystko działało bardzo dobrze, ale zaobserwowaliśmy pewien problem związany z książką adresową programu trybu offline (OAB - Offline Address Book). Po aktualizacji tej książki nowymi obiektami pocztowymi nie są one widoczne dla użytkowników końcowych korzystających z programu Outlook 2007. Próbując rozwiązać ten problem natrafiliśmy w dzienniku aplikacji na serwerze dostępu klienta (Client Access Servers) na zdarzenie o numerze 1021, zawierające następujący opis:

Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location>

This is normal if the directory has never been generated. Otherwise, make sure this directory

and share has read permission for the "Exchange Servers" group.

(Proces MSExchangeFDS.exe (PID=xxxx). Nie można odnaleźć katalogu <współdzielona lokalizacja książki adresowej trybu offline>

Jest to normalne, jeśli katalog ten nigdy nie został wygenerowany. W przeciwnym przypadku należy upewnić się, czy ten katalog oraz jego udostępnienie zawierają uprawnienie odczytu dla grupy "Serwery Exchange")

Próbowaliśmy ręcznie skopiować książkę adresową trybu offline z serwera skrzynek pocztowych opartego na replikacji CCR na serwer dostępu klienta. Powoduje to aktualizację zawartości książki adresowej w programie Outlook, ale chcielibyśmy rozwiązać ten problem na stałe. W jaki sposób moglibyśmy to zrobić?

Odp.
Również miałem do czynienia z tym problemem. Jest on spowodowany sposobem zachowywania się awaryjnych klastrów systemu Windows 2008. Wraz z awaryjnymi klastrami systemu Windows 2008 (Windows 2008 Failover Cluster) wprowadzona została nowa koncepcja nazywana zasięgiem współdzielenia. Zasięg współdzielenia polega zasadniczo na tym, że udostępniany folder sieciowy związany jest albo z nazwą węzła, albo z nazwą jednego z obiektów klastra, na którym znajduje się ten udostępniany folder. Bardziej szczegółowe informacje na temat zasięgu współdzielenia plików znaleźć można na blogu Ask the Core Team (w artykule " File Share 'Scoping' in Windows Server 2008 Failover Clusters ").

W celu rozwiązania tego problemu należy zainstalować aktualizację Exchange 2007 SP1 Rollup Update 5 lub nowszą, która zawiera wymaganą poprawkę rozwiązującą ten błąd. Należy również zapoznać się z artykułem " Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters ". Ponieważ z instalacją tej aktualizacji typu Rollup Update wiążą się także pewne negatywne skutki, więc przed zastosowaniem tego rozwiązania należy dokładnie przeczytać wymieniony artykuł z bazy wiedzy firmy Microsoft.

Henrik Walther jest posiadaczem certyfikatu Microsoft Certified Master w dziedzinie Exchange 2007 oraz certyfikatu and Exchange MVP, z ponad 15-letnim doświadczeniem w pracy w branży informatycznej. Pracuje jako architekt technologii (Technology Architect) dla firmy Trifork Infrastructure Consulting (złoty partner firmy Microsoft z Danii) oraz jako autor tekstów technicznych dla firmy Biblioso Corporation (amerykańskiej firmy specjalizującej się w zarządzaniu dokumentacją oraz w usługach lokalizowania oprogramowania).