En Windows Server-domänkontrollant loggar Directory Services-händelse 2095 när en USN-återställning påträffas

  • Artikel

Den här artikeln beskriver hur du identifierar och återställer om en Windows Server-domänkontrollant återställs felaktigt med hjälp av en avbildningsbaserad installation av operativsystemet.

              Gäller för: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Ursprungligt KB-nummer: 875495

Obs!

Den här artikeln är endast avsedd för tekniska supportagenter och IT-proffs. Om du behöver hjälp med ett problem kan du fråga Microsoft Community.

Sammanfattning

Den här artikeln beskriver ett tyst Active Directory-replikeringsfel som orsakas av en återställning av uppdateringssekvensnummer (USN). En USN-återställning sker när en äldre version av en Active Directory-databas återställs felaktigt eller klistras in på plats.

När en USN-återställning sker replikeras inte ändringar av objekt och attribut som sker på en domänkontrollant till andra domänkontrollanter i skogen. Eftersom replikeringspartner anser att de har en uppdaterad kopia av Active Directory-databasen rapporterar inte övervaknings- och felsökningsverktyg som Repadmin.exe några replikeringsfel.

Domänkontrollanter loggar Directory Services Event 2095 i händelseloggen för Directory Services när de identifierar en USN-återställning. Texten i händelsemeddelandet dirigerar administratörer till den här artikeln för att lära dig mer om återställningsalternativ.

Exempel på händelseloggpost 2095

Log Name:      <Service name> Service  
Source:        Microsoft-Windows-ActiveDirectory_DomainService  
Date:          <DateTime>
Event ID:      2095  
Task Category: Replication  
Level:         Error  
Keywords:      Classic  
User:          <USER NAME>  
Computer:      SERVER.contoso.com  
Description:

During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller.

User Actions:

If this situation occurred because of an improper or unintended restore, forcibly demote the DC.

I följande avsnitt beskrivs hur du identifierar och återställer från en USN-återställning i en Windows Server-baserad domänkontrollant.

Metoder som stöds för att säkerhetskopiera Active Directory på domänkontrollanter som kör Windows Server 2012 och senare versioner

Windows Server 2012 lägger till stöd för Hyper-Visor Generation ID (GenID). Detta gör att den virtuella gästen kan identifiera de diskvolymer som har ett nytt ID och svara på det nya GenID:t. I Active Directory reagerar Directory Services som om domänkontrollanten återställdes från en säkerhetskopia. Den genererar sedan ett nytt anrops-ID. Med hjälp av det nya anrops-ID:t kan databasinstansen på ett säkert sätt ange replikering i skogen.

Det här är ett av de scenarier som beskrivs i Distribution och konfiguration av virtualiserad domänkontrollant.

Metoder som stöds för att säkerhetskopiera Active Directory på domänkontrollanter som kör Windows Server 2003 eller senare versioner av Windows Server

Under en domänkontrollants livscykel kan du behöva återställa eller "återställa" innehållet i Active Directory-databasen till en känd bra tidpunkt. Eller så kan du behöva återställa element i en domänkontrollants värdoperativsystem, inklusive Active Directory, till en känd bra punkt.

Följande metoder stöds som du kan använda för att återställa innehållet i Active Directory:

  • Använd ett Active Directory-medvetet verktyg för säkerhetskopiering och återställning som använder API:er som tillhandahålls av Microsoft och Microsoft. Dessa API:er återställer inte auktoritativt eller auktoritativt en säkerhetskopia av systemtillståndet. Säkerhetskopian som återställs ska komma från samma installation av operativsystemet och från samma fysiska eller virtuella dator som återställs.

  • Använd ett Active Directory-medvetet verktyg för säkerhetskopiering och återställning som använder Api:er för Tjänsten Microsoft Volume Shadow Copy. Dessa API:er säkerhetskopierar och återställer systemtillståndet för domänkontrollanten. Tjänsten Volume Shadow Copy har stöd för att skapa skuggkopior för enskilda tidpunkter av en eller flera volymer på datorer som kör Windows Server 2003, Windows Server 2008 eller Windows Server 2008 R2. Skuggkopior med enstaka tidpunkt kallas även ögonblicksbilder. Mer information finns i "Volume Shadow Copy Service" i Microsoft Support.

  • Återställ systemtillståndet. Utvärdera om det finns giltiga säkerhetskopior av systemtillstånd för den här domänkontrollanten. Om en giltig säkerhetskopia av systemtillståndet gjordes innan den återställda domänkontrollanten återställdes felaktigt, och om säkerhetskopian innehåller de senaste ändringarna som gjorts på domänkontrollanten, återställer du systemtillståndet från den senaste säkerhetskopian.

Typiskt beteende som inträffar när du återställer en Active Directory-medveten säkerhetskopia av systemtillstånd

Windows Server-domänkontrollanter använder USN tillsammans med anrops-ID:na för att spåra uppdateringar som måste replikeras mellan replikeringspartner i en Active Directory-skog.

Källdomänkontrollanter använder USN för att avgöra vilka ändringar som redan har tagits emot av måldomänkontrollanten som begär ändringar. Måldomänkontrollanter använder USN för att avgöra vilka ändringar som ska begäras från källdomänkontrollanter.

Anrops-ID:t identifierar versionen eller instansiering av Active Directory-databasen som körs på en viss domänkontrollant.

När Active Directory återställs på en domänkontrollant med hjälp av DE API:er och metoder som Microsoft har utformat och testat återställs anrops-ID:t korrekt på den återställda domänkontrollanten. domänkontrollanter i skogen får ett meddelande om återställning av anrop. Därför justerar de sina höga vattenstämpelvärden i enlighet med detta.

Programvara och metoder som orsakar USN-återställningar

När följande miljöer, program eller undersystem används kan administratörer kringgå de kontroller och valideringar som Microsoft har utformat för att inträffa när systemtillståndet för domänkontrollanten återställs:

  • Starta en Active Directory-domänkontrollant vars Active Directory-databasfil återställdes (kopierades) på plats med hjälp av ett avbildningsprogram som Norton Ghost.

  • Starta en tidigare sparad virtuell hårddiskbild av en domänkontrollant. Följande scenario kan orsaka en USN-återställning:

    1. Höj upp en domänkontrollant i en virtuell värdmiljö.
    2. Skapa en ögonblicksbild eller en alternativ version av den virtuella värdmiljön.
    3. Låt domänkontrollanten fortsätta att replikera inkommande och utgående replikering.
    4. Starta avbildningsfilen för domänkontrollanten som du skapade i steg 2.

  • Exempel på virtualiserade värdmiljöer som orsakar det här scenariot är Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 och EMC VMWARE. Andra virtualiserade värdmiljöer kan också orsaka det här scenariot.

  • Mer information om supportvillkoren för domänkontrollanter i virtuella värdmiljöer finns i Saker att tänka på när du är värd för Active Directory-domänkontrollanter i virtuella värdmiljöer.

  • Starta en Active Directory-domänkontrollant som finns på en volym där diskundersystemet läses in med hjälp av tidigare sparade avbildningar av operativsystemet utan att det krävs en återställning av systemtillståndet för Active Directory.

    • Scenario A: Starta flera kopior av Active Directory som finns i ett diskundersystem som lagrar flera versioner av en volym

      1. Höj upp en domänkontrollant. Leta upp filen Ntds.dit på ett diskundersystem som kan lagra flera versioner av volymen som är värd för filen Ntds.dit.
      2. Använd diskundersystemet för att skapa en ögonblicksbild av volymen som är värd för Ntds.dit-filen för domänkontrollanten.
      3. Fortsätt att låta domänkontrollanten läsa in Active Directory från den volym som du skapade i steg 1.
      4. Starta domänkontrollanten som Active Directory-databasen sparade i steg 2.

    • Scenario B: Starta Active Directory från andra enheter i en trasig spegling

      1. Höj upp en domänkontrollant. Leta upp filen Ntds.dit på en speglad enhet.
      2. Bryt spegeln.
      3. Fortsätt att replikera inkommande och utgående replikering med hjälp av filen Ntds.dit på den första enheten i speglingen.
      4. Starta domänkontrollanten med hjälp av filen Ntds.dit på den andra enheten i spegeln.

Även om det inte är avsett kan vart och ett av dessa scenarier få domänkontrollanter att återställa till en äldre version av Active Directory-databasen med metoder som inte stöds. Det enda sättet att återställa innehållet i Active Directory eller det lokala tillståndet för en Active Directory-domänkontrollant är att använda ett Active Directory-medvetet säkerhetskopierings- och återställningsverktyg för att återställa en säkerhetskopia av systemtillståndet som kommer från samma installation av operativsystemet och samma fysiska eller virtuella dator som återställs.

Microsoft stöder inte någon annan process som tar en ögonblicksbild av elementen i en Active Directory-domänkontrollants systemtillstånd och kopierar element i det systemtillståndet till en operativsystemsavbildning. Om inte en administratör ingriper orsakar sådana processer en USN-återställning. Den här USN-återställningen gör att de direkta och transitiva replikeringspartnerna för en felaktigt återställd domänkontrollant har inkonsekventa objekt i sina Active Directory-databaser.

Effekterna av en USN-återställning

När USN-återställningar sker replikeras inte ändringar av objekt och attribut av måldomänkontrollanter som tidigare har sett USN.

Eftersom dessa måldomänkontrollanter tror att de är uppdaterade rapporteras inga replikeringsfel i händelseloggarna för Katalogtjänsten eller genom övervaknings- och diagnostikverktyg.

USN-återställning kan påverka replikeringen av alla objekt eller attribut i valfri partition. Den vanligaste sidoeffekten är att användarkonton och datorkonton som skapas på återställningsdomänkontrollanten inte finns på en eller flera replikeringspartner. Eller så finns inte de lösenordsuppdateringar som har sitt ursprung i återställningsdomänkontrollanten på replikeringspartner.

Följande steg visar sekvensen med händelser som kan orsaka en USN-återställning. En USN-återställning sker när systemtillståndet för domänkontrollanten återställs i tid med hjälp av en återställning av systemtillstånd som inte stöds.

  1. En administratör befordrar tre domänkontrollanter i en domän. (I det här exemplet är domänkontrollanterna DC1, DC2 och DC2, och domänen är Contoso.com.) DC1 och DC2 är direktreplikeringspartner. DC2 och DC3 är också direktreplikeringspartner. DC1 och DC3 är inte direktreplikeringspartner utan tar emot ursprungliga uppdateringar transitivt via DC2.

  2. En administratör skapar 10 användarkonton som motsvarar USN 1 till 10 på DC1. Alla dessa konton replikeras till DC2 och DC3.

  3. En diskavbildning av ett operativsystem registreras på DC1. Den här bilden har en post med objekt som motsvarar lokala USN 1 till 10 på DC1.

  4. Följande ändringar görs i Active Directory:

    • Lösenorden för alla 10 användarkonton som skapades i steg 2 återställs på DC1. Dessa lösenord motsvarar USN 11 till 20. Alla 10 uppdaterade lösenord replikeras till DC2 och DC3.
    • 10 nya användarkonton som motsvarar USN 21 till 30 skapas på DC1. Dessa 10 användarkonton replikeras till DC2 och DC3.
    • 10 nya datorkonton som motsvarar USN 31 till 40 skapas på DC1. Dessa 10 datorkonton replikeras till DC2 och DC3.
    • 10 nya säkerhetsgrupper som motsvarar USN 41 till 50 skapas på DC1. Dessa 10 säkerhetsgrupper replikeras till DC2 och DC3.

  5. DC1 har ett maskinvarufel eller ett programvarufel. Administratören använder ett diskavbildningsverktyg för att kopiera operativsystemavbildningen som skapades i steg 3 på plats. DC1 börjar nu med en Active Directory-databas som har kunskaper om USN 1 till och med 10.

    Eftersom operativsystemavbildningen kopierades på plats och en metod som stöds för att återställa systemtillståndet inte användes, fortsätter DC1 att använda samma anrops-ID som skapade den första kopian av databasen och alla ändringar upp till USN 50. DC2 och DC3 har också samma anrops-ID för DC1 samt en uppdaterad vektor med USN 50 för DC1. (En uppdaterad vektor är aktuell status för de senaste uppdateringarna som ska ske på alla domänkontrollanter för en viss katalogpartition.)

    Om inte en administratör ingriper replikerar DC2 och DC3 inte de ändringar som motsvarar lokala USN 11 till 50 som kommer från DC1. Enligt det anrops-ID som DC2 använder har DC1 redan kunskap om de ändringar som motsvarar USN 11 till 50. Dc2 skickar därför inte dessa ändringar. Eftersom ändringarna i steg 4 inte finns på DC1 misslyckas inloggningsbegäranden med felet "åtkomst nekad". Det här felet beror antingen på att lösenord inte matchar eller på att kontot inte finns när de nyare kontona autentiseras slumpmässigt med DC1.

  6. Administratörer som övervakar replikeringshälsan i skogen noterar följande situationer:

    • Kommandoradsverktyget Repadmin /showreps rapporterar att dubbelriktad Active Directory-replikering mellan DC1 och DC2 och mellan DC2 och DC3 sker utan fel. Den här situationen gör eventuell replikeringsinkonsekvens svår att identifiera.

    • Replikeringshändelser i katalogtjänstens händelseloggar för domänkontrollanter som kör Windows Server indikerar inte några replikeringsfel i katalogtjänstens händelseloggar. Den här situationen gör eventuell replikeringsinkonsekvens svår att identifiera.

    • Active Directory - användare och datorer eller Active Directory Administration Tool (Ldp.exe) visar ett annat antal objekt och olika objektmetadata när domänkatalogpartitionerna på DC2 och DC3 jämförs med partitionen på DC1. Skillnaden är den uppsättning ändringar som mappas till USN-ändringar 11 till 50 i steg 4.

      Obs!

      I det här exemplet gäller det olika antalet objekt för användarkonton, datorkonton och säkerhetsgrupper. De olika objektmetadata representerar de olika lösenorden för användarkontot.

    • Begäranden om användarautentisering för de 10 användarkonton som skapades i steg 2 genererar ibland ett "åtkomst nekad" eller "felaktigt lösenord". Det här felet kan inträffa eftersom det finns ett lösenordsfel mellan dessa användarkonton på DC1 och kontona på DC2 och DC3. De användarkonton som upplever det här problemet motsvarar de användarkonton som skapades i steg 4. Användarkontona och lösenordsåterställningen i steg 4 replikerades inte till andra domänkontrollanter i domänen.

  7. DC2 och DC3 börjar med inkommande-replikerande uppdateringar som motsvarar USN-nummer som är större än 50 från DC1. Den här replikeringen fortsätter normalt utan administrativa åtgärder eftersom det tidigare registrerade tröskelvärdet för aktuellhetsvektor, USN 50, har överskridits. (USN 50 var den aktuella vektorn USN som registrerats för DC1 på DC2 och DC3 innan DC1 togs offline och återställdes.) De nya ändringarna som motsvarade USN 11 till 50 på den ursprungliga DC1 efter återställningen som inte stöds replikeras dock aldrig till DC2, DC3 eller deras transitiva replikeringspartner.

Även om de symptom som nämns i steg 6 representerar en del av den effekt som en USN-återställning kan ha på användar- och datorkonton, kan en USN-återställning förhindra att alla objekttyper i en Active Directory-partition replikeras. Dessa objekttyper omfattar följande:

  • Topologin och schemat för Active Directory-replikering

  • Förekomsten av domänkontrollanter i skogen och de roller som dessa domänkontrollanter har

    Obs!

    Dessa roller omfattar den globala katalogen, rid-allokeringar (relative identifier) och operations master-roller. (Operations Master-roller kallas även flexibla enkla huvudåtgärder eller FSMO.)

  • Förekomsten av domän- och programpartitioner i skogen

  • Förekomsten av säkerhetsgrupper och deras nuvarande gruppmedlemskap

  • DNS-postregistrering i Active Directory-integrerade DNS-zoner

Storleken på USN-hålet kan representera hundratals, tusentals eller till och med tiotusentals ändringar av användare, datorer, förtroenden, lösenord och säkerhetsgrupper. (USN-hålet definieras av skillnaden mellan det högsta USN-numret som fanns när säkerhetskopieringen av det återställda systemtillståndet gjordes och antalet ursprungliga ändringar som skapades på den återställda domänkontrollanten innan den togs offline.)

Identifiera en USN-återställning på en Windows Server-domänkontrollant

Eftersom en USN-återställning är svår att identifiera loggar en domänkontrollant i Windows Server 2003 SP1 eller senare version händelse 2095 när en källdomänkontrollant skickar ett tidigare bekräftat USN-nummer till en måldomänkontrollant utan motsvarande ändring i anrops-ID:t.

För att förhindra att unika uppdateringar av Active Directory skapas på den felaktigt återställda domänkontrollanten pausas tjänsten Net Logon . När tjänsten Net Logon pausas kan användar- och datorkonton inte ändra lösenordet på en domänkontrollant som inte kommer att utgående replikera sådana ändringar. På samma sätt prioriterar Active Directory-administrationsverktyg en felfri domänkontrollant när de uppdaterar objekt i Active Directory.

På en domänkontrollant registreras händelsemeddelanden som liknar följande om följande villkor är uppfyllda:

  • En källdomänkontrollant skickar ett tidigare bekräftat USN-nummer till en måldomänkontrollant.
  • Det finns ingen motsvarande ändring i anrops-ID:t.

Dessa händelser kan registreras i händelseloggen för Katalogtjänsten. De kan dock skrivas över innan de observeras av en administratör.

Du kan misstänka att en USN-återställning har inträffat. Du ser dock inte korreleringshändelserna i händelseloggen för Katalogtjänsten. I det här scenariot söker du efter registerposten Dsa Not Writable . Den här posten innehåller kriminaltekniska bevis för att en USN-återställning har inträffat.

  • Registerundernyckel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Registerpost: Dsa kan inte skrivas
  • Värde: 0x4

Om du tar bort eller ändrar registerpostvärdet Dsa Not Writable manuellt försätts återställningsdomänkontrollanten i ett permanent tillstånd som inte stöds. Därför stöds inte sådana ändringar. Mer specifikt tar ändring av värdet bort karantänbeteendet som lagts till av USN-återställningsidentifieringskoden. Active Directory-partitionerna på återställningsdomänkontrollanten kommer att vara permanent inkonsekventa med direkta och transitiva replikeringspartner i samma Active Directory-skog.

Återställa från en USN-återställning

Det finns tre metoder för att återställa från en USN-återställning.

Referenser