[gptalk] Re: Complete list of all available CSEs and their functionality
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Thu, 17 Apr 2008 08:33:03 -0700
Hendrikus-
The only thing I would correct in this is that I would not say that ?most
settings will be processed by the Registry CSE?. Better to say that most
Administrative Template settings will be processed by the Registry CSE (e.g.
Disk Quota and QoS Packet Scheduler appear under Admin. Templates but are
processed by their own CSEs). Software Restriction Policy writes to the same
file as Admin. Templates but I?m not 100% sure it uses the registry CSE.
Outside of that, I don?t think that anything else uses that Registry CSE.
So, its not all that bad in terms of being able to separate GPOs by CSE. But
I think your observations below are fairly reasonable. The other thing to
keep in mind is that its important not to overstate the impact of hits to
your DCs because this is very environmentally dependent. The real impact
there will be dependent upon how many DCs you have sharing the load, what
else is going on on those DCs and your infrastructure. Bottom line is that I
wouldn?t do a lot of reorganization unless you having real performance
problems.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Hendrikus Terwint (SEDIRSI-Prestataire)
Sent: Thursday, April 17, 2008 2:54 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Complete list of all available CSEs and their
functionality
Jerry,
Thank you so very much for this great reply !
It brings me back to my initial motivation to start splitting up some of our
GPOs, as well as grouping together many of them J
For now, my conclusions are:
· Each CSE found under HKLM\?\Winlogon\GPExtensions will (only)
process what its self-explanatory name indicates:
o "Wireless Group Policy"
o "Folder Redirection"
o "Microsoft Disk Quota"
o "QoS Packet Scheduler"
o "Scripts"
o "Internet Explorer Zonemapping"
o "Security"
o "Internet Explorer Branding"
o "EFS recovery"
o "Microsoft Offline Files"
o "Software Installation"
o "IP Security"
· The ?Registry CSE? is responsible for processing most GPO settings
(most everything under Administrative Templates and many more settings).
· Better reduce our number of GPOs (i.e. better not split them up
but rather regroup them together in ?monolithic GPOs?), because 1/ they are
not modified very often, and 2/ the more GPOs the more Gpt.ini hits (thanks
for your math, Jerry!)
· IF GP-settings will be modified often AND they are processed by
one of the GPExtensions (CSEs) above, THEN (and only then) it?s best to keep
them in a separate GPO (e.g. this goes for ?Software Installation?)
· It could be true that some CSEs also rely on the Registry CSE
(e.g. the ?Software Restriction Policy?) ? that?s what Thorbjörn replied ?
although his ?Software Restriction Policy? wasn?t part of my GPExtensions
list anyway
· It could be true that ?any setting? modified in a GPO could
trigger ?any CSE?, because we do not know for sure which ?registry? change
?wakes up? which CSE for processing
· The only way to really find out which setting will be processed by
which CSEs, would be to follow Thorbjörn?s tip to check the value of the
gPCMachineExtensionNames and/or gPCUserExtensionNames before and after we do
a setting and figure out which CSE is used to process it. (Compare the new
GUID added with the ones you can find in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions)
è Which is pretty time-consuming ? maybe not worth doing this, because most
settings will be processed by the ?Registry CSE? anyway?
Again thanks a lot for your reply!
Regards,
Hendrikus
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Cruz, Jerome L
Sent: Wednesday, April 16, 2008 11:46 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [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? J
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! J
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
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-8d
8f-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
Prestataire pour le compte de SEDI-RSI, site de Bagnolet
Tél. : 01 55 82 39 70
Other related posts:
