Dela via

Virtualisera domänkontrollanter med Hyper-V

Windows Server 2012 och senare stöder virtualiserade domänkontrollanter (DCs) med skydd för att förhindra återställning av uppdateringssekvensnummer (USN) på virtuella domänkontrollanter och möjligheten att klona virtuella domänkontrollanter. Virtualisering konsoliderar olika serverroller till en enda fysisk dator. Mer information finns i Virtualisera Active Directory Domain Services (AD DS) på ett säkert sätt.

Den här guiden beskriver hur du kör DC:er som 32-bitars eller 64-bitars operativsystem för gästanvändare.

Planera för virtualisering

Följande avsnitt innehåller planeringsöverväganden som du bör känna till när du virtualiserar en domänkontrollant, inklusive maskinvarukrav, arkitektur, konfiguration och hantering av säkerhet och prestanda.

Hyper-V krav

Om du vill installera och använda rollen Hyper-V måste maskinvaran uppfylla följande krav:

  • Du måste ha en x64-processor.

  • Processorn måste låta dig aktivera funktionen för maskinvaruassisterad virtualisering.

    • Vanligtvis kallas den här inställningen Intel Virtualization Technology (Intel VT) eller Advanced Micro Devices Virtualization (AMD-V).

  • Processorn måste ha stöd för maskinvarudatakörningsskydd (DEP).

    • Du kan bara använda Hyper-V när du aktiverar Intel execute disable (XD)-biten eller AMD no execute (NX)-biten.

Undvik enskilda felpunkter

När du planerar distributionen av den virtuella domänkontrollanten bör du förbereda en strategi för att undvika att skapa enskilda felpunkter. Du kan undvika att införa potentiella enskilda felpunkter eller områden där stilleståndstid kan leda till att hela systemet slutar fungera genom att implementera systemredundans.

Följande rekommendationer kan hjälpa till att förhindra enskilda felpunkter. Men det är också viktigt att komma ihåg att om du följer dessa rekommendationer kan administrationskostnaderna öka.

  • Kör minst två virtualiserade domänkontrollanter per domän på olika virtualiseringsvärdar. Den här konfigurationen minskar risken för att förlora alla domänkontrollanter om en virtualiseringsvärd slutar fungera.

  • Diversifiera maskinvaran som driver dina datacenter. Använd till exempel olika processorer, moderkort, nätverkskort och så vidare. Olika maskinvara förhindrar skador på enhets- och maskinvarufel eller leverantörskonfiguration.

  • Om möjligt kan du köra dina domänkontrollanter på maskinvara som finns i olika regioner. Den här metoden minskar konsekvenserna av katastrofer som påverkar en av de platser som är värd för dina DCs.

  • Lägg till fysiska domänkontrollanter i alla dina domäner. Om du konfigurerar ditt system med fysiska domänkontrollanter kan du förhindra att värdsystemen drabbas av fel på virtualiseringsplattformen.

Säkerhetsfrågor

Du måste hantera värddatorn där du kör dina virtuella domänkontrollanter lika noggrant som en skrivbar domänkontrollant, även om datorn bara är en domänansluten dator eller arbetsgruppsdator. Det här kravet är av säkerhetsskäl. Felhanterade värdar är sårbara för attacker med utökade privilegier, där skadliga användare får åtkomst till högre behörigheter än de ska eftersom administratören har tilldelat fel behörighetsnivå till en rolltilldelning på lägre nivå. Dessa attacker kan äventyra alla virtuella datorer, domäner och skogar som hanteras av den berörda datorn.

Tänk på följande säkerhetsöverväganden när du planerar att virtualisera din domänkontrollant:

  • Autentiseringsuppgifterna för den lokala administratören för en dator som är värd för virtuella skrivbara domänkontrollanter ska betraktas som likvärdiga med standardbehörigheterna för domänadministratörer för alla domäner och domänskogar som dessa domänkontrollanter tillhör.

  • Vi rekommenderar att du konfigurerar systemet så att en värd kör en Server Core-installation av Windows Server utan program förutom Hyper-V. Den här konfigurationen begränsar hur många program och servrar du installerar på servern. Den här begränsningen ger bättre systemprestanda och skapar även en minskad attackyta, där det finns färre startpunkter för skadliga attacker via program och tjänster.

  • För avdelningskontor eller andra platser som är svåra att skydda rekommenderar vi att du använder skrivskyddade domänkontrollanter (RODC). Om du har ett separat administrationsnätverk, rekommenderar vi att du endast ansluter värden till detta nätverk. För mer information om RODC, se Installera en Windows Server Active Directory Read-Only Domänkontrollant (RODC) (Nivå 200).

  • Du kan skydda dina domänkontrollanter med BitLocker. I Windows Server 2016 och senare kan du också använda den virtuella TPM-funktionen (Trusted Platform Module) som tillhandahåller det gästnyckelmaterial som krävs för att låsa upp systemvolymen.

  • Skyddad infrastruktur och avskärmade virtuella datorer kan tillhandahålla andra kontroller för att skydda dina domänkontrollanter.

Mer information om hur du skyddar domänkontrollanter finns i guiden Bästa praxis för att skydda Active Directory-installationer.

Säkerhetsgränser för värd- och gästkonfigurationer

Du kan implementera virtuella datorer (VM) på många olika typer av DC-konfigurationer. Därför måste du noga överväga hur de virtuella datorerna påverkar gränser och förtroenden för din Active Directory-topologi. I följande lista beskrivs två konfigurationer som du kan konfigurera för Active Directory-domänkontrollanter och värdar på en Hyper-V server och gästdatorer som är virtuella datorer som körs på Hyper-V-servern:

  • En värd som är en arbetsgruppsdator eller medlemsdator med en gäst som är en domänkontrollant.
  • En värd som är en arbetsgruppsdator eller en medlemsdator med en gäst som också är en arbetsgruppsdator eller medlemsdator.

Följande diagram visar en konfiguration av tre virtuella gäst-DC-datorer som finns på en Hyper-V server.

diagram som visar säkerhetsgränser i en konfiguration av tre virtuella gäst-DC-datorer som finns på en Hyper-V server.

Baserat på exempelkonfigurationen i föregående diagram bör du tänka på följande när du planerar en distribution som den här:

  • Administratörsåtkomst

    • Administratörsautentiseringsuppgifterna på värddatorn ska behandlas på samma sätt som domänadministratörens på den skrivbara domänkontrollanten. För en RODC-gäst bör administratörsautentiseringsuppgifterna för värddatorn behandlas på samma sätt som för den lokala administratören på gäst-RODC.

  • Administratörsrättigheter för domänkontrollant på värddatorn

    • En administratör av en virtualiserad data center-miljö har administratörsbehörighet på värdservern om man ansluter värdservern till samma domän. Den här åtkomstbehörigheten kan dock också ge skadliga användare en möjlighet att kompromettera alla virtuella datorer om de kan få åtkomst till vm 1. Det här scenariot skapar en möjlig attackvektor. Du kan förhindra den här attackvektorn genom att se till att alla domänkontrollanter som har konfigurerats för flera domäner eller skogar har en central administrationsdomän som är betrodd av alla inblandade domäner, och göra virtualiseringsvärden till medlem i den högt privilegierade administrationsdomänen. Denna metod förhindrar att individuella domänadministratörer styr domänvärden och därmed de andra domänerna.

  • Att undvika attacker

    • Skadliga användare kan attackera VM 1 även om du installerar den som en RODC. Även om RODC-administratörer inte uttryckligen har domänadministratörsrättigheter kan de fortfarande använda rodc för att tillämpa principer på värddatorn. Dessa principer kan till exempel innehålla startskript. Om en illvillig aktör hittar ett sätt att få RODC-administratörsrättigheter och skickar en policy med ett skadligt startskript kan de kompromettera värddatorn och använda den för att angripa andra virtuella datorer på värden.

  • Filsäkerhet för virtuell hårddisk (VHD)

    • VHD-filer för en virtuell DC är som den fysiska hårddisken för en fysisk DC. Du bör vara lika noggrann med att skydda VHD-filen som med en hårddisk. Se till att du bara tillåter tillförlitliga och betrodda administratörer att komma åt dessa VHD-filer.

  • RODCs

    • Du kan placera RODC:er på platser där fysisk säkerhet inte garanteras, till exempel avdelningskontor. Du kan skydda deras VHD-filer med hjälp av Windows BitLocker-diskkryptering från attacker på värden som involverar stöld av den fysiska disken. Dessa skydd gäller dock inte för filsystemen i RODC.

Prestandaöverväganden

64-bitarsarkitekturen Microkernel har bättre Hyper-V prestanda jämfört med tidigare virtualiseringsplattformar.

Vm-prestanda beror på vilken arbetsbelastning du använder den för. Vi rekommenderar att du testar specifika vm-topologier för att se till att du är nöjd med din Active Directory-distributionsprestanda. Du kan utvärdera prestanda under arbetsbelastningar under en viss tidsperiod med hjälp av verktyg som tillförlitlighets- och prestandaövervakaren (Perfmon.msc) eller verktygslådan Microsoft Assessment and Planning (MAP). MAP-verktyget kan också hjälpa dig att inventera alla servrar och serverroller som för närvarande finns i nätverket.

För att ge dig en uppfattning om hur testning av virtualiserade DC-prestanda fungerar skapade vi ett exempel på prestandatest med hjälp av Active Directory Performance Testing Tool (ADTest.exe).

LDAP-tester (Lightweight Directory Access Protocol) utfördes på en fysisk domänkontrollant med hjälp av ADTest.exe. Samma tester kördes på en virtualiserad domänkontrollant som bestod av en virtuell dator som finns på en server som är identisk med den fysiska domänkontrollanten. Endast en logisk processor användes i det här exemplet för den fysiska datorn och endast en virtuell processor för den virtuella datorn. Den här konfigurationen gör det möjligt för distributionen att enkelt nå 100 procent cpu-användning.

I följande tabell visas testresultaten för de fysiska och virtuella domänkontrollanterna. Bokstäverna och siffrorna i parenteser bredvid testnamnen är deras etiketter i ADTest.exe. Dessa data visar att den virtualiserade DC-prestandan var mellan 88 och 98 procent av den fysiska DC-prestandan.

Mått Test Fysisk Virtuell Delta
Sökningar per sekund Sök efter vanligt namn i basomfånget (L1) 11508 10276 -10,71%
Sökningar per sekund Sök efter en uppsättning attribut i basomfånget (L2) 10123 9005 -11.04%
Sökningar per sekund Sök efter alla attribut i basomfånget (L3) 1284 1242 -3,27%
Sökningar per sekund Sök efter vanligt namn i underträdets omfång (L6) 8613 7904 -8,23%
Lyckade bindningar/sek Utföra snabba bindningar (B1) 1438 1374 -4,45%
Lyckade bindningar per sekund Utföra enkla bindningar (B2) 611 550 -9,98%
Lyckade kopplingar per sekund Använd NTLM för att utföra bindningar (B5) 1068 1056 -1,12%
Skrivningar/sek Skriva flera attribut (W2) 6467 5885 -9,00%

För att maximera prestanda i vår testdistribution installerade vi integreringskomponenter (IC) i den här testversionen så att gästoperativsystemet kan använda hypervisormedvetna syntetiska drivrutiner. När du installerar en IC måste du ibland använda emulerad IDE (Integrated Drive Electronics) eller nätverkskortdrivrutiner. I produktionsmiljöer bör du ersätta dessa emulerade drivrutiner med syntetiska drivrutiner för att öka prestandan.

Baserat på det här testet bör du överväga följande rekommendationer för att förbättra prestanda:

  • När du övervakar prestanda för virtuella datorer med hjälp av verktyget Perfmon.msc är processorinformationen för den virtuella datorn ibland inte helt korrekt. Den här felaktigheten beror på hur den virtuella processorn är schemalagd att köras på den fysiska processorn. Om du vill ha mer exakt CPU-information för virtuella datorer som körs på Hyper-V servrar använder du räknare för Hyper-V logiska Hypervisor-processor i värdpartitionen i stället. Mer information om prestandajustering av både AD DS och Hyper-V finns i riktlinjer för prestandajustering för Windows Server.

  • Vi rekommenderar att du undviker att använda olika disk-VHD:er på en virtuell dator som konfigurerats som en domänkontrollant, eftersom olika disk-VHD:er kan minska prestandan. Mer information om Hyper-V disktyper, inklusive differentieringsdiskar, finns i Guiden för ny virtuell hårddisk.

  • Vi rekommenderar också att du bekantar dig med informationen om hur du använder AD DS i virtuella värdmiljöer genom att läsa Saker att tänka på när du är värd för Active Directory-domänkontrollanter i virtuella värdmiljöer.

Distributionsöverväganden

I följande avsnitt beskrivs vanliga metoder för virtuella datorer som du kan undvika när du distribuerar domänkontrollanter och särskilda överväganden för tidssynkronisering och lagring.

Distributionsrekommendationer

Virtualiseringsplattformar som Hyper-V har många funktioner som gör det enklare att hantera, underhålla, säkerhetskopiera och migrera datorer. Det finns dock vissa rekommendationer som du måste följa för att kunna dra nytta av dessa funktioner för dina virtuella domänkontrollanter.

  • För att säkerställa att dina Active Directory-skrivningar är beständiga ska du inte distribuera virtuella DC-databasfiler, till exempel NTDS. DIT Active Directory-databas, loggar och SYSVOL på virtuella IDE-diskar. Skapa i stället en andra virtuell hårddisk (VHD) som är ansluten till en virtuell SCSI-styrenhet (Small Computer System Interface) och se till att databasfilerna finns på den virtuella datorns SCSI-disk när du installerar domänkontrollanten.

  • Implementera inte olika disk-VHD:er på en virtuell dator som du konfigurerar som domänkontrollant. Även om den här metoden gör det enkelt att återställa distributionen till tidigare versioner, minskar även prestandan. Mer information om VHD-typer finns i guiden Ny virtuell hårddisk.

  • Distribuera inte Active Directory-domäner och skogar på en kopia av ett Windows Server OS utan att först använda systemförberedelseverktyget (sysprep) för att förbereda dem för distribution. Mer information om hur du kör Sysprep finns i översikten Sysprep (systemförberedelse).

    Varning

    Att köra Sysprep på en upphöjd domänkontrollant rekommenderas inte eftersom det kan påverka AD-databasen och relaterade komponenter negativt och orsaka följande problem:

    • Dataförlust
    • AD-databasskada
    • Problem med stabilitet och funktioner
    • Problem med program, tjänster och drivrutiner

  • Distribuera inte andra domänkontrollanter med en kopia av en VHD-fil från en domänkontrollant som du redan har distribuerat. Genom att inte använda kopior förhindras potentiella USN-återställningsscenarier. Mer information om USN-återställning finns i USN och USN-återställning.

    • I Windows Server 2012 och senare kan administratörer klona DC-avbildningar för att distribuera fler domänkontrollanter, men bara om de använder korrekt förberedda avbildningar.

  • Använd inte funktionen Hyper-V Export för att exportera en virtuell dator som kör en domänkontrollant.

    • I Windows Server 2012 och senare hanterar systemet export och import av virtuella DC-gäster som en icke-auktoritativ återställning. Den här processen identifierar om generations-ID:t har ändrats och om DC:n inte är konfigurerad för kloning.

    • När du exporterar en virtuell gästdator måste du se till att ingen använder den. För att göra det enklare kan du använda Hyper-V Replication för att skapa en inaktiv kopia av domänkontrollanten. När du börjar använda den replikerade avbildningen måste du också utföra rensningen på samma sätt som för källbilden när du har exporterat en DC-gästbild.

Fysisk till virtuell konvertering

Med System Center VM Manager (VMM) kan du hantera fysiska datorer och virtuella datorer på ett enhetligt sätt. Du kan också använda VMM för att migrera en fysisk dator till en virtuell dator. Den här migreringsprocessen kallas fysiskto-VM konverteringeller P2V-konvertering. För att starta P2V-konverteringsprocessen måste du se till att den virtuella datorn och den fysiska domänkontrollanten som du migrerar inte körs samtidigt. Att säkerställa att de två maskinerna inte är i drift samtidigt förhindrar USN-återställningsscenarier, så som beskrivs i USN och USN-återställning.

Du bör utföra P2V-konvertering i offlineläge så att katalogdata förblir konsekventa när du slår på domänkontrollanten igen. Du kan växla offlineläge i installationsprogrammet Konvertera fysisk server. Mer information om hur du använder offlineläge finns i P2V: Konvertera fysiska datorer till virtuella datorer i VMM.

Du bör också koppla från den virtuella datorn från nätverket under P2V-konverteringen. Du bör bara aktivera nätverkskortet när du har slutfört konverteringsprocessen och kontrollera att allt fungerar. Då bör du inaktivera den fysiska källdatorn. Aktivera inte den fysiska källdatorn igen och återanslut den till nätverket förrän du har formaterat om hårddisken.

Att undvika USN-återställning

När du skapar virtuella domänkontrollanter bör du undvika att skapa USN-återställningsscenarier. För att undvika återställning kan du konfigurera en ny virtuell domänkontrollant med regelbunden befordran, befordran från Installera från media (IfM) eller genom att klona domänkontrollanten om du redan har minst en virtuell domänkontrollant. Med den här metoden kan du också undvika maskinvaru- eller plattformsproblem som P2V-konverterade virtuella gäster kan stöta på.

Varning

Om du vill förhindra problem med Active Directory-replikering kontrollerar du att det bara finns en fysisk eller virtuell domänkontrollant i ett visst nätverk när som helst. Du kan minska sannolikheten för att den gamla klonen är ett problem med någon av följande metoder:

  • När den nya virtuella domänkontrollanten körs kör du följande kommando två gånger för att ändra lösenordet för datorkontot:

    netdom resetpwd /Server:<domain-controller>

  • Exportera och importera den nya virtuella gästen för att tvinga den att bli ett nytt generations-ID och ett databasanrops-ID.

Testa miljöer och P2V-migrering

Du kan använda P2V-migrering i kombination med VMM för att skapa testmiljöer. Med den här metoden kan du migrera produktions-DC:er från fysiska datorer till virtuella datorer för att skapa en testmiljö utan att permanent ta bort produktions-DC:erna. Du måste dock bygga testmiljön i ett separat nätverk från produktionsmiljön för att tillåta två instanser av samma domänkontrollant att existera. Det är viktigt att undvika USN-återställningar när du skapar testmiljöer genom P2V-migrering.

Skapa en testmiljö

Vi rekommenderar att du gör följande när du skapar testmiljöer med P2V:

  • Migrera en domänkontrollant i produktion från varje domän till en virtuell testdator med hjälp av P2V baserat på rekommendationerna i fysisk till virtuell konvertering.

  • Placera de fysiska produktionsdatorerna och de virtuella testdatorerna i olika nätverk när du tar dem online igen.

  • Om du vill undvika USN-återställningar i testmiljön, koppla bort alla domänkontrollanter som du planerar att migrera från nätverket. Du kan koppla från dina domänkontrollanter genom att stoppa NTDS-tjänsten eller starta om servrarna i Katalogtjänsternas återställningsläge (DSRM).

  • Introducera inga nya uppdateringar i miljön efter att du har kopplat från domänkontrollanterna från nätverket.

  • Anslut inte någon av datorerna till nätverket under P2V-migreringen. Du kan bara återansluta dem när du har migrerat alla datorer.

  • Du bör bara promovera test-DC:er som du har skapat efter P2V-konverteringen som repliker i testmiljön.

Tidstjänst och synkronisering

För virtuella datorer som du har konfigurerat som domänkontrollanter rekommenderar vi att du inaktiverar tidssynkronisering mellan värdsystemet och gästoperativsystemet som fungerar som en domänkontrollant. Om gäst-DC inte synkroniseras med värdsystemet synkroniseras den med domänhierarkin i stället.

Om du vill inaktivera Hyper-V tidssynkroniseringsprovidern inaktiverar du den virtuella datorn och går sedan till inställningarna för den virtuella datorn, väljer Integration Services och avmarkerar kryssrutan Time synchronization.

Lagring och optimering

Vi rekommenderar att du följer lagringsrekommendationerna i det här avsnittet för att optimera dina prestanda för virtuella dc-datorer och se till att dina Active Directory-skrivningar är hållbara.

  • För gästlagring lagrar du Active Directory-databasfilen (Ntds.dit) och logg- och SYSVOL-filerna på en separat virtuell disk från OS-filerna. Vi rekommenderar att du lagrar dessa filer på en virtuell SCSI-disk i en andra virtuell hårddisk som är ansluten till en virtuell SCSI-styrenhet. En virtuell SCSI-disk ökar prestandan och stöder Tvingad Enhetsåtkomst (FUA). Med FUA skriver och läser operativsystemet direkt från media och kringgår eventuella cachelagringsmekanismer.

  • Om du använder BitLocker för att skydda din virtuella DC-gäst konfigurerar du de extra volymerna för automatisk upplåsning med hjälp av Enable-BitLockerAutoUnlock PowerShell-cmdlet.

  • När du lagrar VHD-filer på värdar bör du använda en disk som inte används ofta av andra tjänster eller program, till exempel systemdisken för värdoperativsystemet. Lagra varje VHD-fil på en separat partition från värdoperativsystemet och andra VHD-filer, helst på en separat fysisk enhet.

  • Ditt fysiska värddisksystem måste uppfylla minst ett av följande villkor för att uppfylla kraven på virtualiserad arbetsbelastningsdataintegritet:

    • Värden använder diskar av servrarklass, till exempel SCSI eller Fibre Channel.

    • Värden ser till att diskarna är anslutna till en batteribaserad cachelagrings-HBA.

    • Värden använder en lagringskontrollant som en redundant matris med oberoende disksystem (RAID) som lagringsenhet.

    • Värden använder en avbrottsfri strömförsörjning (UPS) för att driva disken.

    • Värden inaktiverar diskens funktion för skrivcachelagring som standardinställning.

  • När du använder VHD-filer rekommenderar vi att du använder direktdiskar eller virtuella hårddiskar med fast storlek eftersom de är optimerade för prestanda. Vi rekommenderar inte dynamiskt utökande och differensierande diskar eftersom de kan orsaka fördröjningar, prestandaförsämring under hög diskaktivitet och potentiell dataförlust när man återställer till en tidigare ögonblicksbild.

  • Vi rekommenderar att du använder virtuella SCSI-styrenheter för att minska risken för att dina Active Directory-data skadas.

    • På Hyper-V-servrar som är värdar för virtuella domänkontrollanter bör du använda fysiska SCSI-diskar. Om ditt scenario inte låter dig använda SCSI-enheter bör du inaktivera skrivcachelagring på den ATA-enhet (Advanced Technology Attachment) eller IDE-enhet (Integrated Drive Electronics) som du använder i stället. Mer information finns i Händelse-ID 1539 – Databasintegritet.

Driftbegränsningar för virtuella datordomänkontrollanter

Domänkontrollanter som körs på virtuella datorer har driftsbegränsningar som inte gäller för domänkontrollanter som körs på fysiska datorer. När du använder en virtualiserad domänkontrollant måste du följa dessa riktlinjer:

  • Pausa, stoppa eller lagra inte det sparade tillståndet för en DC på en virtuell dator längre än tombstonelivstid för skogen. Om du återupptar ett sparat tillstånd som du har pausat eller sparat längre än den tillåtna tiden (tombstone-livslängden) kan det störa replikeringen. För information om hur du fastställer tombstonens livslängd för skogen, se Fastställa tombstonens livslängd för skogen.

  • Kopiera eller klona inte virtuella hårddiskar.

  • Ta inte eller använd inte ögonblicksbilder av virtuella domänkontrollanter. Du bör använda en mer permanent och tillförlitlig säkerhetskopieringsmetod i stället.

  • Använd inte exportfunktionen på en virtuell dator som kör en domänkontrollant.

  • Återställ inte eller återställ inte din domänkontrollant eller innehållet i en Active Directory-databas med hjälp av en säkerhetskopieringsmetod som inte stöds.

Överväganden för säkerhetskopiering och återställning

Du måste säkerhetskopiera dina domänkontrollanter för att förhindra dataförlust på grund av katastrofscenarier eller administrativa fel. Den säkerhetskopieringsmetod som stöds av Active Directory är att genom att använda ett säkerhetskopieringsprogram återställa en säkerhetskopia av systemtillståndet från den aktuella installationen av domänkontrollanten. Programmet ska vara kompatibelt med Active Directory, till exempel Windows Server Backup. För mer information om stödda säkerhetskopieringsmetoder, se steg-för-steg-guiden AD DS-säkerhetskopiering och återställning.

I virtualiserade distributioner måste du vara särskilt uppmärksam på vissa krav för säkerhetskopieringsåtgärder i Active Directory. Om du till exempel återställer en domänkontrollant med hjälp av en kopia av VHD-filen och du inte uppdaterar databasversionen av domänkontrollanten efter återställningen kan det orsaka problem med replikeringen på grund av felaktiga spårningsnummer bland DC-replikerna. I de flesta fall identifierar inte replikeringen det här problemet och rapporterar inga fel, men inkonsekvenser mellan domänkontrollanter kan potentiellt orsaka problem i vissa scenarier.

Den metod som vi rekommenderar att du använder för att säkerhetskopiera och återställa dina virtualiserade domänkontrollanter är att köra Windows Server Backup i gästoperativsystemet. Mer information finns i Återställa en virtuell domänkontrollant.

Även om du tekniskt sett kan använda ögonblicksbilder eller kopior av VHD-filer för att återställa en säkerhetskopia rekommenderar vi inte att du använder dessa metoder av följande skäl:

  • Om du kopierar eller klonar en VHD-fil blir databasen inaktuell eftersom dess databasversionsnummer inte uppdateras automatiskt när du återställer den. Den här inkonsekvensen i spårningsnummer innebär att om du startar den virtuella hårddisken i normalt läge kan du potentiellt orsaka en USN-återställning.

  • Windows Server 2016 och senare är kompatibelt med ögonblicksbilder, men ögonblicksbilder ger inte den typ av stabil, permanent säkerhetskopieringshistorik som du behöver för att konsekvent återställa systemet under katastrofscenarier. Vss-baserade ögonblicksbilder (Volume Shadow Copy Service) som du kan skapa i Windows Server 2016 Hyper-V och senare är inte heller kompatibla med BitLocker, vilket kan orsaka potentiella säkerhetsproblem. Det här problemet hindrar Active Directory-databasmotorn från att komma åt databasen som innehåller ögonblicksbilden när Hyper-V försöker montera ögonblicksbildsvolymen.

Anmärkning

Det skärmade VM-projektet som beskrivs i Skyddad infrastrukturresurs och avskärmade virtuella datorer har en Hyper-V värddriven säkerhetskopiering som ett icke-mål för maximalt dataskydd för den virtuella gästdatorn.

USN- och USN-återställning

I det här avsnittet beskrivs replikeringsproblem som kan uppstå till följd av en felaktig återställning av Active Directory-databasen med en äldre version av en virtuell dator. Mer information om Active Directory-replikeringsprocessen finns i Active Directory-replikeringsbegrepp.

Så använder AD DS och DCs USN

AD DS använder USN för att hålla reda på replikering av data mellan domänkontrollanter. Varje gång du ändrar data i katalogen ökar USN för att indikera en ny ändring.

Destinations-DC:er använder USN:er för att spåra uppdateringar för varje katalogpartition de lagrar. USN spårar också statusen för varje domänkontrollant som lagrar repliker av dessa katalogpartitioner. När domänkontrollanter replikerar ändringar till varandra frågar de sina replikeringspartner om ändringar med USN som är större än den senaste ändringen som domänkontrollanten tog emot från sin partner.

Du hittar tabellerna för replikeringsmetadata som innehåller USN i up-to-dateness-vektorn och högvattenmärket. Både käll- och mål-DC:erna använder dessa tabeller för att filtrera nödvändiga uppdateringar för måldomänkontrollanten.

Måldomänkontrollanten underhåller up-todateness-vektor tabellen för att spåra inkommande uppdateringar som den tar emot från alla käll-domänkontrollanter. När en måldomänkontrollant begär ändringar för en katalogpartition tillhandahåller den sin up-to-dateness-vektor till källdomänkontrollanten. Källdomänkontrollanten använder sedan det här värdet för att filtrera uppdateringarna som skickas till måldomänkontrollanten. Käll-DC skickar sin up-to-dateness-vektor till mål-DC när en lyckad replikeringscykel har slutförts. Källdomänkontrollanten använder USN för att spåra om måldomänkontrollanten synkroniseras med de ursprungliga uppdateringarna vid varje domänkontrollant och att uppdateringarna till målen är på samma nivå som källan.

Måldomänkontrollanten har tabellen med högvattenmärke för att spåra de senaste ändringarna som den fått från en specifik käll-DC för en specifik partition. Tabellen med högvattenmärke förhindrar att källdomänkontrollanten skickar ut ändringar som måldomänkontrollanten redan har tagit emot från den.

Identitet för katalogdatabas

Utöver USN håller domänkontrollanter koll på katalogdatabasen för källreplikeringspartner. Systemet underhåller identiteten för katalogdatabasen som körs på servern separat från identiteten för själva serverobjektet. Katalogdatabasidentiteten för varje domänkontrollant lagras i attributet invocationID för objektet NTDS Settings, som finns under Lightweight Directory Access Protocol (LDAP)-sökvägen cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*.

Systemet lagrar serverobjektets identitet i attributet objectGUID för NTDS Settings-objektet. Serverobjektets identitet ändras aldrig. Katalogdatabasens identitet ändras dock under följande omständigheter:

  • När en återställningsprocedur för systemtillstånd inträffar på servern.

  • När du lägger till en programkatalogpartition på servern tar du bort den och lägger sedan till den igen.

  • När en Hyper-V instans utlöser sina VSS-skrivare på en partition som innehåller en virtuell domänkontrollants virtuella hårddisk.

    I det här scenariot aktiverar gästen sina egna VSS-komponenter. Den här åtgärden är samma mekanism som säkerhetskopierings- och återställningsprocessen använder. Den här metoden återställer attributet invocationID.

Attributet invocationID relaterar en uppsättning ursprungliga uppdateringar på en domänkontrollant med en specifik version av katalogdatabasen. up-to-dateness-vektorn och tabellerna med högvattenmärke använder respektive invocationID och DC GUID. Detta gör att domänkontrollanterna kan känna igen vilken kopia av Active Directory-databasen som replikeringsinformationen kommer från.

Attributet invocationID är ett globalt unikt identifierarvärde (GUID) som visas längst upp i utdata när du har kört kommandot repadmin /showrepl. Följande text representerar exempelutdata från kommandot:

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

När du återställer AD DS på en domänkontrollant återställer systemet attributet invocationID. Den här ändringen ökar replikeringstrafiken, med varaktighet i förhållande till storleken på partitionen som du replikerar.

För att demonstrera det här scenariot visar följande diagram en exempelmiljö där den virtuella domänkontrollanten VDC1 och domänkontrollanten DC2 är två domänkontrollanter i samma domän. Det här diagrammet visar hur DC2 identifierar det invocationID värdet i VDC1 efter en återställning i ett återställningsscenario som stöds.

diagram som visar scenariot när värdet för anrops-ID återställs korrekt.

USN-återställning

USN-återställning sker när systemet inte kan uppdatera ett USN som vanligt, när en användare kringgår USN-uppdateringar eller när en domänkontrollant försöker använda ett USN som är lägre än dess senaste uppdatering. När systemet identifierar en USN-återställning stoppas replikeringen innan ojämnheten kan orsaka avvikelser i skogsstrukturen.

Många faktorer kan orsaka en USN-återställning. Det kan till exempel inträffa om du använder gamla VHD-filer eller utför P2V-konvertering utan att permanent koppla från den fysiska datorn efter konverteringen.

Förhindra USN-återgång

Du kan förhindra USN-återställningar genom att vidta dessa försiktighetsåtgärder:

  • När du inte kör Windows Server 2012 eller senare ska du inte ta eller använda en ögonblicksbild av en virtuell DC-dator.

  • Kopiera inte DC VHD-filen.

  • När du inte kör Windows Server 2012 eller senare bör du inte exportera en VM som kör en DC.

  • Endast återställ en domänkontrollant eller innehållet i en Active Directory-databas med hjälp av stödda förstapartslösningar för säkerhetskopiering, till exempel Windows Server Backup.

Ibland kan systemet inte identifiera USN-återställning innan det kan orsaka replikeringsfel. När du stöter på replikeringsfel måste du identifiera problemets omfattning och åtgärda det så snart som möjligt. Mer information om hur du tar bort kvardröjande objekt som kan uppstå till följd av en USN-rollback finns i Active Directory-replikering Händelse-ID 1388 eller 1988: Ett kvardröjande objekt är upptäckt.

USN-tillbakagångsdetektering

I de flesta fall kan systemet identifiera USN-återställningar genom att spåra inkonsekvenser i attributet invocationID som orsakas av återställning av en domänkontrollant utan att nollställa attributet. Windows Server 2008 ger skydd mot replikeringsfel efter icke-stödda DC-återställningsoperationer. Dessa skyddsåtgärder utlöses när en icke-stödd återställning skapar USN som är lägre än de ursprungliga versionerna, vilket representerar ändringar som replikeringspartner redan har tagit emot.

I Windows Server, när en mål-DC begär ändringar med ett tidigare använt USN, tolkar mål-DC replikeringspartnerns svar så att dess replikeringsmetadata är inaktuella. Inaktuella metadata innebär att Active Directory-databasen på källdomänkontrollanten återställdes till ett tidigare tillstånd, så systemet svarar därefter.

Anta till exempel att en virtuell dators VHD-fil återställdes till en tidigare version. I det här fallet initierar måldomänkontrollanten följande karantänåtgärder för den domänkontrollant som har identifierats som ha genomgått en återställning som inte stöds.

  • AD DS pausar Net Logon-tjänsten, vilket förhindrar att användarkonton och datorkonton ändrar kontolösenord. Den här åtgärden förhindrar förlust av sådana ändringar om de inträffar efter en felaktig återställning.

  • AD DS inaktiverar inkommande och utgående Active Directory-replikering.

  • AD DS genererar händelse-ID 2095 i händelseloggen för Katalogtjänsten för att registrera vad som hände.

Följande diagram visar sekvensen av händelser som inträffar när AD DS identifierar USN-återställning på VDC2, mål-DC:n som körs på en virtuell dator. I den här illustrationen sker upptäckten av USN-återställning på VDC2 när en replikeringspartner upptäcker att VDC2 skickade ett USN-värde för tidsstämpel up-tosom tidigare observerats av destination DC:n. Det här villkoret anger att VDC2-databasen har genomgått en återställning.

Diagram som visar vad som händer när USN-tillbakaställning upptäcks.

Lösa problem med händelse-ID 2095

Om händelse-ID 2095 visas i händelseloggen för Katalogtjänsten följer du dessa instruktioner omedelbart:

  1. Isolera den virtuella dator som registrerade felet från nätverket.

  2. Kontrollera om de rapporterade ändringarna kommer från den här domänkontrollanten och sprids till andra domänkontrollanter. Om händelsen berodde på att en ögonblicksbild eller en kopia av en virtuell dator användes kan du försöka ta reda på när USN-återställningen inträffade. När du har tid kan du kontrollera replikeringspartnerna för den DC för att avgöra om replikeringen ägde rum efter återställningen.

    Du kan använda verktyget Repadmin för att kontrollera var ändringarna kommer ifrån. Information om hur du använder Repadmin finns i Övervakning och felsökning av Active Directory-replikering med Repadmin. Om du inte kan fatta ett beslut kontaktar du Microsoft Support om du behöver hjälp.

  3. Tvångsmässigt förpassa DC till en lägre nivå. Den här åtgärden omfattar rensning av domänkontrollantens metadata och övertagande av operationsmasterrollerna, kallade FSMO-roller (flexible single master operations). Mer information finns i Återställ från USN-återställning.

  4. Ta bort alla tidigare VHD-filer för domänkontrollanten.

Oupptäckt USN-återställning

Domänkontrollanten kanske inte identifierar USN-återställning i följande scenarier:

  • VHD-filen är kopplad till olika virtuella datorer som körs på flera platser samtidigt.

  • USN på den återställda domänkontrollanten ökade och översteg det senaste USN som mottagits av den andra domänkontrollanten.

I scenariot med VHD-filen kan andra domänkontrollanter replikera med någon av de virtuella datorerna, och ändringar kan ske på någon av de virtuella datorerna utan att replikeras till den andra. Den här skillnaden i skogen är svår att identifiera och orsakar oförutsägbara katalogsvar. Den här situationen kan inträffa efter en P2V-migrering om både den fysiska domänkontrollanten och den virtuella datorn körs i samma nätverk. Den här situationen kan också inträffa om flera virtuella domänkontrollanter skapas från samma fysiska domänkontrollant och sedan körs i samma nätverk.

I USN-scenariot gäller ett intervall med USN för två olika uppsättningar med ändringar. Det här scenariot kan fortsätta under längre perioder utan att identifieras. När du ändrar ett objekt som du skapade under den här perioden identifierar systemet ett kvardröjande objekt och rapporterar det som händelse-ID 1988 i Loggboken. Följande diagram visar varför domänkontrollanten (DC) kanske inte upptäcker USN-återställning i det här scenariot.

diagram som visar ett scenario där USN-återställning inte identifieras.

Skrivskyddade domänkontrollanter

Skrivskyddade domänkontrollanter (RODC) är domänkontrollanter som är värdar för skrivskyddade kopior av partitionerna i en Active Directory-databas. RODC:ar undviker de flesta USN-återställningsproblem eftersom de inte replikerar ändringar till de andra domänkontrollanterna. Men om en RODC replikeras från en skrivbar domänkontrollant som påverkas av en USN-återställning, så påverkas även RODC av återställningen.

Vi rekommenderar inte att du använder en ögonblicksbild för att återställa en RODC. Du bör bara återställa en RODC med hjälp av ett Active Directory-kompatibelt säkerhetskopieringsprogram. Precis som med skrivbara domänkontrollanter får du inte heller tillåta att en RODC är offline under mer än tombstone-livslängden. Det här villkoret kan resultera i kvardröjande objekt på RODC.

Mer information om hur du implementerar RODC:er finns i guiden "Steg-för-steg för domänkontrollanter" Read-Only.

Ytterligare innehåll

Lär dig hur du återställer virtualiserade domänkontrollanter på Återställ virtualiserade domänkontrollanter.