I like it when Dean posts longer answers.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Sunday, May 22, 2005 10:25 AM To: Send - AD mailing list Subject: RE: [ActiveDir] "Sticky" group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - <sugar coated>causes additional admin. requirements</sugar coated> - <non-sugar coated>ridiculous, why cache what the DC already has explicit knowledge of?<non-sugar coated> - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] "Sticky" group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] "Sticky" group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] "Sticky" group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of "group membership cache refresh". I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen > -----Original Message----- > From: Ole Thomsen > Sent: Saturday, May 14, 2005 10:11 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] "Sticky" group membership > > I am well aware of the fact that group membership is only updated > during a new logon. > > But this "false" membership can stick for several days, and we reboot > the terminal servers every night. My test user were removed from the > group two days ago, and still get the GPO applied on some of the > servers. > > As far as I can see the membership is recognized correctly on the > network and file servers - just not during logon. > > Thanks, > Ole Thomsen > > > > > > -----Original Message----- > > From: joe [mailto:[EMAIL PROTECTED] > > Sent: Saturday, May 14, 2005 8:42 PM > > To: ActiveDir@mail.activedir.org > > Subject: RE: [ActiveDir] "Sticky" group membership > > > > User security tokens are only updated during authentication. > > This means that > > if you have a group membership change and then connect to a remote > > resources you can get that new token if you completely break any > > previous sessions with the remote resource, then purge your kerberos > > tickets, and then reconnect to the resource. For interactive logons > > (i.e. you have a desktop associated with the logon) you need to log > > off and log on. > > > > joe > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen > > Sent: Saturday, May 14, 2005 1:18 PM > > To: ActiveDir@mail.activedir.org > > Subject: [ActiveDir] "Sticky" group membership > > > > Environment: Three W2K3 DC's and ten WTS (no SP1), all located on > > the same subnet. > > > > We have GPO's applied based on group membership. > > > > A few policies are only intended to be active for some > hours, blocking > > execution of specific applications. > > > > After adding the users to the group, the policy is active almost > > immediately on the terminal servers - but after removing users from > > the group, the GPO's are still applied on some. > > > > GPresult shows that the users are still seen as member of the group, > > while running MemberOf against every DC says they are not? > > > > How can I troubleshoot this further, and where is it > possible that the > > membership is cached? > > > > Ole Thomsen > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
