[gptalk] Re: Complete list of all available CSEs and their functionality
- From: "Sunshine Baines" <sunshine.baines@xxxxxxxxx>
- To: gptalk@xxxxxxxxxxxxx
- Date: Wed, 16 Apr 2008 19:14:36 -0400
Ok here is a dumb one. I thought CSE was a plugin for the newly
upcoming preferences. What exactly do you mean by separating GPO by
CSE?
On Wed, Apr 16, 2008 at 4:31 PM, Darren Mar-Elia <darren@xxxxxxxxxx> wrote:
>
>
>
> 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
>
>
> 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-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
>
>
>
> Prestataire pour le compte de SEDI-RSI, site de Bagnolet
>
> Tél. : 01 55 82 39 70
>
>
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
Other related posts:
