Slik feilsøker du behandlingsfeil for gruppepolicy 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
Det første trinnet i feilsøking av disse problemene bør være å bestemme omfanget. Hvis bare én maskin ikke er i stand til å behandle gruppepolicy, stammer problemet sannsynligvis fra en funksjonsfeil eller feilkonfigurasjon av den maskinen. Hvis problemet er mer utbredt, kan problemet finnes på en domenekontroller (DC) eller selve AD

.Hvis bare én maskin er berørt, kjører du gpupdate /force på den berørte maskinen før feilsøking videre. Dette sikrer at feilen ikke ble forårsaket av et midlertidig nettverksproblem som siden har blitt løst.

Når en maskin ikke kan behandle gruppepolicy, genererer den vanligvis én eller flere Userenv-feil i programloggen. Vanlige hendelses-ID-numre inkluderer 1030, 1053, 1054 og 1058. Beskrivelsene av de spesielle feilene på en berørt maskin bør gi en ide om det underliggende problemet.

DNS-problemer
Kanskje den vanligste årsaken til gruppepolicyfeil - og mange andre AD-problemer - er et navneløsningsproblem. 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 domene (nslookup mydomain.local, for eksempel). 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 DCer til deres IP-adresser.
• Kjør ipconfig /all på en berørt maskin, og kontroller at den er konfigurert til å bruke bare 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 et DNS-problem er løst, kjører du ipconfig /flushdns på alle berørte maskiner. Dette vil fjerne eventuelle ugyldige data fra resolverbufferen på disse maskinene.

Problemer
med sikker kanalDenne typen problem oppstår når passordet til en domenetilknyttet maskins lokalt lagrede datamaskinkonto ikke samsvarer med passordet i AD. Et sikkert kanalproblem hindrer en maskin i å autentisere med en DC. Det manifesterer seg ofte som en "Access denied" -feil når den maskinen 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.
• Informasjonen i netdom Kommandoen kan også teste og tilbakestille den sikre kanalen.
• Cmdleten Test-ComputerSecureChannel PowerShell gir en annen metode for å teste eller tilbakestille den sikre kanalen.
• Hvis du fjerner den berørte maskinen fra domenet, tilbakestiller AD-datamaskinkontoen og kobler den til domenet på nytt, tilbakestilles den sikre kanalen. Dette er imidlertid ikke alltid gjennomførbart.

Problemer med SYSVOL
Gruppepolicymalfiler lagres i SYSVOL-delingen på alle DCer i domenet. SYSVOL-dataene replikeres mellom DC-er ved hjelp av enten File Replication System (FRS) eller Distributed File System Replication (DFSR). Hvis SYSVOL-delingen ikke finnes på en DC, indikerer dette vanligvis et problem med SYSVOL-replikering.

Klokkeskjevhet
Kerberos-godkjenning krever som standard at klokkene til domenetilknyttede maskiner er innen fem minutter fra hverandre. Overskridelse av denne terskelen fører til godkjenningsfeil, som igjen forhindrer behandling av gruppepolicy. Alt i domenet skal konfigureres til å synkronisere klokken med AD, med ett unntak. DC-en, som innehar FSMO-rollen PDC-emulator, er den autoritative tidskilden for domenet. Derfor er det den eneste maskinen i et domene som skal synkronisere med en ekstern kilde, for eksempel en offentlig NTP-server.

Du finner mer informasjon om konfigurering av Windows Time-tjenesten her.

Manglende gruppepolicyfiler
Én eller flere gruppepolicyfiler kan ha blitt slettet fra lagringsplassen i SYSVOL. Sjekk dette ved å gå til SYSVOL\domain\Policies i File Explorer og se etter spesifikke filer nevnt i Userenv-feil. Filene for hvert gruppepolicyobjekt er plassert i en undermappe i mappen «Policyer ». Hver undermappe er oppkalt etter den heksadesimale globalt unike identifikatoren (GUID) til gruppepolicyobjektet hvis filer den inneholder.

Hvis det viser seg at det mangler retningslinjefiler fra alle DC-er, kan de gjenopprettes fra en sikkerhetskopi. Hvis filene med standard domenepolicy eller standard domenekontrollerpolicy mangler, og ingen sikkerhetskopi er tilgjengelig, vises dcgpofix Kommandoen kan gjenopprette begge policyene til standardinnstillingene.

Mer informasjon om dcgpofix finner du her.