Feilsøke feil med behandling av gruppepolicyer i et Active Directory-domene

Artikkelsammendrag: Denne artikkelen inneholder informasjon om hvordan du feilsøker feil med behandling av gruppepolicyer på Windows-maskiner i et Active Directory-domene.

Medlemmer av et Active Directory-domene (AD) kan av flere årsaker oppleve problemer når de bruker gruppepolicy. Denne artikkelen drøfter noen av de vanligste årsakene og gir en veiledning for hvordan du feilsøker de underliggende problemene.
 
Generell feilsøking
Når du skal feilsøke disse problemene, bør du først fastslå omfanget deres. Hvis det bare er én maskin som ikke kan behandle gruppepolicy, skyldes problemet sannsynligvis en funksjonssvikt eller feilkonfigurasjon på den maskinen, ikke et problem med domenekontrolleren (DC) eller selve AD. Hvis det oppstår et maskinspesifikt problem, kan det være nyttig å kjøre gpupdate /force på den berørte maskinen før du feilsøker videre, slik at du kan forsikre deg om at feilen ikke var forårsaket av et midlertidig nettverksproblem som siden har blitt rettet opp.

Når en maskin ikke kan behandle gruppepolicy, vil den som regel generere én eller flere Userenv-feil i applikasjonsloggen. Vanlige hendelses-ID-numre inkluderer 1030, 1053, 1054 og 1058. Beskrivelsene av de bestemte feilene på en berørt maskin bør gi en indikasjon på det underliggende problemet.
 
DNS-problemer
Det som kanskje er den vanligste årsaken til gruppepolicyfeil (og en rekke andre problemer i AD), er et problem med navneløsing: en klient prøver å oppdatere innstillingene for gruppepolicy, men kan ikke fastslå navnet på en domenekontroller i domenet, kan ikke løse et domenekontrollernavn på en IP-adresse, eller løser navnet på adressen til en maskin som ikke er en domenekontroller, og som kanskje ikke eksisterer. Hvis Userenv-feilene på en berørt maskin omfatter «Network path not found» (Finner ikke nettverksbane) eller «Cannot locate a domain controller» (Finner ikke en domenekontroller), kan de skyldes DNS. Nedenfor finner du noen tips for hvordan du feilsøker denne typen problemer:

• Åpne en ledetekst på en berørt maskin, og kjør nslookup domain_name (for eksempel nslookup mydomain.local). Denne kommandoen skal returnere IP-adressene til alle domenekontrollere i domenet. Hvis andre adresser blir returnert, er det sannsynligvis ugyldige poster i DNS. Kommandoen nslookup kan også brukes til å løse navnene på individuelle domenekontrollere til IP-adressene deres (for eksempel nslookup dc1.mydomain.local).
• Kjør ipconfig /all på en berørt maskin, og kontroller at er konfigurert til å bare bruke interne DNS-servere. Bruk av feil DNS-servere er den vanligste årsaken til DNS-problemer i et domene, og kan enkelt rettes opp. Alle domenetilknyttede maskiner må bare bruke interne DNS-servere, som vanligvis er domenekontrollere.
• Hvis den berørte maskinen tilsynelatende bruker de riktige DNS-serverne, må du kontrollere DNS-konsollen på en domenekontroller for å bekrefte at de riktige postene eksisterer. Kontroller at hver domenekontroller har to vertsposter (A) i domenesonen for videresendt oppslag: én med vertsnavnet til domenekontrolleren og én med navnet («samme som overordnet mappe)». Begge postene skal inkludere IP-adressen til domenekontrolleren.
• Når DNS-problemet er løst, må du huske å kjøre ipconfig /flushdns på alle berørte maskiner for å fjerne eventuelle ugyldige data fra løsningsbufferen på disse maskinene.

Problemer med sikker kanal
Denne typen problemer oppstår vanligvis når en domenetilknyttet maskin har vært frakoblet så lenge at passordet på datamaskinkontoen i AD ikke lenger samsvarer med maskinens lokalt hurtigbufrede kopi av passordet, men de kan også oppstå i andre situasjoner. Et problem med sikker kanal vil hindre at maskinen godkjenner med en domenekontroller, og vil vanligvis vises som en «Access denied»-feil (Ingen tilgang) hver gang maskinene prøver å få tilgang til domeneressurser, inkludert gruppepolicyoppdateringer. Det er selvfølgelig ikke alle «Access denied»-hendelser (Ingen tilgang) som skyldes problemer med sikker kanal, men om en berørt maskin har Userenv-feil i applikasjonsloggene med «Access denied» i beskrivelsen, bør du teste den sikre kanalen.

• Kommandoen nltest kan brukes til å teste (og om nødvendig, tilbakestille) den sikre kanalen på et domenemedlem.
• Kommandoen netdom kan også teste og tilbakestille den sikre kanalen.
• Hvis Active Directory PowerShell-modulen er installert, gir PowerShell-cmdleten Test-ComputerSecureChannel en annen metode for å teste og/eller tilbakestille den sikre kanalen.
• I noen tilfeller kan det være nødvendig å fjerne den berørte maskinen fra domenet, tilbakestille maskinens AD-datamaskinkonto og koble den til domenet på nytt for å tilbakestille den sikre kanalen.

Problemer med SYSVOL
Gruppepolicyfiler lagres i den delte SYSVOL-ressursen på alle domenekontrollere i domenet – nærmere bestemt i undermappene til SYSVOL\domain\Policies-mappen. Hvis den delte SYSVOL-ressursen ikke er til stede på en domenekontroller, indikerer dette vanligvis et problem med enten File Replication Service (FRS) eller Distributed File System Replication (DFS-R), avhengig av hvilken som brukes til å replikere SYSVOL.

Denne artikkelen gir ikke en omfattende veiledning for å feilsøke FRS eller DFS-R, men følgende koblinger kan være nyttige:

• Slik gjenbygger du SYSVOL-treet og innholdet i det

Tidsforskyvning
Standardinnstillingen tilsier at hvis klokkeslettet på en berørt maskin avviker mer enn fem minutter fra klokkeslettet på en domenekontroller når du korrigerer tidssoneforskjeller, så kan ikke maskinen godkjenne med domenekontrolleren, og den kan derfor heller ikke behandle gruppepolicyer. Domenemedlemmer bør konfigureres til å synkronisere klokkene med en domenekontroller, og domenekontrollere bør synkronisere klokkene sine med domenekontrolleren som fungerer som emulator for primær domenekontroller. På grunn av dette må emulatoren for primær domenekontroller være den eneste maskinen i et domene som er konfigurert til å synkronisere med en ekstern kilde, for eksempel en offentlig NTP-server.

Du finner mer informasjon om konfigurasjon av Windows Time-tjenesten her.
 
Manglende gruppepolicyfiler
Én eller flere gruppepolicyfiler kan ha blitt slettet fra lagringsstedet sitt i SYSVOL. Den enkleste måten å kontrollere dette på er å åpne SYSVOL\domain\Policies i Windows Utforsker og se etter de spesifikke filene som er nevnt i Userenv-feil på berørte maskiner. Filene for hvert gruppepolicyobjekt er plassert i en undermappe for Policies-mappen (Policyer). Hver undermappe er oppkalt etter GUID-en for gruppepolicyobjektet den inneholder filene til.

Hvis alle domenekontrollere mangler policyfiler, kan filene gjenopprettes fra en sikkerhetskopi. Hvis filene for standard domenepolicy eller standard domenekontrollerpolicy mangler, og ingen sikkerhetskopi er tilgjengelig, kan kommandoen dcgpofix gjenopprette begge policyene til standardinnstillingene. Du finner mer informasjon om dcgpofix i denne artikkelen.