[gptalk] Re: Complete list of all available CSEs and their functionality
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2008 13:31:32 -0700
Great insight into REALLY large environments Jerry. Thanks for that!
Darren
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: