Applying user configuration settings to an OU containing only computer objects

Z

Zack

Hey all,

We're having a rather frustrating issue, and I'm not certain whether we're
just doing something incorrectly or there's a problem here.

We have a terminal server that we're trying to lock down via group policy.
We have the server in its own OU, with a GPO applied to it. In this GPO,
we're applying user settings, to be applied to any user that logs onto the
machine via loopback processing mode. Except users aren't getting the
policy at all--gpresult.exe doesn't even mention the policy for the user.
According to Microsoft here
(http://support.microsoft.com/default.aspx?scid=kb;en-us;260370&Product=win2000
- Method 2), I believe that we're doing it right. Any ideas? We've tried
manually updating the server's GP via secedit /refreshpolicy, tried
waiting out the full 90 minutes just in case, checked permissions, the
whole nine yards. Nothing seems to work.

Server is Windows 2000 Server w/Citrix Metaframe, domain is Windows 2000
native functional level.

Thanks for any ideas,

-Zack-
 
S

Steven L Umbach

When you ran gpresult while logged onto that server, does it show that the GPO for
the OU has been applied to the TS computer successfully and recently? If it has not,
what is the message if any? Running netdiag is always a good idea when you are
having problems looking for failed tests/errors/warning particularly relating to
domain membership, dns, and dclist. --- Steve
 
Z

Zack

The GPO is being applied to the computer (ie 'This computer received
settings from...'), but not to the user.

-Zack-
 
S

Steven L Umbach

The GPO that you created for the OU that the TS is in, does the proper group have
read/apply permissions to the GPO in properties/security and is user configuration
portion of that GPO enabled? If you put a test user into that OU and then logon as
them, do they then get the desired settings and gpresult show the policy is applied
to them? Is there more than one GPO in the TS OU? --- Steve
 
Z

Zack

Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-
 
S

Steven L Umbach

Try logging the test user on from a workstation where you are experiencing problem
with the policy not applying via loopback. Have them logon with their user account in
the OU and then not in the OU [you may have done all this already] after doing a
refresh using secedit for machine and user to see what happens with policy not being
applied. Just trying to verify that it is not a machine problem. Again verify first
that loopback processing is enabled for that GPO that the TS server resides in under
computer configuration/administrative templates/system/Group Policy. For XP machines,
it may take a couple of logons for user policy to process. Running out of ideas on
this end and can understand you being flummoxed. --- Steve
 
Z

Zack Schiel

I have logged them on to that machine while their user account was in the
OU, and the policy applied successfully. Verified that loopback is
enabled for that GPO. Tried dozens of logons by now. :)

It shouldn't matter that the user is logging on via RDP rather than at the
console, correct?

Thanks,

-Zack- >> The lowly MCSA still getting comfortable with advanced Group
Policy. ;)




Try logging the test user on from a workstation where you are
experiencing problem
with the policy not applying via loopback. Have them logon with their
user account in
the OU and then not in the OU [you may have done all this already] after
doing a
refresh using secedit for machine and user to see what happens with
policy not being
applied. Just trying to verify that it is not a machine problem. Again
verify first
that loopback processing is enabled for that GPO that the TS server
resides in under
computer configuration/administrative templates/system/Group Policy. For
XP machines,
it may take a couple of logons for user policy to process. Running out
of ideas on
this end and can understand you being flummoxed. --- Steve

Zack said:
Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-
 
S

Steven Umbach

Zack Schiel said:
I have logged them on to that machine while their user account was in the
OU, and the policy applied successfully. Verified that loopback is
enabled for that GPO. Tried dozens of logons by now. :)

It shouldn't matter that the user is logging on via RDP rather than at the
console, correct?

Thanks,

-Zack- >> The lowly MCSA still getting comfortable with advanced Group
Policy. ;)




Try logging the test user on from a workstation where you are
experiencing problem
with the policy not applying via loopback. Have them logon with their
user account in
the OU and then not in the OU [you may have done all this already] after
doing a
refresh using secedit for machine and user to see what happens with
policy not being
applied. Just trying to verify that it is not a machine problem. Again
verify first
that loopback processing is enabled for that GPO that the TS server
resides in under
computer configuration/administrative templates/system/Group Policy. For
XP machines,
it may take a couple of logons for user policy to process. Running out
of ideas on
this end and can understand you being flummoxed. --- Steve

Zack said:
Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-

On Tue, 27 Apr 2004 21:44:06 GMT, Steven L Umbach

The GPO that you created for the OU that the TS is in, does the proper
group have
read/apply permissions to the GPO in properties/security and is user
configuration
portion of that GPO enabled? If you put a test user into that OU and
then logon as
them, do they then get the desired settings and gpresult show the
policy
is applied
to them? Is there more than one GPO in the TS OU? --- Steve

The GPO is being applied to the computer (ie 'This computer received
settings from...'), but not to the user.

-Zack-

On Tue, 27 Apr 2004 20:11:02 GMT, Steven L Umbach

When you ran gpresult while logged onto that server, does it show
that
the GPO for
the OU has been applied to the TS computer successfully and
recently?
If
it has not,
what is the message if any? Running netdiag is always a good idea
when
you are
having problems looking for failed tests/errors/warning
particularly
relating to
domain membership, dns, and dclist. --- Steve


Hey all,

We're having a rather frustrating issue, and I'm not certain
whether
we're
just doing something incorrectly or there's a problem here.

We have a terminal server that we're trying to lock down via group
policy.
We have the server in its own OU, with a GPO applied to it. In
this
GPO,
we're applying user settings, to be applied to any user that logs
onto
the
machine via loopback processing mode. Except users aren't getting
the
policy at all--gpresult.exe doesn't even mention the policy for
the
user.
According to Microsoft here


(http://support.microsoft.com/default.aspx?scid=kb;en-us;260370&Product=win2000
- Method 2), I believe that we're doing it right. Any ideas? We've
tried
manually updating the server's GP via secedit /refreshpolicy,
tried
waiting out the full 90 minutes just in case, checked permissions,
the
whole nine yards. Nothing seems to work.

Server is Windows 2000 Server w/Citrix Metaframe, domain is
Windows
2000
native functional level.

Thanks for any ideas,

-Zack-
 
S

Steven Umbach

No it should not matter as both are considered interactive logons but what I was
suggesting was having test user logon to the TS from a network workstation while
that account was in the TS OU to see if the policy still applies and
troubleshoot from there depending on the results. --- Steve


Zack Schiel said:
I have logged them on to that machine while their user account was in the
OU, and the policy applied successfully. Verified that loopback is
enabled for that GPO. Tried dozens of logons by now. :)

It shouldn't matter that the user is logging on via RDP rather than at the
console, correct?

Thanks,

-Zack- >> The lowly MCSA still getting comfortable with advanced Group
Policy. ;)




Try logging the test user on from a workstation where you are
experiencing problem
with the policy not applying via loopback. Have them logon with their
user account in
the OU and then not in the OU [you may have done all this already] after
doing a
refresh using secedit for machine and user to see what happens with
policy not being
applied. Just trying to verify that it is not a machine problem. Again
verify first
that loopback processing is enabled for that GPO that the TS server
resides in under
computer configuration/administrative templates/system/Group Policy. For
XP machines,
it may take a couple of logons for user policy to process. Running out
of ideas on
this end and can understand you being flummoxed. --- Steve

Zack said:
Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-

On Tue, 27 Apr 2004 21:44:06 GMT, Steven L Umbach

The GPO that you created for the OU that the TS is in, does the proper
group have
read/apply permissions to the GPO in properties/security and is user
configuration
portion of that GPO enabled? If you put a test user into that OU and
then logon as
them, do they then get the desired settings and gpresult show the
policy
is applied
to them? Is there more than one GPO in the TS OU? --- Steve

The GPO is being applied to the computer (ie 'This computer received
settings from...'), but not to the user.

-Zack-

On Tue, 27 Apr 2004 20:11:02 GMT, Steven L Umbach

When you ran gpresult while logged onto that server, does it show
that
the GPO for
the OU has been applied to the TS computer successfully and
recently?
If
it has not,
what is the message if any? Running netdiag is always a good idea
when
you are
having problems looking for failed tests/errors/warning
particularly
relating to
domain membership, dns, and dclist. --- Steve


Hey all,

We're having a rather frustrating issue, and I'm not certain
whether
we're
just doing something incorrectly or there's a problem here.

We have a terminal server that we're trying to lock down via group
policy.
We have the server in its own OU, with a GPO applied to it. In
this
GPO,
we're applying user settings, to be applied to any user that logs
onto
the
machine via loopback processing mode. Except users aren't getting
the
policy at all--gpresult.exe doesn't even mention the policy for
the
user.
According to Microsoft here


(http://support.microsoft.com/default.aspx?scid=kb;en-us;260370&Product=win2000
- Method 2), I believe that we're doing it right. Any ideas? We've
tried
manually updating the server's GP via secedit /refreshpolicy,
tried
waiting out the full 90 minutes just in case, checked permissions,
the
whole nine yards. Nothing seems to work.

Server is Windows 2000 Server w/Citrix Metaframe, domain is
Windows
2000
native functional level.

Thanks for any ideas,

-Zack-
 
S

Steven L Umbach

Zack.

If you changed any AD object permisions on the OU where the TS is, be sure users or
the appropriate group has at least read permissions to the OU itself and try adding
an individual [tests user] to read/apply for the GPO for that OU for the TS and for
read to the OU container in case there is a problem with group nesting. The link
below may be helpful in more advance Group Policy troubleshooting. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;250842

Steven Umbach said:
No it should not matter as both are considered interactive logons but what I was
suggesting was having test user logon to the TS from a network workstation while
that account was in the TS OU to see if the policy still applies and
troubleshoot from there depending on the results. --- Steve


Zack Schiel said:
I have logged them on to that machine while their user account was in the
OU, and the policy applied successfully. Verified that loopback is
enabled for that GPO. Tried dozens of logons by now. :)

It shouldn't matter that the user is logging on via RDP rather than at the
console, correct?

Thanks,

-Zack- >> The lowly MCSA still getting comfortable with advanced Group
Policy. ;)




Try logging the test user on from a workstation where you are
experiencing problem
with the policy not applying via loopback. Have them logon with their
user account in
the OU and then not in the OU [you may have done all this already] after
doing a
refresh using secedit for machine and user to see what happens with
policy not being
applied. Just trying to verify that it is not a machine problem. Again
verify first
that loopback processing is enabled for that GPO that the TS server
resides in under
computer configuration/administrative templates/system/Group Policy. For
XP machines,
it may take a couple of logons for user policy to process. Running out
of ideas on
this end and can understand you being flummoxed. --- Steve

Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-

On Tue, 27 Apr 2004 21:44:06 GMT, Steven L Umbach

The GPO that you created for the OU that the TS is in, does the proper
group have
read/apply permissions to the GPO in properties/security and is user
configuration
portion of that GPO enabled? If you put a test user into that OU and
then logon as
them, do they then get the desired settings and gpresult show the
policy
is applied
to them? Is there more than one GPO in the TS OU? --- Steve

The GPO is being applied to the computer (ie 'This computer received
settings from...'), but not to the user.

-Zack-

On Tue, 27 Apr 2004 20:11:02 GMT, Steven L Umbach

When you ran gpresult while logged onto that server, does it show
that
the GPO for
the OU has been applied to the TS computer successfully and
recently?
If
it has not,
what is the message if any? Running netdiag is always a good idea
when
you are
having problems looking for failed tests/errors/warning
particularly
relating to
domain membership, dns, and dclist. --- Steve


Hey all,

We're having a rather frustrating issue, and I'm not certain
whether
we're
just doing something incorrectly or there's a problem here.

We have a terminal server that we're trying to lock down via group
policy.
We have the server in its own OU, with a GPO applied to it. In
this
GPO,
we're applying user settings, to be applied to any user that logs
onto
the
machine via loopback processing mode. Except users aren't getting
the
policy at all--gpresult.exe doesn't even mention the policy for
the
user.
According to Microsoft here


(http://support.microsoft.com/default.aspx?scid=kb;en-us;260370&Product=win2000
- Method 2), I believe that we're doing it right. Any ideas? We've
tried
manually updating the server's GP via secedit /refreshpolicy,
tried
waiting out the full 90 minutes just in case, checked permissions,
the
whole nine yards. Nothing seems to work.

Server is Windows 2000 Server w/Citrix Metaframe, domain is
Windows
2000
native functional level.

Thanks for any ideas,

-Zack-
 
Z

Zack

Thanks Steve. No perms were changed, and I verified that they have read
permissions to the OU. I'll do the more in-depth testing that you
suggested, as well. I appreciate all the help.

-Zack-

Zack.

If you changed any AD object permisions on the OU where the TS is, be
sure users or
the appropriate group has at least read permissions to the OU itself and
try adding
an individual [tests user] to read/apply for the GPO for that OU for the
TS and for
read to the OU container in case there is a problem with group nesting.
The link
below may be helpful in more advance Group Policy troubleshooting. ---
Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;250842

Steven Umbach said:
No it should not matter as both are considered interactive logons but
what I was
suggesting was having test user logon to the TS from a network
workstation while
that account was in the TS OU to see if the policy still applies and
troubleshoot from there depending on the results. --- Steve


Zack Schiel said:
I have logged them on to that machine while their user account was in the
OU, and the policy applied successfully. Verified that loopback is
enabled for that GPO. Tried dozens of logons by now. :)

It shouldn't matter that the user is logging on via RDP rather than at the
console, correct?

Thanks,

-Zack- >> The lowly MCSA still getting comfortable with advanced Group
Policy. ;)




On Wed, 28 Apr 2004 00:32:11 GMT, Steven L Umbach

Try logging the test user on from a workstation where you are
experiencing problem
with the policy not applying via loopback. Have them logon with their
user account in
the OU and then not in the OU [you may have done all this already] after
doing a
refresh using secedit for machine and user to see what happens with
policy not being
applied. Just trying to verify that it is not a machine problem. Again
verify first
that loopback processing is enabled for that GPO that the TS server
resides in under
computer configuration/administrative templates/system/Group Policy. For
XP machines,
it may take a couple of logons for user policy to process. Running out
of ideas on
this end and can understand you being flummoxed. --- Steve

Thanks for the continued help!

Yes, read/apply are given to the correct users; moving a test user into
the OU and logging in as them does apply the policy. User config is
enabled. There is more than one GPO in this OU, however they modify
completely different settings, this is top priority, and none have 'no
override' or 'block policy inheritance' enabled.

-Zack-

On Tue, 27 Apr 2004 21:44:06 GMT, Steven L Umbach

The GPO that you created for the OU that the TS is in, does the proper
group have
read/apply permissions to the GPO in properties/security and is user
configuration
portion of that GPO enabled? If you put a test user into that OU and
then logon as
them, do they then get the desired settings and gpresult show the
policy
is applied
to them? Is there more than one GPO in the TS OU? --- Steve

The GPO is being applied to the computer (ie 'This computer received
settings from...'), but not to the user.

-Zack-

On Tue, 27 Apr 2004 20:11:02 GMT, Steven L Umbach

When you ran gpresult while logged onto that server, does it show
that
the GPO for
the OU has been applied to the TS computer successfully and
recently?
If
it has not,
what is the message if any? Running netdiag is always a good idea
when
you are
having problems looking for failed tests/errors/warning
particularly
relating to
domain membership, dns, and dclist. --- Steve


Hey all,

We're having a rather frustrating issue, and I'm not certain
whether
we're
just doing something incorrectly or there's a problem here.

We have a terminal server that we're trying to lock down via group
policy.
We have the server in its own OU, with a GPO applied to it. In
this
GPO,
we're applying user settings, to be applied to any user that logs
onto
the
machine via loopback processing mode. Except users aren't getting
the
policy at all--gpresult.exe doesn't even mention the policy for
the
user.
According to Microsoft here


(http://support.microsoft.com/default.aspx?scid=kb;en-us;260370&Product=win2000
- Method 2), I believe that we're doing it right. Any ideas? We've
tried
manually updating the server's GP via secedit /refreshpolicy,
tried
waiting out the full 90 minutes just in case, checked permissions,
the
whole nine yards. Nothing seems to work.

Server is Windows 2000 Server w/Citrix Metaframe, domain is
Windows
2000
native functional level.

Thanks for any ideas,

-Zack-
http://www.opera.com/m2/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top