Dela via

Konfigurera haveriberedskap för Active Directory och DNS

Företagsprogram som SharePoint, Dynamics AX och SAP är beroende av Active Directory och en DNS-infrastruktur för att fungera korrekt. När du konfigurerar haveriberedskap för program måste du ofta återställa Active Directory och Domain Name System (DNS) innan du återställer andra programkomponenter för att säkerställa rätt programfunktioner.

Du kan använda Site Recovery för att skapa en haveriberedskapsplan för Active Directory. När ett avbrott inträffar kan du initiera en övergång. Active Directory kan vara igång på några minuter. Om du har distribuerat Active Directory för flera applikationer på din primära sajt, till exempel för SharePoint och SAP, kanske du vill genomföra en failover för hela sajten. Du kan först växla över Active Directory med hjälp av Site Recovery. Växla sedan över de andra applikationerna med hjälp av applikationsspecifika återställningsplaner.

Den här artikeln beskriver hur du skapar en haveriberedskapslösning för Active Directory. Den innehåller krav och instruktioner för redundans. Du bör känna till Active Directory och Site Recovery innan du börjar.

Förutsättningar

Replikera domänkontrollanten

  • Du måste konfigurera Site Recovery-replikering på minst en virtuell dator (VM) som är värd för en domänkontrollant eller DNS.
  • Om du har flera domänkontrollanter i din miljö måste du också konfigurera ytterligare en domänkontrollant på målplatsen. Den ytterligare domänkontrollanten kan finnas i Azure eller i ett sekundärt lokalt datacenter.
  • Om du bara har ett fåtal program och en domänkontrollant kanske du vill växla över hela webbplatsen. I det här fallet rekommenderar vi att du använder Site Recovery för att replikera domänkontrollanten till målplatsen, antingen i Azure eller i ett sekundärt lokalt datacenter. Du kan använda samma replikerade domänkontrollant eller virtuella DNS-dator för redundanstest.
  • Om du har många program och fler än en domänkontrollant i din miljö, eller om du planerar att redundansväxla några program åt gången, förutom att replikera den virtuella domänkontrollantens virtuella dator med Site Recovery, rekommenderar vi att du konfigurerar ytterligare en domänkontrollant på målplatsen (antingen i Azure eller i ett sekundärt lokalt datacenter). För failovertest kan du använda en domänkontrollant som replikeras av Site Recovery. För redundans kan du använda ytterligare domänkontrollant på målplatsen.

Aktivera skydd med Site Recovery

Du kan använda Site Recovery för att skydda den virtuella datorn som är värd för domänkontrollanten eller DNS.

Skydda den virtuella datorn

Domänkontrollanten som replikeras med hjälp av Site Recovery används för redundanstest. Se till att den uppfyller följande krav:

  1. Domänkontrollanten är en global katalogserver.
  2. Domänkontrollanten ska vara FSMO-rollägaren (Flexible Single Master Operations) för roller som behövs under ett redundanstest. Annars måste dessa roller tas i beslag efter redundansväxlingen.

Konfigurera nätverksinställningar för virtuella datorer

För den virtuella dator som är värd för domänkontrollanten eller DNS i Site Recovery konfigurerar du nätverksinställningar under Nätverksinställningarna för den replikerade virtuella datorn. Detta säkerställer att den virtuella datorn är ansluten till rätt nätverk efter redundansväxlingen.

Skydda Active Directory

Plats-till-plats-skydd

Skapa en domänkontrollant på den sekundära platsen. När du befordrar servern till en domänkontrollantroll anger du namnet på samma domän som används på den primära platsen. Du kan använda snapin-modulen Active Directory-platser och -tjänster för att konfigurera inställningar för platslänkobjektet som platserna läggs till i. Genom att konfigurera inställningar på en platslänk kan du styra när replikeringen sker mellan två eller flera platser och hur ofta den inträffar. Mer information finns i Schemalägga replikering mellan platser.

Plats-till-Azure-skydd

Skapa först en domänkontrollant i ett virtuellt Azure-nätverk. När du befordrar servern till en domänkontrollantroll anger du samma domännamn som används på den primära platsen.

Konfigurera sedan om DNS-servern för det virtuella nätverket för att använda DNS-servern i Azure.

Azure-nätverk

Azure-till-Azure-skydd

Skapa först en domänkontrollant i ett virtuellt Azure-nätverk. När du befordrar servern till en domänkontrollantroll anger du samma domännamn som används på den primära platsen.

Konfigurera sedan om DNS-servern för det virtuella nätverket för att använda DNS-servern i Azure.

Överväganden för att testa redundans

För att undvika påverkan på produktionsarbetsbelastningar sker redundanstestet i ett nätverk som är isolerat från produktionsnätverket.

De flesta program kräver närvaro av en domänkontrollant eller en DNS-server. För att applikationen inte ska misslyckas, måste du skapa en domänkontrollant i det isolerade nätverket som ska användas för att testa failover. Det enklaste sättet att göra detta är att använda Site Recovery för att replikera en virtuell dator som är värd för en domänkontrollant eller DNS. Kör sedan ett failover-test för den virtuella domänkontrollanten innan du kör ett failover-test av återställningsplanen för programmet.

  1. Använd Site Recovery för att replikera den virtuella datorn som är värd för domänkontrollanten eller DNS.

  2. Skapa ett isolerat nätverk. Alla virtuella nätverk som du skapar i Azure är isolerade från andra nätverk som standard. Vi rekommenderar att du använder samma IP-adressintervall för det här nätverket som du använder i produktionsnätverket. Aktivera inte plats-till-plats-anslutning i det här nätverket.

  3. Ange en DNS IP-adress i det isolerade nätverket. Använd DEN IP-adress som du förväntar dig att den virtuella DNS-datorn ska hämta. Om du replikerar till Azure anger du IP-adressen för den virtuella dator som används vid redundansväxling. Om du vill ange IP-adressen går du till den replikerade virtuella datorn och i nätverksinställningarna väljer du IP-målinställningarna .

    Azure-testnätverk

    Tips

    Site Recovery försöker skapa virtuella testdatorer i ett undernät med samma namn och med samma IP-adress som anges i nätverksinställningarna för den virtuella datorn. Om ett undernät med samma namn inte är tillgängligt i det virtuella Azure-nätverk som tillhandahålls för redundanstest skapas den virtuella testdatorn i det alfabetiskt första undernätet.

    Om mål-IP-adressen är en del av det valda undernätet försöker Site Recovery skapa den virtuella datorn för redundanstest med hjälp av mål-IP-adressen. Om mål-IP inte ingår i det valda undernätet skapas den virtuella datorn för redundanstest med hjälp av nästa tillgängliga IP-adress i det valda undernätet.

Testa växling till en sekundär anläggning

  1. Om du replikerar till en annan lokal plats och använder DHCP konfigurerar du DNS och DHCP för redundanstest.
  2. Gör ett redundanstest för den virtuella domänkontrollantdator som körs i det isolerade nätverket. Använd den senaste tillgängliga programkonsekventa återställningspunkten för domänkontrollantens virtuella maskin för att utföra teståterställning.
  3. Kör ett redundanstest för återställningsplanen som innehåller virtuella datorer som programmet körs på.
  4. När testningen är klar rensar du redundanstestet på den virtuella domänkontrollantens virtuella dator. Det här steget tar bort domänkontrollanten som skapades för redundanstest.

Ta bort referenser till andra domänkontrollanter

När du initierar ett redundanstest ska du inte ta med alla domänkontrollanter i testnätverket. Om du vill ta bort referenser till andra domänkontrollanter som finns i produktionsmiljön kan du behöva ta över FSMO Active Directory-roller och rensa metadata för saknade domänkontrollanter.

Problem som orsakas av virtualiseringsskydd

Viktigt!

Vissa av de konfigurationer som beskrivs i det här avsnittet är inte standardkonfigurationer för domänkontrollanter. Om du inte vill göra dessa ändringar i en produktionsdomänkontrollant kan du skapa en domänkontrollant som är dedikerad för Site Recovery att använda för redundanstest. Gör endast dessa ändringar i domänkontrollanten.

Från och med Windows Server 2012 är ytterligare skydd inbyggda i Active Directory-domän Services (AD DS). Dessa skydd hjälper till att skydda virtualiserade domänkontrollanter mot återställningar av uppdateringssekvensnummer (USN) om den underliggande hypervisor-plattformen stöder VM-GenerationID. Azure stöder VM-GenerationID. Därför har domänkontrollanter som kör Windows Server 2012 eller senare på virtuella Azure-datorer dessa ytterligare skydd.

När VM-GenerationID återställs återställs även värdet InvocationID för AD DS-databasen. Dessutom ignoreras den relativa ID-poolen (RID) och SYSVOL mappen markeras som icke-auktoritativ. Mer information finns i Introduktion till Active Directory-domän Services-virtualisering och Virtualisering av distribuerad filsystemreplikering (DFSR) på ett säkert sätt.

Om du växlar över till Azure kan det leda till att VM-GenerationID återställs. Återställning av VM-GenerationID utlöser ytterligare skydd när den virtuella domänkontrollantens virtuella dator startar i Azure. Detta kan leda till en betydande fördröjning i att kunna logga in på den virtuella domänkontrollantens virtuella dator.

Eftersom den här domänkontrollanten endast används i ett redundanstest är virtualiseringsskydd inte nödvändiga. För att säkerställa att värdet VM-GenerationID för den virtuella domänkontrollanten inte ändras kan du ändra värdet för följande DWORD till 4 i den lokala domänkontrollanten:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gencounter\Start

Symtom på virtualiseringsskydd

Om virtualiseringsskydd utlöses efter ett redundanstest kan du se ett eller flera av följande symtom:

  • Värdet för GenerationID ändras:

  • Värdet för InvocationID ändras:

  • SYSVOL mappen och NETLOGON delningarna är inte tillgängliga.

    SYSVOL-mappdelning

    NtFrs SYSVOL-katalog

  • DFSR-databaser tas bort.

Felsöka problem med domänkontrollanter under redundanstest

Viktigt!

Vissa av de konfigurationer som beskrivs i det här avsnittet är inte standardkonfigurationer för domänkontrollanter. Om du inte vill göra dessa ändringar i en produktionsdomänkontrollant kan du skapa en domänkontrollant som är dedikerad för Site Recovery-testredundans. Gör bara ändringarna i den dedikerade domänkontrollanten.

  1. I kommandotolken kör du följande kommando för att kontrollera om SYSVOL mappen och NETLOGON mappen delas:

    NET SHARE

  2. Kör följande kommando i kommandotolken för att säkerställa att domänkontrollanten fungerar korrekt:

    dcdiag /v > dcdiag.txt

  3. Leta efter följande text i utdataloggen. Texten bekräftar att domänkontrollanten fungerar korrekt.

    • passed test Connectivity
    • passed test Advertising
    • passed test MachineAccount

Om de föregående villkoren är uppfyllda är det troligt att domänkontrollanten fungerar korrekt. Om så inte är fallet, slutför följande steg:

  1. Gör en auktoritativ återställning av domänkontrollanten. Tänk på följande information:

  2. Kringgå det inledande synkroniseringskravet genom att ange följande registernyckel till 0 i den lokala domänkontrollanten. Om den DWORD inte finns kan du skapa den under noden Parametrar .

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

    Mer information finns i Felsöka DNS-händelse-ID 4013: DNS-servern kunde inte läsa in AD-integrerade DNS-zoner.

  3. Inaktivera kravet på att en global katalogserver ska vara tillgänglig för att verifiera användarens inloggning. För att göra detta anger du följande registernyckel till 1 i den lokala domänkontrollanten. Om DWORD inte finns, kan du skapa den under Lsa-noden.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures

    Mer information finns i Så här fungerar den globala katalogen.

DNS och domänkontrollant på olika datorer

Om du kör domänkontrollanten och DNS på samma virtuella dator kan du hoppa över den här proceduren.

Om DNS inte finns på samma virtuella dator som domänkontrollanten måste du skapa en virtuell DNS-dator för redundanstestet. Du kan använda en ny DNS-server och skapa alla nödvändiga zoner. Om din Active Directory-domän till exempel är contoso.comkan du skapa en DNS-zon med namnet contoso.com. Posterna som motsvarar Active Directory måste uppdateras i DNS enligt följande:

  1. Kontrollera att de här inställningarna finns på plats innan någon annan virtuell dator i återställningsplanen startar:

    • Zonen måste namnges efter skogens rotnamn.
    • Zonen måste vara filbaserad.
    • Zonen måste vara aktiverad för säkra och icke-säkra uppdateringar.
    • Lösaren för den virtuella maskinen som kör domänkontrollern ska peka på IP-adressen för den virtuella DNS-maskinen.

  2. Kör följande kommando på den virtuella dator som är värd för domänkontrollanten:

    nltest /dsregdns

  3. Kör följande kommandon för att lägga till en zon på DNS-servern, tillåta icke-säkerhetsuppdateringar och lägga till en post för zonen i DNS:

    dnscmd /zoneadd contoso.com  /Primary

dnscmd /recordadd contoso.com  contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1

dnscmd /recordadd contoso.com %computername%  A <IP_OF_DNS_VM>

dnscmd /config contoso.com /allowupdate 1

Nästa steg

Läs mer om att skydda företagsarbetsbelastningar med Azure Site Recovery.