Well I've done a quick check and the average user account belongs to ~199 AD groups by way of the domain users group. I guess this isn't huge. That said the problem I have is this: For simplicity sake lets assume you have a static environment and no one adds users to any ad group and group policy is not touched bar the GPOs already in place. Group policy should apply once when a new user logs in (foreground) and then should process again the next time they login as it hasn't detected any changes in group membership or group policy. The issue we have ( and I hope to resolve) is that to allow people to install software off a specially made menu that ties in with our software distribution tool, we have been adding domain users to an ad group with say the name of the software. The SD tool has its own policy reolsution which assigns policy to ad groups. The policy is assigned to that ad group saying everyone in this group can install this software. As we want everyone to have access domain users is in there. However group policy detects this change and processes policy again. If domain users is added to a new group (or deleted for that matter) then GP will continually reprocess as opposed to not processing as no changes would have occurred. We also use full disk encryption. I've run IOMeter on an unencrypted machine and encrypted and its definitely slower during boot. Combine that with on active antivirus scanning and slow notebook hdds and you have the formula for slow login. As an aside is there just some group policies that will slow down the login significantly? I know registry and file system policy can cause a performance hit but we have like 1 or 2 settings in there at most, IE branding apparently also causes slowness. Do people on this listapply IE settings via scripts or ....? cheers -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Nelson, Jamie Sent: Friday, 6 June 2008 8:17 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Domain User account and GP processing Yeah, the spell checker hosed that up somehow. Pupdate /force /target:floor -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia Sent: Thursday, June 05, 2008 12:49 PM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Domain User account and GP processing Pupdate :). Makes me think of something my puppy might do... -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Nelson, Jamie Sent: Thursday, June 05, 2008 10:46 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Domain User account and GP processing John, Group policy only processes at specific times, or when manually triggered (by running the pupate command). Adding a user to a group would not cause a policy refresh, although in your case it might cause the user account to be subjected to additional policies when the refresh eventually occurs. By default, Group policy applied to users gets processed/applied at user logon. A background refresh also occurs every 1 1/2 to 2 hours, although certain extensions (logon scripts, for example) don't get applied at that time. Since you've already stated you're not using GP Software Installation policy, may I ask what product you are referring to? List members might be more able to assist you if you don't mind sharing. Regards, Jamie Nelson | IT Consultant | BI&T Operations | Devon Energy | Phone 405.552.8054 | http://www.dvn.com -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of John Bateman Sent: Thursday, June 05, 2008 11:55 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Domain User account and GP processing Hi Darren, Thanks for the replies. I guess the relationship between the product and group policy is to do with the Domain User account. The software distribution tool relies on AD to resolve policy on what software users can install. There is essentially two ways for users to be assigned software - add domain users to an AD group and assign the software policy to the AD group or add the policy to the top of the OU where the user accounts reside. Currently we do the former, adding Domain User to a whole lot of AD groups. Subsequently this means all users are part of a whole lot of groups. Say for instance we don't touch group policy or AD. Users login and process policy. Once this is done they shouldn't process policy unless group membership changes. If we add Domain Users to a group everyone processes policy again as they have been added to another group. This could all be avoided if they add the policy to the top of the user account OU as in essence policy resolution is being done on the software distribution server. A little convoluted but thanks for your reply anyway. I have a suspicion what I've tried to explain (rather poorly :p) is happening and causing policy to be processed rather more often than it should, which may be an additional factor in the longer than usual login times I asked about a month or two ago. cheers -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia Sent: Thursday, 5 June 2008 11:47 PM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Re: Domain User account and GP processing John- I'm a little confused about what this sw. distribution product is doing as it relates to GP but here goes: 1. If group membership changes, that constitutes a change in the list of GPOs that apply and so yes, GP would process. 2. I'm not sure I know what you mean by "using AD to resolve policy". What policy? GP? 3. There is a maximum size to a process token. Don't remember it now but at 40 groups, you are probably not hitting it. However, performance does degrade the more groups you have to resolve and evaluate when hitting resources. Darren -----Original Message----- From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On Behalf Of John Bateman Sent: Thursday, June 05, 2008 1:59 AM To: gptalk@xxxxxxxxxxxxx Subject: [gptalk] Domain User account and GP processing Hi. Say we have a software distribution product which uses AD for policy resolution. So for example, if we wanted a particular machine to have a certain piece of software, we simply add it to an AD group which has the software policy assigned to it and away it goes. We can also do this with users (so a user can be put into an AD group), however it is a little different. In this instance we have the idea of mandatory and optional software. If we assign a policy to an AD group and give it the attribute of optional, the user can install if they wish but it will not be forced. As all users are part of the Domain Users group if say a piece of software was packaged that all staff could install, but would be optional, then an AD group would be created and Domain Users group would be added to the group. This has led to quite a number of AD groups and as users are all part of Domain Users then they also belong to these groups (at least 40). Computer accounts are not part of nearly as many. Please note: we do not use GP software distribution, we have a product we use. Now my questions: 1. Assuming that no AD groups are changed for a day nor are any group policy objects. If a user logs in, policy processing does not occur as it does not detect any changes in GPO or group membership (or WMI filters). If we then add Domain Users to a new AD group, processing would then occur on the next login correct? 2. Is this a common scenario with software distribution products that use AD to resolve policy? 3. Is there a maximum number of groups it is generally accepted a user should (rather than could) be part of that would not impact login performance? cheers *********************** 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/ ************************ *********************** 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/ ************************ *********************** 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/ ************************ Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. *********************** 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/ ************************ *********************** 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/ ************************ *********************** 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/ ************************ *********************** 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/ ************************