Przed przystąpieniem do aktualizacji serwera Exchange (wgranie poprawek CU) koniecznie musimy sprawdzić kompatybilność posiadanych serwerów z konkretną aktualizacją CU tj. sprawdzić czy na serwerze na którym zainstalowany jest Exchange są wszystkie wymagane komponenty np. odpowiednia wersja oprogramowania Microsoft .NET Framework. Aby to sprawdzić możemy wpisać w wyszukiwarce frazę „exchange compatibility matrix” i sprawdzić wymagania na odpowiedniej stronie. W czasie tworzenia niniejszego opisu powyższa informacja dostępna była pod adresem https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019. W przypadku gdy na serwerze brakuje jakiegoś komponentu koniecznie musimy go dograć przed rozpoczęciem aktualizacji Exchange.
W opisanym przykładzie posiadamy infrastrukturę składającą się z dwóch serwerów o nazwach EXCH1 oraz EXCH2.
W dużym skrócie całe zadanie polega na wprowadzeniu jednego z serwerów w tryb konserwacji („Maintenance mode”), wykonanie na nim aktualizacji, następnie wyjście z trybu konserwacji, migracja baz na zaktualizowany serwer, wprowadzenie drugiego serwera w tryb konserwacji i wykonanie na nim aktualizacji.
Wszystkie polecenia wydajemy w konsoli „Exchange Management Shell” uruchomionej z uprawnieniami administratora.
W poniższym opisie w pierwszej kolejności wykonana zostanie aktualizacja serwera EXCH2 a następnie serwera EXCH1.
1. Wyczyszczenie kolejki wiadomości na serwerze EXCH2
Set-ServerComponentState EXCH2 -Component HubTransport -State Draining -Requester Maintenance
2. Microsoft zaleca restart usług transportowych. Wykonany to poleceniami:
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
3. Migracja wiadomości będących w trakcie realizacji z serwera EXCH2 na serwer EXCH1 (serwer docelowy musimy podać wraz z pełną nazwą domeny)
Redirect-Message -Server EXCH2 -Target EXCH1.domena.local
W przypadku gdy serwer nie jest członkiem DAG przechodzimy do p.8, w przeciwnym wypadku wykonujemy poniższe polecenia
4. Wstrzymaj węzeł DAG
Suspend-ClusterNode EXCH2
5. Zmigrowanie wszystkich aktywnych baz na inny serwer będący członkiem DAG
Set-MailboxServer EXCH2 -DatabaseCopyActivationDisabledAndMoveNow $True
6. Sprawdź status polityki automatycznej aktywacji bazy danych. Zanotuj go gdyż będzie potrzebny, gdy wyłączy się serwer z trybu konserwacji.
Get-MailboxServer EXCH2 | Select DatabaseCopyAutoActivationPolicy
W przypadku gdy polityka jest ustawiona na „Blocked” można pominąć punkt 7.
7. Zablokuj serwer przed hostowaniem aktywnych baz
Set-MailboxServer EXCH2 -DatabaseCopyAutoActivationPolicy Blocked
8. Wprowadź serwer w trym konserwacji
Set-ServerComponentState EXCH2 -Component ServerWideOffline -State Inactive -Requester Maintenance
9. Zamykamy konsolę „Exchange Management Shell” i uruchamiamy instalator CU w trybie administratora. Przechodzimy kolejne kroki. Cierpliwie czekamy na wykonanie wszystkich zadań – instalator może się zatrzymać na dłużej przy kilkunastu %.
Po zakończonej instalacji uruchamiamy konsolę „Exchange Management Shell” w trybie administratora i wykonujemy kolejne kroki.
W przypadku gdy serwer nie jest członkiem DAG wykonujemy kroki 10, 14 i 15.
10. Wyłączenie trybu konserwacji
Set-ServerComponentState EXCH2 -Component ServerWideOffline -State Active -Requester Maintenance
11. Uruchamiamy węzeł DAG
Resume-ClusterNode EXCH2
12. Zezwalamy na aktywację kopii bazy danych na serwerze
Set-MailboxServer EXCH2 -DatabaseCopyActivationDisabledAndMoveNow $False
13. Przywrócenie pierwotnej polityki automatycznej aktywacji baz danych (odczytanej w p.6). Jeśli pierwotnie ustawiona była na „Blocked” pozostaw ją w tym stanie tzn. pomiń poniższe polecenie. Domyślnie polityka ustawiona jest na Unrestricted
Set-MailboxServer EXCH2 -DatabaseCopyAutoActivationPolicy Unrestricted
14. Ustaw komponenty transportowe w tryb aktywny aby mogły przyjmować połączenia.
Set-ServerComponentState EXCH2 -Component HubTransport -State Active -Requester Maintenance
15. Microsoft zaleca restart usług transportowych, aby ta zmiana została natychmiast wykonana.
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Jeśli serwer jest członkiem DAG i zmigrowaliśmy z niego wszystkie aktywne bazy, możemy w prosty sposób rozłożyć je automatycznie wykorzystując ustawione preferencje poprzez wykonanie skryptu RedistributeActiveDatabases.ps1 dostarczonego przez Microsoft wraz z instalacją serwera Exchange
C:\Program Files\Microsoft\Exchange Server\V15\Scripts> .\RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference -Confirm:$false
Po wykonaniu powyższych czynności serwer został zaktualizowany. Pozostaje zaktualizować drugi z serwerów.
——————————————-
Wykonujemy wszystkie powyższe czynności w odniesieniu do serwera EXCH1
1. Wyczyszczenie kolejki wiadomości na serwerze EXCH1
Set-ServerComponentState EXCH1 -Component HubTransport -State Draining -Requester Maintenance
2. Microsoft zaleca restart usług transportowych. Wykonany to poleceniami:
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
3. Migracja wiadomości będących w trakcie realizacji z serwera EXCH1 na serwer EXCH2 (serwer docelowy musimy podać wraz z pełną nazwą domeny)
Redirect-Message -Server EXCH1 -Target EXCH2.domena.local
W przypadku gdy serwer nie jest członkiem DAG przechodzimy do p.8, w przeciwnym wypadku wykonujemy poniższe polecenia
4. Wstrzymaj węzeł DAG
Suspend-ClusterNode EXCH1
5. Zmigrowanie wszystkich aktywnych baz na inny serwer będący członkiem DAG
Set-MailboxServer EXCH1 -DatabaseCopyActivationDisabledAndMoveNow $True
6. Sprawdź status polityki automatycznej aktywacji bazy danych. Zanotuj go gdyż będzie potrzebny, gdy wyłączy się serwer z trybu konserwacji.
Get-MailboxServer EXCH1 | Select DatabaseCopyAutoActivationPolicy
W przypadku gdy polityka jest ustawiona na „Blocked” można pominąć punkt 7.
7. Zablokuj serwer przed hostowaniem aktywnych baz
Set-MailboxServer EXCH1 -DatabaseCopyAutoActivationPolicy Blocked
8. Wprowadź serwer w trym konserwacji
Set-ServerComponentState EXCH1 -Component ServerWideOffline -State Inactive -Requester Maintenance
9. Zamykamy konsolę „Exchange Management Shell” i uruchamiamy instalator CU w trybie administratora. Przechodzimy kolejne kroki. Cierpliwie czekamy na wykonanie wszystkich zadań – instalator może się zatrzymać na dłużej przy kilkunastu %.
Po zakończonej instalacji, uruchamiamy konsolę „Exchange Management Shell” w trybie administratora i wykonujemy kolejne kroki.
W przypadku gdy serwer nie jest członkiem DAG wykonujemy kroki 10, 14 i 15.
10. Wyłączenie trybu konserwacji
Set-ServerComponentState EXCH1 -Component ServerWideOffline -State Active -Requester Maintenance
11. Uruchamiamy węzeł DAG
Resume-ClusterNode EXCH1
12. Zezwalamy na aktywację kopii bazy danych na serwerze
Set-MailboxServer EXCH1 -DatabaseCopyActivationDisabledAndMoveNow $False
13. Przywrócenie pierwotnej polityki automatycznej aktywacji baz danych (odczytanej w p.6). Jeśli pierwotnie ustawiona była na „Blocked” pozostaw ją w tym stanie tzn. pomiń poniższe polecenie. Domyślnie polityka ustawiona jest na Unrestricted
Set-MailboxServer EXCH1 -DatabaseCopyAutoActivationPolicy Unrestricted
14. Ustaw komponenty transportowe w tryb aktywny aby mogły przyjmować połączenia.
Set-ServerComponentState EXCH1 -Component HubTransport -State Active -Requester Maintenance
15. Microsoft zaleca restart usług transportowych, aby ta zmiana została natychmiast wykonana.
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport
Jeśli serwer jest członkiem DAG i zmigrowaliśmy z niego wszystkie aktywne bazy, możemy w prosty sposób rozłożyć je automatycznie wykorzystując ustawione preferencje poprzez wykonanie skryptu RedistributeActiveDatabases.ps1 dostarczonego przez Microsoft wraz z instalacją serwera Exchange
C:\Program Files\Microsoft\Exchange Server\V15\Scripts> .\RedistributeActiveDatabases.ps1 -BalanceDbsByActivationPreference -Confirm:$false
Po wykonaniu powyższych czynności serwer został zaktualizowany.
W przypadku gdy mamy większą ilość serwerów Exchange kolejno aktualizujemy wszystkie serwery w powyższy sposób. Aktualizacja jednego z serwerów może potrać nawet 3-4 godziny więc na przeprowadzenie aktualizacji całego środowiska Exchange należy zaplanować odpowiednią ilość czasu.