User GPO not applying unless linked to computers

  • Thread starter Thread starter Andrew Mitchell
  • Start date Start date
A

Andrew Mitchell

Hi,
I'm wondering if anyone has a solution to this problem.
Windows 2003 native domain, Win2k and XP workstations. Single domain, no
trusts, 2 DCs in the primary AD site (both running AD integrated DNS) and 1
DC in a DR site containing no workstations. All clients are pointing to the
AD integrated DNS servers.

I have an OU which contains all computer accounts for the domain. I have
another totally separate (not a child) OU which contains user accounts.

If I create a GPO containing only User settings and link it to the OU
containing the user accounts, the GPO does not take effect. GPResult does not
display the GPO at all, even if I wait for a full day to ensure replication
has taken place before rebooting.

It is not until I link the GPO to the OU containing the Computer accounts
that it begins to work. Linking computer setting GPO's to the computers OU
works fine.

DNS is working fine and everything else is healthy on the network.
The only thing I can think of is loopback policies set to Replace and being
applied to the computer accounts, but I haven't been able to find any.

Any ideas?
 
Hi,

Andrew said:
If I create a GPO containing only User settings and link it to the OU
containing the user accounts, the GPO does not take effect. GPResult does not
display the GPO at all, even if I wait for a full day to ensure replication
has taken place before rebooting.
It is not until I link the GPO to the OU containing the Computer accounts
that it begins to work. Linking computer setting GPO's to the computers OU
works fine.
Click to expand...

It sounds like you are trying to deploy security setting to your
Users, but even if they are planned to be for users, the security
settings can only be deployed to computers ...

CU
Mark
 
It does sound like loopback processing is enabled on the computer OU
possibly. Try to move one of the computers into the users OU to see what
happens when a user logs onto it as loopback processing would only be
applying to computers in the computer OU if enabled only there. If you are
not using it yet try using Group Policy Management Console and try RSOP in
logging and planning mode to see what is shown. Verify that user
configuration is enabled on the GPO and that read and apply permissions are
correct. If not using default permissions such as authenticated users I like
to use global groups and not domain local groups in GPO permissions.
Gpupdate /force first on domain controller and then on user's computer can
speed up GPO propagation quite a bit. Also when testing be sure to logon and
logoff at least twice, particularly on XP Pro computers. -- Steve
 
Mark Heitbrink said:
Hi,



It sounds like you are trying to deploy security setting to your
Users, but even if they are planned to be for users, the security
settings can only be deployed to computers ...
Click to expand...

No. It happens with all user settings. The ones I am attempting to apply at
the moment are logon scripts (not startup scripts), although this problem is
occuring with any user setting. It won't apply unless I also apply the GPO to
the OU containing the computers.
 
Steven L Umbach said:
It does sound like loopback processing is enabled on the computer OU
possibly.
Click to expand...

That's what I thought.
Try to move one of the computers into the users OU to see what
happens when a user logs onto it as loopback processing would only be
applying to computers in the computer OU if enabled only there.
Click to expand...

I've tried that and it causes the GPO to work, though I'm not certain if
that's because the GPO is also being applied to the computer object.

I'll try creating a temp OU at the domain level and move the computer
account there to see what happens.
If you
are not using it yet try using Group Policy Management Console and try
RSOP in logging and planning mode to see what is shown.
Click to expand...

Thanks. I'll give that a try.
Verify that user
configuration is enabled on the GPO and that read and apply permissions
are correct.
Click to expand...

Permissions are definitely correct.
If not using default permissions such as authenticated
users I like to use global groups and not domain local groups in GPO
permissions.
Click to expand...

I don't have any Deny permissions on the GPO and I've even set the
permissions to read and apply for the Everyone group. Still no luck.
Gpupdate /force first on domain controller and then on
user's computer can speed up GPO propagation quite a bit. Also when
testing be sure to logon and logoff at least twice, particularly on XP
Pro computers.
Click to expand...

Yep. I've tried all of those an still no good.
Thanks for the tip on GPMC though. I'll have a look and see what it shows
up.
 
Andrew Mitchell said:
That's what I thought.


I've tried that and it causes the GPO to work, though I'm not certain if
that's because the GPO is also being applied to the computer object.

I'll try creating a temp OU at the domain level and move the computer
account there to see what happens.


Thanks. I'll give that a try.
Click to expand...

Further to this:
I have applied a GPO containing a user login script to an OU containing the
users I want to run this script. Everyone has read and apply permissions to
the GPO. The GPO does not work unless I also link it to the OU containing
the computer accounts. RSOP shows that the GPO is not applied (it's not
filtered - just doesn't show up) unless it's linked to the computers OU.
The strange thing is that when I do this, anyone who is in the Domain
Admins group also has the policy applied, even if they are not in an OU
that the GPO is linked to (or a child of that OU).

RSOP in the GPMC gives an error : "key may not be null. key name is 'key'"
Checking each GPO in the domain using GPMC shows that they all look OK.

This is starting to sound like a corrupted AD. Does anyone know of any
tools to check AD integrity?
 
That is bizarre. I have never experienced such but the error message you get
does not sound too good. It would be interesting to see what happens if you
create a new OU that is not a child OU of the "problem" OU with it's own new
GPO to see if the behavior is repeated. Since you are having unusual
problems I would run netdiag, dcdiag, and gpotool on at least the pdc fsmo
domain controller to see if anything unusual is reported. You can
check/repair AD database with the ntdsutil.exe tool as shown in the link
below. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;315131 -- please
read all the fine print before proceeding.
 
Back
Top