Gruppepolicy mangler på VPN? Sjekk omfanget før tunnelen

Noe som gjaldt på kontornettverket, slutter å gjelde i uken en bruker begynner å jobbe over VPN, og tunnelen får skylden før noen åpner en rapport. Gruppepolicy bestemmer hvilke innstillinger som lander på Windows-brukeren og -datamaskinen, henter materialet fra domenet og kjører behandlingen på klientsiden, og de tre trinnene feiler på tre ulike måter. Tunnelen endrer bare hvilken vei klienten har. Å gå gjennom kontrollene i rekkefølge hindrer at et filrettighetsproblem blir jaget som et ruteproblem.

Start med innstillingen, ikke tunnelen

Skriv ned én forventet GPO og én konkret innstilling i den, og avgjør deretter om innstillingen hører til brukerkonfigurasjon eller datamaskinkonfigurasjon. Dette forutsetter en autorisert Windows-klient som er domentilknyttet, på en godkjent VPN, ikke en uhåndtert eller ren skyenhet som gjøres til domenemedlem. Svaret om omfanget avgjør hvem som kan lese resultatet og om det trengs forhøyede rettigheter, så avklar det før du kjører noe.

Spør domeneadministratoren hvilken kobling, objektplassering, sikkerhetsfiltre og WMI-filtre som skal være i spill. Å endre disse kontrollene for at en test skal bestå er et annet prosjekt med en annen eier.

Les rapporten med kontoen som eier innstillingen

I den berørte brukerens egen økt, kjør whoami /user og deretter gpresult /scope user /r. Kontoen som autentiserte VPN-en, er ikke automatisk den Windows-kontoen du leser policyen til, og en kontroll fra en administratorkonto svarer på et annet spørsmål. Lagre grunnlinjen under et nytt filnavn, for eksempel %TEMP%\vpn-policy-user-before.html. gpresult-referansen dokumenterer bryterne for omfang og utdata, og det er verdt å vite at det ikke oppdaterer noe å generere en rapport.

Datamaskinpolicy har sitt eget omfang og sin egen rettighetskontekst, så undersøk den separat med den forhøyelsen den trenger. Å folde begge omfangene inn i én rapport er måten en brukerinnstilling erklæres manglende på, selv om den aldri var i det omfanget.

Oppdagelse er ikke tilgang: først SRV-poster, så SMB

Med den godkjente VPN-en tilkoblet, bekreft at klienten løser domenekontrollere gjennom den tiltenkte DNS-veien; et offentlig nettsted som lastes, sier ingenting om kontrolleroppdagelse. For eksempeldomenet corp.example svarer nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example på spørsmålet du faktisk har. En returnert tjenestepost er bare oppdagelsesbevis, fordi adressen til den valgte kontrolleren fortsatt må være nåbar med den påkrevde autentiseringen og tillatte katalogtjenestene. Policymaterialet kommer deretter fra SYSVOL, som er en SMB-lesing mot nettopp den kontrolleren og ikke en ICMP-test.

Svakere bevis forveksles lett med bevis. Et ICMP-svar fra en kontroller ved siden av en avvist lesing av en policymal, gir en rapport som ser tom ut av en grunn ingen ennå har koblet.

Hold distribusjonens AD-tjenestetillatelser, returveier og tidssynkronisering sammenhengende i stedet for å erstatte dem med en generell brannmuropning eller en offentlig DNS-tjener. Policydata som er forskjellige mellom kontrollere, er et replikeringsspørsmål for katalogeieren.

Én oppdatering, to rapporter, én sammenligning

Når veien er bevist, be om den relevante oppdateringen med gpupdate /target:user og les resultatet i stedet for å anta det. Standardoppdateringen bruker endret policy, mens /force ber om ny anvendelse; ingen av dem reparerer DNS, filrettigheter eller filtrering. Noen utvidelser fullføres først ved en senere pålogging eller en annen hendelse i forgrunnen, så én kjøring er ikke en dom. Å legge til avloggings- eller omstartsbrytere i økten til en ekstern bruker som rutinediagnostikk kaster det brukeren hadde åpent.

Generer en andre rapport under et annet filnavn og sammenlign behandlingstiden, den forventede GPO-en, dens anvendte eller avviste status og selve innstillingen. En rapport fra en tidligere vellykket økt beviser ingenting om denne oppdateringen. En policy som ble filtrert bort, peker på anvendelighet snarere enn transport, noe som endrer hvem som eier neste steg.

Bind feilen til én enkelt aktivitet

I Loggbok for hendelser starter du med gruppepolicyvarselet eller -feilen i systemloggen, og går deretter til den operative loggen GroupPolicy under Program- og tjenestelogger. Filtrer den operative loggen på aktivitetsidentifikatoren for oppdateringen du nettopp kjørte, fordi en ny oppdatering får en ny identifikator, og å blande den med gårsdagens hendelser gir en skråsikker og gal konklusjon. Noter tidspunktet, bruker- eller datamaskinkonteksten, den valgte kontrolleren, GPO-en, feilkoden og den mislykkede avhengigheten.

Den noten er det nettverks- eller katalogeieren kan handle på. Å være tilkoblet VPN og ha kjørt gpupdate flere ganger er ikke bevis, og ingen av dem overlever en overlevering.

Hold HTML-rapportene private, siden de avdekker interne navn, gruppemedlemskap og sikkerhetskonfigurasjon. Når innstillingen er bekreftet, fjern de midlertidige tillatelsene du la til, i stedet for å la dem stå.