Access denied to Control Panel applets!

[Brad Pears]

I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's set up
and some policies are applied. However, nowhere do I have a policy set to
not allow access to control panel appletss for domain users of any OU -
EXCEPT for our terminal server users - who are in a separate OU altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at all, yet
when he tries to access a control panel applet (i.e. Printers and other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this Control
Panel Category has been made unavailable by your system administrator. To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU who are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on his
laptop. If I log on to his machine using the local administrator account, I
can access the control panel applets no probs... If he logs in locally to
his laptop, he can also access the control panel applets. I also checked the
local policies on his machine - saw nothing there that would prevent his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Steven L Umbach]

Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like domain
level user configuration Group Policy since it does not apply to. See if he
can run rsop.msc while logged onto his computer as a domain user to see what
GP settings it shows for his user account and what Group Policy is applying
the setting in question. If he can not run rsop.msc [I am not sure if it
will work for a regular user offhand] then logon as an administrator and run
the Resultant Set of Policy mmc snapin for his user account. --- Steve

 

[Brad Pears]

I was able to run RSOP when logged on as the user. It really didn't show
that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do anything...
It is definately a user policy causing the issue because I had him log into
our domain using another computer and he get's the same restrictions on that
other PC!! I also had another user log into the domain using his laptop and
that user had full rights - so that pretty much tells me it is a user policy
being applied somewhere...Incidentally, the user that logged onto his
machine is in the same OU as him!!!

This user does log onto our terminal servers from time to time and these
policy restrictions he is seeing are definately applied to the terminal
servers - as the terminal servers are in an OU of their own so that users
logging onto those machines can not play too much! I don'lt think this
is causing the issue though because a few of the other users in his OU also
log onto the term servers from time to time and none of those users have the
same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad

Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like
domain level user configuration Group Policy since it does not apply to.
See if he can run rsop.msc while logged onto his computer as a domain user
to see what GP settings it shows for his user account and what Group
Policy is applying the setting in question. If he can not run rsop.msc [I
am not sure if it will work for a regular user offhand] then logon as an
administrator and run the Resultant Set of Policy mmc snapin for his user
account. --- Steve

I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's set up
and some policies are applied. However, nowhere do I have a policy set to
not allow access to control panel appletss for domain users of any OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at all,
yet
when he tries to access a control panel applet (i.e. Printers and other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system administrator. To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU who
are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on his
laptop. If I log on to his machine using the local administrator account,
I
can access the control panel applets no probs... If he logs in locally
to
his laptop, he can also access the control panel applets. I also checked
the
local policies on his machine - saw nothing there that would prevent his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Steven L Umbach]

Weird. Try running gpresult on his computer for him as the user to see if it
reports his user account in the OU you expect and compare his gpresult for
user configuration to the other domain user that does not have the
restrictions including the applied Group Policy objects and group
membership. I don't think deleting his user profile will help because he is
seeing the same behavior on multiple computers which really seems to
indicate a GP is applying those restrictions to his user account . If
nothing apparent is found try moving his user account out of that OU
temporarily assuming it is not in the default user container and putting him
in the default user container. Below is an example of gpresult output for
user settings showing in this case that my user account is in the default
users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

I was able to run RSOP when logged on as the user. It really didn't show
that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do anything...
It is definately a user policy causing the issue because I had him log into
our domain using another computer and he get's the same restrictions on
that other PC!! I also had another user log into the domain using his
laptop and that user had full rights - so that pretty much tells me it is a
user policy being applied somewhere...Incidentally, the user that logged
onto his machine is in the same OU as him!!!

This user does log onto our terminal servers from time to time and these
policy restrictions he is seeing are definately applied to the terminal
servers - as the terminal servers are in an OU of their own so that users
logging onto those machines can not play too much! I don'lt think
this is causing the issue though because a few of the other users in his
OU also log onto the term servers from time to time and none of those
users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad

Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like
domain level user configuration Group Policy since it does not apply to.
See if he can run rsop.msc while logged onto his computer as a domain
user to see what GP settings it shows for his user account and what Group
Policy is applying the setting in question. If he can not run rsop.msc [I
am not sure if it will work for a regular user offhand] then logon as an
administrator and run the Resultant Set of Policy mmc snapin for his user
account. --- Steve

I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's set
up
and some policies are applied. However, nowhere do I have a policy set
to
not allow access to control panel appletss for domain users of any OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at all,
yet
when he tries to access a control panel applet (i.e. Printers and other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system administrator.
To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU who
are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on
his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in locally
to
his laptop, he can also access the control panel applets. I also checked
the
local policies on his machine - saw nothing there that would prevent his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Brad Pears]

Tried everything...

Moved him out of the OU he was in - I tried the default User OU and even
moved him into our administrators OU!!! gpresult reports exactly the
correct OU in each scenario but he still cannot run the control panel
applets.... i.e. nothiong changed! I moved him in and out of a few other
GPO's - making sure to refresh and running gpresult to see which OU it said
he was in. Each time I ran gpresult, it reported the correct OU but did not
change his access... This is strange. I think the only thing left to try is
to delete his profile and then recreate it to see what happens... There
must be a huge f_ck up in active directory group policy - wherever it stores
this crap...

PS... I compared his gpresult with another user in the same OU (logged onto
the same machine) - exactly the same!!!! Yet that user has the appropriate
rights!!!

Another microsoft funny??

Thanks, Brad

Weird. Try running gpresult on his computer for him as the user to see if
it reports his user account in the OU you expect and compare his gpresult
for user configuration to the other domain user that does not have the
restrictions including the applied Group Policy objects and group
membership. I don't think deleting his user profile will help because he
is seeing the same behavior on multiple computers which really seems to
indicate a GP is applying those restrictions to his user account . If
nothing apparent is found try moving his user account out of that OU
temporarily assuming it is not in the default user container and putting
him in the default user container. Below is an example of gpresult output
for user settings showing in this case that my user account is in the
default users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

I was able to run RSOP when logged on as the user. It really didn't show
that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do
anything... It is definately a user policy causing the issue because I had
him log into our domain using another computer and he get's the same
restrictions on that other PC!! I also had another user log into the
domain using his laptop and that user had full rights - so that pretty
much tells me it is a user policy being applied somewhere...Incidentally,
the user that logged onto his machine is in the same OU as him!!!

This user does log onto our terminal servers from time to time and these
policy restrictions he is seeing are definately applied to the terminal
servers - as the terminal servers are in an OU of their own so that users
logging onto those machines can not play too much! I don'lt think
this is causing the issue though because a few of the other users in his
OU also log onto the term servers from time to time and none of those
users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad

Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like
domain level user configuration Group Policy since it does not apply to.
See if he can run rsop.msc while logged onto his computer as a domain
user to see what GP settings it shows for his user account and what
Group Policy is applying the setting in question. If he can not run
rsop.msc [I am not sure if it will work for a regular user offhand] then
logon as an administrator and run the Resultant Set of Policy mmc snapin
for his user account. --- Steve


I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's set
up
and some policies are applied. However, nowhere do I have a policy set
to
not allow access to control panel appletss for domain users of any OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at
all, yet
when he tries to access a control panel applet (i.e. Printers and other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system administrator.
To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU who
are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on
his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in locally
to
his laptop, he can also access the control panel applets. I also
checked the
local policies on his machine - saw nothing there that would prevent
his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Steven L Umbach]

That is bizarre. Also verify that this user does not have any logon scripts
assigned to him in his user account properties that could be applying
restrictions that way such as a batch file that contains a .reg file. I
assume that gpresult showed exactly the same Group Polices applied to all
the users you compared. You could also try running gpresult /z to get
verbose output to compare to a couple users but you would want to pipe the
output to a text file using >c:\gpresult.txt after the command or using
whatever filename/path you want. There is a way that you probably could
track it down if it is Group Policy related but it is not real user friendly
and that is to enable debug logging of userenv.log on his computer and then
having him do a gpresult /force while he is logged on and then going through
the userenv.log to see if you can find that registry entry in question and
the Group Policy applying it. I also suggest you post in the
Microsoft.public.Windows.group_policy newsgoup explaining all that you have
done so far. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833

Tried everything...

Moved him out of the OU he was in - I tried the default User OU and even
moved him into our administrators OU!!! gpresult reports exactly the
correct OU in each scenario but he still cannot run the control panel
applets.... i.e. nothiong changed! I moved him in and out of a few other
GPO's - making sure to refresh and running gpresult to see which OU it
said he was in. Each time I ran gpresult, it reported the correct OU but
did not change his access... This is strange. I think the only thing left
to try is to delete his profile and then recreate it to see what
happens... There must be a huge f_ck up in active directory group
policy - wherever it stores this crap...

PS... I compared his gpresult with another user in the same OU (logged
onto the same machine) - exactly the same!!!! Yet that user has the
appropriate rights!!!

Another microsoft funny??

Thanks, Brad

Weird. Try running gpresult on his computer for him as the user to see if
it reports his user account in the OU you expect and compare his gpresult
for user configuration to the other domain user that does not have the
restrictions including the applied Group Policy objects and group
membership. I don't think deleting his user profile will help because he
is seeing the same behavior on multiple computers which really seems to
indicate a GP is applying those restrictions to his user account . If
nothing apparent is found try moving his user account out of that OU
temporarily assuming it is not in the default user container and putting
him in the default user container. Below is an example of gpresult
output for user settings showing in this case that my user account is in
the default users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

I was able to run RSOP when logged on as the user. It really didn't show
that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do
anything... It is definately a user policy causing the issue because I
had him log into our domain using another computer and he get's the same
restrictions on that other PC!! I also had another user log into the
domain using his laptop and that user had full rights - so that pretty
much tells me it is a user policy being applied somewhere...Incidentally,
the user that logged onto his machine is in the same OU as him!!!

This user does log onto our terminal servers from time to time and these
policy restrictions he is seeing are definately applied to the terminal
servers - as the terminal servers are in an OU of their own so that
users logging onto those machines can not play too much! I don'lt
think this is causing the issue though because a few of the other users
in his OU also log onto the term servers from time to time and none of
those users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad
Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like
domain level user configuration Group Policy since it does not apply
to. See if he can run rsop.msc while logged onto his computer as a
domain user to see what GP settings it shows for his user account and
what Group Policy is applying the setting in question. If he can not
run rsop.msc [I am not sure if it will work for a regular user offhand]
then logon as an administrator and run the Resultant Set of Policy mmc
snapin for his user account. --- Steve


I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's set
up
and some policies are applied. However, nowhere do I have a policy set
to
not allow access to control panel appletss for domain users of any
OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at
all, yet
when he tries to access a control panel applet (i.e. Printers and
other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system administrator.
To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU
who are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on
his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in
locally to
his laptop, he can also access the control panel applets. I also
checked the
local policies on his machine - saw nothing there that would prevent
his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Brad Pears]

Thanks Steve... I will try the debug logging of userenv.log to see if I can
find anything... Also, I assume you meant I should use "gpupdate/force" as
opposed to gpresult/force once logging is turned on - on his machine?

Brad

That is bizarre. Also verify that this user does not have any logon
scripts assigned to him in his user account properties that could be
applying restrictions that way such as a batch file that contains a .reg
file. I assume that gpresult showed exactly the same Group Polices applied
to all the users you compared. You could also try running gpresult /z to
get verbose output to compare to a couple users but you would want to pipe
the output to a text file using >c:\gpresult.txt after the command or
using whatever filename/path you want. There is a way that you probably
could track it down if it is Group Policy related but it is not real user
friendly and that is to enable debug logging of userenv.log on his
computer and then having him do a gpresult /force while he is logged on
and then going through the userenv.log to see if you can find that
registry entry in question and the Group Policy applying it. I also
suggest you post in the Microsoft.public.Windows.group_policy newsgoup
explaining all that you have done so far. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833

Tried everything...

Moved him out of the OU he was in - I tried the default User OU and even
moved him into our administrators OU!!! gpresult reports exactly the
correct OU in each scenario but he still cannot run the control panel
applets.... i.e. nothiong changed! I moved him in and out of a few
other GPO's - making sure to refresh and running gpresult to see which OU
it said he was in. Each time I ran gpresult, it reported the correct OU
but did not change his access... This is strange. I think the only thing
left to try is to delete his profile and then recreate it to see what
happens... There must be a huge f_ck up in active directory group
policy - wherever it stores this crap...

PS... I compared his gpresult with another user in the same OU (logged
onto the same machine) - exactly the same!!!! Yet that user has the
appropriate rights!!!

Another microsoft funny??

Thanks, Brad

Weird. Try running gpresult on his computer for him as the user to see
if it reports his user account in the OU you expect and compare his
gpresult for user configuration to the other domain user that does not
have the restrictions including the applied Group Policy objects and
group membership. I don't think deleting his user profile will help
because he is seeing the same behavior on multiple computers which
really seems to indicate a GP is applying those restrictions to his user
account . If nothing apparent is found try moving his user account out
of that OU temporarily assuming it is not in the default user container
and putting him in the default user container. Below is an example of
gpresult output for user settings showing in this case that my user
account is in the default users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

I was able to run RSOP when logged on as the user. It really didn't show
that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do
anything... It is definately a user policy causing the issue because I
had him log into our domain using another computer and he get's the same
restrictions on that other PC!! I also had another user log into the
domain using his laptop and that user had full rights - so that pretty
much tells me it is a user policy being applied
somewhere...Incidentally, the user that logged onto his machine is in
the same OU as him!!!

This user does log onto our terminal servers from time to time and
these policy restrictions he is seeing are definately applied to the
terminal servers - as the terminal servers are in an OU of their own so
that users logging onto those machines can not play too much! I
don'lt think this is causing the issue though because a few of the
other users in his OU also log onto the term servers from time to time
and none of those users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad
Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and user
account are in the containers you expect. It definitely sounds like
domain level user configuration Group Policy since it does not apply
to. See if he can run rsop.msc while logged onto his computer as a
domain user to see what GP settings it shows for his user account and
what Group Policy is applying the setting in question. If he can not
run rsop.msc [I am not sure if it will work for a regular user
offhand] then logon as an administrator and run the Resultant Set of
Policy mmc snapin for his user account. --- Steve


I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's
set up
and some policies are applied. However, nowhere do I have a policy
set to
not allow access to control panel appletss for domain users of any
OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at
all, yet
when he tries to access a control panel applet (i.e. Printers and
other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system
administrator. To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU
who are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator" on
his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in
locally to
his laptop, he can also access the control panel applets. I also
checked the
local policies on his machine - saw nothing there that would prevent
his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad

 

[Steven L Umbach]

Yep you are right, use gpupdate /force. That will make sure that all Group
Policy settings are applied again so that they will show up in the
userenv.log. Otherwise Group Policy settings are not applied unless the
computer detects that a change has been made in a GPO. Then in particular
examine log entries that include SetRegistryValue:for under each
User\registry.pol line and there should be one for each GPO. That is where
you should find the registry setting for the user assuming it is applied by
Group Policy administrative templates. You will need to be logged on as his
user account though you may need to logon as an administrator when done to
view userenv.log or temporarily give his user account read permissions to
userenv.log. The userenv.log entries are timestamped so that you can make
sure you are looking at entries that would apply to his user account based
on the time logged on and running gpupdate /force. --- Steve

Thanks Steve... I will try the debug logging of userenv.log to see if I
can find anything... Also, I assume you meant I should use
"gpupdate/force" as opposed to gpresult/force once logging is turned on -
on his machine?

Brad

That is bizarre. Also verify that this user does not have any logon
scripts assigned to him in his user account properties that could be
applying restrictions that way such as a batch file that contains a .reg
file. I assume that gpresult showed exactly the same Group Polices
applied to all the users you compared. You could also try running
gpresult /z to get verbose output to compare to a couple users but you
would want to pipe the output to a text file using >c:\gpresult.txt
after the command or using whatever filename/path you want. There is a
way that you probably could track it down if it is Group Policy related
but it is not real user friendly and that is to enable debug logging of
userenv.log on his computer and then having him do a gpresult /force
while he is logged on and then going through the userenv.log to see if
you can find that registry entry in question and the Group Policy
applying it. I also suggest you post in the
Microsoft.public.Windows.group_policy newsgoup explaining all that you
have done so far. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833

Tried everything...

Moved him out of the OU he was in - I tried the default User OU and even
moved him into our administrators OU!!! gpresult reports exactly the
correct OU in each scenario but he still cannot run the control panel
applets.... i.e. nothiong changed! I moved him in and out of a few
other GPO's - making sure to refresh and running gpresult to see which
OU it said he was in. Each time I ran gpresult, it reported the correct
OU but did not change his access... This is strange. I think the only
thing left to try is to delete his profile and then recreate it to see
what happens... There must be a huge f_ck up in active directory group
policy - wherever it stores this crap...

PS... I compared his gpresult with another user in the same OU (logged
onto the same machine) - exactly the same!!!! Yet that user has the
appropriate rights!!!

Another microsoft funny??

Thanks, Brad


Weird. Try running gpresult on his computer for him as the user to see
if it reports his user account in the OU you expect and compare his
gpresult for user configuration to the other domain user that does not
have the restrictions including the applied Group Policy objects and
group membership. I don't think deleting his user profile will help
because he is seeing the same behavior on multiple computers which
really seems to indicate a GP is applying those restrictions to his
user account . If nothing apparent is found try moving his user account
out of that OU temporarily assuming it is not in the default user
container and putting him in the default user container. Below is an
example of gpresult output for user settings showing in this case that
my user account is in the default users container.--- Steve


USER SETTINGS
--------------
CN=steve,CN=Users,DC=umbach3,DC=com
Last time Group Policy was applied: 6/9/2006 at 12:28:05 PM
Group Policy was applied from: server1-2003.umbach3.com
Group Policy slow link threshold: 500 kbps
Domain Name: UMBACH3
Domain Type: Windows 2000

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Local Group Policy

The user is a part of the following security groups
---------------------------------------------------
Domain Users
Everyone
CERTSVC_DCOM_ACCESS
BUILTIN\Administrators
BUILTIN\Users
BUILTIN\Pre-Windows 2000 Compatible Access
REMOTE INTERACTIVE LOGON
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
This Organization
LOCAL
Domain Admins
CERTSVC_DCOM_ACCESS

I was able to run RSOP when logged on as the user. It really didn't
show that much - nothing for the control panel etc... I even tried a
gpupdate/force when logged on as this user - but that didn;t do
anything... It is definately a user policy causing the issue because I
had him log into our domain using another computer and he get's the
same restrictions on that other PC!! I also had another user log into
the domain using his laptop and that user had full rights - so that
pretty much tells me it is a user policy being applied
somewhere...Incidentally, the user that logged onto his machine is in
the same OU as him!!!

This user does log onto our terminal servers from time to time and
these policy restrictions he is seeing are definately applied to the
terminal servers - as the terminal servers are in an OU of their own
so that users logging onto those machines can not play too much!
I don'lt think this is causing the issue though because a few of the
other users in his OU also log onto the term servers from time to time
and none of those users have the same issue he does...

Maybe I should just delete his profile and re-create it to see if that
works... I cannot think of anywhere else to check.

What do you think?

Brad
Try having another domain user logon to his computer to see if they
experience the same behavior or not. Verify that his computer and
user account are in the containers you expect. It definitely sounds
like domain level user configuration Group Policy since it does not
apply to. See if he can run rsop.msc while logged onto his computer
as a domain user to see what GP settings it shows for his user
account and what Group Policy is applying the setting in question. If
he can not run rsop.msc [I am not sure if it will work for a regular
user offhand] then logon as an administrator and run the Resultant
Set of Policy mmc snapin for his user account. --- Steve


I have a strange issue going on here...

We have a Windows 2000 SBS domain in our company. I have some OU's
set up
and some policies are applied. However, nowhere do I have a policy
set to
not allow access to control panel appletss for domain users of any
OU -
EXCEPT for our terminal server users - who are in a separate OU
altogether.

I have one user on a new XP Pro SP2 laptop who is NOT in this OU at
all, yet
when he tries to access a control panel applet (i.e. Printers and
other
hardware) he gets the following message...

"These Control Panel options are not available. The content of this
Control
Panel Category has been made unavailable by your system
administrator. To
make changes on this area, contact your system administrator."

This user is logged onto the domain, and other users in the same OU
who are
also logged into the domain, have full access to their control panel
applets. His domain account is also listed as local "adminstrator"
on his
laptop. If I log on to his machine using the local administrator
account, I
can access the control panel applets no probs... If he logs in
locally to
his laptop, he can also access the control panel applets. I also
checked the
local policies on his machine - saw nothing there that would prevent
his
domain account access to the applets...

Any ideas on how to maybe rectify this issue?

Help!

Thanks, Brad