Hi John, you asked << 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?">> That depends upon several factors. What's your domain's defined MaxTokenSize entry in the registry? How many Local groups is the average user account in? How many Domain Global / Universal groups? Any cross-domain groups? Are the accounts Trusted for Delegation? Microsoft has a good KB article that discusses this (and hotfix available if necessary). New resolution for problems with Kerberos authentication when users belong to many groups http://support.microsoft.com/kb/327825 They also have a KB article that shows you how to use a GPO to set this value (if necessary) on your devices. How to use Group Policy to add the MaxTokenSize registry entry to multiple computers on a domain controller that is running Windows Server 2003 or that is running Windows 2000 http://support.microsoft.com/kb/938118 All that said, while it does take "longer" to authenticate certain things, especially for cross-domain memberships, it's also not something the average user should ever notice. It certainly does not typically add 10-20 extra seconds to any logon that I've ever seen. Let's say that an End User's token is 50 KB in size (that's huge). That's also not something that should take more than a few milliseconds to download on a 10 Megabit network connection. Even if the user is accessing things remotely (and mind you, they'd typically be using locally cached credentials..., but let's say for example that they use an 'ancient' 56 Kilobit speed modem at the User Logon Screen to connect first), then it'd only take about 8 seconds to get their entire token (even that assumes no line compression...and even that is unlikely). If your folks are experiencing slow logons, there's way more to look at. I be asking things like: Do they utilize Roaming Profiles? Are any poorly performing services staring up right away that are eating the CPU for breakfast? Are you deploying many applications at logon time? If so, is this slowing down the entire network throughput for everyone? Also, instead of "security groups", perhaps what sounds like your internal "custom application" could instead utilize "Distribution Lists". My understanding is that this would at least "lighten" the load and reduce the chance of Token Bloat. Here is something I just ran across from Microsoft (published Feb 2008) that discusses a similar approach (for another purpose, but similar in goal to keep user's token's size within reason). Provisioning Objects Based on Group Membership http://download.microsoft.com/download/c/b/3/cb3e8ab9-d892-442e-b16a-51b54509fdc8/MIIS32_DC_GroupProv.doc "As a matter of best practice to avoid the well known "Token Bloat" problem, MCS decided to use AD Distribution Lists for the groups leveraged by this solution..." Good Luck.... Jerry Cruz | Group Policies Product Manager | Boeing IT -----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/ ************************