[XP] wijziging in gpedit terugvinden in registry.

[Verwijderd]

vraagje..

Ik ben bezig om erachter te komen welke key in het register veranderd wordt nadat ik een wijziging in de group policy editor heb gemaakt.

Ik heb al een export van het register voor en na de wijziging gemaakt, en deze 2 files met Ultra Edit met elkaar vergeleken. Maar ik kom daar geen wijs uit met al die hexadecimale abracadabra. Is er misschien een simpele oplossing of zie ik iets over het hoofd?

[elevator]

GpEdit.msc werkt met .adm files - daarin staan de registry wijzigingen die uitgevoerd worden

[WildernessChild]

Regmon is je vriend

[Verwijderd]

ok dat met die *.adm file is gelukt en heb betreffende key gevonden.

maar nu volgt het volgende probleem.
Het is de bedoeling dat ik een regkey maak die een bepaalde optie "enabled". Als ik nu de optie op "not configured" zet en dan de regkey importeer, komt er in de registry inderdaad die key bij, maar in de policy editor blijft betreffende optie op "not configured" staan. Iemand een idee hoe dit nu weer kan?

[elevator]

De policy editor is wel een registry editor - maar niet een van de actiev registry.

De gpedit.msc edit namelijk de registry in een eigen file (een *.pol file) en merged die later met de actieve (systeem) registry.

[Verwijderd]

Ok dat is duidelijk.. Maar dat gaat natuurlijk niet andersom? Ik wilde namelijk voor een x aantal pc's een regkey maken die deze optie "enabled".

Ik heb net gezocht naar zo'n *.pol file maar die zijn niet aanwezig op de pc. Misschien dat ik daar iets mee kan?

[mutsje]

de key middels een inlog script mergen is dat geen optie?

[Verwijderd]

draadje weer oppikken...

het mergen van de regkey in een loginscript is geen optie, omdat het maar een bepaalde groep gebruikers betreft. En waarom zou het wel werken in een loginscript als het handmatig niet gebeurd?

[Dr. Bean]

Die optie wordt wel via gpedit enabled, maar dat komt inderdaad niet terug in gpedit zelf, die blijft gewoon z'n huidige waarde behouden (dus doorgaans "not configured") Of je moet de gpedit-settings alweer opslaan in een .ADM ofzo.

Stel: je past een policy aan, en die moet worden uitgerold op diverse PC's, of die instelling nu wél of níet gemaakt is, je wilt 'm toch doorvoeren. (al was het maar om zeker te weten dat een bepaalde setting wordt doorgevoerd over je netwerk)

Als je die regkey nu hebt geisoleerd, en je weet dat de key OP ZICH werkt (dus niet kijken naar de results van gpedit, aangezien gpedit je bestaande registrysettings niet scant oid), dan kun je die zeker mbv een loginscript doorvoeren: je zorgt dat die key alléén uitgevoerd wordt als mensen in een bepaalde groep zitten (OU of weetikwat, even ervanuitgaande dat je daar een DC hebt)
Dan ben je toch klaar? Of denk ik nu te simpel?

[ Voor 19% gewijzigd door Dr. Bean op 08-07-2004 11:12 . Reden: ff wat extra :+ ]

[Verwijderd]

Ja je hebt gelijk. De regkey blijft gehandhaafd ondanks wat gpedit aangeeft.

Voor zover is het probleem dan opgelost, maar via het loginscript gaat het niet. Probleem hierbij is dat de bovenliggende entry (SOFTWARE\Policies\Microsoft\windows ) alleen schrijfrechten heeft voor de administrator en system. En het loginscript gebeurd op userniveau.

even een korte uitleg over ons probleem:
Sinds de ingebruikname van XP doet het vervelende probleem zich voor dat een roaming profile welke zich op een Windows 2003 server bevind tijdens de login van een gebruiker niet geladen wordt.


Oorzaak hiervan is een controle op “owner” van de betreffende profilemap welke een negatief resultaat oplevert. Gevolg hiervan is dat het roaming profile niet geladen wordt tijdens de user login.

Om de controle niet meer plaats te laten vinden en dus de melding achterwege te laten en het roaming profile te laden dient in de lokale policies van de Pc een setting aangepast te worden.

Het gaat hier om de volgende optie: Computer Configuration->Adminstrative Templates->System->User Profiles->Do not check for user ownership of Roaming profile folders.

tot zover duidelijk denk ik...

de regkey is inmiddels gevonden zoals jullie begrijpen. Maar het mooiste zou nu zijn dat we zo'n policy maken, maar ik heb geen flauw idee hoe. Ik heb al zitten klooien met poledit (NT4) maar dit werkt niet echt goed.

We kunnen natuurlijk onder nt4 de ntconfig.pol zo maken dat het werkt maar dan dienen de users (XP en/of w2k) eerst onder een nt domein in te loggen waarna we dan voor elke user het profile om moeten zetten voor gebruik op de w22k3 server.

Ik hoop dat het duidelijk is en het wijkt natuurlijk alweer een beetje af van de topictitel maar ik stel hem toch maar nu dit al rolt...

[sjdurand]

Waarom niet via een GPO instellen? En deze koppelen aan de ou van de computers.

[ Voor 40% gewijzigd door sjdurand op 08-07-2004 16:31 ]

[Verwijderd]

uhm zou je de afkorting ou even willen definieren want ik snap even niet wat je bedoelt.

[Dr. Bean]

OU=Organizational Unit, dit is om bv je organisatie in een domein goed te kunnen beheren.
Je kunt alle mensen op 1 afdeling de rechten geven op een bepaalde netwerkschijf, en andere afdelingen géén toegang verlenen, om maar een zijstraat te noemen.

Om terug te komen op jouw vraag: alle PC's zijn in één of meerdere OU's geplaatst. Je kunt over een specifieke OU rechten geven, en policies koppelen.

Zet dus de PC's die het probleem hebben in een andere OU, en koppel een GPO, met de goede registry-aanpassingen ed, aan die OU.
Zie bv het volgende: Windows 2000: Account & Computer policy's zetten, hierin wordt het aardig uitgelegd.

Verder raad ik je dan aan om eens een goed boek over Windows 2003 te lezen, voornamelijk één over de inrichting van een 2k3 (Active Directory) domein.

[Verwijderd]

ok dat is me duidelijk en die link is ook erg informatief. Maar wat daar beschreven staat is (nog) niet van toepassing want we draaien nog geen AD (nt4 he) alleen worden voor de gebruikers de profiles al op de fileserver geplaatst wat dus al win 2003 is. En dan komt het al eerder beschreven probleem om de hoek kijken.

Maar wellicht heeft het proberen met de gegeven tips enig positief effect.