Tracking changes in Group Policy

[daluebb]

I'm wondering if you can help me with this one. About a week ago, we noticed that all of our Administrative Settings (Computer) were missing from our Default Domain Policy. We are not sure when they were deleted. Here's the weird part. The last modified date (according to GPMC) was Feb. 17,2004. I have a backup from Feb. 18, 2004 and all the settings are there? This is not just a case where I have a different template file and I can't see the settings, I've had that happen before. The settings have literally been deleted, but we can't figure out how? Our server team is the only one with permissions to this policy, but they don't know much about group policy. Bascally, when changes need to be made, we end up having me do the changes with someone from the server team to log me on. We are really scratching our heads on this one. Any help/suggestions would be appreciated.

Auditing GP changes is VERY tough.

But, let's step back a second..

When you open a GPO, you're not looking at the SETTINGS..
you're looking at the ADM templates which SET THE SETTINGS.

Soooo... I'm not sure how they could have been "deleted."

Are you sure the specific ADM templates didn't "drop out" of that GPO? (ie: right-click on Administrative Templates and see which were loaded?)

I read what you wrote.. but maybe you can double check...

-J

[daluebb]

The template file was just fine. I had the same reaction. I even made a copy of the policy and then re-imported the adm files. The settings were gone. The weirdest part is that I have a backup of the policy with all the correct settings and the backup was made after the last modified date on the policy. I'm almost wondering if it could be some sort of error at the file level on the server???

If it occurs again.. try to get a screenshot.

[MikeG]

Two things that come to mind when I read your question. I pulled these from "Designing a Managed Environment" resource kit publication.
:idea: "Keep in mind that creating and linking GPOs is a sensitive privilege that should be delegated only to administrators who are trusted and understand Group Policy."
&
:idea: "Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create a new GPO at the domain level and set it to override the default settings in the default policies."

On the first item, it's very easy for a person who has permissions and doesn't fully know what they're doing, to incorrectly configure something.
On the second item, I think this is recommended in case a service patch accidently reconfigures or corrupts the two default GP's. So in order to avoid this, never modify the two default ones, create new ones.
Neither of these may be what happened in your case, but it's at least a best practice.

Mike:

I couldn't agree with you more on your first "lightbulb" point.

But, I'm not too sweet on point #2. That is, I DONT recommend
that people EVER link anything higher in the food chain than
the Default Domain Policy.

See page 237 and 238 of the new book...

The "best practice" you speak of is kinda old in this case..
as I state in the book, it has merit.. but ultimately,
I think going forth and modifying the Defaults for
"WHAT THEY DO BEST" is A OK, if you know what it
is that THEY DO BEST. :-)

Hope that makes sense.

[verb`]

Ive always been of the mindset as well that very little should be modified on the default GPO.

For me, the reason has always been that there is going to be *someone* who needs an exception from something youve set in a GPO. By having your function specific settings in seperate GPO's, you have more flexibility in how they are applied.

So I've always found myself in a situation where, unless I know with out a doubt that every setting in my default GPO has to be applied to every user/computer, I make it a seperate GPO. The only thing that drives that is corporate policy, and even then I end up with exceptions =)

Just my 2....
Tim

[clandouglas]

daluebb, I have read that you can turn on "Directory Service Auditing" in the Domain Controller Security Policy. This should spit out Event ID 565's. I have played with this in my test domain and rebooted both DC's to no avail. I am getting 565's, but nothing related to Group Policy changes, even when I do deletions or additions.
I got these suggestions from the following article, which you need acceess to:
Site: www.windowsitpro.com ArticleID: 39769.

Has anyone been able to generate valid Event 565's to audit group policy changes?

[clandouglas]

I have now figured out that the event ID's I was looking for were 566's and I have now been able to track them throughout my test domain and figure out which user created, deleted, and modified each specfic GPO.... now to automate this.

[kevsully]

Tim,

I think I understand your choice here, have heard it many times before for different reasons, and I am not one to judge peoples justifications for why they make certain administrative choices. For the benefit of the group though I feel like chiming in with a differing opinion is necessary.

Your model of creating a new GPO for every change has major issues associated with it. First of and not the least important is the fact that every GPO created adds 4MB of files to the SYSVOL. These are the default administrative templates. This is a big issues. And when there are changes to administrative templates (I know this does not happen a lot but it did multiple times this year!) keeping all stores in cahoots is tough! Very very difficult to manage and some significant SYSVOL bloat. So this is one point. In a small organization this may not be a problem but manageing many GPOs in any sized org is tough.

Next, from a processing perspective this is bound to cause logon latency. I know that this has been discussed a lot in different forums so I don't want to kill the point and if there is disagreement I strongly suggest you test this yourself. When a client processes 100 GPOs with 1 setting each (1000 settings) the client processing is going to drag much, much more than if a client is processing 1 GPO with 100 settings (1000 settings). What is missing to make this appealing to everyone is settings based filters. Currently there are filtering options on the GPO itself, meaning every setting/policy within that GPO will be processed based on the results of the filter. There are also WMI queries available on the GPO in Windows server 2003. These are very powerful but are not very flexible and anyone who has worked with WMI knows that some of the performance of WMI queries leaves a bit to be desired.

My suggestion is always to limit the numbers of GPO in the organization. (Yeah, I know, easier said than done). There are tools now and new tools will become available that make the reporting and management of Group Policy better and better.

Kevin