can't override screen saver policy

Archived from groups: microsoft.public.win2000.group_policy (More info?)

We've enabled a mandatory screen saver policy and applied it at the
domain level - it works as it's supposed to.

There's a handful of machines we don't want this policy to apply to,
and we don't want to muck around with GP permissions, or create
exception OU's, play with GP deny settings etc.

We should just be able to specify a local policy to override (as local
is first in order or precedence).

However we can't get it to work. Clients are XP SP2.

I specify the settings locally, log off and on, tried rebooting as well
- but when I check the registry key
HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
showing the entries from the domain policy.

What gives?
16 answers Last reply
More about override screen saver policy
  1. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    You're right in that the local policy gets applied first. The only thing is
    later settings in the L, S, D, Ou order 'win'. So your domain policy won
    out over the local policy... and the domain wins.

    If you had a different policy on the OU, that one would win, provided your
    domain policy did not have "No override" or "Enforced" checked off.

    Easiest way I would think to get those computers to not apply the
    screensaver policy would be to create a security group, add the computers to
    that group, and then give that group Deny permission to Read & Apply the
    policy on the security tab of the policy itself. This way you can
    add/remove/edit the list at your own whim, and you'll have a listing of all
    the computers that won't have that policy apply to them.

    HTH

    Ken

    <lee.james@spartan.ab.ca> wrote in message
    news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > We've enabled a mandatory screen saver policy and applied it at the
    > domain level - it works as it's supposed to.
    >
    > There's a handful of machines we don't want this policy to apply to,
    > and we don't want to muck around with GP permissions, or create
    > exception OU's, play with GP deny settings etc.
    >
    > We should just be able to specify a local policy to override (as local
    > is first in order or precedence).
    >
    > However we can't get it to work. Clients are XP SP2.
    >
    > I specify the settings locally, log off and on, tried rebooting as well
    > - but when I check the registry key
    > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > showing the entries from the domain policy.
    >
    > What gives?
    >
  2. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    I am having the same issue and the original post. I have tried adding the
    setting at the OU level which is below the domain level, so that policy
    should be applied. However, it seems that this setting is a user setting.
    The users are in the user OU which is above the target computer OU. So they
    don't get this policy setting. I have also tried setting the permissions to
    allow access to only the specific machine accounts and that has no effect.
    It only seems to care about the user portion.

    Anyone have any ideas?

    DC

    "Ken B" wrote:

    > You're right in that the local policy gets applied first. The only thing is
    > later settings in the L, S, D, Ou order 'win'. So your domain policy won
    > out over the local policy... and the domain wins.
    >
    > If you had a different policy on the OU, that one would win, provided your
    > domain policy did not have "No override" or "Enforced" checked off.
    >
    > Easiest way I would think to get those computers to not apply the
    > screensaver policy would be to create a security group, add the computers to
    > that group, and then give that group Deny permission to Read & Apply the
    > policy on the security tab of the policy itself. This way you can
    > add/remove/edit the list at your own whim, and you'll have a listing of all
    > the computers that won't have that policy apply to them.
    >
    > HTH
    >
    > Ken
    >
    > <lee.james@spartan.ab.ca> wrote in message
    > news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > > We've enabled a mandatory screen saver policy and applied it at the
    > > domain level - it works as it's supposed to.
    > >
    > > There's a handful of machines we don't want this policy to apply to,
    > > and we don't want to muck around with GP permissions, or create
    > > exception OU's, play with GP deny settings etc.
    > >
    > > We should just be able to specify a local policy to override (as local
    > > is first in order or precedence).
    > >
    > > However we can't get it to work. Clients are XP SP2.
    > >
    > > I specify the settings locally, log off and on, tried rebooting as well
    > > - but when I check the registry key
    > > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > > showing the entries from the domain policy.
    > >
    > > What gives?
    > >
    >
    >
    >
  3. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Settings in the User Configuration part of a GPO always apply to User
    Accounts, not Computer Accounts, so any User Configuration settings you want
    to apply must be in a GPO that applies to the User's Account, not the
    Computer's Account.

    If you acutally want some User Configuration settings applied ONLY when
    users log on to specific computers, then enable Loopback processing in a GPO
    that is applied to the OU containing those Computer Accounts and put the
    User Configuration settings into a GPO that applies to that OU. See
    http://support.microsoft.com/kb/231287/. Not that the User Configuration
    part of a GPO processed by the Loopback feature are still applied to User
    Accounts, but only when a (any) user logs on at the computers that GPO
    applies to. Loopback processing does not actaully convert User
    Configuration settings to Computer Configuration settings.

    The best way (IMHO) is to establish an OU hierarchy/structure that reflects
    how you want to manage things and how you want to apply GPOs. One of the
    major features of AD is the ability to nest OUs and to change the OU
    structure easily. Settings in GPOs applied at the lower levels in the
    hierarchy (e.g. NeedScreenSaver in the example below) will take precedence
    over corresponding settings applied higher in the heirarchy. Take advantage
    of this feature to make your life easier. In particular, have seperate OU
    hierarchies for User and Computer Accounts (as opposed to having the
    computer accounts in an OU nested inside the Users OU).

    E.g.
    Domain
    Computers - apply GPO that is to be applied to all computers here
    NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    here
    Users - apply GPO that is to be applied to all users here
    SpecialUsers - apply GPO that has settings specific to only some
    (special) users
    as opposed to
    Domain
    Computers
    Users

    --
    Bruce Sanderson MVP Printing
    http://members.shaw.ca/bsanders

    It is perfectly useless to know the right answer to the wrong question.


    "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    >I am having the same issue and the original post. I have tried adding the
    > setting at the OU level which is below the domain level, so that policy
    > should be applied. However, it seems that this setting is a user setting.
    > The users are in the user OU which is above the target computer OU. So
    > they
    > don't get this policy setting. I have also tried setting the permissions
    > to
    > allow access to only the specific machine accounts and that has no effect.
    > It only seems to care about the user portion.
    >
    > Anyone have any ideas?
    >
    > DC
    >
    > "Ken B" wrote:
    >
    >> You're right in that the local policy gets applied first. The only thing
    >> is
    >> later settings in the L, S, D, Ou order 'win'. So your domain policy won
    >> out over the local policy... and the domain wins.
    >>
    >> If you had a different policy on the OU, that one would win, provided
    >> your
    >> domain policy did not have "No override" or "Enforced" checked off.
    >>
    >> Easiest way I would think to get those computers to not apply the
    >> screensaver policy would be to create a security group, add the computers
    >> to
    >> that group, and then give that group Deny permission to Read & Apply the
    >> policy on the security tab of the policy itself. This way you can
    >> add/remove/edit the list at your own whim, and you'll have a listing of
    >> all
    >> the computers that won't have that policy apply to them.
    >>
    >> HTH
    >>
    >> Ken
    >>
    >> <lee.james@spartan.ab.ca> wrote in message
    >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    >> > We've enabled a mandatory screen saver policy and applied it at the
    >> > domain level - it works as it's supposed to.
    >> >
    >> > There's a handful of machines we don't want this policy to apply to,
    >> > and we don't want to muck around with GP permissions, or create
    >> > exception OU's, play with GP deny settings etc.
    >> >
    >> > We should just be able to specify a local policy to override (as local
    >> > is first in order or precedence).
    >> >
    >> > However we can't get it to work. Clients are XP SP2.
    >> >
    >> > I specify the settings locally, log off and on, tried rebooting as well
    >> > - but when I check the registry key
    >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    >> > showing the entries from the domain policy.
    >> >
    >> > What gives?
    >> >
    >>
    >>
    >>
  4. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    "" wrote:
    > We've enabled a mandatory screen saver policy and applied it
    > at the
    > domain level - it works as it's supposed to.
    >
    > There's a handful of machines we don't want this policy to
    > apply to,
    > and we don't want to muck around with GP permissions, or
    > create
    > exception OU's, play with GP deny settings etc.
    >
    > We should just be able to specify a local policy to override
    > (as local
    > is first in order or precedence).
    >
    > However we can't get it to work. Clients are XP SP2.
    >
    > I specify the settings locally, log off and on, tried
    > rebooting as well
    > - but when I check the registry key
    > HKCUSWpoliciesMicrosoftWindowsControl PanelDesktop it
    > keeps
    > showing the entries from the domain policy.
    >
    > What gives?

    all the solutions you do not want to use ARE the solutions you should
    use....

    Concerning GPOs and the order they apply:
    1 local
    2 site
    3 domain
    4 OU

    so if you set something at local level the setting in the domain will
    overwrite it

    --
    Posted using the http://www.windowsforumz.com interface, at author's request
    Articles individually checked for conformance to usenet standards
    Topic URL: http://www.windowsforumz.com/Group-Policy-override-screen-saver-ftopict398823.html
    Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.windowsforumz.com/eform.php?p=1318253
  5. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    >Easiest way I would think to get those computers to not apply the
    >screensaver policy would be to create a security group, add the
    >computers to that group, and then give that group Deny permission to
    >Read & Apply the policy on the security tab of the policy itself

    Hi Ken,

    The only problem is that he says he has the Screen Saver setting at
    the Domain level and if he deny’s computers access to the Default
    Domain policy he will be in real trouble.

    The Screen Saver setting is a Users Profile setting. Therefore you
    cannot set it per computer Unless you use the Group Policy Loopback
    mode.

    Cheers,

    Lara

    --
    Posted using the http://www.windowsforumz.com interface, at author's request
    Articles individually checked for conformance to usenet standards
    Topic URL: http://www.windowsforumz.com/Group-Policy-override-screen-saver-ftopict398823.html
    Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.windowsforumz.com/eform.php?p=1319369
  6. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Hi Lara-

    I had considered that, but being he didn't mention it specifically, my
    thought was that he applied a separate policy at the domain level... but it
    could have been a setting configured directly in the DDP, in which case, DO
    NOT DO WHAT I SAID!! ;0

    Ken

    "lforbes" <UseLinkToEmail@WindowsForumz.com> wrote in message
    news:3_1319369_c5738aa62240b9c41a1842ebb4afeb43@windowsforumz.com...
    > >Easiest way I would think to get those computers to not apply the
    >>screensaver policy would be to create a security group, add the
    >>computers to that group, and then give that group Deny permission to
    >>Read & Apply the policy on the security tab of the policy itself
    >
    > Hi Ken,
    >
    > The only problem is that he says he has the Screen Saver setting at
    > the Domain level and if he denyâ?Ts computers access to the Default
    > Domain policy he will be in real trouble.
    >
    > The Screen Saver setting is a Users Profile setting. Therefore you
    > cannot set it per computer Unless you use the Group Policy Loopback
    > mode.
    >
    > Cheers,
    >
    > Lara
    >
    > --
    > Posted using the http://www.windowsforumz.com interface, at author's
    > request
    > Articles individually checked for conformance to usenet standards
    > Topic URL:
    > http://www.windowsforumz.com/Group-Policy-override-screen-saver-ftopict398823.html
    > Visit Topic URL to contact author (reg. req'd). Report abuse:
    > http://www.windowsforumz.com/eform.php?p=1319369
  7. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Hi Bruce,

    Yes, I figured out that using loopback processing was the answer (Ok, I
    ended up calling MS support). I created a seperate OU that had loopback
    processing applied and put the particular systems in the OU. That now
    works fine.

    However, what I can't understand and MS can't seem to explain, is why I
    can't enable loopback processing on the local policy of the problem
    systems instead of having to do it at the OU level?

    MS keeps saying the order or precedence is the reason, but as I
    understand it, the local gets 'read' first, tells that it's using
    loopback processing - which should then tell it to ignore the user
    settings at the site level, domain level, ou level etc.

    J.

    Bruce Sanderson wrote:
    > Settings in the User Configuration part of a GPO always apply to User
    > Accounts, not Computer Accounts, so any User Configuration settings you want
    > to apply must be in a GPO that applies to the User's Account, not the
    > Computer's Account.
    >
    > If you acutally want some User Configuration settings applied ONLY when
    > users log on to specific computers, then enable Loopback processing in a GPO
    > that is applied to the OU containing those Computer Accounts and put the
    > User Configuration settings into a GPO that applies to that OU. See
    > http://support.microsoft.com/kb/231287/. Not that the User Configuration
    > part of a GPO processed by the Loopback feature are still applied to User
    > Accounts, but only when a (any) user logs on at the computers that GPO
    > applies to. Loopback processing does not actaully convert User
    > Configuration settings to Computer Configuration settings.
    >
    > The best way (IMHO) is to establish an OU hierarchy/structure that reflects
    > how you want to manage things and how you want to apply GPOs. One of the
    > major features of AD is the ability to nest OUs and to change the OU
    > structure easily. Settings in GPOs applied at the lower levels in the
    > hierarchy (e.g. NeedScreenSaver in the example below) will take precedence
    > over corresponding settings applied higher in the heirarchy. Take advantage
    > of this feature to make your life easier. In particular, have seperate OU
    > hierarchies for User and Computer Accounts (as opposed to having the
    > computer accounts in an OU nested inside the Users OU).
    >
    > E.g.
    > Domain
    > Computers - apply GPO that is to be applied to all computers here
    > NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    > here
    > Users - apply GPO that is to be applied to all users here
    > SpecialUsers - apply GPO that has settings specific to only some
    > (special) users
    > as opposed to
    > Domain
    > Computers
    > Users
    >
    > --
    > Bruce Sanderson MVP Printing
    > http://members.shaw.ca/bsanders
    >
    > It is perfectly useless to know the right answer to the wrong question.
    >
    >
    >
    > "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    > news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    > >I am having the same issue and the original post. I have tried adding the
    > > setting at the OU level which is below the domain level, so that policy
    > > should be applied. However, it seems that this setting is a user setting.
    > > The users are in the user OU which is above the target computer OU. So
    > > they
    > > don't get this policy setting. I have also tried setting the permissions
    > > to
    > > allow access to only the specific machine accounts and that has no effect.
    > > It only seems to care about the user portion.
    > >
    > > Anyone have any ideas?
    > >
    > > DC
    > >
    > > "Ken B" wrote:
    > >
    > >> You're right in that the local policy gets applied first. The only thing
    > >> is
    > >> later settings in the L, S, D, Ou order 'win'. So your domain policy won
    > >> out over the local policy... and the domain wins.
    > >>
    > >> If you had a different policy on the OU, that one would win, provided
    > >> your
    > >> domain policy did not have "No override" or "Enforced" checked off.
    > >>
    > >> Easiest way I would think to get those computers to not apply the
    > >> screensaver policy would be to create a security group, add the computers
    > >> to
    > >> that group, and then give that group Deny permission to Read & Apply the
    > >> policy on the security tab of the policy itself. This way you can
    > >> add/remove/edit the list at your own whim, and you'll have a listing of
    > >> all
    > >> the computers that won't have that policy apply to them.
    > >>
    > >> HTH
    > >>
    > >> Ken
    > >>
    > >> <lee.james@spartan.ab.ca> wrote in message
    > >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > >> > We've enabled a mandatory screen saver policy and applied it at the
    > >> > domain level - it works as it's supposed to.
    > >> >
    > >> > There's a handful of machines we don't want this policy to apply to,
    > >> > and we don't want to muck around with GP permissions, or create
    > >> > exception OU's, play with GP deny settings etc.
    > >> >
    > >> > We should just be able to specify a local policy to override (as local
    > >> > is first in order or precedence).
    > >> >
    > >> > However we can't get it to work. Clients are XP SP2.
    > >> >
    > >> > I specify the settings locally, log off and on, tried rebooting as well
    > >> > - but when I check the registry key
    > >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > >> > showing the entries from the domain policy.
    > >> >
    > >> > What gives?
    > >> >
    > >>
    > >>
    > >>
  8. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Do you have any policy later in the precedence that says Loopback Processing
    = Disabled ? That would be the only thing I could think of that would
    explain the behavior.

    Ken

    <lee.james@spartan.ab.ca> wrote in message
    news:1122398002.779863.111890@g14g2000cwa.googlegroups.com...
    > Hi Bruce,
    >
    > Yes, I figured out that using loopback processing was the answer (Ok, I
    > ended up calling MS support). I created a seperate OU that had loopback
    > processing applied and put the particular systems in the OU. That now
    > works fine.
    >
    > However, what I can't understand and MS can't seem to explain, is why I
    > can't enable loopback processing on the local policy of the problem
    > systems instead of having to do it at the OU level?
    >
    > MS keeps saying the order or precedence is the reason, but as I
    > understand it, the local gets 'read' first, tells that it's using
    > loopback processing - which should then tell it to ignore the user
    > settings at the site level, domain level, ou level etc.
    >
    > J.
    >
    > Bruce Sanderson wrote:
    >> Settings in the User Configuration part of a GPO always apply to User
    >> Accounts, not Computer Accounts, so any User Configuration settings you
    >> want
    >> to apply must be in a GPO that applies to the User's Account, not the
    >> Computer's Account.
    >>
    >> If you acutally want some User Configuration settings applied ONLY when
    >> users log on to specific computers, then enable Loopback processing in a
    >> GPO
    >> that is applied to the OU containing those Computer Accounts and put the
    >> User Configuration settings into a GPO that applies to that OU. See
    >> http://support.microsoft.com/kb/231287/. Not that the User Configuration
    >> part of a GPO processed by the Loopback feature are still applied to User
    >> Accounts, but only when a (any) user logs on at the computers that GPO
    >> applies to. Loopback processing does not actaully convert User
    >> Configuration settings to Computer Configuration settings.
    >>
    >> The best way (IMHO) is to establish an OU hierarchy/structure that
    >> reflects
    >> how you want to manage things and how you want to apply GPOs. One of the
    >> major features of AD is the ability to nest OUs and to change the OU
    >> structure easily. Settings in GPOs applied at the lower levels in the
    >> hierarchy (e.g. NeedScreenSaver in the example below) will take
    >> precedence
    >> over corresponding settings applied higher in the heirarchy. Take
    >> advantage
    >> of this feature to make your life easier. In particular, have seperate
    >> OU
    >> hierarchies for User and Computer Accounts (as opposed to having the
    >> computer accounts in an OU nested inside the Users OU).
    >>
    >> E.g.
    >> Domain
    >> Computers - apply GPO that is to be applied to all computers here
    >> NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    >> here
    >> Users - apply GPO that is to be applied to all users here
    >> SpecialUsers - apply GPO that has settings specific to only some
    >> (special) users
    >> as opposed to
    >> Domain
    >> Computers
    >> Users
    >>
    >> --
    >> Bruce Sanderson MVP Printing
    >> http://members.shaw.ca/bsanders
    >>
    >> It is perfectly useless to know the right answer to the wrong question.
    >>
    >>
    >>
    >> "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    >> news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    >> >I am having the same issue and the original post. I have tried adding
    >> >the
    >> > setting at the OU level which is below the domain level, so that policy
    >> > should be applied. However, it seems that this setting is a user
    >> > setting.
    >> > The users are in the user OU which is above the target computer OU. So
    >> > they
    >> > don't get this policy setting. I have also tried setting the
    >> > permissions
    >> > to
    >> > allow access to only the specific machine accounts and that has no
    >> > effect.
    >> > It only seems to care about the user portion.
    >> >
    >> > Anyone have any ideas?
    >> >
    >> > DC
    >> >
    >> > "Ken B" wrote:
    >> >
    >> >> You're right in that the local policy gets applied first. The only
    >> >> thing
    >> >> is
    >> >> later settings in the L, S, D, Ou order 'win'. So your domain policy
    >> >> won
    >> >> out over the local policy... and the domain wins.
    >> >>
    >> >> If you had a different policy on the OU, that one would win, provided
    >> >> your
    >> >> domain policy did not have "No override" or "Enforced" checked off.
    >> >>
    >> >> Easiest way I would think to get those computers to not apply the
    >> >> screensaver policy would be to create a security group, add the
    >> >> computers
    >> >> to
    >> >> that group, and then give that group Deny permission to Read & Apply
    >> >> the
    >> >> policy on the security tab of the policy itself. This way you can
    >> >> add/remove/edit the list at your own whim, and you'll have a listing
    >> >> of
    >> >> all
    >> >> the computers that won't have that policy apply to them.
    >> >>
    >> >> HTH
    >> >>
    >> >> Ken
    >> >>
    >> >> <lee.james@spartan.ab.ca> wrote in message
    >> >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    >> >> > We've enabled a mandatory screen saver policy and applied it at the
    >> >> > domain level - it works as it's supposed to.
    >> >> >
    >> >> > There's a handful of machines we don't want this policy to apply to,
    >> >> > and we don't want to muck around with GP permissions, or create
    >> >> > exception OU's, play with GP deny settings etc.
    >> >> >
    >> >> > We should just be able to specify a local policy to override (as
    >> >> > local
    >> >> > is first in order or precedence).
    >> >> >
    >> >> > However we can't get it to work. Clients are XP SP2.
    >> >> >
    >> >> > I specify the settings locally, log off and on, tried rebooting as
    >> >> > well
    >> >> > - but when I check the registry key
    >> >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    >> >> > showing the entries from the domain policy.
    >> >> >
    >> >> > What gives?
    >> >> >
    >> >>
    >> >>
    >> >>
    >
  9. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    >However, what I can’t understand and MS can’t seem to
    >explain, is why I can’t enable loopback processing on the local
    >policy of the problem
    >systems instead of having to do it at the OU level?

    Hi,

    You should be able to apply the Loopback at the Local Policy and as
    long as no one ever sets any loopback settings at ANY Domain level. OU
    or otherwise then it should stick.

    However, Group Policies are by far the best and easiest route to go.
    Because any Local Settings are Always Overridden by Group Policies in
    case of any conflict, it is best just to set them in the Group
    Policies where you can view them with out having to logon to each
    machine. Also, then the machines are kept "clean" so that in future
    you or someone else may wonder why the loopback is enabled when there
    is no Group Policy doing it.

    Personally I haven’t had a reason ever to use Local Policies. I
    would just set them at the OU/Gp level.

    Cheers,

    Lara

    --
    Posted using the http://www.windowsforumz.com interface, at author's request
    Articles individually checked for conformance to usenet standards
    Topic URL: http://www.windowsforumz.com/Group-Policy-override-screen-saver-ftopict398823.html
    Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.windowsforumz.com/eform.php?p=1326611
  10. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    No, this is the first time we've tried loopback..........all other
    entries everywhere else would be the default 'Not Configured'.

    J.

    Ken B wrote:
    > Do you have any policy later in the precedence that says Loopback Processing
    > = Disabled ? That would be the only thing I could think of that would
    > explain the behavior.
    >
    > Ken
    >
    > <lee.james@spartan.ab.ca> wrote in message
    > news:1122398002.779863.111890@g14g2000cwa.googlegroups.com...
    > > Hi Bruce,
    > >
    > > Yes, I figured out that using loopback processing was the answer (Ok, I
    > > ended up calling MS support). I created a seperate OU that had loopback
    > > processing applied and put the particular systems in the OU. That now
    > > works fine.
    > >
    > > However, what I can't understand and MS can't seem to explain, is why I
    > > can't enable loopback processing on the local policy of the problem
    > > systems instead of having to do it at the OU level?
    > >
    > > MS keeps saying the order or precedence is the reason, but as I
    > > understand it, the local gets 'read' first, tells that it's using
    > > loopback processing - which should then tell it to ignore the user
    > > settings at the site level, domain level, ou level etc.
    > >
    > > J.
    > >
    > > Bruce Sanderson wrote:
    > >> Settings in the User Configuration part of a GPO always apply to User
    > >> Accounts, not Computer Accounts, so any User Configuration settings you
    > >> want
    > >> to apply must be in a GPO that applies to the User's Account, not the
    > >> Computer's Account.
    > >>
    > >> If you acutally want some User Configuration settings applied ONLY when
    > >> users log on to specific computers, then enable Loopback processing in a
    > >> GPO
    > >> that is applied to the OU containing those Computer Accounts and put the
    > >> User Configuration settings into a GPO that applies to that OU. See
    > >> http://support.microsoft.com/kb/231287/. Not that the User Configuration
    > >> part of a GPO processed by the Loopback feature are still applied to User
    > >> Accounts, but only when a (any) user logs on at the computers that GPO
    > >> applies to. Loopback processing does not actaully convert User
    > >> Configuration settings to Computer Configuration settings.
    > >>
    > >> The best way (IMHO) is to establish an OU hierarchy/structure that
    > >> reflects
    > >> how you want to manage things and how you want to apply GPOs. One of the
    > >> major features of AD is the ability to nest OUs and to change the OU
    > >> structure easily. Settings in GPOs applied at the lower levels in the
    > >> hierarchy (e.g. NeedScreenSaver in the example below) will take
    > >> precedence
    > >> over corresponding settings applied higher in the heirarchy. Take
    > >> advantage
    > >> of this feature to make your life easier. In particular, have seperate
    > >> OU
    > >> hierarchies for User and Computer Accounts (as opposed to having the
    > >> computer accounts in an OU nested inside the Users OU).
    > >>
    > >> E.g.
    > >> Domain
    > >> Computers - apply GPO that is to be applied to all computers here
    > >> NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    > >> here
    > >> Users - apply GPO that is to be applied to all users here
    > >> SpecialUsers - apply GPO that has settings specific to only some
    > >> (special) users
    > >> as opposed to
    > >> Domain
    > >> Computers
    > >> Users
    > >>
    > >> --
    > >> Bruce Sanderson MVP Printing
    > >> http://members.shaw.ca/bsanders
    > >>
    > >> It is perfectly useless to know the right answer to the wrong question.
    > >>
    > >>
    > >>
    > >> "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    > >> news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    > >> >I am having the same issue and the original post. I have tried adding
    > >> >the
    > >> > setting at the OU level which is below the domain level, so that policy
    > >> > should be applied. However, it seems that this setting is a user
    > >> > setting.
    > >> > The users are in the user OU which is above the target computer OU. So
    > >> > they
    > >> > don't get this policy setting. I have also tried setting the
    > >> > permissions
    > >> > to
    > >> > allow access to only the specific machine accounts and that has no
    > >> > effect.
    > >> > It only seems to care about the user portion.
    > >> >
    > >> > Anyone have any ideas?
    > >> >
    > >> > DC
    > >> >
    > >> > "Ken B" wrote:
    > >> >
    > >> >> You're right in that the local policy gets applied first. The only
    > >> >> thing
    > >> >> is
    > >> >> later settings in the L, S, D, Ou order 'win'. So your domain policy
    > >> >> won
    > >> >> out over the local policy... and the domain wins.
    > >> >>
    > >> >> If you had a different policy on the OU, that one would win, provided
    > >> >> your
    > >> >> domain policy did not have "No override" or "Enforced" checked off.
    > >> >>
    > >> >> Easiest way I would think to get those computers to not apply the
    > >> >> screensaver policy would be to create a security group, add the
    > >> >> computers
    > >> >> to
    > >> >> that group, and then give that group Deny permission to Read & Apply
    > >> >> the
    > >> >> policy on the security tab of the policy itself. This way you can
    > >> >> add/remove/edit the list at your own whim, and you'll have a listing
    > >> >> of
    > >> >> all
    > >> >> the computers that won't have that policy apply to them.
    > >> >>
    > >> >> HTH
    > >> >>
    > >> >> Ken
    > >> >>
    > >> >> <lee.james@spartan.ab.ca> wrote in message
    > >> >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > >> >> > We've enabled a mandatory screen saver policy and applied it at the
    > >> >> > domain level - it works as it's supposed to.
    > >> >> >
    > >> >> > There's a handful of machines we don't want this policy to apply to,
    > >> >> > and we don't want to muck around with GP permissions, or create
    > >> >> > exception OU's, play with GP deny settings etc.
    > >> >> >
    > >> >> > We should just be able to specify a local policy to override (as
    > >> >> > local
    > >> >> > is first in order or precedence).
    > >> >> >
    > >> >> > However we can't get it to work. Clients are XP SP2.
    > >> >> >
    > >> >> > I specify the settings locally, log off and on, tried rebooting as
    > >> >> > well
    > >> >> > - but when I check the registry key
    > >> >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > >> >> > showing the entries from the domain policy.
    > >> >> >
    > >> >> > What gives?
    > >> >> >
    > >> >>
    > >> >>
    > >> >>
    > >
  11. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Can you go into more detail on what you mean?

    I am trying to have certain PC's with screen saver timeouts different from
    the rest in the office (60Min vs. 10 min.). I have been playing around with
    the GPO's trying to make it work for days.

    I am looking for detailed instructions on how to implement what is being
    discussed in here. Any help would be GREATLY appreciated.

    Thanks


    "Bruce Sanderson" wrote:

    > Settings in the User Configuration part of a GPO always apply to User
    > Accounts, not Computer Accounts, so any User Configuration settings you want
    > to apply must be in a GPO that applies to the User's Account, not the
    > Computer's Account.
    >
    > If you acutally want some User Configuration settings applied ONLY when
    > users log on to specific computers, then enable Loopback processing in a GPO
    > that is applied to the OU containing those Computer Accounts and put the
    > User Configuration settings into a GPO that applies to that OU. See
    > http://support.microsoft.com/kb/231287/. Not that the User Configuration
    > part of a GPO processed by the Loopback feature are still applied to User
    > Accounts, but only when a (any) user logs on at the computers that GPO
    > applies to. Loopback processing does not actaully convert User
    > Configuration settings to Computer Configuration settings.
    >
    > The best way (IMHO) is to establish an OU hierarchy/structure that reflects
    > how you want to manage things and how you want to apply GPOs. One of the
    > major features of AD is the ability to nest OUs and to change the OU
    > structure easily. Settings in GPOs applied at the lower levels in the
    > hierarchy (e.g. NeedScreenSaver in the example below) will take precedence
    > over corresponding settings applied higher in the heirarchy. Take advantage
    > of this feature to make your life easier. In particular, have seperate OU
    > hierarchies for User and Computer Accounts (as opposed to having the
    > computer accounts in an OU nested inside the Users OU).
    >
    > E.g.
    > Domain
    > Computers - apply GPO that is to be applied to all computers here
    > NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    > here
    > Users - apply GPO that is to be applied to all users here
    > SpecialUsers - apply GPO that has settings specific to only some
    > (special) users
    > as opposed to
    > Domain
    > Computers
    > Users
    >
    > --
    > Bruce Sanderson MVP Printing
    > http://members.shaw.ca/bsanders
    >
    > It is perfectly useless to know the right answer to the wrong question.
    >
    >
    >
    > "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    > news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    > >I am having the same issue and the original post. I have tried adding the
    > > setting at the OU level which is below the domain level, so that policy
    > > should be applied. However, it seems that this setting is a user setting.
    > > The users are in the user OU which is above the target computer OU. So
    > > they
    > > don't get this policy setting. I have also tried setting the permissions
    > > to
    > > allow access to only the specific machine accounts and that has no effect.
    > > It only seems to care about the user portion.
    > >
    > > Anyone have any ideas?
    > >
    > > DC
    > >
    > > "Ken B" wrote:
    > >
    > >> You're right in that the local policy gets applied first. The only thing
    > >> is
    > >> later settings in the L, S, D, Ou order 'win'. So your domain policy won
    > >> out over the local policy... and the domain wins.
    > >>
    > >> If you had a different policy on the OU, that one would win, provided
    > >> your
    > >> domain policy did not have "No override" or "Enforced" checked off.
    > >>
    > >> Easiest way I would think to get those computers to not apply the
    > >> screensaver policy would be to create a security group, add the computers
    > >> to
    > >> that group, and then give that group Deny permission to Read & Apply the
    > >> policy on the security tab of the policy itself. This way you can
    > >> add/remove/edit the list at your own whim, and you'll have a listing of
    > >> all
    > >> the computers that won't have that policy apply to them.
    > >>
    > >> HTH
    > >>
    > >> Ken
    > >>
    > >> <lee.james@spartan.ab.ca> wrote in message
    > >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > >> > We've enabled a mandatory screen saver policy and applied it at the
    > >> > domain level - it works as it's supposed to.
    > >> >
    > >> > There's a handful of machines we don't want this policy to apply to,
    > >> > and we don't want to muck around with GP permissions, or create
    > >> > exception OU's, play with GP deny settings etc.
    > >> >
    > >> > We should just be able to specify a local policy to override (as local
    > >> > is first in order or precedence).
    > >> >
    > >> > However we can't get it to work. Clients are XP SP2.
    > >> >
    > >> > I specify the settings locally, log off and on, tried rebooting as well
    > >> > - but when I check the registry key
    > >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > >> > showing the entries from the domain policy.
    > >> >
    > >> > What gives?
    > >> >
    > >>
    > >>
    > >>
    >
    >
    >
  12. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    What instructions did Microsoft give you to follow? Can you share with
    everyone on what you did you resolve this issue. I am facing the same issue
    and any help would be GREATLY appreciated.

    Thanks!


    "lee.james@spartan.ab.ca" wrote:

    > Hi Bruce,
    >
    > Yes, I figured out that using loopback processing was the answer (Ok, I
    > ended up calling MS support). I created a seperate OU that had loopback
    > processing applied and put the particular systems in the OU. That now
    > works fine.
    >
    > However, what I can't understand and MS can't seem to explain, is why I
    > can't enable loopback processing on the local policy of the problem
    > systems instead of having to do it at the OU level?
    >
    > MS keeps saying the order or precedence is the reason, but as I
    > understand it, the local gets 'read' first, tells that it's using
    > loopback processing - which should then tell it to ignore the user
    > settings at the site level, domain level, ou level etc.
    >
    > J.
    >
    > Bruce Sanderson wrote:
    > > Settings in the User Configuration part of a GPO always apply to User
    > > Accounts, not Computer Accounts, so any User Configuration settings you want
    > > to apply must be in a GPO that applies to the User's Account, not the
    > > Computer's Account.
    > >
    > > If you acutally want some User Configuration settings applied ONLY when
    > > users log on to specific computers, then enable Loopback processing in a GPO
    > > that is applied to the OU containing those Computer Accounts and put the
    > > User Configuration settings into a GPO that applies to that OU. See
    > > http://support.microsoft.com/kb/231287/. Not that the User Configuration
    > > part of a GPO processed by the Loopback feature are still applied to User
    > > Accounts, but only when a (any) user logs on at the computers that GPO
    > > applies to. Loopback processing does not actaully convert User
    > > Configuration settings to Computer Configuration settings.
    > >
    > > The best way (IMHO) is to establish an OU hierarchy/structure that reflects
    > > how you want to manage things and how you want to apply GPOs. One of the
    > > major features of AD is the ability to nest OUs and to change the OU
    > > structure easily. Settings in GPOs applied at the lower levels in the
    > > hierarchy (e.g. NeedScreenSaver in the example below) will take precedence
    > > over corresponding settings applied higher in the heirarchy. Take advantage
    > > of this feature to make your life easier. In particular, have seperate OU
    > > hierarchies for User and Computer Accounts (as opposed to having the
    > > computer accounts in an OU nested inside the Users OU).
    > >
    > > E.g.
    > > Domain
    > > Computers - apply GPO that is to be applied to all computers here
    > > NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    > > here
    > > Users - apply GPO that is to be applied to all users here
    > > SpecialUsers - apply GPO that has settings specific to only some
    > > (special) users
    > > as opposed to
    > > Domain
    > > Computers
    > > Users
    > >
    > > --
    > > Bruce Sanderson MVP Printing
    > > http://members.shaw.ca/bsanders
    > >
    > > It is perfectly useless to know the right answer to the wrong question.
    > >
    > >
    > >
    > > "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    > > news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    > > >I am having the same issue and the original post. I have tried adding the
    > > > setting at the OU level which is below the domain level, so that policy
    > > > should be applied. However, it seems that this setting is a user setting.
    > > > The users are in the user OU which is above the target computer OU. So
    > > > they
    > > > don't get this policy setting. I have also tried setting the permissions
    > > > to
    > > > allow access to only the specific machine accounts and that has no effect.
    > > > It only seems to care about the user portion.
    > > >
    > > > Anyone have any ideas?
    > > >
    > > > DC
    > > >
    > > > "Ken B" wrote:
    > > >
    > > >> You're right in that the local policy gets applied first. The only thing
    > > >> is
    > > >> later settings in the L, S, D, Ou order 'win'. So your domain policy won
    > > >> out over the local policy... and the domain wins.
    > > >>
    > > >> If you had a different policy on the OU, that one would win, provided
    > > >> your
    > > >> domain policy did not have "No override" or "Enforced" checked off.
    > > >>
    > > >> Easiest way I would think to get those computers to not apply the
    > > >> screensaver policy would be to create a security group, add the computers
    > > >> to
    > > >> that group, and then give that group Deny permission to Read & Apply the
    > > >> policy on the security tab of the policy itself. This way you can
    > > >> add/remove/edit the list at your own whim, and you'll have a listing of
    > > >> all
    > > >> the computers that won't have that policy apply to them.
    > > >>
    > > >> HTH
    > > >>
    > > >> Ken
    > > >>
    > > >> <lee.james@spartan.ab.ca> wrote in message
    > > >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > > >> > We've enabled a mandatory screen saver policy and applied it at the
    > > >> > domain level - it works as it's supposed to.
    > > >> >
    > > >> > There's a handful of machines we don't want this policy to apply to,
    > > >> > and we don't want to muck around with GP permissions, or create
    > > >> > exception OU's, play with GP deny settings etc.
    > > >> >
    > > >> > We should just be able to specify a local policy to override (as local
    > > >> > is first in order or precedence).
    > > >> >
    > > >> > However we can't get it to work. Clients are XP SP2.
    > > >> >
    > > >> > I specify the settings locally, log off and on, tried rebooting as well
    > > >> > - but when I check the registry key
    > > >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > > >> > showing the entries from the domain policy.
    > > >> >
    > > >> > What gives?
    > > >> >
    > > >>
    > > >>
    > > >>
    >
    >
  13. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    This information (loopback) was dead-on target with a problem I was
    having applying user policies to a computer OU. Thanks!
  14. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    John,

    Create an OU, create a Group Policy for that OU....set loopback
    processing (Computer Configuration\Adminstrative Templates\System\Group
    Policy - User Group Policy loopback processing mode - Enable it, select
    Replace

    Then go into the User config container and set the options you want
    (eg. Hide Control Panel).

    Save the Group Policy you created.

    Move the systems you want Loopback processing enabled into this new OU
    and either wait for things to get updated or force using either secedit
    or GPUpdate.

    Now when any user logs into a system that's in that OU they will have
    the same settings applied.

    That will be $500 :)

    J.

    John Williams wrote:
    > What instructions did Microsoft give you to follow? Can you share with
    > everyone on what you did you resolve this issue. I am facing the same issue
    > and any help would be GREATLY appreciated.
    >
    > Thanks!
    >
    >
    > "lee.james@spartan.ab.ca" wrote:
    >
    > > Hi Bruce,
    > >
    > > Yes, I figured out that using loopback processing was the answer (Ok, I
    > > ended up calling MS support). I created a seperate OU that had loopback
    > > processing applied and put the particular systems in the OU. That now
    > > works fine.
    > >
    > > However, what I can't understand and MS can't seem to explain, is why I
    > > can't enable loopback processing on the local policy of the problem
    > > systems instead of having to do it at the OU level?
    > >
    > > MS keeps saying the order or precedence is the reason, but as I
    > > understand it, the local gets 'read' first, tells that it's using
    > > loopback processing - which should then tell it to ignore the user
    > > settings at the site level, domain level, ou level etc.
    > >
    > > J.
    > >
    > > Bruce Sanderson wrote:
    > > > Settings in the User Configuration part of a GPO always apply to User
    > > > Accounts, not Computer Accounts, so any User Configuration settings you want
    > > > to apply must be in a GPO that applies to the User's Account, not the
    > > > Computer's Account.
    > > >
    > > > If you acutally want some User Configuration settings applied ONLY when
    > > > users log on to specific computers, then enable Loopback processing in a GPO
    > > > that is applied to the OU containing those Computer Accounts and put the
    > > > User Configuration settings into a GPO that applies to that OU. See
    > > > http://support.microsoft.com/kb/231287/. Not that the User Configuration
    > > > part of a GPO processed by the Loopback feature are still applied to User
    > > > Accounts, but only when a (any) user logs on at the computers that GPO
    > > > applies to. Loopback processing does not actaully convert User
    > > > Configuration settings to Computer Configuration settings.
    > > >
    > > > The best way (IMHO) is to establish an OU hierarchy/structure that reflects
    > > > how you want to manage things and how you want to apply GPOs. One of the
    > > > major features of AD is the ability to nest OUs and to change the OU
    > > > structure easily. Settings in GPOs applied at the lower levels in the
    > > > hierarchy (e.g. NeedScreenSaver in the example below) will take precedence
    > > > over corresponding settings applied higher in the heirarchy. Take advantage
    > > > of this feature to make your life easier. In particular, have seperate OU
    > > > hierarchies for User and Computer Accounts (as opposed to having the
    > > > computer accounts in an OU nested inside the Users OU).
    > > >
    > > > E.g.
    > > > Domain
    > > > Computers - apply GPO that is to be applied to all computers here
    > > > NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    > > > here
    > > > Users - apply GPO that is to be applied to all users here
    > > > SpecialUsers - apply GPO that has settings specific to only some
    > > > (special) users
    > > > as opposed to
    > > > Domain
    > > > Computers
    > > > Users
    > > >
    > > > --
    > > > Bruce Sanderson MVP Printing
    > > > http://members.shaw.ca/bsanders
    > > >
    > > > It is perfectly useless to know the right answer to the wrong question.
    > > >
    > > >
    > > >
    > > > "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    > > > news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    > > > >I am having the same issue and the original post. I have tried adding the
    > > > > setting at the OU level which is below the domain level, so that policy
    > > > > should be applied. However, it seems that this setting is a user setting.
    > > > > The users are in the user OU which is above the target computer OU. So
    > > > > they
    > > > > don't get this policy setting. I have also tried setting the permissions
    > > > > to
    > > > > allow access to only the specific machine accounts and that has no effect.
    > > > > It only seems to care about the user portion.
    > > > >
    > > > > Anyone have any ideas?
    > > > >
    > > > > DC
    > > > >
    > > > > "Ken B" wrote:
    > > > >
    > > > >> You're right in that the local policy gets applied first. The only thing
    > > > >> is
    > > > >> later settings in the L, S, D, Ou order 'win'. So your domain policy won
    > > > >> out over the local policy... and the domain wins.
    > > > >>
    > > > >> If you had a different policy on the OU, that one would win, provided
    > > > >> your
    > > > >> domain policy did not have "No override" or "Enforced" checked off.
    > > > >>
    > > > >> Easiest way I would think to get those computers to not apply the
    > > > >> screensaver policy would be to create a security group, add the computers
    > > > >> to
    > > > >> that group, and then give that group Deny permission to Read & Apply the
    > > > >> policy on the security tab of the policy itself. This way you can
    > > > >> add/remove/edit the list at your own whim, and you'll have a listing of
    > > > >> all
    > > > >> the computers that won't have that policy apply to them.
    > > > >>
    > > > >> HTH
    > > > >>
    > > > >> Ken
    > > > >>
    > > > >> <lee.james@spartan.ab.ca> wrote in message
    > > > >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    > > > >> > We've enabled a mandatory screen saver policy and applied it at the
    > > > >> > domain level - it works as it's supposed to.
    > > > >> >
    > > > >> > There's a handful of machines we don't want this policy to apply to,
    > > > >> > and we don't want to muck around with GP permissions, or create
    > > > >> > exception OU's, play with GP deny settings etc.
    > > > >> >
    > > > >> > We should just be able to specify a local policy to override (as local
    > > > >> > is first in order or precedence).
    > > > >> >
    > > > >> > However we can't get it to work. Clients are XP SP2.
    > > > >> >
    > > > >> > I specify the settings locally, log off and on, tried rebooting as well
    > > > >> > - but when I check the registry key
    > > > >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    > > > >> > showing the entries from the domain policy.
    > > > >> >
    > > > >> > What gives?
    > > > >> >
    > > > >>
    > > > >>
    > > > >>
    > >
    > >
  15. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    lforbes <UseLinkToEmail@WindowsForumz.com> said

    >>Easiest way I would think to get those computers to not apply the
    >>screensaver policy would be to create a security group, add the
    >>computers to that group, and then give that group Deny permission to
    >>Read & Apply the policy on the security tab of the policy itself
    >
    > Hi Ken,
    >
    > The only problem is that he says he has the Screen Saver setting at
    > the Domain level and if he deny’s computers access to the Default
    > Domain policy he will be in real trouble.
    >

    I was under the impression that modifying the default domain policy was not
    recommended in the first place.


    --

    Andy.
  16. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    All the screen saver settings are USER settings, not COMPUTER settings, so,
    to get them applied to users that logon to certain computers, you need to
    have loopback processing enabled for the OU with the computer accounts in
    it - I suggest using "Merge" mode so that any settings applied to the OU
    containing the user accounts will also be applied when those users logon at
    the computers that are subject to loopback processing.

    The Loopback processing setting is in Computer Configuration, Administrative
    Templates, System, Group Policy.

    Create a child OU under the OU with the computer accounts, move the computer
    accounts for those with different screensaver timeouts into the child OU.
    Create a new GPO, linked to the child OU, that has just the "special"
    screensaver timeout setting .

    For example:

    Domain
    |
    |-- MyComputersOU <- put "most" of the computer accounts in this OU
    | |---> SpecialComputersOU -< link GPO with loopback enabled (GPO#1)
    | and;
    | link GPO with screen saver settings
    | you want for users
    | on the "special" computers
    | (GPO#2);
    | put computers with "special" screen
    | saver requirement in this OU
    |-MyUsersOU <- link GPO that has normal user settings, including the
    "default" ("normal"?) screen saver timeout
    setting (GPO#3);
    put your user's user accounts into this OU

    Note: GPO#2 only needs to have settings for the screen saver timeout - all
    the other settings from GPO#3 will be applied to users that logon at any
    computer regardless of which OU the computer's account is in. The
    loopback setting in GPO#1 will cause the User Configuration settings in
    GPO#2 to be applied to any user that logs on to a computer whose
    computer account is in SpecialComputersOU.

    The order of application of USER settings will then be:

    1. settings in the User Configuration part of GPOs at the Domain level
    2. settings in the User Configuration part of GPOs applied to MyUsersOU -
    including any screen saver settings in GPO#3
    3. settings in the User Configuration part of GPO#1 (I suggest NOT having
    any USER settings in this GPO)
    4. Settings in the User Configuration part of GPO#2 - the special
    screensaver timeout value

    Settings applied later in the application order take precedence (override)
    corresponding settings applied earlier. So, the screensaver timeout setting
    in GPO#2 will be in effect when users logon at computers that have computer
    accounts in the SpecialComputersOU because they are applied last.

    All of this assumes you have not done anything "unusual", such as applying a
    Security or WMI filter any of the GPOs or GPO links.

    I find it useful to keep User Configuration settings and Computer
    Configuration settings in separate GPOs - avoids confusion (see
    http://members.shaw.ca/bsanders/WindowsGeneralWeb/HappyGPOs.htm.

    Correct application of GPOs requires an appropriate OU structure for the
    computer accounts and user accounts. It is generally more useful to create
    your own OUs and avoid putting objects that you create into the "default OU"
    that are created when the Domain is created.


    --
    Bruce Sanderson MVP Printing
    http://members.shaw.ca/bsanders

    It is perfectly useless to know the right answer to the wrong question.


    "John Williams" <JohnWilliams@discussions.microsoft.com> wrote in message
    news:BBF70A0A-AC1E-43E9-922B-4D5E644AFAFB@microsoft.com...
    > Can you go into more detail on what you mean?
    >
    > I am trying to have certain PC's with screen saver timeouts different from
    > the rest in the office (60Min vs. 10 min.). I have been playing around
    > with
    > the GPO's trying to make it work for days.
    >
    > I am looking for detailed instructions on how to implement what is being
    > discussed in here. Any help would be GREATLY appreciated.
    >
    > Thanks
    >
    >
    > "Bruce Sanderson" wrote:
    >
    >> Settings in the User Configuration part of a GPO always apply to User
    >> Accounts, not Computer Accounts, so any User Configuration settings you
    >> want
    >> to apply must be in a GPO that applies to the User's Account, not the
    >> Computer's Account.
    >>
    >> If you acutally want some User Configuration settings applied ONLY when
    >> users log on to specific computers, then enable Loopback processing in a
    >> GPO
    >> that is applied to the OU containing those Computer Accounts and put the
    >> User Configuration settings into a GPO that applies to that OU. See
    >> http://support.microsoft.com/kb/231287/. Not that the User Configuration
    >> part of a GPO processed by the Loopback feature are still applied to User
    >> Accounts, but only when a (any) user logs on at the computers that GPO
    >> applies to. Loopback processing does not actaully convert User
    >> Configuration settings to Computer Configuration settings.
    >>
    >> The best way (IMHO) is to establish an OU hierarchy/structure that
    >> reflects
    >> how you want to manage things and how you want to apply GPOs. One of the
    >> major features of AD is the ability to nest OUs and to change the OU
    >> structure easily. Settings in GPOs applied at the lower levels in the
    >> hierarchy (e.g. NeedScreenSaver in the example below) will take
    >> precedence
    >> over corresponding settings applied higher in the heirarchy. Take
    >> advantage
    >> of this feature to make your life easier. In particular, have seperate
    >> OU
    >> hierarchies for User and Computer Accounts (as opposed to having the
    >> computer accounts in an OU nested inside the Users OU).
    >>
    >> E.g.
    >> Domain
    >> Computers - apply GPO that is to be applied to all computers here
    >> NeedScreenSaver - apply GPO with Loopback and Screen Saver settings
    >> here
    >> Users - apply GPO that is to be applied to all users here
    >> SpecialUsers - apply GPO that has settings specific to only some
    >> (special) users
    >> as opposed to
    >> Domain
    >> Computers
    >> Users
    >>
    >> --
    >> Bruce Sanderson MVP Printing
    >> http://members.shaw.ca/bsanders
    >>
    >> It is perfectly useless to know the right answer to the wrong question.
    >>
    >>
    >>
    >> "dcompton" <dcompton@discussions.microsoft.com> wrote in message
    >> news:A1384096-7547-42B2-BEF0-BF17423A72F7@microsoft.com...
    >> >I am having the same issue and the original post. I have tried adding
    >> >the
    >> > setting at the OU level which is below the domain level, so that policy
    >> > should be applied. However, it seems that this setting is a user
    >> > setting.
    >> > The users are in the user OU which is above the target computer OU. So
    >> > they
    >> > don't get this policy setting. I have also tried setting the
    >> > permissions
    >> > to
    >> > allow access to only the specific machine accounts and that has no
    >> > effect.
    >> > It only seems to care about the user portion.
    >> >
    >> > Anyone have any ideas?
    >> >
    >> > DC
    >> >
    >> > "Ken B" wrote:
    >> >
    >> >> You're right in that the local policy gets applied first. The only
    >> >> thing
    >> >> is
    >> >> later settings in the L, S, D, Ou order 'win'. So your domain policy
    >> >> won
    >> >> out over the local policy... and the domain wins.
    >> >>
    >> >> If you had a different policy on the OU, that one would win, provided
    >> >> your
    >> >> domain policy did not have "No override" or "Enforced" checked off.
    >> >>
    >> >> Easiest way I would think to get those computers to not apply the
    >> >> screensaver policy would be to create a security group, add the
    >> >> computers
    >> >> to
    >> >> that group, and then give that group Deny permission to Read & Apply
    >> >> the
    >> >> policy on the security tab of the policy itself. This way you can
    >> >> add/remove/edit the list at your own whim, and you'll have a listing
    >> >> of
    >> >> all
    >> >> the computers that won't have that policy apply to them.
    >> >>
    >> >> HTH
    >> >>
    >> >> Ken
    >> >>
    >> >> <lee.james@spartan.ab.ca> wrote in message
    >> >> news:1121956401.102170.315600@g43g2000cwa.googlegroups.com...
    >> >> > We've enabled a mandatory screen saver policy and applied it at the
    >> >> > domain level - it works as it's supposed to.
    >> >> >
    >> >> > There's a handful of machines we don't want this policy to apply to,
    >> >> > and we don't want to muck around with GP permissions, or create
    >> >> > exception OU's, play with GP deny settings etc.
    >> >> >
    >> >> > We should just be able to specify a local policy to override (as
    >> >> > local
    >> >> > is first in order or precedence).
    >> >> >
    >> >> > However we can't get it to work. Clients are XP SP2.
    >> >> >
    >> >> > I specify the settings locally, log off and on, tried rebooting as
    >> >> > well
    >> >> > - but when I check the registry key
    >> >> > HKCU\SW\policies\Microsoft\Windows\Control Panel\Desktop it keeps
    >> >> > showing the entries from the domain policy.
    >> >> >
    >> >> > What gives?
    >> >> >
    >> >>
    >> >>
    >> >>
    >>
    >>
    >>
Ask a new question

Read More

Policy Microsoft Windows