Group Policy Performance and Security Policy

Here’s a great article about group policy. I didn’t realize that you could set ACL’s on files using GPO’s that’s sweet. To bad the Event Viewer for Operational Logs isn’t available for XP or 2003. 🙁

If you haven’t already seen it, check out my article in this month’s TechNet Magazine on "Optimizing Group Policy Performance". The article goes into fair bit of detail about things you can do (or not do) to ensure that GP performance is good on your Windows systems. But one thing I didn’t get into is how some specific Client Side Extension (CSE) behaviors can cause performance slowdowns. I received an email from someone at Microsoft asking about this yesterday. His specific question was around the performance impact of using GP to set file system or registry security. GP today has that capability under Computer Configuration/Windows Settings/Security Settings/File System (or Registry). But of course, if you use this feature against large numbers of files or folders (or reg keys), its going to take a while to modify ACLs on those objects, just as it would if you are doing it through Explorer. But his question had to do with the impact of this on system performance, if GP processed these ACL changes every time processing ran. The answer, of course, is that GP processing settings only if one of several situations occur. First, if *something* changes in the GP environment, a client will process those changes during the next processing cycle (I talk about what those changes could be in the article).

The other scenario where security policy would process every time GP processes is if an administrator explicitly told it to do so by setting the per-computer policy at Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing\Process even if the Group Policy Objects have not changed. Now of course, enabling this setting can have a very obvious impact on system performance if what you’re doing in security policy are expensive operations like file system re-ACLing. But if not, the advantage of using this setting is that you ensure that, every 90 minutes or so, any security policy you have defined will be re-applied, just in case a pesky user figured out a way to undo them (which they should not if they are not administator on their systems, right????). But in general, I would leave this setting alone.

The 3rd scenario where security policy would process is by virtue of its own built-in behavior. That is, the Security CSE will process security policy every 16 hours by default, regardless of what else is happening. This is a failsafe that MS decided to put into security policy so that security policy will get re-applied if the environment is reasonably static. You can actually modify this interval to be something other than 16 hours via a registry tweak (I actually created a custom ADMX file for this that will be on the CD in the upcoming Windows Server 2008 Resource Kit book, which I wrote the GP chapter for). The registry tweak info can be found at http://support.microsoft.com/kb/277543/en-us.

Tags:

Group Policy, Security Policy, TechNet Magazine

Group Policy Performance and Security Policy
gpoguy
Thu, 17 Jan 2008 22:15:57 GMT