[gptalk] Re: Domain User account and GP processing

  • From: "Nelson, Jamie" <Jamie.Nelson@xxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Thu, 5 Jun 2008 17:17:13 -0500

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/
************************

Other related posts: