[gptalk] Re: Complete list of all available CSEs and their functionality
- From: "Cruz, Jerome L" <jerome.l.cruz@xxxxxxxxxx>
- To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2008 11:45:44 -0700
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:
