Virtual Study

21 czerwca 2016

CU2 dla Exchange 2016 - zmiany w DAG

Microsoft właśnie wydał paczki poprawek - Exchange Server 2016 Cumulative Update 2 and Exchange Server 2013 Cumulative Update 13. Obie paczki oprócz usunięcia kilku błędów funkcjonalnych zapewniają wsparcie dla .Net Framework 4.6.1, którego udostępnienie na Windows Update jako rekomendowana aktualizacja, wprowadziło sporo problemów, o czym pisałem niedawno. Inna pożyteczna i potrzebna zmiana to wprowadzenie podpisu SHA-2 do certyfikatów wystawianych przez serwer Exchange (self-signed). Warto pamiętać, że część przeglądarek już niebawem zacznie blokować dostęp do stron zabezpieczonych certyfikatem z SHA-1.
W przypadku Exchange 2016 zaszło również kilka zmian w cmdletach - scalenie ról CAS i Mailbox powoduje w przypadku niektórych poleceń wygenerowanie ostrzeżeń o zmianie funkcjonalności, jak na poniższym rysunku:

W CU2 wprowadzono zmiany, porządkujących zmiany w przypisaniu ról do serwerów.
Przed CU2 informacja o rolach serwera wyglądała tak jak na rysunku z lewej, po instalacji CU zniknęła rola ClientAccess, jednak serwer jest nadal świadomy tej funkcjonalności (rysunek z prawej):
Kolejną ciekawą i dla wielu przydatną zmianą jest modyfikacja funkcjonalności DAG. Sześć i pół roku po wprowadzeniu funkcjonalności DAG, w końcu przypisywanie priorytetów do replik bazy danych zaczęło mieć sens. W trakcie tworzenia kolejnych replik bazy danych w ramach DAG nadajemy kolejnym replikom atrybut ActivationPreference z kolejnym numerem. Ale niestety, dotychczas trzeba było aktywować repliki zgodnie z naszymi preferencjami ręcznie lub poprzez uruchomienie skryptu - np. dostępnego na serwerach Exchange RedistributeActiveDatabases.ps1.
W Cumulative Update 2 zespół produktowy zmodyfikował działanie Primary Active Managera, czyli procesu koordynującego działanie replik baz danych w ramach DAG. Do właściwości DAG został dodany atrybut - PreferenceMoveFrequency, który określa z jaką częstotliwością są sprawdzane wartości ActivationPreference replik poszczególnych baz danych i Replication Service aktywuje odpowiednie repliki bazy zgodnie z wartościami ActivationPreference. Domyślną wartością jest jedna godzina, jednak jeżeli jest to dla nas niewygodne, możemy tą wartość zmienić wykonując komendę:
Set-DatabaseAvailabilityGroup -PreferenceMoveFrequency
Jeżeli z jakiegoś powodu nie chcemy stosować nowej funkcjonalności, musimy uruchomić komendę:
Set-DatabaseAvailabilityGroup -PreferenceMoveFrequency ([TimeSpan]::Zero)
Po restarcie usługi Replication Service automatyczne przełączanie zostanie wyłączone.
Funkcjonalność została dokładnie opisana w artykule na blogu zespołu produktowego.

Brak komentarzy: