Re: Access denied to Control Panel applets!

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


"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:ea$6jALjGHA.1552@xxxxxxxxxxxxxxxxxxxxxxx
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


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8vednZ_QSreQWRTZnZ2dnUVZ_tSdnZ2d@xxxxxxxxxxxxxx
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

"Brad Pears" <donotreply@xxxxxxxxxxx> wrote in message
news:emvVSc9iGHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
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
"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8sSdnRdnlIkxxRXZnZ2dneKdnZydnZ2d@xxxxxxxxxxxxxx
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" <donotreply@xxxxxxxxxxx> wrote in message
news:uXC8FPxiGHA.2220@xxxxxxxxxxxxxxxxxxxxxxx
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













.

Relevant Pages

  • Re: Access denied to Control Panel applets!
    ... indicate a GP is applying those restrictions to his user account. ... Group Policy was applied from: ... that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • RE: Restrict logon hours
    ... Change Logon Times for a User Account ... Edit the user account properties by using the net user command. ... Enforce Logon Time Restrictions Using Group Policy ...
    (microsoft.public.win2000.group_policy)
  • RE: Group policy not applied
    ... If you logon this workstation with another regular user, does the GPO ... click to check the "Hide All Microsoft Services" ... problematic user account in the same OU with the good user account. ... | Thread-Topic: Group policy not applied ...
    (microsoft.public.windows.server.sbs)
  • Re: Access denied to Control Panel applets!
    ... GPO's - making sure to refresh and running gpresult to see which OU it said ... must be a huge f_ck up in active directory group policy - wherever it stores ... indicate a GP is applying those restrictions to his user account. ... that much - nothing for the control panel etc... ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Stop users from Downloading...
    ... You can not really stop users from downloading files on the Internet short ... This is also a Group Policy thing. ... Removing the domain user account object from the computer's local ...
    (microsoft.public.win2000.active_directory)