I need help getting the computer side of GPO on Server 2008 R2 to work.

Are you sure the GPO's are being passed out to computers?

Have you tried to run a gpupdate /force from command line of one of the PC's and checking for errors? This will force the updating of GPO on the PC.

Also you can check the event viewer of the PC which should tell you if GPO's being applied and if not due to error will point you in the right direction.

I'm not entirely sure what you are asking, since the question is a little vague.  Perhaps you could provide a more concrete example of something you are trying to do?  Is it that you can manipulate icons (user-level targeting) but cannot change password complexity requirements (machine-level targeting)?

Remember that when you are changing user-level settings you apply the GPO to user accounts.  But, when you want to change machine-level policies, you have to target the actual COMPUTERS themselves, not the user accounts.  In other words, if you have an OU where your domain computers are located, then you should apply machine-level GPOs to that OU instead of the one with your users.

HTH, good luck!  Let me know if you need some more help.

" I have created an OU, created a new GPO, and linked it to the Domain Users and Computers"

Are your USERS and COMPUTERS both in this OU?

GPO's only apply to objects in the OU it is linked to. (Or inherited into)

I am just trying to get a policy to work. I changed 1 item from both sides Users and Computers so I could see if it was working.
I have run gpupdate /force which allows me to see the desktop change so I know the User side is working.

I have setup two OU's but they are both linked to the same policy. Do I need a policy for the Computers and a separate one for the Users?

No, you don't but I usually recommend having separate ones for each.  The reason is that I apply the user-level policies to my user OUs and then the machine-level policies to my computer OUs.

Now, I'm assuming you have put both users and computers into this test OU you have created and then linked one GPO to that OU to see if both types of policies apply?  Correct?  In this case, for troubleshooting, yes I would definitely separate your GPOs and apply them one at a time to check the errors occurring.

Please also note that some user policies override machine policies and vice-versa, so hopefully you are not testing the same policy on both levels and having them cancel each other out!  Yet another reason to separate the GPO for testing purposes.

OK I will give this a whirl.

Still no joy.

This is a test server and test workstation. The only roles installed are AD Domain Services, DNS, and File Services. I have 1 user installed. I have had the user in the user folder and in a OU folder. I would like to enforce password rules but no joy.

What is the priority of the new GPO you are adding?  Is it a higher or lower priority than your other policies, especially the default domain policy?  Remember that GPOs are applied in reverse numerical order so that that lowest number applies last and, thus, takes precedence.  

For example, if your GPO is called Password Policy and is linked as number 2 and the Default Domain Policy is linked as number 1 then the Default Domain Policy will overwrite your changes made in Password Policy.  Does that make sense?  I know it's a little counter-intuitive.  Maybe this is your issue?

On the server when a user is created the policy is enforced, but the workstation ignores these computer policies.

Maybe I am missing something in the setup. Yesterday morning I performed clean installs on the server 2008 r2 box and the win 7 box. I installed security on both. On the server I installed a graphics driver to allow better display. Then the roles, file server and active directory for domains were installed. The network adapter was set to static with the server pointing to itself for the dns. Dcpromo was run and a local domain was configured. During this dns was installed. After this a user was installed. I installed the user in ad. On win 7 the dns was set to point to the server. The workstation was changed to the local domain and the domain user and password were entered and the domain was joined. (A side note here, I read about domain users being setup and instructions say there are two sides the user and the computer. If I create the computer side the user will not join the domain. If I delete the computer in the ad the user will join. After the reboot and logon I have tried to create the computer side but I get a message saying it is already created.) I open gpmc and make one change to the user side  and one change to the computer side just so I can verify that it is working. The computer side never works. I have tried this with the default policy with no ou. I have tried this with an ou and one gpo joined to that ou. I have tried this with a user ou and a joined user gpo and a hardware ou with a hardware gpo. I always get the same ending.

Do you see anything in this that I am missing?

There is nothing wrong with your setup in terms of GPO processing that I can see.  I'm not sure what you mean by two sides to joining the domain, but that is really not relevant here.  If the user is created in AD and the computer appears in the AD then that's all that matters in this case.

May I ask what specific policies you are trying to apply?  Perhaps that will shed some light on the matter.  Please let me know the full path of the user policy and the computer policy you are trying to apply.  Also, please let me know where both the computer and the user are located in the AD (i.e. are they in the same OU, separate, at the root of the site, etc.) Thanks.

Don't worry... we'll get this sorted out!

Just thought of something else:  What security filtering are you using?  Authenticated users?  Try targeting the specific computer and see if that helps... it could be that the computer in question is not actually in the group being filtered.

Under users I am disabling desktop icons. This is a quick visual change that works on the server and workstation. In computer I have changed the password length to 13 characters. The rest of the password settings are also defined except the reverse encryption rule. Right now I have a "c" ou with its own gpo and a "u" ou with its own gpo. Both of these are directly below the domain in the tree.

Where in ad do the user and computer account need to be? Unfortunately I have been unable to find this info from MS and have had to rely on other info and some of the info is very contradictory.

The full path is
local domain, user ou, user gpo
local domain computer ou, computer gpo

But as I said earlier I have had it in previous attempts
local domain, default domain policy

Currently security filtering is set pointing to the user and the computer.

As long as the user is in the U OU and the computer in the C OU, you should be fine.  Please check my other comment regarding security filtering, we may have to check group memberships depending on what's in the security filtering box.  Also, what happens if you run gpupdate /target:computer /force from the client machine in question?

Currently security filtering is set pointing to the user and the computer.

I have been running gpupdate /force. I will try these other switches.

I will try and get back with you but it will be an hour and a half or so.

No problem, get yourself a coffee while you're at it too :-)

If you get a chance, please post the output from gpresult on the client computer (whatever filename you choose after the /h switch)
GPRESULT /scope computer /h filename.html

Running GPRESULT /scope computer /h filename.html gives

INFO: The user "mydomain\administrator" does not have RSOP data

Are you running gpresult from an elevated command prompt?  If so, are you elevating with an admin account that differs from the currently logged in user?

Yes and yes

That's the problem with gpresult then, it is accessing the elevated user's profile instead of the current user's profile.  

This happens when, for example, you log in a StandardUser1 and then elevate with LocalAdmin1's credentials but LocalAdmin1 has never actually  logged into the system before.  As such, there is no RSOP data for LocalAdmin1.

Can you run gpresult from an elevated command prompt as an existing user with actual administrator credentials?

I would suguest that you rollback and start from scratch..

1) In ADUC creat a new OU directly under your Domain Root call TEST-Computers
2) Move your Test Computer into this OU
3) Create a NEW GPO and set your COMPUTER elements of the Policy up in this. DO NOT CHANGE TARGETING
4) On your test computer do a GPUPDATE /force.
5) Reboot your test computer
6) Log in to test computer and then reboot again
7) log in to test computer and do a GPRESULT /h c:\filename.html

View results

When run at a normal prompt I get access is denied. Let me elevate this user and try again.

But you said that your USER policy is already working fine? If so I would stop worrying on elevating users and understand why your computer policy is not working.

Making that test user an administrator would work.  Or you could just enable and use the built-in administrator account since this is just a test machine.

@Neilsr he is receiving an error running gpresult that stems from a user profile error although we are only interested in the computer policies.  This has to be resolved to run gpresult properly.  Gpresult will not run at all if it cannot query the current user profile regardless of whether it is actually looking for user profile information vs. computer information.

He could simply log into the workstation as a domain admin. No need mess with the test user to be able to identify issues with computer policies. Changing a totaly unrelated item in testing is not the best way to progress.

I have the gpresult
newadmin.html

According to the result file, only the default domain policy is being applied.  Is this correct?  I thought you were trying to apply a separate policy as well?  Or did you just make all of your changes to the default domain policy itself?

asifbacchus - No, I have two other policies under two ou's the computer is enforced but the user is not. Neither is showing up.

Neilsr - You stated

3) Create a NEW GPO and set your COMPUTER elements of the Policy up in this. DO NOT CHANGE TARGETING

What do you mean by DO NOT CHANGE TARGETING?

security filtering. Dont "Target" anything, just leave it as authenticated users

What is the exact path to your COMPUTER OU ?

This may be a silly question, but are you sure you have linked the GPO to the correct OU containing your test computer?  Are you sure it isn't accidentally linked to a different OU?

Since this is a test environment and we're not too worried about sensitive data, is there any way you can provide a screenshot of your GPMC?  One showing the full tree, one of the OU in question showing it's links and then the summary screenshot of the GPO itself?

OK I assumed security filtering and continued. I have another gpresult. This one shows policies being denied because they are empty. At the bottom of the report the computer configuration shows "No data available." and the user configuration shows "No settings defined.". The user is correct because I removed the change after I had it working.
new4.html

I think something went wrong here... the computer configuration shouldn't show "No data available".  Try re-running the gpresult.  Even better, please try re-running it after rebooting the machine, if possible.  Thanks.

I did, the last one posted was after a reboot.

Here are a couple of screen shots. NEW GPO is of the changes in the GPO that show there is data there. GPMC shows where the policy is in the structure.

Your setup looks alright, I don't see any problems with it.  We will probably have to look at some permissions.  Before that though, let's try a few last-ditch things on the workstation.

1.   Clear-out (except for the default entry) the following registry keys on the workstation
                 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
                 HKEY_LOCAL_MACHINE_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
2.   Add the following registry keys
                 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
                 "GroupPolicyMinTransferRate"=dword:00000000

                 [HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
                 "GroupPolicyMinTransferRate"=dword:00000000

This is in case there is some kind of network error (as per MS tech-net suggestions).  If this doesn't work, we'll have to start looking at the permission entries to see if the error is there... which it really shouldn't be.

Before doing this I did as Neilsr suggested and logged into the wkstn as the domain admin. I got a different gpresult. It lists the password requirements but it did not require them. Here it isadmin.html

HKEY_LOCAL_MACHINE_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

I am assuming you meant HKLM. Under History there are a couple of keys with sub-keys under them. Am I cleaning out everything except default in History and the sub-keys?

Hold off on those registry changes, seems that your GPO is applying just fine based on the last gpresult.  The blank one you posted seems to have been run from a non-elevated command prompt.  The most recent one you posted shows the policy applied.  Go ahead and test it, as Neil suggested, and it should be working.

I created a new user, set the password, set the password to be changed at log on, and the policy was enforced. I set the password to expire in 2 days. I rolled the calendar forward on both computers, logged off and back on. I got a message that the password had expired. I changed the password and was granted access. So, when the users are setup and given a password that meets the requirements of the policy, they create a new password, when the policy dictates due to the password age the policy will be enforced. I never saw anything that even hinted that the policy as it stands would not be enforced on an existing password. I assume there are other tidbits of knowledge like that that would be helpful. Do you have a recommended primer on this?

Welcome to the world of Active Directory and Group Policies :D

This would normally be in the very first set of changes made when configuring a new domain. As it is done before ANY new users are created, nobody ever gives it a second thought, its just there and it works.
From now on, you'll know :D

I want to thank both of you for your help.

You are welcome.

Yup, it's a wild and wacky world that once you figure out the little quirks makes your life much easier.  My best advice is to read exactly what the policy description says it does and then assume it does absolutely no more and no less.  Also, learn to accept double-negatives in the policy descriptions.

Can't think of any primers off the top of my head.  My best advice for that would be to, again, read the descriptions and then google the policy since many people blog about their experiences setting a policy and then have it do something they didn't expect.  EE is also a great spot for asking questions and learning more!

Glad you got everything sorted out :-)