Hi, Tim here. Ever heard of a Best Practice Analyzer , otherwise known as a ‘BPA’? It’s a type of tool that many of our product or support teams have been creating the last few years which can be used to gauge the general health of a…(read more)

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

Yesterday at TechEd in Barcelona, Microsoft made a slew of announcements. And buried in those announcements was the note about Group Policy Preferences. This is the name Microsoft has given to the DesktopStandard PolicyMaker extensions that they acquired last year. The good news is that these extensions are finally going to see the light of day as a free part of the OS when Server 2008 ships!!! This is HUGE because these extensions greatly add to what you can configure via Group Policy. And my understanding is that they will work on XP and above, which means that you get some of these great features without having to upgrade to Vista. In addition to adding support for new policy areas such as mapped drives, mapped printers, ini files, environment variables, shortcut distribution, local users and groups, scheduled tasks, power options, network options and IE settings, they also support much more granular filtering than you could ever get from WMI filters or security groups. This is huge because it means that there will be few things that you can’t configure on a Windows desktop using Group Policy!

Microsoft has created a whitepaper that you can download to get more detail on this new feature. This is great news!!! Cudos to the Group Policy team for making this happen!

Tags:

Group Policy