GPO blijft toegepast ondanks dat deze niet meer bestaat

[DarkSide]

Ik heb een aantal maanden geleden een GPO gemaakt met een software restriction op Outlook.exe.
Dit was een simpele pathrule met een disalowed erop. Dit werkte prima. Mensen kregen keurig de melding dat het starten van Outlook niet mocht omdat een policy dit verbiedde.
De reden voor deze policy was omdat we bezig waren met een mailmigratie van Lotus Notes naar Outlook.

Voor de migratie heb ik de link van de GPO verwijderd van Alle OU's en mensen konden maandag ook gewoon Outlook opstarten.
Nu krijgen we meldingen dat sommige gebruikers Outlook niet meer kunnen opstarten vanwege de restrictie die op Outlook staat.
Als ik een RSOP draai zie ik de policy er niet tussen staan (zoals verwacht). Als ik de policy weer link naar de OU's maar nu met een unristricted optie. Dan zie ik dat de GPO idd toegepast is via een RSOP. Maar outlook kan nog steeds niet worden opgestart. Totdat ik outlook.exe rename naar Outook2003.exe.

Ergens is de policy dus weer actief geworden. Maar hoe? In de eventviewer zie ik dat er een software restriction policy op outlook actief is met de GUID van de policy vermeld. Deze staat niet op de sysvol directory van de domain controller. En wordt ook niet vernoemd in het register (van de client en de DC).

Wat kan er nog meer aan de hand zijn? Ik kom er niet achter hoe deze policy weer actief is geworden. Omdat men de afgelopen dagen wel gewoon Outlook heeft kunnen opstarten.

oplossing gevonden.
Waarschijnlijk typ fout gemaakt met het zoeken in het register.
Regkey verwijderder met de hashcode van de deny rule en het werkt inmiddels weer.

blijft raar dat deze plotseling wel weer actief geworden is.

[ Voor 7% gewijzigd door DarkSide op 14-04-2010 15:02 . Reden: oplossing gevonden ]

[Rolfie]

Heb je hem verwijderd, of geunlinkt?

[didi79]

2e DC ? AD sync die niet werkt en waardoor de policy op die 2e DC nog actief staat ?

[DarkSide]

Heb hem geunlinked. En op alle DC's was de GPO niet meer aanwezig (niet in sysvol dir).
Daarbij hadden een paar gebruikers hier last van over verschillende sites en de rest niet.
Maar het is inmiddels opgelost.

[DrFlash]

Een policy is in de meeste gevallen niets meer dan een registry setting die applied wordt. Als je dan de policy verwijderd wordt NIET de registry aanpassing teruggedraaid. Om dat voor mekaar te krijgen moet je een policy maken die het tegenovergestelde doet van de oude regel (eg, allow op outlook) of inderdaad met de hand de registry setting verwijderen.

Note, dit geld niet voor alle policies, sommige zullen wel automatisch verdwijnen omdat die key bij het opstarten van windows weer default gezet wordt.

In het kort, het is nooit verstandig een link van een policy weg te gooien, je moet de policy de-activeren.

[DarkSide]

Ik heb nog nooit een officiele policy moeten deactiveren (het tegenovergestelde laten doen). Tijdens het laden van de policy worden de juiste regkeys geladen/gezet. Als daarna de policy niet meer nodig is moet je deze gewoon kunnen unlinken en dan zou alles weer normaal moeten draaien.
Wel kan dit problemen opleveren bij eigengemaakte ADM's waardoor je Tattooing krijgt. Maar daar ging het hier niet om.
Heb vaker pathrules toegepast in GPO's om tijdelijk bestanden te blokkeren. Na het opheffen van de rule werkt alles weer.
Daarbij had ik ook expliciet een unristrected gegeven maar nog werkte dit niet.

[SteeringWheel]

DarkSide schreef op donderdag 15 april 2010 @ 14:06:
Ik heb nog nooit een officiele policy moeten deactiveren (het tegenovergestelde laten doen). Tijdens het laden van de policy worden de juiste regkeys geladen/gezet. Als daarna de policy niet meer nodig is moet je deze gewoon kunnen unlinken en dan zou alles weer normaal moeten draaien.

Dit laatste is niet waar, als je een policy verwijdert blijven de settings gewoon staan op de client. Ik zou dus maar op de client op zoek gaan naar de betreffende registry keys en deze verwijderen en zien wat er dan gebeurt.