Active Directory -toimialueen ryhmäkäytäntöjen käsittelyvirheiden vianmääritys

Artikkelin yhteenveto: tässä artikkelissa käsitellään Active Directory -toimialueen Windows-tietokoneiden ryhmäkäytäntöjen käsittelyvirheiden vianmääritystä.

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
Ensin määritetään ongelman laajuus. Jos vain yksi tietokone ei pysty käsittelemään ryhmäkäytäntöä, ongelma johtuu todennäköisemmin kyseisen tietokoneen määritysvirheestä tai toimintahäiriöstä kuin toimialueen ohjauskoneesta tai itse AD:stä. Jos ongelma koskee vain tiettyä tietokonetta, ennen vianmäärityksen jatkamista kannattaa suorittaa komento gpupdate /force kyseisessä tietokoneessa. Näin voidaan varmistaa, ettei vika johdu verkon tilapäisestä ongelmasta, joka on jo ratkaistu.

Kun tietokone ei pysty käsittelemään ryhmäkäytäntöä, se lisää sovelluslokiinsa yleensä vähintään yhden Userenv-virheen. Tavallisia tapahtumatunnuksia ovat 1030, 1053, 1054 ja 1058. Kyseisen tietokoneen virheiden kuvauksista saadaan vihjeitä taustalla olevasta ongelmasta.
 
DNS-ongelmat
Ryhmäkäytäntöihin liittyvät virheet (ja monet muut AD-virheet) johtuvat useimmiten nimenselvityksen ongelmasta: asiakas yrittää päivittää ryhmäkäytäntöasetuksensa, mutta ei pysty määrittämään nimeä toimialueen ohjauskoneelle tai sen IP-osoitteelle, tai asiakas selvittää kyseisen nimen sellaisen tietokoneen osoitteelle, joka ei todellisuudessa ole toimialueen ohjauskone tai jota ei ehkä ole edes olemassa. 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 kyseisessä tietokoneessa ja suorita komento nslookup toimialueen_nimi (esimerkiksi nslookup mydomain.local). 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 selvittää myös yksittäisten toimialueen ohjauskoneiden nimien ja niiden IP-osoitteiden välinen vastaavuus (esimerkiksi nslookup dc1.mydomain.local).
• Suorita komento ipconfig /all tietokoneessa, johon ongelma liittyy, ja varmista, että se on määritetty käyttämään ainoastaan 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, muista suorittaa komento ipconfig /flushdns ongelmaan liittyvissä tietokoneissa. Se tyhjentää virheelliset tiedot kyseisten tietokoneiden selvityksen välimuistista.

Suojatun kanavan ongelmat
Näitä ongelmia ilmenee yleensä, kun toimialueeseen liitetty tietokone on ollut offline-tilassa niin kauan, että sen AD-tietokonetilin salasana ei enää vastaa tietokoneen paikalliseen välimuistiin tallennettua kopiota kyseisestä salasanasta. Näitä ongelmia voi ilmetä muissakin tilanteissa. Suojatun kanavan ongelma estää tietokonetta tekemästä todennusta toimialueen ohjauskoneen kanssa ja ilmenee yleensä Access denied -virheenä, kun kyseinen tietokone yrittää käyttää toimialueen resursseja, kuten ryhmäkäytäntöjen 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.
• Myös netdom-komento voi testata ja nollata suojatun kanavan.
• Jos Active Directory PowerShell -moduuli on asennettu, suojattu kanava voidaan testata ja nollata myös Test-ComputerSecureChannel PowerShell cmdlet -komennolla.
• Joissain tapauksissa ongelmaan liittyvä tietokone tarvitsee poistaa toimialueelta, nollata sen AD-tietokonetili ja liittää se toimialueeseen uudelleen, jotta sen suojattu kanava voidaan nollata.

SYSVOL-ongelmat
Ryhmäkäytäntötiedostot tallennetaan toimialueen kaikkien ohjauskoneiden yhteiseen SYSVOL-resurssiin ja siinä SYSVOL\domain\Policies-kansioon. Jos SYSVOL-resurssi puuttuu toimialueen ohjauskoneesta, ongelma liittyy yleensä tiedostojen replikointipalveluun (FRS) tai DFS-replikointipalveluun sen mukaan, kumpaa niistä käytetään SYSVOL-replikoinnissa.

Tässä artikkelissa ei annetta ratkaisuja kaikkiin tiedostojen replikointipalvelun (FRS) tai DFS-replikointipalvelun ongelmiin, mutta seuraavat linkit voivat osoittautua hyödyllisiksi:

• SYSVOL-puun ja sen sisällön muodostaminen uudelleen (englanninkielinen).

Kellon poikkeama
Jos ongelmaan liittyvän tietokoneen kellonaika poikkeaa toimialueen ohjauskoneen kellonajasta yli viisi minuuttia aikavyöhykkeiden mukaan korjattuna, oletusarvon mukaan kyseinen tietokone ei pysty tekemään todennusta toimialueen ohjauskoneen kanssa eikä siksi pysty käsittelemään ryhmäkäytäntöä. Toimialueen jäsenet on määritettävä synkronoimaan kellonsa toimialueen ohjauskoneen kanssa, ja toimialueen ohjauskoneiden on puolestaan synkronoitava kellonsa PDC-emulaattoriroolissa olevan toimialueen ohjauskoneen kanssa. Siksi PDC-emulaattorin on oltava toimialueen ainoa tietokone, joka on määritetty synkronoitumaan ulkoiseen lähteeseen, kuten julkiseen NTP-palvelimeen.

Saat lisätietoja Windows-aikapalvelun määrittämisestä täältä.
 
Puuttuvat ryhmäkäytäntötiedostot
Ryhmäkäytäntötiedostoja on voitu poistaa niiden SYSVOL-tallennuspaikasta. Tämän helpoin tarkistustapa on avata Resurssienhallinnasta SYSVOL\domain\Policies ja etsiä tiedostoja, jotka on mainittu ongelmaan liittyvien tietokoneiden Userenv-virheissä. Kunkin ryhmäkäytäntöobjektin tiedostot ovat Policies-kansion alikansiossa. Alikansion nimi perustuu sen ryhmäkäytäntöobjektin GUID-tunnukseen, jonka tiedostoja se sisältää.

Jos käy ilmi, että käytäntötiedostoja puuttuu kaikista toimialueen ohjauskoneista, ne voidaan palauttaa varmuuskopiosta. Jos toimialueen oletuskäytännön tai toimialueen ohjauskoneen oletuskäytännön tiedostoja puuttuu eikä varmuuskopiota ole käytettävissä, molempien käytäntöjen oletusasetukset voidaan palauttaa dcgpofix-komennolla. Lisätietoja dcgpofix-komennosta on tässä artikkelissa.