Michael Kleef ::: MSFT

http://twitter.com/mkleef

Reducing confusion: Group Policy isnt dependant on schema versions or server version

Reducing confusion: Group Policy isnt dependant on schema versions or server version

  • Comments 2
  • Likes

We hear consistent questions on forums and emails around the recurring question:

"If I want to take advantage of XYZ new feature in Group Policy do I need to be on the latest server version?"

Variations to this theme are:

"If I want to implement XYZ new feature in GP do I need to update schema?"

"Are there any interop issues in GP with x86 or x64 versions?"

"Do I have to update my XP/2003 policies to 2008/Vista versions?"

The answer to all of these, generally, is no.

Group Policy technically isnt bound by the AD version or server version - though sometimes the settings within require schema updates to enable them to work. Examples of these are the recent changes to support BitLocker and Wireless settings where the schema required extending because those attributes didnt exist to support the storage of those functions in AD.

Heres (very basically) how GP works:

1. The GP Client discovers through an AD lookup that policy objects apply to it. Note that the method of doing this hasnt changed since Win2k. AD tells it where in the SYSVOL it can find the policy file associated with the object referenced in AD.

2. The GP Client uses an SMB call to read the policy file from the SYSVOL

3. The GP Client reads any necessary settings out of those policy files using client side extensions (CSE's) that process those settings

4. The GP Client applies those settings to itself

Note in every instance here, the GP Client does all the work. The server doesnt do anything! Note also that the settings are stored in a file on the SYSVOL. That file hasnt changed in architecture since inception. So the very base fundamentals of the GP platform really dont change from release to release. There have been minor improvements though in discovery and link state detection though again, this is a client function.

We essentially extend on top of this GP delivery platform with new plugged in extensions. This means that there isnt an "XP" version of policy. Any policy you write today stays the same even as you upgrade your servers. What determines changes to policy is:

1. New extensions

2. New administrative tools

A good example of this in Group Policy Preferences. This is supported in Vista SP1 and Windows Server 2008 administrative tools. These administrative tools write the new extension settings into the same policy files that have always been there!

Of course the GP client has to be able to support these settings with client side extensions (CSE's) given it really does all the work of processing the policies. This means that you may need to install a CSE to update the client to support new settings. Sometimes (though rarely) we extend the CSE downlevel, as we did with Group Policy Preferences cause its just so cool...

The key here is that to get the settings into policy you only need a Vista SP1 machine with the latest RSAT tools in order to write the new extension changes into policy. You dont need to change your servers. You dont need to change domain functional modes. You dont need to change forest functional modes!!

Sometimes you will need to update schema to support specific newly introduced settings though you only need to do this if you want to actually use those settings!

So go ahead. Use the new stuff like GPP - it will save you time, supports downlevel clients and doesnt require you to change servers or update AD. Its really quite low impact. Get started!

 

Comments
  • I just blogged about this very question over on my blog . Essentially the question we hear a lot is do

  • We had a question a couple of days ago about the usage of ADMX template formats in Windows XP/Server

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment