Przywracanie i odzyskiwanie uszkodzonego lokalnego kontrolera domeny

Gdy kontroler domeny ulegnie uszkodzeniu lub zostanie nieprawidłowo przywrócony, strach jest ogromny: Logowania kończą się niepowodzeniem, obiekty GPO przestają być stosowane, a replikacja przestaje działać praktycznie bez żadnych oznak.Dobra wiadomość jest taka, że ​​istnieją jasne procedury odzyskiwania fizycznego lub wirtualnego centrum danych, pod warunkiem przestrzegania akceptowanych metod tworzenia kopii zapasowych i przywracania.

W nowoczesnych środowiskach Windows Server przywrócenie kontrolera domeny wymaga dobrego zrozumienia takich pojęć, jak: stan systemu, przywracanie autorytatywne/nieautorytatywne, wycofywanie SYSVOL, DFSR/FRS i USNJeśli problemy te zostaną rozwiązane pochopnie lub przy użyciu niekompatybilnych narzędzi obrazowania, efektem może być las ukrytych nieścisłości, które bardzo trudno zdiagnozować.

Dlaczego tak ważne jest prawidłowe zabezpieczenie i odzyskanie kontrolera domeny

Usługa Active Directory stanowi serce uwierzytelniania i autoryzacji w domenie WindowsPrzechowuje użytkowników, komputery, grupy, relacje zaufania, zasady grupowe, certyfikaty i inne kluczowe elementy. Informacje te znajdują się głównie w bazie danych. Ntds.dit, powiązane pliki dziennika i folder SYSVOL, wśród innych komponentów składających się na tzw. „stan systemu”.

Stan systemu obejmuje m.in.: Pliki dziennika i dane usługi Active Directory, rejestr systemu Windows, wolumin systemowy, SYSVOL, baza danych certyfikatów (jeśli istnieje urząd certyfikacji), metabaza usług IIS, pliki rozruchowe i chronione komponenty systemu operacyjnegoDlatego też każda poważna strategia ciągłości działania przedsiębiorstwa musi uwzględniać regularne tworzenie kopii zapasowych stanu systemu każdego centrum danych.

W przypadku rzeczywistego uszkodzenia bazy danych Active Directory, poważnego błędu replikacji lub problemu z uprawnienia na SYSVOLKontroler domeny może przestać przetwarzać zapytania, nie uruchomić usług Active Directory lub wywołać kaskadowe błędy w całym lesie. W takich przypadkach Szybka i właściwa pomoc może decydować o tym, czy poważny incydent stanie się długotrwałą katastrofą..

Przed podjęciem próby przywrócenia danych kluczowe jest rozróżnienie między rzeczywistym problemem z bazą danych a bardziej przyziemnymi awariami. Bardzo często Przyczyną jest DNS, zmiany w sieci, zapory sieciowe lub trasy zmodyfikowane za pomocą narzędzi takich jak polecenie netshDlatego też zaleca się wykluczenie tych czynników przed przystąpieniem do pracy z bazą danych AD.

Podstawowe narzędzia diagnostyczne i kontroli replikacji

W przypadku wystąpienia symptomów uszkodzenia lub błędów replikacji, pierwszym rozsądnym krokiem jest sprawdzenie stanu środowiska przy użyciu narzędzi natywnych. DCDiag, Repadmin, ReplMon (w starszych wersjach) i Podgląd zdarzeń Są Twoimi najlepszymi sprzymierzeńcami, zanim zdecydujesz się na drastyczne renowacje.

z Diagnoza DC Przeprowadzana jest ogólna kontrola wszystkich kontrolerów domeny w celu zidentyfikowania problemów z replikacją, DNS, usługami AD DS itp. Repadmin Umożliwia przeglądanie statusu replikacji, partnerów replikacji, znaków wodnych USN i wykrywanie obiektów trwałych. W starszych wersjach systemu Windows ReplMon Oferuje graficzny podgląd błędów replikacji w obrębie domeny.

Oprócz tych narzędzi, konieczne jest sprawdzenie Podglądu zdarzeń dla „Usług katalogowych” i „Replikacji DFS”. Zdarzenia takie jak 467 i 1018 wskazują na faktyczne uszkodzenie bazy danych, podczas gdy zdarzenia 1113/1115/1114/1116 dotyczą włączania lub wyłączania replikacji wejścia/wyjścia.

Jeśli podejrzany DC musi zostać tymczasowo odizolowany, aby zapobiec rozprzestrzenianiu się korupcji, możemy Wyłącz replikację przychodzącą i wychodzącą za pomocą Repadmin:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Aby przywrócić replikację do normy, wystarczy usunąć te opcje:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Obsługiwane kopie zapasowe stanu systemu na kontrolerach domeny

Aby móc odzyskać DC z gwarancjami, niezbędne jest posiadanie Kopie zapasowe stanu systemu wykonywane przy użyciu narzędzi zgodnych z Active DirectoryNarzędzia te wykorzystują interfejsy API firmy Microsoft do tworzenia kopii zapasowych i przywracania danych oraz usługę kopiowania woluminów w tle (VSS) w obsługiwany sposób.

Do najpopularniejszych rozwiązań należą: Kopia zapasowa systemu Windows Server, rozwiązania innych firm zintegrowane z usługą VSS (takie jak NAKIVO, Backup Exec i inne)lub starsze narzędzia, takie jak Kopia zapasowa w systemach Windows 2000/2003. We wszystkich przypadkach muszą one respektować interfejsy API usługi Active Directory, aby zapewnić spójność bazy danych i jej replik po przywróceniu.

W systemie Windows Server 2012 i nowszych wersjach wprowadzono ważną nową funkcję: Identyfikator generacji Hyper-V (GenID)Ten identyfikator pozwala wirtualnemu kontrolerowi domeny wykryć, że jego dysk został cofnięty do poprzedniego punktu w czasie. W takim przypadku Usługa AD DS generuje nowy identyfikator InvocationID i traktuje sytuację tak, jakby została przywrócona z pomyślnie wykonanej kopii zapasowej.powiadamiając partnerów replikacji, co pozwala na bezpieczne przepisywanie bez konieczności cofnięcia numeru USN.

Ważne jest, aby szanować żywotność nagrobkaWskazuje, jak długo można korzystać z kopii zapasowej stanu systemu bez ryzyka ponownego wprowadzenia obiektów usuniętych dawno temu. W nowoczesnych wersjach jest to zazwyczaj 180 dni, a zaleca się wykonywanie kopii zapasowych co najmniej co 90 dni, aby zachować odpowiedni margines bezpieczeństwa.

Nieautoryzowane metody powodujące odwrócenie USN

Jedną z najniebezpieczniejszych przyczyn ukrytych niespójności w usłudze Active Directory jest Wycofanie USNTaka sytuacja ma miejsce, gdy zawartość bazy danych AD zostanie wycofana przy użyciu nieobsługiwanej techniki, bez przywrócenia identyfikatora InvocationID lub powiadomienia partnerów replikacji.

Typowy scenariusz polega na uruchomieniu kontrolera domeny z obraz dysku lub migawki maszyny wirtualnej wykonanej w przeszłościbez użycia kompatybilnego przywracania systemu. Możesz też skopiować plik Ntds.dit bezpośrednio, użyć programów do tworzenia obrazów, takich jak Ghost, uruchomić system z uszkodzonego lustra dysku lub ponownie utworzyć migawkę pamięci masowej na poziomie macierzy.

W takich przypadkach kontroler domeny nadal używa tego samego identyfikatora wywołania co poprzednio, ale jego Lokalny licznik USN działa wsteczPozostałe kontrolery domeny pamiętają otrzymywanie zmian aż do wysokiego USN, więc gdy przywrócony kontroler domeny próbuje odesłać już rozpoznane USN, Ich partnerzy uważają, że są na bieżąco i przestają akceptować konkretne zmiany.

W rezultacie pewne modyfikacje (np. tworzenie użytkowników, zmiana hasła, rejestracja urządzenia, zmiany członkostwa w grupie, nowe rekordy DNSTe błędy nigdy nie są replikowane z przywróconego kontrolera domeny do reszty sieci, ale narzędzia monitorujące mogą nie wskazywać wyraźnych błędów. To niezwykle niebezpieczna, ukryta awaria.

Aby wykryć takie sytuacje, sterowniki systemu Windows Server 2003 SP1 i nowszych rejestrują Zdarzenie usług katalogowych 2095 Gdy zdalny kontroler domeny zostanie wykryty i wyśle ​​już potwierdzone numery USN bez zmiany identyfikatora wywołania, system Poddaje kwarantannie dotknięty problem kontroler domeny, wstrzymuje działanie usługi Netlogon i zapobiega wprowadzaniu dalszych zmian. którego nie dało się poprawnie odtworzyć.

Jako dodatkowy dowód kryminalistyczny może do konsultacji w Rejestrze klucz HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters i wartość DSA nie do zapisuJeżeli ta wartość jest ustawiona (np. 0x4), oznacza to, że kontroler został wprowadzony w stan „no-write” przez wykrycie odwrócenia numeru USN. Ręczna modyfikacja tej wartości w celu jej „naprawienia” jest całkowicie nieobsługiwana. i pozostawia bazę danych w stanie trwale niespójnym.

Ogólne strategie na wypadek uszkodzenia lub przywrócenia kontrolera domeny

Procedura postępowania w przypadku uszkodzonego lub nieprawidłowo przywróconego kontrolera domeny zależy od kilku czynników: Liczba kontrolerów domeny w domenie/lesie, dostępność prawidłowych kopii stanu systemu, obecność innych ról (FSMO, CA, katalog globalny) i zakres czasowy problemu.

Jeśli w domenie znajdują się inne zdrowe DC i Brak unikalnych danych krytycznych na temat uszkodzonego kontrolera domenyNajszybszą i najczystszą opcją jest zazwyczaj usunięcie tego kontrolera domeny i jego odbudowa. Jeśli jednak jest to jedyny kontroler domeny lub hostuje on poufne role i dane, konieczne będzie dokładniejsze przywrócenie (autorytatywne lub nieautorytatywne).

Ogólnie rzecz biorąc, opcje są następujące:

• Przymusowo zdegraduj uszkodzony kontroler domeny i usuń go z domeny, a następnie czyszczenie metadanych i, jeśli to możliwe, nowa promocja.
• Przywróć z prawidłowej kopii zapasowej stanu systemu, niezależnie od tego, czy w trybie autorytatywnym, czy nieautorytatywnym.
• Odbudowa kontrolera domeny z innego urządzenia przy użyciu IFM (instalacja z nośnika), gdy nie ma żadnej aktualnej kopii, ale są inne poprawne DC.
• Korzystanie z migawki VHD wirtualnego kontrolera domeny, stosując dodatkowe kroki w celu oznaczenia bazy danych jako przywróconej z kopii zapasowej (Baza danych przywrócona z kopii zapasowej = 1) i upewniając się, że wygenerowany został nowy identyfikator InvocationID.

Jeśli istnieje wyraźne podejrzenie wycofania numeru USN (na przykład po przywróceniu maszyny wirtualnej z migawki bez zastosowania się do najlepszych praktyk) i pojawi się zdarzenie 2095, najrozsądniejszym sposobem działania jest zazwyczaj Wyłącz ten DC z użytku i nie próbuj go „naprawiać” na miejscu., chyba że można powrócić do kopii zapasowej obsługiwanego stanu systemu wykonanej przed wycofaniem.

Przymusowe obniżenie poziomu i czyszczenie metadanych

Jeśli kontroler domeny jest tak uszkodzony, że nie można go obniżyć w normalny sposób lub został nieprawidłowo przywrócony i chcesz zapobiec rozprzestrzenianiu się problemów, możesz skorzystać z przymusowa degradacja.

W starszych wersjach operację tę wykonywano za pomocą dcpromo /forceremoval, co Usuń rolę AD DS bez próby replikowania zmian w pozostałej części lasu.W nowoczesnych środowiskach kreator uległ zmianie, ale koncepcja jest ta sama: usunąć problematyczny kontroler domeny z topologii AD bez angażowania go w dalszą replikację.

Po wymuszonym obniżeniu wersji konieczne jest wykonanie polecenia ze sprawnego kontrolera domeny. czyszczenie metadanych za pomocą narzędzia NtdsutilTen proces usuwa wszystkie odwołania do usuniętego kontrolera domeny (obiekty ustawień NTDS, odwołania DNS itp.) z bazy danych AD, dzięki czemu nie pozostały żadne „duchowe” pozostałości, które mogłyby utrudnić replikację.

Jeżeli zdegradowany kontroler miał role FSMO (emulator PDC, RID Master, Schema Master itd.), konieczne będzie przenieść lub przejąć te role do innego kontrolera domeny przed lub po degradacji, w zależności od sytuacji. Później system operacyjny można ponownie zainstalować na tym serwerze i przywrócić go do stanu czystego kontrolera domeny.

Przywracanie autorytatywne i nieautorytatywne w usłudze Active Directory

Gdy dostępna jest prawidłowa kopia stanu systemu, odzyskiwanie danych z usługi AD można przeprowadzić na dwa sposoby: nieautorytatywne i autorytatywneZrozumienie tej różnicy jest kluczowe, aby nie przegapić ostatnich zmian ani nie powielać nieaktualnych danych.

W jednym przywrócenie nieautorytatywneDC wraca do poprzedniego punktu, ale po uruchomieniu, Pozostałe kontrolery domeny są uważane za referencyjneInnymi słowy, po uruchomieniu przywrócony kontroler domeny żąda replikacji przychodzącej i aktualizuje swoją bazę danych o wszelkie brakujące zmiany z innych kontrolerów domeny. Ta opcja jest idealna, gdy Istnieją również inne zdrowe kontrolery i chcemy, aby ten, który odzyskał sprawność, dogonił ich..

W jednym restauracja autorytarnaJednakże wyraźnie stwierdzono, że Powinny obowiązywać przywrócone dane. nad tym, co mają inne kontrolery domeny. Oznacza to, że po przywróceniu odzyskane obiekty będą miały wyższy numer wersji, co wymusi ich replikację z tego kontrolera domeny do reszty domeny. Jest to właściwy wybór, gdy Przypadkowo usunęliśmy obiekty lub jednostki organizacyjne albo chcemy przywrócić zawartość SYSVOL i GPO do poprzedniego stanu i zreplikować ją..

Ważnym szczegółem jest to, że przywracanie autorytatywne nie musi koniecznie dotyczyć całej bazy danych. Dzięki narzędziu Ntdsutil Poszczególne obiekty, poddrzewa (np. jednostka organizacyjna) lub cała domena mogą być oznaczone jako autorytatywne. Zapewnia to znaczną elastyczność, na przykład w przypadku pobierz tylko użytkownika, grupę, jednostkę organizacyjną lub poddrzewo dc=mycompany,dc=local.

Ogólna procedura przywracania stanu systemu w centrum danych

Podstawowy schemat przywracania stanu systemu DC (fizycznego lub wirtualnego) przy użyciu kompatybilnych narzędzi jest zawsze podobny: Uruchom w trybie przywracania usług katalogowych (DSRM), przywróć za pomocą narzędzia do tworzenia kopii zapasowych i uruchom ponownie.

Podsumowując, typowe kroki dla wirtualnego kontrolera domeny wyglądają następująco:

1. Uruchom maszynę wirtualną w Menedżerze rozruchu systemu Windows (zwykle poprzez naciśnięcie klawisza F5/F8 podczas uruchamiania). Jeśli maszyna wirtualna jest zarządzana przez hiperwizor, może być konieczne wstrzymanie działania maszyny w celu zarejestrowania naciśnięcia klawisza.
2. W zaawansowanych opcjach rozruchu wybierz Tryb przywracania usług katalogowych (Tryb przywracania usług katalogowych). Ten tryb uruchamia serwer bez funkcjonalnego montowania bazy danych Active Directory.
3. Zaloguj się na konto administratora DSRM zdefiniowano podczas pierwotnej promocji DC (nie przy użyciu standardowego konta administratora domeny).
4. Uruchom narzędzie do tworzenia kopii zapasowych używany (Windows Server Backup, NAKIVO lub inny kompatybilny) i wybierz przywrócenie stanu systemu do żądanego punktu kopii zapasowej.
5. Ukończ kreatora przywracania i Uruchom ponownie DC w trybie normalnymW przypadku przywracania nieautorytatywnego serwer zainicjuje replikację, aby nawiązać kontakt z innymi kontrolerami domeny.

Kiedy mówimy o produktach do tworzenia kopii zapasowych innych firm, takich jak Kopia zapasowa i replikacja NAKIVOJego tryb „z uwzględnieniem aplikacji” potrafi rozpoznać, że odzyskiwana maszyna jest kontrolerem domeny i automatycznie dostosowuje proces, aby zachować spójność ADW większości scenariuszy z wieloma kontrolerami wystarczające jest pełne odzyskiwanie w trybie nieautorytatywnym.

Autorytatywne przywracanie za pomocą Ntdsutil

Jeśli chcesz, aby zmiany wprowadzone na przywróconym kontrolerze domeny miały pierwszeństwo przed pozostałymi, musisz dodać dodatkowy krok po przywróceniu nieautorytatywnym: użyj Ntdsutil do oznaczenia obiektów jako autorytatywnych.

Uproszczony przepływ wyglądałby następująco:

1. Przywróć stan systemu w standardowy sposób i pozostaw serwer nadal w stanie aktywnym. Tryb DSRM (Nie uruchamiaj jeszcze ponownie w trybie normalnym).
2. Otwórz wiersz poleceń z podwyższonymi uprawnieniami i biegnij ntdsutil.
3. Aktywuj instancję AD za pomocą aktywuj instancję ntds.
4. Wejście w kontekst autorytatywnej restauracji z autorytatywne przywrócenie.
5. Użyj poleceń takich jak restore object <DN_objeto> o restore subtree <DN_subarbol>, gdzie DN jest wyróżniającą nazwą obiektu lub poddrzewa, który ma zostać autorytatywnie przywrócony.
6. Potwierdź transakcję i po jej zakończeniu Uruchom ponownie DC w trybie normalnym tak aby oznaczone obiekty były replikowane w pierwszej kolejności w stosunku do reszty domeny.

Ten rodzaj renowacji wymaga dużej ostrożności. Jeśli cała domena zostanie autorytatywnie przywrócona, a kopia zapasowa jest staraIstnieje ryzyko utraty legalnych zmian wprowadzonych po utworzeniu kopii zapasowej (na przykład utworzenia użytkownika, zmiany hasła lub modyfikacji grup). Dlatego powszechną praktyką jest ograniczanie przywracania autorytatywnego tylko do niezbędnych obiektów lub drzew.

Przywracanie i odzyskiwanie SYSVOL (FRS vs DFSR)

SYSVOL jest kluczowym komponentem kontrolera domeny: Przechowuje skrypty startowe, zasady grupy, szablony zabezpieczeń i inne ważne współdzielone zasoby.Awaria uprawnień, uszkodzenie pliku lub problemy z replikacją mogą sprawić, że obiekty GPO staną się bezużyteczne lub będą powodować nieprawidłowe działanie klientów.

W zależności od wersji systemu Windows Server i stanu migracji, SYSVOL może zostać zreplikowany przez FRS (Usługa replikacji plików) dlaczego DFSR (replikacja rozproszonego systemu plików)Procedura autorytatywnego przywracania folderu SYSVOL różni się w zależności od tego, która z dwóch opcji jest używana.

Aby to ustalić, możesz sprawdzić klucz w Rejestrze. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateJeśli ten podklucz istnieje i jego wartość wynosi 3 (USUNIĘTO), używany jest DFSR. Jeśli nie istnieje lub jego wartość jest inna, mamy do czynienia ze środowiskiem, które nadal korzysta z FRS.

W środowiskach z FRS autorytatywne odzyskiwanie SYSVOL zwykle wiąże się z dostosowaniem wartości Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process do określonej wartości (np. 212 dziesiętnie / 0xD4 szesnastkowo), aby wskazać, że dany kontroler domeny jest źródłem autorytatywnym.

Jeżeli SYSVOL jest replikowany przez DFSR, proces jest nieco bardziej złożony: polega na użyciu ADSIEdit aby zmodyfikować obiekty subskrypcji SYSVOL (atrybuty msDFSR-Włączony y Opcje msDFSR) na autorytatywnym kontrolerze domeny i na pozostałych, wymusić replikację AD, wykonać dfsrdiag pollad i potwierdź w dzienniku zdarzeń pojawienie się wydarzenia 4114, 4602, 4614 i 4604 które potwierdzają, że SYSVOL został poprawnie zainicjowany i zreplikowany.

Odzyskiwanie wirtualnych kontrolerów domeny z dysku VHD

W środowiskach zwirtualizowanych bardzo często zdarza się, że Pliki VHD/VHDX kontrolerów domenyJeśli nie masz kopii zapasowej stanu systemu, ale dysponujesz działającym „starym” dyskiem VHD, możesz zamontować nowy kontroler domeny z tego dysku, choć musisz to zrobić bardzo ostrożnie, aby nie spowodować wycofania numeru USN.

Zalecenie to Nie uruchamiaj tej maszyny wirtualnej bezpośrednio w trybie normalnymZamiast tego należy uruchomić komputer z poprzedniego dysku VHD DSRMOtwórz Edytor rejestru i przejdź do HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersTam wskazane jest sprawdzenie wartości Liczba poprzednich restauracji DSA (jeśli istnieje) i przede wszystkim utwórz nową wartość DWORD (32-bitową) o nazwie Baza danych przywrócona z kopii zapasowej o wartości 1.

Wybierając tę ​​wartość, usługa Active Directory zostanie poinformowana, że ​​baza danych została przywrócona z kopii zapasowej, co wymusi generowanie nowego InvocationID podczas rozruchu w trybie normalnymW ten sposób pozostałe kontrolery domeny interpretują je jako nową instancję i prawidłowo dostosowują swoje znaki wodne replikacji, zapobiegając wycofaniu numeru USN.

Po ponownym uruchomieniu kontrolera domeny w trybie normalnym zaleca się sprawdzenie Podglądu zdarzeń, a w szczególności dziennika zdarzeń usługi katalogowe, szukam wydarzenie 1109To zdarzenie potwierdza zmianę atrybutu InvocationID serwera i wyświetla stare i nowe wartości, a także najwyższy numer USN w momencie tworzenia kopii zapasowej. Dodatkowo wartość Liczba poprzednich restauracji DSA Należało zwiększyć ją o jeden.

Jeżeli te zdarzenia nie występują lub ich liczba nie wzrasta, należy sprawdzić wersje systemu operacyjnego i pakiety Service Pack, ponieważ Niektóre zachowania przywracania zależą od konkretnych poprawekW każdym razie zawsze zaleca się pracę na kopii oryginalnego dysku VHD i zachowanie nienaruszonej wersji na wypadek, gdyby zaszło konieczność powtórzenia procesu.

Scenariusze praktyczne i dodatkowe zalecenia

W praktyce problemy korupcji lub niewłaściwych napraw często pojawiają się w codziennych sytuacjach: Ręczne modyfikacje uprawnień w SYSVOL, próby aktualizacji szablonów ADMX/ADML, zmiany w GPO, które nie są replikowaneitp. Dość łatwo jest spowodować niespójności, jeśli foldery współdzielone są modyfikowane ręcznie, np. SYSVOL\Policies bez poszanowania replikacji.

W przypadku podstawowego kontrolera domeny z uszkodzoną replikacją (zarówno danych AD, jak i SYSVOL) i monitorujących wiadomości typu „Baza danych została przywrócona przy użyciu nieobsługiwanej procedury. Możliwa przyczyna: wycofanie numeru USN.„Rozsądnie jest postąpić tak:

• Sprawdź z dcdiag y ponownie zakres błędów i czy występują „trwałe obiekty”.
• Sprawdź zdarzenie 2095 i jego wartość DSA nie do zapisu w Rejestrze.
• Oceń, czy to możliwe usuń ten DC i odbuduj go (Jeśli są trzy lub więcej zdrowych komórek DC, to zazwyczaj jest to najlepsze rozwiązanie).
• Jeśli to jedyny DC lub krytyk, zgłoś przywracanie stanu systemu ze zgodnej kopii zapasowej, najlepiej niedawnej i z okresu, w którym została utworzona.

W domenach z wieloma kontrolerami zdecydowanie zaleca się, aby kontrolery domeny były jak najbardziej „czyste”: bez dodatkowych ról lub lokalnych danych użytkownikaW ten sposób, jeśli jeden z nich ulegnie awarii lub uszkodzeniu, można sformatować i promować nowy na podstawie innego kontrolera domeny lub za pośrednictwem IFM, co znacznie upraszcza proces odzyskiwania.

Warto ponadto pamiętać o ograniczeniach takich jak: Kopie stanu systemu są ważne tylko w okresie przechowywania (60, 90, 180 dni w zależności od konfiguracji), aby uniknąć przywracania usuniętych obiektów, a klucze maszynowe NTLM zmieniają się co 7 dni. W przypadku przywracania bardzo starych danych może być konieczne zresetuj konta zespołu problemów z „Użytkownikami i komputerami usługi Active Directory”, a nawet ich usuwania i ponownego dołączania do domeny.

Posiadanie procedur umożliwiających regularne tworzenie kopii zapasowych stanu systemu, Jasno udokumentuj role FSMO, katalog globalny i topologię replikacjiTestowanie kroków przywracania danych w warunkach laboratoryjnych to inwestycja czasu, która pozwala uniknąć wielu problemów, gdy nadejdzie dzień, w którym kontroler domeny ulegnie uszkodzeniu lub ktoś bez namysłu utworzy migawkę.