Active Directory -domainin ryhmäkäytännön käsittelyvirheiden vianmääritys

Active Directory (AD) -toimialueen jäsenten ryhmäkäytäntöjen käyttöönottoon liittyvät ongelmat voivat johtua monista syistä. Tässä artikkelissa käsitellään yleisimpiä syitä ja annetaan ohjeita taustaongelmien vianmääritykseen.
 
Yleinen vianmääritys
Ensimmäinen vaihe näiden ongelmien vianmäärityksessä on niiden laajuuden määrittäminen. Jos vain yksi kone ei pysty käsittelemään ryhmäkäytäntöä, ongelma johtuu todennäköisesti kyseisen laitteen toimintahäiriöstä tai virheellisestä määrityksestä. Jos ongelma on laajempi, ongelma saattaa olla toimialueen ohjauskoneessa (DC) tai itse AD:ssä.

Jos ongelma koskee vain yhtä konetta, suorita suoritus gpupdate /force tietokoneessa, jota ongelma koskee, ennen kuin teet lisävianmääritystä. Näin varmistetaan, että vika ei johtunut tilapäisestä verkko-ongelmasta, joka on sittemmin ratkaistu.

Kun kone ei pysty käsittelemään ryhmäkäytäntöä, se luo yleensä yhden tai useamman Userenv-virheen sovelluslokiinsa. Tavallisia tapahtumatunnuksia ovat 1030, 1053, 1054 ja 1058. Haavoittuvuuden sisältävän koneen virheiden kuvausten pitäisi antaa jonkinlainen käsitys taustalla olevasta ongelmasta.

DNS-ongelmat
Ehkä yleisin syy ryhmäkäytäntövirheisiin - ja lukuisiin muihin AD-ongelmiin - on nimenselvitysongelma. Jos kyseisen tietokoneen Userenv-virheisiin sisältyy lause Network path not found tai Cannot locate a domain controller, ongelma saattaa johtua DNS:stä. Vihjeitä tällaisen ongelman vianmääritykseen:

• Avaa komentokehote tietokoneessa, jota ongelma koskee, ja suorita komento nslookup verkkotunnus (nslookup mydomain.local, esimerkiksi). Tämän komennon tuloksen pitäisi sisältää toimialueen kaikkien ohjauskoneiden IP-osoitteet. Jos tuloksissa on muita osoitteita, ne ovat todennäköisesti DNS:n virheellisiä tietueita. nslookup-komennolla voidaan myös selvittää yksittäisten toimialueen ohjauskoneiden nimet niiden IP-osoitteisiin.
• Suorita ipconfig /all koneessa, jota ongelma koskee, ja varmista, että se on määritetty käyttämään vain sisäisiä DNS-palvelimia. Väärien DNS-palvelimien käyttäminen on toimialueen DNS-ongelmien yleisin syy, ja se on helppo korjata. Kaikkien toimialueeseen liitettyjen tietokoneiden on käytettävä ainoastaan sisäisiä DNS-palvelimia, ja ne ovat yleensä toimialueen ohjauskoneita.
• Jos ongelmaan liittyvä tietokone näyttää käyttävän oikeita DNS-palvelimia, tarkista toimialueen ohjauskoneen DNS-konsolista, että järjestelmä sisältää oikeat tietueet. Tarkista, että jokaisella toimialueen ohjauskoneella on kaksi isännän (A) tietuetta toimialueen edelleenlähetyshakujen alueella: toisella on toimialueen ohjauskoneen isäntänimi ja toisella on nimi "(sama kuin pääkansio)". Molemmissa tietueissa pitäisi olla toimialueen ohjauskoneen IP-osoite.
• Kun DNS-ongelma on ratkaistu, suorita komento ipconfig /flushdns kaikissa koneissa, joita ongelma koskee. Tämä tyhjentää virheelliset tiedot kyseisten koneiden selvitysvälimuistista.

Suojatun kanavan ongelmat
Tämän tyyppinen ongelma ilmenee, kun toimialueeseen liitetyn tietokoneen paikallisesti tallennetun tietokonetilin salasana ei vastaa sen salasanaa AD:ssä. Suojatun kanavan ongelma estää laitetta suorittamasta todennusta ohjauskoneen kanssa. Se ilmenee usein "käyttö estetty" -virheenä aina, kun tietokone yrittää käyttää toimialueresursseja, kuten ryhmäkäytäntöpäivityksiä. Kaikki Access denied -tapahtumat eivät tietenkään johdu suojatun kanavan ongelmista, mutta jos ongelmaan liittyvän tietokoneen sovelluslokissa on Userenv-virheitä, joiden kuvauksessa lukee Access denied, suojattu kanava kannattaa testata.

• Toimialueen jäsenen suojattu kanava voidaan testata (ja tarvittaessa nollata) nltest-komennolla.
• pikanäppäimellä netdom Command voi myös testata suojatun kanavan ja nollata sen.
• Test-ComputerSecureChannel PowerShell -cmdlet-komennolla voit myös testata tai nollata suojatun kanavan.
• Jos kyseinen tietokone poistetaan toimialueelta, sen AD-tietokonetili nollataan ja siihen liitetään uudelleen toimialueeseen, sen suojattu kanava nollataan. Tämä ei kuitenkaan ole aina mahdollista.

SYSVOL-ongelmia
Ryhmäkäytäntömallitiedostot tallennetaan toimialueen kaikkien toimialueen ohjauskoneiden jaettuun SYSVOL-resurssiin. SYSVOL-tiedot replikoidaan toimihenkilöiden kesken käyttämällä joko FRS (File Replication System)- tai DFSR (Distributed File System Replication) -replikointia. Jos ohjauskoneessa ei ole jaettua SYSVOL-resurssia, tämä tarkoittaa yleensä SYSVOL-replikointiongelmaa.

Kellon vinous
Oletusarvoisesti Kerberos-todennus edellyttää, että toimialueeseen liitettyjen koneiden kellot ovat enintään viiden minuutin päässä toisistaan. Tämän kynnyksen ylittäminen aiheuttaa todennusvirheen, mikä puolestaan estää ryhmäkäytännön käsittelyn. Kaikki verkkotunnuksessa on määritettävä synkronoimaan kellonsa AD: n kanssa yhtä poikkeusta lukuun ottamatta. Toimialueen ohjauskone, jolla on PDC-emulaattori FSMO -rooli, on toimialueen hallitseva aikalähde. Siksi se on verkkotunnuksen ainoa kone, jonka pitäisi synkronoida ulkoisen lähteen, kuten julkisen NTP-palvelimen, kanssa.

Lisätietoja Windows-aikapalvelun määrittämisestä on täällä.

Puuttuvat ryhmäkäytäntötiedostot
Vähintään yksi ryhmäkäytäntötiedosto on saatettu poistaa tallennussijainnistaan SYSVOL-kansiossa. Tarkista asia siirtymällä resurssienhallinnassa kohtaan SYSVOL\domain\Policies ja etsimällä tiettyjä Userenv-virheissä mainittuja tiedostoja. Kunkin ryhmäkäytäntöobjektin tiedostot sijaitsevat Käytännöt-kansion alikansiossa. Kukin alikansio on nimetty sen ryhmäkäytäntöobjektin heksadesimaalisen GUID-tunnuksen (GUID) mukaan, jonka tiedostot se sisältää.

Jos käytäntötiedostoja puuttuu kaikista toimialueen ohjauskoneista, ne voidaan palauttaa varmuuskopiosta. Jos toimialueen oletuskäytäntö- tai toimialueen oletusohjauskoneen käytäntötiedostot puuttuvat eikä varmuuskopiota ole saatavilla, dcgpofix Command voi palauttaa molempien käytäntöjen oletusasetukset.

Lisätietoja aiheesta dcgpofix löytyy täältä.