Problems with my domain admin account. Access denied when triyng to modify workstations settings.

Hello and Good Morning:

Recently I installed Windows Server 2003 Standard Edition SP2 and Trend Micro Anti-virus on a Power Edge 650. His  primary role is Domain Controler and File Server. My next step was to add the selected workstations to the domain. Some of this workstations which had Windows XP Pro SP3 and Windows XP Pro SP2 installed are presenting group policy problems, where a domain admin account like mine can't make any changes, like manually configure IP settings to the workstation NIC or add/remove a printer. Is like having a Domain/Admin account with only  Domain/User privileges.

Please help me find a solution to this problem. I'm seeking professional help from you guys.

Thank You.
Who is Participating?
AmericomConnect With a Mentor Commented:
Are these machines in question joined the domain yet? Or is it already joined the domain but after applying GPO then you lose admin rights? need a bit clarification if possible.
Mike KlineConnect With a Mentor Commented:
You should run an RSoP report (using GPMC) to see if any "lockdown" policies are applying to admin accounts.  Admin accounts can be affected by GPOs just like any other account.
If you find that there are unwanted policies applying you can use security filtering so the policies don't apply to the admin accounts.  More on security filtering here:
alamowConnect With a Mentor Commented:
Do you have multiple OUs or all the computer accounts end up in the Computers container?  I have seen this problem when administrators have multiple OUs and give rights to certain personnel for their respective OU.  When the GPO is applied those people are not allowed full rights on their workstations after adding them to the domain because the computer accounts is created automatically in the Computers container, for which they have not been given full rights.  To resolve it without changing the GPO just move the computer account to the container created to store those accounts on the respective OU.  Example:  Workstation1 account is on Computers container - move Workstation1 to the Desktops container inside the HQ OU "HQ\Desktops"
The other solution is to manually create the account and give rights to the admin group or user for the respective OU.

Not sure if this is your case, but hope it helps.
AmericomConnect With a Mentor Commented:
The problem is that admin cannot make changes to a machine such as configuring the TCP/IP settings or add/remove printers. This has nothing to do with computer object being on the default computer container as GPO do not appy to there. It is more like there may be GPO prevent or deny access to all users or to specifict security group which the admin account is a member of the linked to the OU where the computer object is in, as Mike suggested above.
alamowConnect With a Mentor Commented:
Tha is exactly why I told him to check the location of the Object.  If the GPO prevents (deny) someone from doing that on a machine, it could be because the computer account object in AD is not in the OU where the user does has rights to manage it.

Like I said, I do not know if this is his case (multiple OU with different admins for each one and GPO controlling those access rights).  If is not the case, then all computer account objects are located in a single place for all admins to manage them.  Then the GPO is the problem as, like Americom and Mike said, your admin group is being affected by the GPO.  The GPO is being applied to your admin group.
All Courses

From novice to tech pro — start learning today.