[gptalk] Re: Complete list of all available CSEs and their functionality

Hendrikus,

I see that you are also interested in designing GPOs in light of performance. 
In small companies or for those companies whose work-force is not 
geographically dispersed, spending a lot of effort to design GPO for super 
efficient deployment is typically not necessary because all the updates can 
take place quickly and with low load on the infrastructure devices (DCs and 
networks). There is no clear delineation of what company size or what level of 
workforce dispersion starts to cause impacts to your systems. I can also highly 
recommend Darren's article on 'how to isolate GPOs by client extension'.

Since I recently responded to a similar question on a different GPO forum, I'll 
duplicate some of that information here with some estimated numbers to give 
everyone a chance to understand the impacts of GPOs on our DCs and networks.

========================================================================
VERY LONG WINDEDNESS WARNING
========================================================================

Group Policies process in order by 'client extension'. That means they 
essentially process all registry entries from the ordered list of all GPOs 
applicable to the Computer and then process all security entries from the 
ordered list of all GPOs applicable to the Computer and so on.... It's 
typically milliseconds between the registry updates. Then the user logs on and 
the GPO processing engine performs the exact same "client extension" by "client 
extension" processing for each of the GPOs applicable to the user account.

The 'use' of separate GPOs to implement registry entries (as an example) from 
different Administrative template sections and then placing one or the other of 
the GPOs above/below just isn't going to get you much--other than "generic 
content of GPO visibility" by naming your GPO for what it does (Wireless 
Settings GPO, User Profile Settings GPO, Printer Configuration settings GPO, 
etc.).  But, you can design GPOs to operate more efficiently by separating them 
by 'client extension'.

Note: This next bit is admittedly long (yeah long-winded). Some of the other 
GPO Admins have written articles on this (Hi Darren), but my spin on it will 
have some numbers to look at...or better yet to 'look aghast' at.

Core Idea: Separate GPO Settings by Client Extension for better Performance 
(create your GPOs with only one kind of setting type in each...registry, 
security, etc.)
----------------
Let's say you've been editing GPOs for some time in a domain (in a large 
Enterprise). "Real world" experience leads me to guess that a good many GPO 
admins simply add additional settings to 'existing' GPOs over time because it's 
more convenient that creating new ones. Sometimes they add Security settings, 
sometimes Registry settings, etc. The point is that over time, a limited number 
of Group Policy Objects contain multiple client extensions linked to them. 
Okay, so what is the impact to your DCs of doing that kind of thing at the 
domain root level?

When it comes time for a device to perform its background group policy refresh, 
the device uses several criteria to determine whether the GPOs that are 
applicable to it need to be re-processed. Examples of changes are 'new GPOs 
being targeted', 'GPT.INI version changes', and 'security group changes' (and 
please note that the same goes for the user account background policy 
refreshes).

Let's focus upon "just" a Gpt.Ini file change. "One" change to a GPO updates 
the GPO's GPT.Ini "version history" file in AD and in Sysvol. Each client 
device knows what the version numbers of the GPOs that were last applied are 
(stores them in its registry). Therefore, when the background GPO refresh 
"wakes up" and checks its local versions against those in Active Directory, the 
GPO sub-systems "wake up" to re-process the GPOs on-the-fly.

Here's the kicker, all that the GPO sub-system knows is that a GPO 'changed', 
it doesn't know what "part" or which "client extension" changed. So if the GPO 
had both security settings and registry settings, then both of those client 
extensions have to wake up and process the GPOs. Stated another way, you've 
just told all of your client devices to process 'both' registry AND security 
client extensions for all GPOs with those kinds of settings in them. BUT, you 
only "needed" the "registry" client extension processed. In short, you have 
asked the client, the network, and the DC to perform more work than is 
necessary. Let me give you a more realistic idea how this impacts your systems.

As an example, say that you have a large domain with 54,253+ devices (okay, 
I'll be nice and say that only 50,000 are online...nice round number). Guess 
what? The GPOs at the root of your domain get 'hammered' all day long (or 
rather, the Gpt.Ini version history files at the root of each GPO get 
'hammered').  Let's say you have 5 DCs in your local domain (ignore backup DCs 
in remote locations). Also assume a standard 9 hour day. How many hits will you 
have for "each" GPT.Ini file per DC per day (ignoring the device boot up/user 
logon situation...we'll just estimate the background refresh hits)? [And 
remember that GPOs perform a standard background refresh every 90-120 minutes, 
so we'll estimate right in the middle and say that each device initiates a 
background refresh every 105 minutes (both computer and user because these are 
launched separately).]

The Math
========
Nine hours = 60 * 9             = 540     Minutes
540 minutes / 105 minutes       = 5.14    Refreshes per day for each side
5.14 refreshes * 2              = 10.28   AD GPO hits for both Computer and User
                                          settings for each device per day
10.28 hits/day * 50,000 devices = 514,000 Total hits/day
514,000 Hits per day / 5 DCs    = 102,800 GPT.INI read hits per DC per day

That's a lot of hits already, but now lets add the 'multiple' GPOs into this.

Let's say you have targeted 8 Computer GPOs towards clients on average and 8 
User GPOs on average. Okay, okay, let's just focus on domain root level 
impacts, let's say that you only have 4 of each type of GPO (Computer settings 
and User settings) linked to the root with the rest of your GPOs split up into 
various user and computer OUs.

So... that would be a "Read my Gpt.Ini file version" load on SYSVOL for each DC 
of (102,800 hits per GPO * 8 root level GPOs) = 822,400 reads per DC per day.
And remember, so far you've made no changes. "Just" reading the version history 
files in the GPOs places a load of 800,000 hits on each DC in this simplified 
scenario.

Now let's say that you change a Computer registry setting in 1 GPO. Each DC now 
has to respond to additional file access requests for each GPO for the next two 
hours until all devices are up to date. Let's also say that each of the "domain 
root level" GPOs has both registry and security settings... that means that 
there is a Gpt.Ini file, a Registry.Pol file, and a GptTmpl.Inf file within the 
sysvol folder structure in 'each' GPO.

Therefore, in addition to having to read 200,000 Gpt.Ini files (4 GPOs * 50,000 
devices) you've added a load of 400,000 reads (4 GPOs * two additional file 
reads * 50,000 devices) for the next two hours for a total of 600,000 reads 
(again, that's 50,000 devices reading 3 files per GPO at the root of the domain 
* 4 Computer GPOs). [BTW: That's ~95 reads/sec in SYSVOL for the next two hours 
straight. And that is only for the root level GPOs, there are also the read 
requests for the remaining GPOs in lower level OUs.]

Oh, did I forget to mention that there may be "On Access" AV scans going on as 
well for all three files for each read request? Not a separate read, but 
certainly a 'processor' on the DC is involved as well as possibly the AV 
scanner on the local client device. Okay, okay, assume I didn't mention 
those...  :)

If you had separated the GPOs at the root by client extension then the "load" 
on the DC's root level GPOs would have been only a total of 400,000 reads. That 
is certainly significant enough for you to seriously consider redesigning the 
way you use GPOs. It's a scale thing to be certain. Smaller companies do not 
have to worry too much about performance issue of this kind (assumes these 
companies staffs are geographically centered near their DCs).

However, if a company is smaller, but has a large number of the 
employees/devices that are dispersed (far distances away from their DCs) and if 
they log on for significant periods of time, then the background refreshes 
under this scenario can take much longer due to latency in the network. Again, 
separating the GPOs by client extension means that changing one type of setting 
can improve experience those remote systems and reduce total network traffic at 
the same time.

Note: Since I work for a larger Enterprise than noted above and my access 
numbers are easily into the millions of SYSVOL read accesses per day. We have 
to be very cognizant about when/where/how we allow GPO changes to be made or we 
can run into replication issues and/or place undue processing requirements upon 
our customers, their devices, the network, and/or the DCs.

TIP: GPO Admins may want to take a look at eliminating 'On Access' anti-virus 
scanning of the GPT.Ini files to reduce the 'load' on the DCs. Make sure that 
you have good GPO backup processes in place, make sure your security folks 
agree, and also make sure that other scheduled AV scans are left intact (both 
on the DC as well as on the clients accessing them), and test, test, test.

Aren't GPOs fun! :)

Jerry C

This posting is provided "AS IS" with no warranties and confers no rights.
------------------------------------------------------------------------------------------------


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Thorbjörn Sjövold
Sent: Wednesday, April 16, 2008 8:49 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Complete list of all available CSEs and theirfunctionality

Hendrikus,

the Registry CSE is pretty much the descendant of the old NT 4 policies, it has 
GUID {35378EAC-683F-11D2-A89A-00C04FBBCFA2} (and is listed but no settings), it 
is very special and not a "true" CSE to 100%, for example when you register 
your own CSE, you can say that it should only process if the Registry CSE 
successfully executed etc. But to sum up it is the CSE that is responsible for 
anything under Administrative Templates, i.e. ADM/ADMX. Also a number of other 
extensions rely on the Registry CSE, for example the Software Restriction 
Policy as far as I recall, that in reality adds settings that the Registry CSE 
will manage but from its own GPOE snap-in.


HTH,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com<http://www.specopssoft.com>
thorbjorn.sjovold a t specopssoft.com

Download our free tool for remote Gpupdate with graphical reporting, 
http://www.specopssoft.com/products/specopsgpupdate/






From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Hendrikus Terwint (SEDIRSI-Prestataire)
Sent: den 16 april 2008 17:31
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Complete list of all available CSEs and their 
functionality

Thanks a lot for your quick reply, Darren, as well as Thorbjörn.

I'm not quite sure though if I understand what you both mean by "Registry CSE". 
I guess you mean it's not one of the CSEs listed in my GPExtensions registry 
key? (I'm not sure whether there is one main "registry" CSE with some 
additional CSE extensions, or if the "registry CSE" is just one of those/ any 
of those extensions we can find under HKLM\Software\Microsoft\Windows 
NT\CurrentVersion\Winlogon\GPExtensions).

I'd like to optimize our GPOs, i.e. per GPO only add settings that are 
processed by a single CSE. (Goal: if the GPO version is incremented, have only 
CSE x update its list, and not CSE y)

You are right Darren: the GPExtensions list is pretty straightforward, but they 
only cover a small percentage of the overall settings. If the "Registry CSE" 
does most everything, I'm wondering if my "optimization" would make sense....

Hendrikus


De : gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] De la 
part de Darren Mar-Elia
Envoyé : mercredi 16 avril 2008 16:03
À : gptalk@xxxxxxxxxxxxx
Objet : [gptalk] Re: Complete list of all available CSEs and their functionality

Hendrikus-
Frankly the most definitive list of CSEs will be on the machine of the most 
recent version of Windows you are running, in the registry under 
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.

In terms of which settings are processed by which CSEs, this is not completely 
straightforward but, for example, most everything under Administrative 
Templates is processed by the Registry CSE and then the rest of the CSEs are 
pretty self-explanatory. But I don't think you will find a definitive list of 
which CSE processes every setting.

Darren



From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Hendrikus Terwint (SEDIRSI-Prestataire)
Sent: Wednesday, April 16, 2008 6:39 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Complete list of all available CSEs and their functionality

Hello everybody,

Is there a way to determine which GP setting is processed by which CSE ?

I have found a list of default Client-Side Extensions on Technet:
http://technet2.microsoft.com/windowsserver/en/library/824b4758-9430-4633-8d8f-3dad0f2bf8391033.mspx?mfr=true

However, I'd like to see a complete list, just like the "Group Policy Settings 
Reference" on windows.com/downloads, with a column that says which CSE is 
responsible for processing which setting.

For example: if we use the DFS.admx to change the DFS network policy. Is there 
a DFS CSE that processes this policy, or is it processed by one of the default 
CSEs? Does it require an extension at all? Maybe the CSE list on the link above 
is quite complete, and all other settings are processed by the Group Policy 
Engine itself?

Is there such list around somewhere? (that links every possible GP setting to 
the GP Engine or CSE component that processes this setting)

Many thanks in advance,

Hendrikus TERWINT
Consultant Avanade France
hendrikus.terwint@xxxxxxxxxxx<mailto:hendrikus.terwint@xxxxxxxxxxx>

Prestataire pour le compte de SEDI-RSI, site de Bagnolet
Tél. : 01 55 82 39 70

Other related posts: