Felsöka problem med grupprincipbearbetning i en Active Directory-domän

Artikelsammanfattning: Den här artikeln innehåller information om felsökning av problem med grupprincipbearbetning på Windows-datorer i en Active Directory-domän.

Medlemmar i en Active Directory-domän (AD) kan få problem med att använda grupprinciper av flera skäl. I den här artikeln beskrivs några av de vanligaste skälen och riktlinjer för felsökning av underliggande problem.
 
Allmän felsökning
Det första steget för att felsöka problemen är att fastställa deras omfattning. Om det bara är en dator som inte kan bearbeta grupprincipen beror problemet troligtvis på ett fel eller en felaktig konfiguration av den datorn, och inte ett problem med själva domänkontrollanten eller AD. Om det är ett problem med den specifika datorn kan det vara bra att köra gpupdate /force på datorn innan du felsöker vidare, för att vara säker på att felet inte orsakades av ett tillfälligt nätverksproblem som redan har lösts.

När en dator inte kan bearbeta en grupprincip genererar den vanligtvis ett eller flera Userenv-fel i programloggen. Vanliga händelse-id-nummer är bland annat 1030, 1053, 1054 och 1058. Beskrivningarna av de specifika felen på en dator borde ge någon uppfattning om det underliggande problemet.
 
DNS-problem
Den vanligaste orsaken till grupprincipfel (och många andra problem i AD) är ett namnmatchningsfel: en klient försöker uppdatera sina grupprincipinställningar, men kan inte identifiera namnet på en domänkontrollant i domänen, kan inte matcha domänkontrollantens namn med en IP-adress eller matchar namnet med adressen till en dator som inte är en domänkontrollant och kanske inte ens finns. Om Userenv-felen på en dator innehåller frasen ”Nätverkssökvägen kan inte hittas” eller ”Det går inte att hitta en domänkontrollant” kan det bero på DNS. Här följer några tips för felsökning av den här typen av problem:

• Öppna en kommandotolk på en dator som har problem och kör nslookup domain_name (till exempel nslookup mydomain.local). Det här kommandot bör returnera IP-adresserna till alla domänkontrollanter i domänen. Om några andra adresser returneras finns det troligen ogiltiga poster i DNS. Kommandot nslookup kan även användas för att matcha namn på enskilda domänkontrollanter med deras IP-adresser (till exempel nslookup dc1.mydomain.local).
• Kör ipconfig/all på en dator som har problem och kontrollera att den är konfigurerad till att bara använda interna DNS-servrar. Att använda fel DNS-servrar är den vanligaste orsaken till DNS-problem i en domän, och det är lätt att lösa. Alla domänanslutna datorer får endast använda interna DNS-servrar, som vanligtvis är domänkontrollanter.
• Om datorn som har problem verkar använda rätt DNS-servrar kontrollerar du DNS-konsolen på en domänkontrollant för att se att rätt poster finns. Kontrollera att varje domänkontrollant har två värdposter (A) i domänzonen för vanlig sökning: en med domänkontrollantens värdnamn och en med samma namn som den överordnade mappen. Båda posterna ska innehålla IP-adressen till domänkontrollanten.
• När DNS-problemet har lösts måste du komma ihåg att köra ipconfig /flushdns på alla berörda datorer för att rensa ogiltiga data från matcharcachen på dessa datorer.

Problem med säkra kanaler
Den här typen av problem uppstår vanligtvis när en domänansluten dator har varit offline under så lång tid att lösenordet för datorkontot i AD inte längre matchar datorns kopia av lösenordet som är sparad i det lokala cacheminnet, men de kan även uppstå i andra situationer. Ett problem med säkra kanaler förhindrar att en dator autentiseras med en domänkontrollant och yttrar sig vanligtvis som felet ”åtkomst nekas” när datorn försöker komma åt domänresurser, bland annat grupprincipuppdateringar. Naturligtvis beror inte alla förekomster av ”åtkomst nekas” på problem med säkra kanaler, men om en dator har Userenv-fel i programloggen med ”åtkomst nekas” i beskrivningen är det värt att testa den säkra kanalen.

• Kommandot nltest kan användas för att testa (och vid behov återställa) den säkra kanalen på en domänmedlem.
• Med kommandot netdom kan du även testa och återställa den säkra kanalen.
• Om Active Directory PowerShell-modulen är installerad kan du också testa eller återställa den säkra kanalen med PowerShell cmdlet Test-ComputerSecureChannel.
• I vissa fall kan det vara nödvändigt att ta bort den berörda datorn från domänen, återställa datorkontot på AD och ansluta den till domänen igen för att återställa den säkra kanalen.

Problem med SYSVOL
Grupprincipfiler lagras i SYSVOL-resursen på alla domänkontrollanter i domänen, i undermappar till mappen SYSVOL\domain\Policies. Om SYSVOL-resursen inte finns på en domänkontrollant tyder det vanligtvis på ett problem med antingen File Replication Service (FRS) eller Distributed File System Replication (DFS-R), beroende på vilken av dem som används för att replikera SYSVOL.

Den här artikeln kan inte ge en heltäckande guide för felsökning av FRS eller DFS-R, men följande länkar kan vara användbara:

• Återskapa SYSVOL-trädet och dess innehåll (på engelska)

Klockan går fel
Om tiden på en dator skiljer sig från tiden på en domänkontrollant med mer än fem minuter när den korrigerats för skillnader i tidszoner kan den datorn inte autentisera med domänkontrollanten och kan därför inte bearbeta grupprincipen. Domänmedlemmar ska konfigureras för att synkronisera sina klockor med en domänkontrollant, och domänkontrollanter i sin tur ska synkronisera sina klockor med den domänkontrollant som innehar rollen som PDC-emulator. Därför bör PDC-emulatorn vara den enda dator i domänen som konfigureras för att synkroniseras mot en extern källa, t.ex. en offentlig NTP-server.

Mer information om att konfigurera Windows-tidstjänsten finns här.
 
Grupprincipfil saknas
En eller flera grupprincipfiler kan ha tagits bort från lagringsplatsen i SYSVOL. Det enklaste sättet att kontrollera detta är att öppna SYSVOL\domain\Policies i Utforskaren och leta efter de specifika filer som nämns i Userenv-felen som visas på de datorer som påverkas. Filerna för varje GPO finns i en undermapp i mappen Policies. Varje undermapp namnges efter GUID för den GPO vars filer den innehåller.

Om det saknas principfiler för alla domänkontrollanter kan de återställas från en säkerhetskopia. Om standarddomänprincipen eller domänkontrollanternas standardprincipfiler saknas och det inte finns någon säkerhetskopia kan båda principerna återställas till standardinställningarna med kommandot dcgpofix. Mer information om dcgpofix hittar du i den här artikeln.