Sådan foretages fejlfinding af behandlingsfejl i gruppepolitik i et Active Directory-domæne

Medlemmer af et Active Directory-domæne (AD) kan opleve problemer med at anvende gruppepolitik af flere forskellige årsager. Denne artikel omhandler nogle af de mest almindelige problemer og giver vejledning til fejlfinding af de underliggende problemer.
 
Generel fejlfinding
Det første trin i fejlfinding af disse problemer bør være at bestemme deres omfang. Hvis kun én maskine ikke er i stand til at behandle gruppepolitikken, skyldes problemet sandsynligvis en funktionsfejl eller en fejlkonfiguration af maskinen. Hvis problemet er mere udbredt, kan problemet eksistere på en domænecontroller (DC) eller i AD selv.

Hvis kun én maskine er berørt, skal du køre gpupdate /force på den berørte maskine før yderligere fejlfinding. Dette sikrer, at fejlen ikke skyldtes et midlertidigt netværksproblem, der siden er blevet løst.

Når en maskine ikke er i stand til at behandle gruppepolitik, genererer den typisk en eller flere Userenv-fejl i programloggen. Typiske hændelses-id-numre omfatter 1030, 1053, 1054 og 1058. Beskrivelserne af de særlige fejl på en berørt maskine bør give en idé om det underliggende problem.

DNS-problemer
Måske er den mest almindelige årsag til gruppepolitikfejl - og mange andre AD-problemer - et navneløsningsproblem. Hvis Userenv-fejlene på en berørt computer inkluderer udtrykket "Network path not found" eller "Cannot locate a domain controller", er DNS muligvis skyld i problemet. Følgende er et par tip til fejlfinding af denne type problem:

• Åbn en kommandoprompt på en berørt maskine, og kør nslookup domæne (nslookup mydomain.local, for eksempel). Denne kommando bør returnere IP-adresserne for alle domænecontrollere i domænet. Hvis der returneres andre adresser, er der sandsynligvis ugyldige poster i DNS. Kommandoen nslookup kan også bruges til at fortolke navnene på individuelle DC'er til deres IP-adresser.
• Kør ipconfig /all på en berørt maskine, og kontrollér, at den er konfigureret til kun at bruge interne DNS-servere. Brug af forkerte DNS-servere er hovedårsagen til DNS-problemer i et domæne, og det er nemt at løse problemet. Alle domænetilsluttede computere må kun bruge interne DNS-servere, som typisk er domænecontrollere.
• Hvis den berørte computer tilsyneladende bruger de korrekte DNS-servere, skal du kontrollere DNS-konsollen på en DC for at kontrollere, at de rigtige poster er til stede. Bekræft, at hver DC har to værtsposter (A) i domænets fremsøgezone: en med DC'ens værtsnavn og en med navnet "(samme som overordnet mappe)". Begge poster skal inkludere domænecontrollerens IP-adresse.
• Når et DNS-problem er løst, skal du køre ipconfig /flushdns på alle berørte maskiner. Dette vil fjerne ugyldige data fra resolvercachen på disse maskiner.

Problemer med
sikre kanalerDenne type problem opstår, når en domænetilsluttet maskines lokalt gemte computerkontoadgangskode ikke stemmer overens med dens adgangskode i AD. Et problem med sikker kanal forhindrer en maskine i at godkende med en DC. Det manifesterer sig ofte som en "Adgang nægtet" fejl, når den maskine forsøger at få adgang til domæneressourcer, herunder gruppepolitikopdateringer. Selvfølgelig er det ikke alle "Access denied"-hændelser, der skyldes problemer med den sikre kanal, men hvis en berørt computer har Userenv-fejl i sin programlog med "Access denied" i deres beskrivelse, er det forsøget værd at teste den sikre kanal.

• Kommandoen nltest kan bruges til at teste (og nulstille, om nødvendigt) den sikre kanal på et domænemedlem.
• Ikonet netdom Kommandoen kan også teste og nulstille den sikre kanal.
• Test-ComputerSecureChannel PowerShell-cmdlet'en giver en anden metode til at teste eller nulstille den sikre kanal.
• Hvis du fjerner den berørte maskine fra domænet, nulstiller dens AD-computerkonto og slutter den til domænet igen, nulstilles dens sikre kanal. Dette er imidlertid ikke altid muligt.

Problemer med SYSVOL
Skabelonfiler til gruppepolitik gemmes i SYSVOL-sharet på alle udviklingscentre i domænet. SYSVOL-dataene replikeres mellem DC'er ved hjælp af enten FRS (File Replication System) eller DFSR (Distributed File System Replication). Hvis SYSVOL-sharet ikke findes på en DC, skyldes det normalt et problem med SYSVOL-replikering.

Uret skævvrider
Kerberos-godkendelse kræver som standard, at clockene for domæneforbundne maskiner er inden for fem minutter fra hinanden. Overskridelse af denne tærskel forårsager godkendelsesfejl, hvilket igen forhindrer behandling af gruppepolitik. Alt i domænet skal konfigureres til at synkronisere sit ur med AD, med en undtagelse. DC, der har PDC Emulator FSMO-rollen, er den autoritative tidskilde for domænet. Derfor er det den eneste maskine i et domæne, der skal synkroniseres med en ekstern kilde, såsom en offentlig NTP-server.

Du kan finde flere oplysninger om konfiguration af tjenesten Windows Time her.

Manglende gruppepolitikfiler
En eller flere gruppepolitikfiler kan være blevet slettet fra deres lagerplacering i SYSVOL. Kontroller dette ved at gå til SYSVOL\domæne\Politikker i Stifinder og kigge efter specifikke filer, der er nævnt i Userenv-fejl. Filerne for hvert GPO er placeret i en undermappe til mappen Politikker . Hver undermappe er opkaldt efter den hexadecimale GUID (Globally Unique Identifier) for det GPO, hvis filer den indeholder.

Hvis politikfiler mangler i alle DC'er, kan de gendannes fra en sikkerhedskopi. Hvis filerne Default Domain Policy eller Default Domain Controller Policy mangler, og der ikke er nogen sikkerhedskopi tilgængelig, vises ikonet dcgpofix Kommandoen kan gendanne begge politikker til deres standardindstillinger.

Flere oplysninger om dcgpofix kan findes her.