Niestety, nie ma automatycznych mechanizmów pozwalających uchronić "administratora" przed tego typu skutkami. Dokonując operacji seize, system dostaje informację, że poprzedni kontroler domeny wraz ze wzorcem/wzorcami jest nieosiągalny i w założeniu nigdy już nie będzie osiągalny. Dlatego też typujemy jego następcę.

W trakcie samego procesu przejmowania roli/ról system nim dokona trwałego przeniesienia, mimo wszystko próbuje nawiązać kontakt z aktualnym kontrolerem przetrzymującym wzorzec i dokonać operacji "transfer" zamiast "seize". Gdy ta operacja się nie powiedzie, dopiero wtedy następuje trwałe przejęcie roli przez nowy kontroler domeny.

Pozwolę sobie podać odnośnik do artykułu o trwałym przenoszeniu ról FSMO na moim blogu (jest on w języku angielskim i mam nadzieję, że nie stanowi to kłopotu): http://kpytko.pl/active-directory-domain-services/seizing-fsmo-roles/, gdzie pokazany jest proces przenoszenia wzorców.

Problem, który wystąpi, to taki, iż każdy kontroler domeny posiada swoją własną bazę danych Active Directory, w której znajdują się wpisy identyfikujące jego samego. Jak wiesz, od czasu Active Directory opartego o Windows 2000 Server, baza Active Directory jest replikowana w trybie multi-master, co oznacza, że każdy DC posiada własną kopię w trybie do zapisu. Wszelkie zmiany są replikowane z innymi kontrolerami w środowisku, co może doprowadzić do problemu z niekonsystentnymi wpisami identyfikującymi serwer(y) wzorców.

Posłużę się przykładem opartym o RID Master. Gdy będziemy posiadać dwa takie serwery w jednej domenie i część kontrolerów identyfikować będzie nieprawidłowo ten wzorzec wskazując na serwer, który powinien być już usunięty, pula identyfikatorów może ulec nałożeniu i wówczas wystąpi problem z tworzeniem nowych obiektów Active Directory oraz dostępem do już istniejących ze względu na zduplikowane identyfikatory. Mogą wówczas pojawić się w bazie błędne obiekty, które będą wchodzić w konflikt w trakcie replikacji - pojawią się z identyfikatorem CNF: świadczącym o konflikcie replikacji obiektu.

Co do wzorca PDC Emulator, to jak wiemy jedną z jego istotnych funkcji jest tworzenie, modyfikacja Group Policy Objects. Każdorazowo, gdy tworzymy lub modyfikujemy politykę, jest ona wykonywana właśnie na serwerze będącym PDC. Gdy w bazie Active Directory pojawi się informacja o więcej niż jednym takim wzorcu, polityki mogą ulec nawet uszkodzeniu, a przede wszystkim w środowisku zrobi się bałagan, gdyż polityki będą się znajdować w różnych miejscach, powodując, że klienci mogą nie stosować zamierzonych przez administratora ustawień.

Co do pozostałych wzorców, konsekwencje również istnieją, lecz są trudniej wykrywalne, gdyż wzorce te są o wiele rzadziej wykorzystywane, co nie znaczy, że można przestać o nie dbać.

Mam nadzieję, że udało mi się trochę przybliżyć potencjalny problem.