Wirtualizacja kontrolerów domeny przy użyciu Hyper-V

System Windows Server 2012 lub nowszy obsługuje zwirtualizowane kontrolery domeny (DCs) z zabezpieczeniami, aby zapobiec wycofywaniu numeru sekwencji aktualizacji (USN) na wirtualnych kontrolerach domeny i możliwości klonowania wirtualnych kontrolerów domeny. Wirtualizacja konsoliduje różne role serwera na jednej maszynie fizycznej. Aby uzyskać więcej informacji, zobacz Safely virtualizing Active Directory Domain Services (AD DS).

W tym przewodniku opisano, jak uruchamiać DCs jako 32-bitowe lub 64-bitowe systemy operacyjne gościa.

Planowanie wirtualizacji

Poniższe sekcje zawierają zagadnienia dotyczące planowania, które należy znać podczas wirtualizacji kontrolera domeny, w tym wymagań sprzętowych, architektury, konfiguracji i zarządzania bezpieczeństwem i wydajnością.

wymagania dotyczące Hyper-V

Aby zainstalować i użyć roli Hyper-V, sprzęt musi spełniać następujące wymagania:

• Musisz mieć procesor x64.

• Procesor musi umożliwić włączenie funkcji wirtualizacji wspomaganej sprzętowo.

  • Zazwyczaj to ustawienie jest nazywane technologią Intel Virtualization Technology (Intel VT) lub advanced Micro Devices Virtualization (AMD-V).

• Procesor musi obsługiwać sprzętowe zabezpieczenie przed wykonywaniem danych (DEP).

  • Bitu Hyper-V można używać tylko po włączeniu bitu Intel Execute Disable (XD) lub bitu AMD No Execute (NX).

Unikaj pojedynczych punktów awarii

Podczas planowania wdrożenia wirtualnej infrastruktury DC należy przygotować strategię, aby uniknąć tworzenia pojedynczych punktów awarii. Można uniknąć wprowadzania potencjalnych pojedynczych punktów awarii lub obszarów, w których przestój może spowodować, że cały system przestanie działać, implementując nadmiarowość systemu.

Poniższe zalecenia mogą pomóc w zapobieganiu pojedynczym punktom awaryjnym. Należy jednak pamiętać, że przestrzeganie tych zaleceń może zwiększyć koszty administracyjne.

• Uruchom co najmniej dwie zwirtualizowane kontrolery domeny dla każdej domeny na różnych hostach wirtualizacji. Ta konfiguracja zmniejsza ryzyko utraty wszystkich DC, gdy host wirtualizacji przestanie działać.

• Zdywersyfikuj sprzęt obsługujący Twoje centra danych. Na przykład użyj różnych procesorów CPU, płyt głównych, kart sieciowych itd. Zróżnicowany sprzęt zapobiega uszkodzeniu urządzenia i awarii sprzętu lub konfiguracji dostawcy.

• Jeśli to możliwe, uruchom kontrolery domeny na sprzęcie znajdującym się w różnych regionach. Takie podejście zmniejsza konsekwencje awarii, które wpływają na jedną z witryn hostujących kontrolery domeny.

• Dodaj fizyczne kontrolery domeny do wszystkich swoich domen. Skonfigurowanie systemu z fizycznymi kontrolerami domeny zapobiega awariom platformy wirtualizacji na systemach hostów.

Zagadnienia dotyczące zabezpieczeń

Należy zarządzać komputerem hosta, na którym są uruchamiane wirtualne kontrolery domeny, tak dokładnie, jak w przypadku zapisywalnego kontrolera domeny, nawet jeśli komputer jest tylko komputerem przyłączonym do domeny lub grupy roboczej. To wymaganie jest ze względów bezpieczeństwa. Niegospodarne hosty są narażone na ataki z podwyższonym poziomem uprawnień, w których złośliwi użytkownicy uzyskują dostęp do wyższych uprawnień, niż powinni, ponieważ administrator przypisał niewłaściwy poziom uprawnień do przypisania roli niższego poziomu. Te ataki mogą naruszyć bezpieczeństwo wszystkich maszyn wirtualnych, domen i lasów hostowanych przez komputer, którego dotyczy problem.

Podczas planowania wirtualizacji kontrolera domeny należy pamiętać o następujących kwestiach dotyczących zabezpieczeń:

• Poświadczenia administratora lokalnego komputera, który hostuje wirtualne kontrolery domeny z możliwością zapisu danych, powinny być traktowane jako równorzędne domyślnemu administratorowi domeny wszystkich domen i lasów, do których należą te kontrolery domeny.

• Zalecamy skonfigurowanie systemu tak, aby host działał w oparciu o instalację Server Core systemu Windows Server, nie posiadając zainstalowanych aplikacji poza funkcją Hyper-V. Ta konfiguracja ogranicza liczbę aplikacji i serwerów instalowanych na serwerze. To ograniczenie skutkuje lepszą wydajnością systemu, a także tworzy ograniczonej powierzchni ataków, gdzie istnieje mniej punktów wejścia na złośliwe ataki za pośrednictwem aplikacji i usług.

• W przypadku oddziałów lub innych lokalizacji, które są trudne do zabezpieczenia, zalecamy użycie kontrolerów domeny tylko do odczytu (RODC). Jeśli masz oddzielną sieć zarządzania, zalecamy połączenie hosta tylko z siecią zarządzania. Aby uzyskać więcej informacji na temat kontrolerów RODC, zobacz Install a Windows Server Active Directory Active Directory Read-Only Domain Controller (RODC) (Poziom 200).

• Kontrolery domeny można zabezpieczyć BitLockerem. W systemie Windows Server 2016 lub nowszym można również użyć funkcji wirtualnego modułu TPM (Trusted Platform Module), która udostępnia materiał klucza do systemu dla gościa, wymagany do odblokowania woluminu systemowego.

• Chroniona tkanina i chronione maszyny wirtualne mogą udostępniać inne zabezpieczenia w celu ochrony kontrolerów domeny.

Aby uzyskać więcej informacji na temat zabezpieczania kontrolerów domeny, zobacz przewodnik Najlepsze praktyki dotyczące zabezpieczania instalacji usługi Active Directory.

Granice zabezpieczeń dla konfiguracji hosta i gościa

Maszyny wirtualne można zaimplementować na wielu różnych typach konfiguracji centrum danych. W związku z tym należy dokładnie rozważyć, jak te maszyny wirtualne wpływają na granice i relacje zaufania w topologii usługi Active Directory. Na poniższej liście opisano dwie konfiguracje do skonfigurowania dla kontrolerów domeny Active Directory i hostów na serwerze Hyper-V oraz komputerów gościa będących maszynami wirtualnymi działającymi na serwerze Hyper-V.

• Host będący komputerem w grupie roboczej lub członkiem domeny z gościem, który jest kontrolerem domeny.
• Host, który jest grupą roboczą lub komputerem członkowskim z gościem, który jest również grupą roboczą lub komputerem członkowskim.

Na poniższym diagramie przedstawiono konfigurację trzech gościnnych maszyn wirtualnych kontrolera domeny hostowanych na serwerze Hyper-V.

Diagram przykładowego wdrożenia trzech maszyn wirtualnych i serwera Hyper-V. Trzy maszyny wirtualne znajdują się wewnątrz niebieskiego prostokąta oznaczonego jako "maszyny-gościa". Wszystkie trzy maszyny wirtualne są kontrolerami domeny. Maszyna wirtualna 1 znajduje się w domenie Corp i w lesie Contoso.com. Maszyna wirtualna VM2 znajduje się w domenie Fabrikam i lesie domenowym Fabrikam.com. Maszyna wirtualna 3 znajduje się w domenie HQ i lesie Fineartschool.net. Serwer Hyper-V znajduje się poza niebieskim prostokątem. Jest to serwer członkowski znajdujący się w domenie Corp i lesie Contoso.com.

Na podstawie przykładowej konfiguracji na poprzednim diagramie poniżej przedstawiono kilka ważnych kwestii, które należy wziąć pod uwagę podczas planowania wdrożenia w następujący sposób:

• Dostęp administratora

  • Poświadczenia administratora na komputerze hosta powinny być traktowane tak samo jak poświadczenia administratora domeny na zapisywalnym kontrolerze domeny. W przypadku gościa RODC poświadczenia administratora komputera hosta powinny być traktowane tak samo, jak poświadczenia administratora lokalnego na RODC gościa.

• Uprawnienia administracyjne kontrolera domeny na komputerze hosta

  • Administrator zwirtualizowanego centrum danych ma uprawnienia administracyjne na hoście, jeśli przyłączysz hosta do tej samej domeny. Jednak to uprawnienie dostępu może również dać złośliwym użytkownikom możliwość naruszenia zabezpieczeń wszystkich maszyn wirtualnych, jeśli mogą uzyskać dostęp do maszyny wirtualnej 1. Ten scenariusz tworzy możliwy wektor ataku. Można zapobiec temu wektorowi ataków, upewniając się, że wszystkie kontrolery domeny skonfigurowane dla wielu domen lub lasów mają scentralizowaną domenę administracyjną zaufaną przez wszystkie domeny i sprawić, że host wirtualizacji będzie członkiem domeny administracyjnej o wysokim poziomie uprawnień. Takie podejście uniemożliwia poszczególnym administratorom domeny kontrolowanie hosta, a tym samym innych domen.

• Unikanie ataków

  • Złośliwi użytkownicy mogą atakować maszynę wirtualną 1, nawet jeśli zainstalujesz ją jako kontroler RODC. Mimo że administratorzy RODC nie mają jawnie uprawnień administratora domeny, nadal mogą używać RODC do wdrażania zasad na komputerze hosta. Te zasady mogą obejmować na przykład skrypty uruchamiania. Jeśli osoba atakująca znajdzie sposób na uzyskanie praw administratora kontrolera RODC i wyśle politykę ze złośliwym skryptem uruchamiania, może zagrozić bezpieczeństwu komputera hosta i wykorzystać go do kompromitacji innych maszyn wirtualnych na hoście.

• Zabezpieczenia plików wirtualnego dysku twardego (VHD)

  • Pliki VHD wirtualnego kontrolera domeny są podobne do fizycznego dysku twardego fizycznego kontrolera domeny. Należy zachować ostrożność podczas zabezpieczania pliku VHD tak samo jak w przypadku dysku twardego. Upewnij się, że zezwalasz tylko niezawodnym i zaufanym administratorom na dostęp do tych plików VHD.

• Kontrolery RODC

  • Kontrolery RODC można umieścić w lokalizacjach, w których bezpieczeństwo fizyczne nie jest gwarantowane, na przykład w oddziałach. Pliki VHD można chronić przy użyciu szyfrowania dysków funkcją BitLocker systemu Windows przed atakami na hosta z udziałem kradzieży dysku fizycznego. Jednak te zabezpieczenia nie mają zastosowania do systemów plików wewnątrz kontrolera RODC.

Zagadnienia dotyczące wydajności

Architektura 64-bitowa Mikrokernel zapewnia lepszą Hyper-V wydajność w porównaniu z poprzednimi platformami wirtualizacji.

Wydajność maszyny wirtualnej zależy od obciążenia, którego używasz. Zalecamy przetestowanie określonych topologii maszyn wirtualnych, aby upewnić się, że wydajność wdrożenia usługi Active Directory jest satysfakcjonująca. Wydajność można ocenić w ramach obciążeń w określonym przedziale czasu przy użyciu narzędzi takich jak Monitor niezawodności i wydajności (Perfmon.msc) lub zestawu narzędzi Microsoft Assessment and Planning (MAP). Narzędzie MAP może również pomóc w spisie wszystkich serwerów i ról serwera znajdujących się obecnie w sieci.

Aby przedstawić ideę, jak działa testowanie wydajności zwirtualizowanego kontrolera domeny, utworzyliśmy przykładowy test wydajnościowy przy użyciu narzędzia Active Directory Performance Testing Tool (ADTest.exe).

Testy protokołu LDAP (Lightweight Directory Access Protocol) zostały przeprowadzone na fizycznym kontrolerze domeny przy użyciu ADTest.exe. Te same testy były uruchamiane na zwirtualizowanym kontrolerze domeny, który składał się z maszyny wirtualnej hostowanej na serwerze identycznym z fizycznym kontrolerem domeny. W tym przykładzie użyto tylko jednego procesora logicznego dla komputera fizycznego i tylko jednego procesora wirtualnego dla maszyny wirtualnej. Ta konfiguracja umożliwiła łatwe osiągnięcie pełnego 100-procentowego wykorzystania procesora.

W poniższej tabeli wymieniono wyniki testów dla fizycznych i wirtualnych kontrolerów domeny (DC). Litery i cyfry w nawiasach obok nazw testów są ich oznaczeniami w ADTest.exe. Te dane pokazują, że zwirtualizowana wydajność kontrolera domeny wynosiła od 88 do 98 procent wydajności fizycznego kontrolera domeny.

Miara	Testowanie	Fizyczny	Wirtualny	Delta
Wyszukiwania na sekundę	Wyszukaj nazwę pospolitą w zakresie podstawowym (L1)	11508	10276	-10.71%
Wyszukiwania na sekundę	Wyszukiwanie zestawu atrybutów w zakresie podstawowym (L2)	10123	9005	-11.04%
Wyszukiwania na sekundę	Wyszukaj wszystkie atrybuty w zakresie podstawowym (L3)	1284	1242	-3,27%
Wyszukiwania na sekundę	Wyszukaj nazwę pospolitą w zakresie poddrzewa (L6)	8613	7904	-8,23%
Pomyślne wiązania na sekundę	Wykonaj szybkie powiązania (B1)	1438	1374	-4.45%
Pomyślne wiązania na sekundę	Wykonywanie prostych powiązań (B2)	611	550	-9,98%
Pomyślne wiązania na sekundę	Używanie protokołu NTLM do wykonywania powiązań (B5)	1068	1056	-1,12%
Zapisy na sekundę	Zapisywanie wielu atrybutów (W2)	6467	5885	-9.00%

Aby zmaksymalizować wydajność wdrożenia testowego, w tej kompilacji testowej zainstalowano składniki integracji (IC), aby umożliwić systemowi operacyjnemu gościa używanie sterowników syntetycznych obsługujących funkcję hypervisor. Podczas instalowania IC czasami konieczne jest użycie emulowanych sterowników zintegrowanej stacji dysków (IDE) lub kart sieciowych. W środowiskach produkcyjnych należy zastąpić te emulowane sterowniki sterownikami syntetycznymi, aby zwiększyć wydajność.

Na podstawie tego testu należy wziąć pod uwagę następujące zalecenia dotyczące poprawy wydajności:

• Podczas monitorowania wydajności maszyny wirtualnej przy użyciu narzędzia Perfmon.msc czasami informacje o procesorze CPU maszyny wirtualnej nie są całkowicie dokładne. Ta niedokładność wynika ze sposobu uruchamiania wirtualnego procesora CPU na procesorze fizycznym. Aby uzyskać dokładniejsze informacje o CPU maszyny wirtualnej działającej na serwerach Hyper-V, użyj liczników logicznych procesorów Hypervisor Hyper-V w partycji hosta. Aby uzyskać więcej informacji na temat dostrajania wydajności usług AD DS i funkcji Hyper-V, zobacz Wytyczne dotyczące dostrajania wydajności dla systemu Windows Server.

• Zalecamy unikanie używania dysków różnicowych VHD na maszynie wirtualnej skonfigurowanej jako kontroler domeny, ponieważ dyski różnicowe VHD mogą zmniejszyć wydajność. Aby dowiedzieć się więcej na temat typów dysków Hyper-V, w tym dysków różnicowych, zobacz Kreator nowego wirtualnego dysku twardego.

• Proponujemy także, abyś zapoznał się z informacjami, jak korzystać z AD DS w środowiskach hostingu wirtualnego, czytając Rzeczy do rozważenia podczas używania kontrolerów domeny Active Directory w takich środowiskach.

Uwagi dotyczące wdrażania

W poniższych sekcjach opisano typowe praktyki dotyczące maszyn wirtualnych, których należy unikać przy wdrażaniu kontrolerów domeny, oraz szczególne kwestie dotyczące synchronizacji czasu i przechowywania.

Zalecenia dotyczące wdrażania

Platformy wirtualizacji, takie jak Hyper-V, mają wiele funkcji, które ułatwiają zarządzanie, konserwowanie, tworzenie kopii zapasowych i migrowanie maszyn. Istnieją jednak pewne zalecenia, które należy przestrzegać, aby skorzystać z tych funkcji dla kontrolerów domeny wirtualnych.

• Aby mieć pewność, że zapisy w usłudze Active Directory są trwałe, nie wdrażaj plików bazy danych wirtualnego kontrolera domeny, takich jak pliki bazy danych Active Directory NTDS.DIT, dzienniki i folder SYSVOL, na wirtualnych dyskach IDE. Zamiast tego utwórz drugi wirtualny dysk twardy (VHD) dołączony do wirtualnego kontrolera SCSI i upewnij się, że pliki bazy danych znajdują się na dysku SCSI VM podczas instalowania kontrolera domeny.

• Nie stosuj różnicowych dysków VHD na maszynie wirtualnej, którą konfigurujesz jako kontroler domeny. Chociaż takie podejście ułatwia przywrócenie wdrożenia do poprzednich wersji, zmniejsza również wydajność. Aby uzyskać więcej informacji na temat typów dysków VHD, zobacz Kreator nowego wirtualnego dysku twardego.

• Nie wdrażaj domen i lasów usługi Active Directory na kopii systemu operacyjnego Windows Server bez uprzedniego użycia narzędzia przygotowywania systemu (sysprep) w celu przygotowania ich do wdrożenia. Aby uzyskać więcej informacji na temat uruchamiania narzędzia Sysprep, zobacz Sysprep (przygotowanie systemu) — omówienie.

  Ostrzeżenie

  Uruchamianie narzędzia Sysprep na promowanym kontrolerze domeny jest niewskazane, ponieważ może negatywnie wpłynąć na bazę danych usługi Active Directory i powiązane składniki, powodując następujące problemy:

  • Utrata danych
  • Uszkodzenie bazy danych usługi AD
  • Problemy ze stabilnością i funkcjonalnością
  • Problemy z aplikacjami, usługami i sterownikami

• Nie wdrażaj innych kontrolerów domeny, używając kopii pliku VHD z już wdrożonego kontrolera domeny. Unikanie korzystania z kopii zapobiega potencjalnym scenariuszom cofnięcia USN. Aby uzyskać więcej informacji na temat wycofywania USN, zobacz USN i wycofywanie USN.

  • W systemie Windows Server 2012 lub nowszym administratorzy mają możliwość klonowania obrazów kontrolera domeny w celu wdrożenia większej liczby kontrolerów domeny, ale tylko wtedy, gdy używają prawidłowo przygotowanych obrazów.

• Nie używaj funkcji eksportowania Hyper-V, aby wyeksportować maszynę wirtualną z uruchomionym kontrolerem domeny.

  • W systemie Windows Server 2012 i nowszym, system obsługuje eksportowanie i importowanie wirtualnych gości kontrolerów domen, podobnie jak w przypadku przywracania nieautorytatywnego. Procedura wykrywa, czy zmienił się identyfikator generacji i czy kontroler domeny nie jest skonfigurowany do klonowania.

  • Podczas eksportowania maszyny wirtualnej gościa musisz upewnić się, że nikt z niej nie korzysta. Aby ułatwić sprawy, można użyć Replikacji Hyper-V do utworzenia nieaktywnej kopii DC. Po rozpoczęciu korzystania z zreplikowanego obrazu należy również przeprowadzić czyszczenie, tak jak w przypadku obrazu źródłowego po wyeksportowaniu obrazu maszyny wirtualnej DC.

Konwersja fizyczna-wirtualna

Program System Center VM Manager (VMM) umożliwia ujednolicone zarządzanie maszynami fizycznymi i maszynami wirtualnymi. Program VMM umożliwia również migrację maszyny fizycznej do maszyny wirtualnej. Ten proces migracji nosi nazwę konwersji fizycznejto-VMlub konwersji P2V. Aby rozpocząć proces konwersji P2V, należy upewnić się, że maszyna wirtualna i fizyczny kontroler domeny, które są migrowane, nie są uruchomione jednocześnie. Zapewnienie, że dwie maszyny nie są uruchomione w tym samym czasie, zapobiega scenariuszom wycofywania USN, zgodnie z opisem w USN i wycofywaniem USN.

Należy wykonać konwersję P2V w trybie offline, aby zachować spójność danych katalogu po ponownym włączeniu DC. Tryb offline można przełączać w instalatorze Konwertuj serwer fizyczny. Aby uzyskać więcej informacji na temat korzystania z trybu offline, zobacz P2V: Konwertowanie komputerów fizycznych na maszyny wirtualne w programie VMM.

Należy również odłączyć maszynę wirtualną od sieci podczas konwersji P2V. Należy włączyć kartę sieciową tylko po zakończeniu procesu konwersji i sprawdzić, czy wszystko działa. W tym momencie należy wyłączyć fizyczną maszynę źródłową. Nie włączaj fizycznej maszyny źródłowej i ponownie połącz ją z siecią dopiero po ponownym sformatowaniu dysku twardego.

Unikanie cofnięcia zmian USN

Podczas tworzenia wirtualnych kontrolerów domeny należy unikać sytuacji z wycofywaniem numerów USN. Aby uniknąć wycofywania, możesz skonfigurować nowy wirtualny kontroler domeny za pomocą regularnego promowania, promowania z instalacji z nośnika (IfM) lub, jeśli masz już co najmniej jeden wirtualny kontroler domeny, klonując istniejący kontroler. Takie podejście pozwala również uniknąć problemów ze sprzętem lub platformą, które mogą się pojawić u wirtualnych gości po konwersji P2V.

Ostrzeżenie

Aby zapobiec problemom z replikacją usługi Active Directory, upewnij się, że w określonym czasie istnieje tylko jeden fizyczny lub wirtualny kontroler domeny w danej sieci. Można zmniejszyć prawdopodobieństwo wystąpienia problemu ze starym klonem przy użyciu jednej z następujących metod:

• Po uruchomieniu nowego wirtualnego kontrolera domeny wykonaj następujące polecenie dwa razy, aby zmienić hasło konta systemowego:

  netdom resetpwd /Server:<domain-controller>
  

• Wyeksportuj i zaimportuj nowego gościa wirtualnego, aby wymusić na nim utworzenie nowego identyfikatora generacji i identyfikatora wywołania bazy danych.

Środowiska testowe i migracja P2V

Migrację P2V można używać w połączeniu z programem VMM do tworzenia środowisk testowych. Dzięki tej metodzie można migrować produkcyjne kontrolery domeny z maszyn fizycznych do maszyn wirtualnych, aby utworzyć środowisko testowe bez trwałego wyłączania produkcyjnych kontrolerów domeny. Należy jednak skompilować środowisko testowe w oddzielnej sieci od środowiska produkcyjnego, aby umożliwić istnienie dwóch wystąpień tego samego kontrolera domeny. Ważne jest, aby uniknąć wycofywania numerów USN podczas tworzenia środowisk testowych przy użyciu migracji P2V.

Tworzenie środowiska testowego

Zalecamy wykonanie następujących czynności podczas tworzenia środowisk testowych przy użyciu funkcji P2V:

• Przeprowadź migrację jednego kontrolera domeny w środowisku produkcyjnym z każdej domeny do testowej maszyny wirtualnej przy użyciu funkcji P2V na podstawie zaleceń w konwersji fizycznej na wirtualną.

• Umieść fizyczne maszyny produkcyjne i testowe maszyny wirtualne w różnych sieciach po powrocie do trybu online.

• Aby uniknąć wycofywania numerów USN w środowisku testowym, odłącz wszystkie kontrolery domeny, które mają być migrowane z sieci. Można odłączyć kontrolery domeny, zatrzymując usługę NTDS lub ponownie uruchamiając komputery w trybie przywracania usług katalogowych (DSRM).

• Nie wprowadzaj żadnych nowych aktualizacji w środowisku po odłączeniu kontrolerów domeny od sieci.

• Nie należy łączyć żadnych maszyn z siecią podczas migracji P2V. Można je ponownie połączyć tylko po zakończeniu migracji wszystkich maszyn.

• Należy promować tylko te testowe kontrolery domeny, które zostały utworzone po konwersji P2V, jako repliki w środowisku testowym.

Usługa czasowa i synchronizacja

W przypadku maszyn wirtualnych skonfigurowanych jako kontrolery domeny zalecamy wyłączenie synchronizacji czasu między systemem hosta a systemem operacyjnym gościa działającym jako kontroler domeny. Jeśli kontroler domeny gościa nie synchronizuje się z systemem hosta, to zamiast tego synchronizuje się z hierarchią domeny.

Aby wyłączyć dostawcę synchronizacji czasu Hyper-V, wyłącz maszynę wirtualną, a następnie przejdź do ustawień maszyny wirtualnej, wybierz Integration Services i usuń zaznaczenie pola wyboru Synchronizacja czasu .

Magazynowanie i optymalizacja

Zalecamy przestrzeganie zaleceń dotyczących przechowywania w niniejszym rozdziale, aby zoptymalizować wydajność maszyny wirtualnej kontrolera domeny i zapewnić trwałość zapisów w usłudze Active Directory.

• Dla przechowywania danych gościa należy przechowywać plik bazy danych usługi Active Directory (Ntds.dit) oraz pliki dziennika i folderu SYSVOL na oddzielnym dysku wirtualnym od plików systemu operacyjnego. Zalecamy przechowywanie tych plików na wirtualnym dysku SCSI w drugim wirtualnym dysku VHD dołączonym do wirtualnego kontrolera SCSI. Wirtualny dysk SCSI zwiększa wydajność i obsługuje wymuszony dostęp jednostkowy (FUA). Dzięki funkcji FUA system operacyjny zapisuje i odczytuje bezpośrednio z nośnika, pomijając wszelkie mechanizmy buforowania.

• Jeśli używasz funkcji BitLocker do zabezpieczenia wirtualnego gościa kontrolera domeny, skonfiguruj dodatkowe woluminy do automatycznego odblokowywania przy użyciu Enable-BitLockerAutoUnlock polecenia cmdlet programu PowerShell.

• Podczas przechowywania plików VHD na hostach należy użyć dysku, który nie jest często używany przez inne usługi lub aplikacje, takie jak dysk systemowy dla systemu operacyjnego hosta. Przechowuj każdy plik VHD na oddzielnej partycji od systemu operacyjnego hosta i innych plików VHD, najlepiej na oddzielnym dysku fizycznym.

• System dysku fizycznego hosta musi spełniać co najmniej jedno z następujących kryteriów, aby spełnić wymagania dotyczące integralności danych zwirtualizowanych obciążeń:

  • Host używa dysków klasy serwera, takich jak SCSI lub Fibre Channel.

  • Serwer upewnia się, że dyski są podłączone do kart HBA z buforem zasilanym bateryjnie.

  • Host używa kontrolera magazynu, takiego jak nadmiarowa tablica niezależnych dysków (RAID) jako urządzenie magazynujące.

  • Host używa zasilacza awaryjnego (UPS) do zasilania dysku.

  • Host domyślnie wyłącza funkcję buforowania zapisu dysku.

• W przypadku korzystania z plików VHD zalecamy używanie dysków przekazywania lub dysków VHD o stałym rozmiarze, ponieważ są one zoptymalizowane pod kątem wydajności. Nie zalecamy dynamicznego rozszerzania i tworzenia różnic na dyskach, ponieważ mogą one powodować opóźnienia, spadek wydajności podczas intensywnej aktywności dysku i potencjalną utratę danych przy przywracaniu poprzedniego stanu migawki.

• Zalecamy użycie wirtualnych kontrolerów SCSI w celu zmniejszenia prawdopodobieństwa uszkodzenia danych usługi Active Directory.

  • Na serwerach Hyper-V hostujących wirtualne kontrolery domeny należy użyć dysków fizycznych SCSI. Jeśli w twoim scenariuszu nie można używać dysków SCSI, należy wyłączyć buforowanie zapisu na dysku Advanced Technology Attachment (ATA) lub Zintegrowane Układy Napędowe (IDE), którego używasz zamiast tego. Aby uzyskać więcej informacji, zobacz Identyfikator zdarzenia 1539 — Integralność bazy danych.

Ograniczenia operacyjne dla kontrolerów domeny maszyny wirtualnej

Kontrolery domeny uruchomione na maszynach wirtualnych mają ograniczenia operacyjne, które nie mają zastosowania do kontrolerów domeny działających na maszynach fizycznych. W przypadku używania zwirtualizowanego kontrolera domeny należy postępować zgodnie z następującymi wytycznymi:

• Nie wstrzymuj, zatrzymaj ani nie przechowuj zapisanego stanu kontrolera domeny na maszynie wirtualnej dłużej niż okres istnienia grobowca lasu. Wznawianie zapisanego stanu, który został wstrzymany lub zapisany dłużej niż okres istnienia grobowca, może zakłócać replikację. Aby dowiedzieć się, jak określić okres istnienia grobowca dla lasu, zobacz Określanie okresu istnienia grobowca dla lasu.

• Nie kopiuj ani nie klonuj dysków VHD.

• Nie wykonuj ani nie używaj snapshotów wirtualnych kontrolerów domeny. Zamiast tego należy użyć bardziej trwałej i niezawodnej metody tworzenia kopii zapasowych.

• Nie używaj funkcji Eksportuj na maszynie wirtualnej z uruchomionym kontrolerem domeny.

• Nie przywracaj ani nie cofaj zmian w kontrolerze domeny lub zawartości bazy danych usługi Active Directory, używając nieobsługiwanej metody tworzenia kopii zapasowej.

Zagadnienia dotyczące tworzenia kopii zapasowych i przywracania

Należy utworzyć kopię zapasową kontrolerów domeny, aby zapobiec utracie danych z powodu scenariuszy awarii lub błędów administracyjnych. Metoda tworzenia kopii zapasowej obsługiwana przez Active Directory polega na użyciu aplikacji do kopii zapasowych w celu przywrócenia kopii zapasowej stanu systemu wykonanej z bieżącej instalacji kontrolera domeny. Aplikacja powinna być zgodna z usługą Active Directory, taką jak Kopia zapasowa systemu Windows Server. Aby uzyskać więcej informacji na temat obsługiwanych metod tworzenia kopii zapasowych, zobacz przewodnik krok po kroku dotyczący tworzenia kopii zapasowych i odzyskiwania AD DS.

W przypadku wdrożeń zwirtualizowanych należy zwrócić szczególną uwagę na pewne wymagania dotyczące operacji tworzenia kopii zapasowych usługi Active Directory. Jeśli na przykład przywrócisz kontroler domeny przy użyciu kopii pliku VHD i nie zaktualizujesz wersji bazy danych kontrolera domeny po przywróceniu go, może to spowodować problemy z replikacją z powodu niedokładnych numerów śledzenia wśród replik kontrolera domeny. W większości przypadków replikacja nie wykrywa tego problemu i nie zgłasza żadnych błędów, ale niespójności pomiędzy kontrolerami domen mogą potencjalnie powodować problemy w pewnych scenariuszach.

Zalecana metoda tworzenia kopii zapasowych i przywracania zwirtualizowanych kontrolerów domeny

Metoda, którą zalecamy do wykonania kopii zapasowej i przywracania zwirtualizowanych kontrolerów domeny, to uruchomienie Windows Server Backup w systemie operacyjnym gościa. Aby uzyskać więcej informacji, zobacz Przywracanie wirtualnego kontrolera domeny.

Chociaż można technicznie używać migawek lub kopii plików VHD do przywrócenia kopii zapasowej, nie zalecamy używania tych metod z następujących powodów:

• Jeśli skopiujesz lub sklonujesz plik VHD, baza danych stanie się nieaktualna, ponieważ jej numer wersji bazy danych nie zostanie automatycznie zaktualizowany podczas przywracania. Ta niespójność w numerach śledzenia oznacza, że jeśli uruchomisz VHD w trybie normalnym, możesz potencjalnie spowodować wycofanie USN .

• Chociaż system Windows Server 2016 lub nowszy jest zgodny z migawkami, migawki nie zapewniają stabilnej i trwałej historii kopii zapasowych, która jest niezbędna do konsekwentnego przywracania systemu w sytuacjach awaryjnych. Migawki oparte na usłudze kopiowania woluminów w tle (VSS), które można utworzyć w systemach Windows Server 2016 Hyper-V i późniejszych, również nie są zgodne z funkcją BitLocker, co może prowadzić do potencjalnych problemów z zabezpieczeniami. Ten problem uniemożliwia silnikowi bazy danych usługi Active Directory uzyskanie dostępu do bazy danych zawierającej wolumin migawki, gdy Hyper-V próbuje zamontować wolumin migawki.

Uwaga

Projekt chronionej maszyny wirtualnej opisany w artykule Chroniona sieć szkieletowa i chronione maszyny wirtualne ma Hyper-V kopii zapasowej opartej na hoście jako nienależącą do celu w celu zapewnienia maksymalnej ochrony danych maszyny wirtualnej gościa.

Wycofywanie USN i cofanie USN

W tej sekcji opisano problemy z replikacją, które mogą wystąpić w wyniku nieprawidłowego przywrócenia bazy danych usługi Active Directory ze starszą wersją maszyny wirtualnej. Aby uzyskać więcej informacji na temat procesu replikacji usługi Active Directory, zobacz pojęcia dotyczące replikacji usługi Active Directory.

Jak usługi AD DS i kontrolery domeny używają numerów identyfikacyjnych USN

Usługi AD DS używają numerów USN do śledzenia replikacji danych między kontrolerami domeny. Za każdym razem, gdy zmieniasz dane w katalogu, wartość USN zwiększa się, aby wskazać nową zmianę.

Docelowe kontrolery domeny wykorzystują USN-y do śledzenia aktualizacji każdej z przechowywanych partycji katalogu. USN śledzi stan każdego DC, który przechowuje repliki tych partycji katalogu. Gdy kontrolery domeny replikują zmiany między sobą, pytają swoich partnerów replikacji o zmiany z numerami USN większymi niż ostatnia zmiana otrzymana przez kontroler domeny od partnera.

Można znaleźć tabele metadanych replikacji zawierające numery USN w wektorze up-to-dateness i znaczniku maksymalnym poziomu wody. Zarówno źródłowe, jak i docelowe kontrolery domeny używają tych tabel do filtrowania wymaganych aktualizacji dla docelowego kontrolera domeny.

Docelowy kontroler domeny utrzymuje tabelę wektorów up-to-dateness, aby śledzić aktualizacje pochodzące ze wszystkich źródłowych kontrolerów domeny. Gdy docelowy kontroler domeny żąda zmian dla partycji katalogu, przekazuje swój wektor up-to-dateness do źródłowego kontrolera domeny. Następnie źródłowy kontroler domeny używa tej wartości do filtrowania aktualizacji, które wysyła do docelowego kontrolera domeny. Źródłowy kontroler domeny wysyła swój wektor up-to-dateness do docelowego kontrolera domeny po pomyślnym zakończeniu cyklu replikacji. Źródłowy kontroler domeny używa USN do śledzenia, czy docelowy kontroler domeny jest zsynchronizowany z aktualizacjami pochodzącymi z każdego kontrolera domeny i czy aktualizacje docelowe są na tym samym poziomie co źródłowe.

Docelowy kontroler domeny utrzymuje tabelę wysokiego poziomu wody w celu śledzenia najnowszych zmian otrzymanych z określonego źródłowego kontrolera domeny dla określonej partycji. Tabela z wysokim znacznikami wody uniemożliwia źródłowemu kontrolerowi domeny wysyłanie zmian, które docelowy kontroler domeny już odebrał.

Tożsamość bazy danych katalogu

Oprócz numerów USN kontrolery domeny śledzą katalogową bazę danych źródłowych partnerów replikacji. System utrzymuje tożsamość bazy danych katalogów uruchomionej na serwerze niezależnie od tożsamości samego obiektu serwera. Tożsamość bazy danych katalogów na każdym kontrolerze domeny, jest przechowywana w atrybucie invocationID obiektu NTDS Settings, który znajduje się w ścieżce LDAP cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*.

System przechowuje tożsamość obiektu serwera w atrybucie objectGUID obiektu NTDS Settings. Tożsamość obiektu serwera nigdy się nie zmienia. Jednak tożsamość bazy danych katalogów zmienia się w następujących okolicznościach:

• W przypadku wystąpienia procedury przywracania stanu systemu na serwerze.

• Po dodaniu partycji katalogu aplikacji do serwera usuń ją, a następnie dodaj ją ponownie.

• Gdy wystąpienie Hyper-V wyzwala programy skryptowe VSS na partycji zawierającej wirtualny dysk VHD kontrolera domeny wirtualnej.

  W tym scenariuszu gość wyzwala własnych pisarzy VSS. Ta akcja jest tym samym mechanizmem, którego używa proces tworzenia kopii zapasowej i przywracania. Ta metoda resetuje atrybut invocationID.

Atrybut invocationID wiąże zestaw aktualizacji pochodzących na kontrolerze domeny z określoną wersją bazy danych katalogów. Wektor up-to-dateness i tabele wskaźników wysokiej wody używają odpowiednio identyfikatora GUID invocationID i identyfikatora kontrolera domeny, aby kontrolery domeny rozpoznały, z której kopii bazy danych usługi Active Directory pochodzą informacje o replikacji.

Atrybut invocationID jest globalnie unikatową wartością identyfikatora (GUID), która jest widoczna w górnej części danych wyjściowych po uruchomieniu polecenia repadmin /showrepl. Poniższy tekst reprezentuje przykładowe dane wyjściowe polecenia :

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Podczas przywracania usług Active Directory Domain Services (AD DS) na kontrolerze domeny system resetuje atrybut invocationID. Ta zmiana zwiększa ruch związany z replikacją, którego czas trwania jest zależny od rozmiaru replikowanej partycji.

Aby zademonstrować ten scenariusz, na poniższym diagramie przedstawiono przykładowe środowisko, w którym wirtualny kontroler domeny VDC1 i kontroler domeny DC2 to dwa kontrolery domeny w tej samej domenie. Na tym diagramie pokazano, jak dc2 wykrywa wartość invocationID w VDC1 po zresetowaniu w obsługiwanym scenariuszu przywracania.

Diagram przedstawiający schemat blokowy widoku VDC1 na samego siebie i widoku DC2 na VDC1. W linii VDC1, VDC1 rozpoczyna się od USN o wartości 1000 i identyfikatora wywołania B. Następnie VDC1 zostaje przywrócone do poprzedniej wersji, która ma USN o wartości 500 i identyfikator wywołania B. Na VDC1 zachodzą zmiany, które zwiększają USN do 600, podczas gdy identyfikator wywołania pozostaje taki sam. Na linii, gdzie napisano "Widok DC2 na VDC1", DC2 rozpoczyna się od identyfikatora wywołania VDC1(A)@USN1000. Po tym, jak VDC1 zostaje przywrócony, kontroler DC2 resetuje oczekiwany numer USN z 1000 na 500, ustawiając wartość identyfikatora wywołania B jako VDC1(B)@USN500. Kontynuuje śledzenie zarówno identyfikatora wywołania A, jak i identyfikatora wywołania B. Po następnym zestawie zmian na VDC1, DC2 śledzi teraz identyfikator wywołania A VDC1 o USN 1000 oraz jego nowy identyfikator wywołania B o USN 600.

Wycofywanie USN

Wycofanie USN występuje, gdy system nie może zaktualizować USN w normalny sposób, użytkownik pomija aktualizacje USN lub kontroler domeny (DC) próbuje użyć USN niższej niż najnowsza aktualizacja. Gdy system wykryje wycofanie USN, zatrzymuje replikację, aby niezgodność nie spowodowała rozbieżności w strukturze lasu.

Wiele czynników może spowodować USN rollback. Na przykład może się zdarzyć, jeśli używasz starych plików VHD lub wykonasz konwersję P2V bez trwałego odłączenia maszyny fizycznej po konwersji.

Zapobieganie cofnięciu USN

Można zapobiec wycofaniu USN, stosując następujące środki ostrożności:

• Jeśli system Windows Server 2012 lub nowszy nie jest uruchomiony, nie należy wykonywać ani używać migawki maszyny wirtualnej kontrolera domeny.

• Nie kopiuj pliku VHD DC.

• Jeśli nie jest uruchomiony system Windows Server 2012 lub nowszy, nie eksportuj maszyny wirtualnej, która działa jako kontroler domeny.

• Przywróć kontroler domeny lub wycofaj zawartość bazy danych usługi Active Directory przy użyciu obsługiwanych rozwiązań do tworzenia kopii zapasowych innych firm, takich jak kopia zapasowa systemu Windows Server.

Czasami system nie może wykryć wycofania numerów USN, zanim to spowoduje błędy replikacji. W przypadku wystąpienia błędów replikacji należy zidentyfikować zakres problemu i rozwiązać go tak szybko, jak to możliwe. Aby uzyskać więcej informacji na temat usuwania utrzymujących się obiektów, które mogą wystąpić w wyniku wycofania USN, zobacz identyfikator zdarzenia replikacji Active Directory 1388 lub 1988: wykryto utrzymujący się obiekt.

Wykrywanie cofnięcia USN

W większości przypadków system może wykrywać wycofywanie USN poprzez śledzenie niespójności w atrybucie invocationID, spowodowanych przywróceniem kontrolera domeny bez resetowania atrybutu. System Windows Server 2008 chroni przed błędami replikacji po nieobsługiwanych przywróceniach kontrolera domeny. Zabezpieczenia są wyzwalane, gdy przywracanie bez wsparcia tworzy numery USN niższe niż oryginalne wersje, co oznacza zmiany, które już dotarły do partnerów replikacji.

W systemie Windows Server, gdy docelowy kontroler domeny żąda zmian przy użyciu wcześniej używanej nazwy USN, docelowy kontroler domeny interpretuje odpowiedź partnera replikacji, aby oznaczać, że jego metadane replikacji są nieaktualne. Nieaktualne metadane oznaczają, że baza danych usługi Active Directory na źródłowym kontrolerze domeny została cofnięta do wcześniejszego stanu, co powoduje odpowiednią reakcję systemu.

Załóżmy na przykład, że plik VHD maszyny wirtualnej został przywrócony do poprzedniej wersji. W takim przypadku docelowy kontroler domeny inicjuje następujące środki kwarantanny na kontrolerze domeny, który zidentyfikowano jako poddany nieobsługiwanemu przywracaniu.

• Usługa AD DS wstrzymuje usługę Net Logon, co uniemożliwia kontom użytkowników i komputerów na zmianę haseł kont. Ta akcja zabezpiecza przed utratą takich zmian, jeśli wystąpią po nieprawidłowym przywróceniu.

• Usługi AD DS wyłącza replikację ruchu przychodzącego i wychodzącego usługi Active Directory.

• Usługi AD DS generują zdarzenie o identyfikatorze 2095 w dzienniku zdarzeń usługi katalogowej, aby zarejestrować, co się stało.

Na poniższym diagramie przedstawiono sekwencję zdarzeń, które występują, gdy AD DS wykrywa wycofywanie numerów USN na VDC2, docelowym kontrolerze domeny, który działa na maszynie wirtualnej. Na tej ilustracji wykrywanie wycofania USN występuje na VDC2, gdy partner replikacji wykryje, że VDC2 wysłał wartość USN up-to-dateness, którą wcześniej widział docelowy kontroler domeny. Ten warunek wskazuje, że baza danych VDC2 napotkała wycofanie.

Diagram przedstawiający schemat blokowy aktualizacji VDC2 i wartość aktualności DC1 up-todla VDC2. VDC2 rozpoczyna się od USN 100 i numer identyfikacyjny wywołania A. Następnie aktualizuje numery USN z 101 do 200, które są replikowane na DC1. Jednakże użytkownik również tworzy kopię wirtualnego dysku twardego (VHD) VDC2 USN 200. Następnie VDC2 aktualizuje USN od 201 do 350 i replikuje te zmiany na DC1. Jednak VDC2 kończy się niepowodzeniem. Następnie użytkownik przywraca VDC2 przy użyciu kopii wykonanej na USN 200 VHD. Następnie użytkownik dokonuje kolejnej aktualizacji VDC2 dla nowej wersji numerów USN 201-355. DC1 żąda zmian większych niż USN 350 z VDC2 i otrzymuje replikację, ponieważ USN na VDC2 jest wyższy niż na DC1. Jednak nowa wersja USN od 201 do 350 nie jest taka sama jak te na DC1, co powoduje wycofanie USN.

Rozwiązywanie problemów z identyfikatorem zdarzenia 2095

Jeśli w dzienniku zdarzeń usługi katalogowej zostanie wyświetlony identyfikator zdarzenia 2095, wykonaj następujące instrukcje natychmiast:

1. Izoluj maszynę wirtualną, która zarejestrowała błąd z sieci.

2. Sprawdź, czy zgłoszone zmiany pochodzą z tego kontrolera domeny albo zostały propagowane do innych kontrolerów domeny. Jeśli zdarzenie było wynikiem użycia migawki lub kopii maszyny wirtualnej, spróbuj dowiedzieć się, kiedy wystąpiło wycofanie USN. Po upływie tego czasu można sprawdzić partnerów replikacji tego kontrolera domeny, aby określić, czy replikacja wystąpiła po wycofaniu.

   Możesz użyć narzędzia Repadmin, aby sprawdzić, skąd pochodzą zmiany. Aby uzyskać informacje na temat korzystania z repozytorium Repadmin, zobacz Monitorowanie i rozwiązywanie problemów z replikacją usługi Active Directory za pomocą narzędzia Repadmin. Jeśli nie możesz dokonać ustalenia, skontaktuj się z microsoft support, aby uzyskać pomoc.

3. Siłowo zdegraduj kontroler domeny. Ta operacja obejmuje czyszczenie metadanych kontrolera domeny oraz przejęcie ról wzorca operacji, znanych również jako elastyczne role jednowzorcowego modelu operacji (FSMO). Aby uzyskać więcej informacji, zobacz Odzyskiwanie po cofnięciu USN.

4. Usuń wszystkie poprzednie pliki VHD dla kontrolera domeny.

Niewykryte przywracanie USN

Kontroler domeny może nie wykryć cofnięcia numeracji USN w następujących scenariuszach:

• Plik VHD jest dołączony do różnych maszyn wirtualnych działających jednocześnie w wielu lokalizacjach.

• USN na przywróconym kontrolerze domeny wzrósł poza ostatni USN odebrany przez inny kontroler domeny.

W scenariuszu z plikiem VHD inne kontrolery domeny mogą replikować się z jedną z maszyn wirtualnych, a zmiany mogą wystąpić na jednej z nich, nie będąc replikowane na drugą. Ta rozbieżność leśnej struktury jest trudna do wykrycia i powoduje nieprzewidywalne odpowiedzi systemu plików. Taka sytuacja może wystąpić po migracji P2V, jeśli fizyczny kontroler domeny i maszyna wirtualna są uruchamiane w tej samej sieci. Taka sytuacja może również wystąpić, jeśli wiele wirtualnych kontrolerów domeny jest tworzonych na podstawie tego samego fizycznego kontrolera domeny, a następnie działa w tej samej sieci.

W scenariuszu dotyczącym USN zakres numerów USN odnosi się do dwóch różnych zestawów zmian. Ten scenariusz może być kontynuowany przez dłuższy czas bez wykrycia. Podczas modyfikowania obiektu utworzonego w tym okresie system wykrywa utrzymujący się obiekt i zgłasza go jako identyfikator zdarzenia 1988 w Podglądzie zdarzeń. Na poniższym diagramie przedstawiono, dlaczego DC może nie wykryć cofnięcia USN w tym scenariuszu.

Diagram przedstawiający schemat blokowy dla procesu detekcji cofania w przykładowej kompilacji. Istnieją dwa kontrolery domeny oznaczone etykietą "VDC1" i "DC2". Początkowy etap schematu blokowego przedstawia wirtualny kontroler domeny, VDC1, który tworzy migawkę, gdy jego USN wynosi 2000. Po utworzeniu migawki VDC1 tworzy 100 użytkowników, a zaktualizowana VDC1 ma teraz 2100 usN. Aktualizacje na VDC1 replikują do DC2, i teraz udostępnia USN 2100. Jednak VDC1 używa migawki, którą wykonał, aby przywrócić swoją wersję USN do 2000. Przywrócona wersja VDC1 tworzy 150 nowych użytkowników, co powoduje, że jego numer USN wzrasta do 2150. Zaktualizowany VDC1 replikuje do DC2, ale DC2 nie wykrywa niezgodności zmian, ponieważ jego USN jest wyższy niż USN DC2 wynoszący 2100. Tekst w dolnej części mówi: "Wycofywanie numerów USN nie jest wykrywane, co powoduje niezakrytą rozbieżność, w której numery USN od 2001 do 2100 nie są takie same między dwoma kontrolerami domeny.

Kontrolery domeny tylko do odczytu

Kontrolery domeny tylko do odczytu (RODC) to kontrolery domeny, które hostują kopie tylko do odczytu partycji w bazie danych usługi Active Directory. RODC unikają większości problemów z wycofywaniem numerów USN, ponieważ nie replikują żadnych zmian w innych kontrolerach domeny. Jeśli jednak kontroler RODC replikuje z zapisywalnego kontrolera domeny, którego dotyczy proces wycofywania numerów USN, wycofanie również wpływa na kontroler RODC.

Nie zalecamy używania migawki do przywrócenia kontrolera RODC. Należy przywrócić kontroler RODC tylko przy użyciu aplikacji kopii zapasowej zgodnej z usługą Active Directory. Ponadto, podobnie jak w przypadku zapisywalnych kontrolerów domeny, nie można zezwolić kontrolerowi RODC na tryb offline przez więcej niż okres istnienia grobowca. Ta sytuacja może prowadzić do pozostawania obiektów na kontrolerze RODC.

Aby uzyskać więcej informacji na temat implementowania RODC, zobacz przewodnik krok po kroku kontrolerów domeny Read-Only.

Dodatkowa zawartość

Dowiedz się, jak przywrócić zwirtualizowane kontrolery domeny w Przywróć zwirtualizowane kontrolery domeny.