Policy loopback causes domain-level policies to reapply

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

Background:

We're using 2000 domain controllers in a mixed environment of 2000/2003
servers and 2000/XP desktops.

Our domain tree looks like this:

Domain container
|-- (Screen Saver Policy)
|-- Desktops
| `-- (Package Deployment Policy)
|-- Screensaver Disabled Users
| `-- (Screensaver Disabled Policy)
|-- Servers
|-- Users (default container)

Our computers are split between the Desktops and Servers OUs, depending on
their function. Our users are mostly in the Users default container, except
for a handful who are in the "Screensaver Disabled Users" OU.

What we're trying to do is deploy client tools to the desktop computers
during user login. We don't want these tools to install on servers, so we
placed the deployment policy under the Desktops OU. Since this policy
contains user-based settings under a computers-only OU, we turned on Loopback
for this policy. (This is the only to get it to go, right?)

The trouble is that this seems to come back around and reapply all the
policies from the domain on down to the Deployment policy. When this
happens, the "Screensave Disabled" users receive an overwrite of the
domain-wide Screensaver policy, which turns the screensaver back on for them.
Does this sound like normal operation?

Since the Users object is a default container, it can't have policies
applied directly to it. This is why the Screensaver policy is applied to the
domain. If necessary, I guess we could create a new Users OU and place all
our screensaver-enabled users in it, shifting the policy to that level -- but
we see this as a last resort to be done only if absolutely unavoidable. Is
there a way to prevent the domain-wide policies from being reapplied when
loopback is active on a single policy?

TIA for any help,

Kevin
4 answers Last reply
More about policy loopback domain level policies reapply
  1. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Weird question... why not assign it to the computer? You know you want it
    to apply to all the desktops, so why not create the policy as a machine
    policy instead?

    Ken

    "Kevin S. Forsyth" <Kevin S. Forsyth@discussions.microsoft.com> wrote in
    message news:8DAC186A-82AB-4CA3-B2A1-EA9D410C3D92@microsoft.com...
    > Background:
    >
    > We're using 2000 domain controllers in a mixed environment of 2000/2003
    > servers and 2000/XP desktops.
    >
    > Our domain tree looks like this:
    >
    > Domain container
    > |-- (Screen Saver Policy)
    > |-- Desktops
    > | `-- (Package Deployment Policy)
    > |-- Screensaver Disabled Users
    > | `-- (Screensaver Disabled Policy)
    > |-- Servers
    > |-- Users (default container)
    >
    > Our computers are split between the Desktops and Servers OUs, depending on
    > their function. Our users are mostly in the Users default container,
    > except
    > for a handful who are in the "Screensaver Disabled Users" OU.
    >
    > What we're trying to do is deploy client tools to the desktop computers
    > during user login. We don't want these tools to install on servers, so we
    > placed the deployment policy under the Desktops OU. Since this policy
    > contains user-based settings under a computers-only OU, we turned on
    > Loopback
    > for this policy. (This is the only to get it to go, right?)
    >
    > The trouble is that this seems to come back around and reapply all the
    > policies from the domain on down to the Deployment policy. When this
    > happens, the "Screensave Disabled" users receive an overwrite of the
    > domain-wide Screensaver policy, which turns the screensaver back on for
    > them.
    > Does this sound like normal operation?
    >
    > Since the Users object is a default container, it can't have policies
    > applied directly to it. This is why the Screensaver policy is applied to
    > the
    > domain. If necessary, I guess we could create a new Users OU and place
    > all
    > our screensaver-enabled users in it, shifting the policy to that level --
    > but
    > we see this as a last resort to be done only if absolutely unavoidable.
    > Is
    > there a way to prevent the domain-wide policies from being reapplied when
    > loopback is active on a single policy?
    >
    > TIA for any help,
    >
    > Kevin
  2. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Fair question. IIRC from the documentation, assigning it to the computer
    means that the installation is triggered by a full reboot, rather than a
    logoff/logon cycle. We would prefer not to have to force our users to do
    this every time a new tool comes out (which can be almost daily). They're up
    in arms enough just having to log out.

    Kevin


    "Ken B" wrote:

    > Weird question... why not assign it to the computer? You know you want it
    > to apply to all the desktops, so why not create the policy as a machine
    > policy instead?
    >
    > Ken
    >
    > "Kevin S. Forsyth" <Kevin S. Forsyth@discussions.microsoft.com> wrote in
    > message news:8DAC186A-82AB-4CA3-B2A1-EA9D410C3D92@microsoft.com...
    > > Background:
    > >
    > > We're using 2000 domain controllers in a mixed environment of 2000/2003
    > > servers and 2000/XP desktops.
    > >
    > > Our domain tree looks like this:
    > >
    > > Domain container
    > > |-- (Screen Saver Policy)
    > > |-- Desktops
    > > | `-- (Package Deployment Policy)
    > > |-- Screensaver Disabled Users
    > > | `-- (Screensaver Disabled Policy)
    > > |-- Servers
    > > |-- Users (default container)
    > >
    > > Our computers are split between the Desktops and Servers OUs, depending on
    > > their function. Our users are mostly in the Users default container,
    > > except
    > > for a handful who are in the "Screensaver Disabled Users" OU.
    > >
    > > What we're trying to do is deploy client tools to the desktop computers
    > > during user login. We don't want these tools to install on servers, so we
    > > placed the deployment policy under the Desktops OU. Since this policy
    > > contains user-based settings under a computers-only OU, we turned on
    > > Loopback
    > > for this policy. (This is the only to get it to go, right?)
    > >
    > > The trouble is that this seems to come back around and reapply all the
    > > policies from the domain on down to the Deployment policy. When this
    > > happens, the "Screensave Disabled" users receive an overwrite of the
    > > domain-wide Screensaver policy, which turns the screensaver back on for
    > > them.
    > > Does this sound like normal operation?
    > >
    > > Since the Users object is a default container, it can't have policies
    > > applied directly to it. This is why the Screensaver policy is applied to
    > > the
    > > domain. If necessary, I guess we could create a new Users OU and place
    > > all
    > > our screensaver-enabled users in it, shifting the policy to that level --
    > > but
    > > we see this as a last resort to be done only if absolutely unavoidable.
    > > Is
    > > there a way to prevent the domain-wide policies from being reapplied when
    > > loopback is active on a single policy?
    > >
    > > TIA for any help,
    > >
    > > Kevin
    >
    >
    >
  3. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    I don't understand why you would consider creating an OU structure for users
    a last resort option.
    I would consider User OUs as the preferred method to deploy user assigned
    applications.

    I suggest you create a OU for your users and put all users in this
    container.
    Link the Package deployment policy to the users OU and remove the "loopback
    processing" setting from the GPO.
    Then link ScreenSaver Disabled policy to the Users OU and security filter it
    to only the users that should have their screen saver disabled.
    I'm assuming your user base does not log into servers interactively?
    If they do, and you want to prevent the tools from being installed on the
    server, then you will need to add a GPO to the servers OU and configure
    loopback processing in replace mode.

    To answer your question "Does this sound like normal operation?"
    Yes it is the designed behavior.
    see http://grouppolicy.editme.com/Loopback for an explanation.


    --
    Glenn L
    CCNA, MCSE 2000/2003 + Security

    "Kevin S. Forsyth" <KevinSForsyth@discussions.microsoft.com> wrote in
    message news:2050E0A0-702D-4EBF-9F3D-D9098745462D@microsoft.com...
    > Fair question. IIRC from the documentation, assigning it to the computer
    > means that the installation is triggered by a full reboot, rather than a
    > logoff/logon cycle. We would prefer not to have to force our users to do
    > this every time a new tool comes out (which can be almost daily). They're
    > up
    > in arms enough just having to log out.
    >
    > Kevin
    >
    >
    > "Ken B" wrote:
    >
    >> Weird question... why not assign it to the computer? You know you want
    >> it
    >> to apply to all the desktops, so why not create the policy as a machine
    >> policy instead?
    >>
    >> Ken
    >>
    >> "Kevin S. Forsyth" <Kevin S. Forsyth@discussions.microsoft.com> wrote in
    >> message news:8DAC186A-82AB-4CA3-B2A1-EA9D410C3D92@microsoft.com...
    >> > Background:
    >> >
    >> > We're using 2000 domain controllers in a mixed environment of 2000/2003
    >> > servers and 2000/XP desktops.
    >> >
    >> > Our domain tree looks like this:
    >> >
    >> > Domain container
    >> > |-- (Screen Saver Policy)
    >> > |-- Desktops
    >> > | `-- (Package Deployment Policy)
    >> > |-- Screensaver Disabled Users
    >> > | `-- (Screensaver Disabled Policy)
    >> > |-- Servers
    >> > |-- Users (default container)
    >> >
    >> > Our computers are split between the Desktops and Servers OUs, depending
    >> > on
    >> > their function. Our users are mostly in the Users default container,
    >> > except
    >> > for a handful who are in the "Screensaver Disabled Users" OU.
    >> >
    >> > What we're trying to do is deploy client tools to the desktop computers
    >> > during user login. We don't want these tools to install on servers, so
    >> > we
    >> > placed the deployment policy under the Desktops OU. Since this policy
    >> > contains user-based settings under a computers-only OU, we turned on
    >> > Loopback
    >> > for this policy. (This is the only to get it to go, right?)
    >> >
    >> > The trouble is that this seems to come back around and reapply all the
    >> > policies from the domain on down to the Deployment policy. When this
    >> > happens, the "Screensave Disabled" users receive an overwrite of the
    >> > domain-wide Screensaver policy, which turns the screensaver back on for
    >> > them.
    >> > Does this sound like normal operation?
    >> >
    >> > Since the Users object is a default container, it can't have policies
    >> > applied directly to it. This is why the Screensaver policy is applied
    >> > to
    >> > the
    >> > domain. If necessary, I guess we could create a new Users OU and place
    >> > all
    >> > our screensaver-enabled users in it, shifting the policy to that
    >> > level --
    >> > but
    >> > we see this as a last resort to be done only if absolutely unavoidable.
    >> > Is
    >> > there a way to prevent the domain-wide policies from being reapplied
    >> > when
    >> > loopback is active on a single policy?
    >> >
    >> > TIA for any help,
    >> >
    >> > Kevin
    >>
    >>
    >>
  4. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Thanks, Glenn! It took some convincing to get my boss to agree to it, but
    the restructuring you suggested helped a great deal. Now I have a different
    issue, but I'll start a new thread for it.

    Thanks again,

    Kevin


    "Glenn L" wrote:

    > I don't understand why you would consider creating an OU structure for users
    > a last resort option.
    > I would consider User OUs as the preferred method to deploy user assigned
    > applications.
Ask a new question

Read More

Policy Screensaver Domain Windows