Computer based group policies not applying in Windows 10

Settings that are the same should work, but to be on the safe side use a Server 2012 R2 server with the Group Policy Management Feature enabled for Group Policy management, or use a Windows 10 machine with the Remote Desktop Administration Tools deployed (RSAT)
From either of those machine's access the Group Policies you are looking at, and ensure that:

1] Windows 10 machines have been moved to an OU targeted by the policies.
2] The policies scope target has been set to include the Windows 10 machines (Some people lock it down to specific computer names)
3] The Domain Controllers are properly replicating the policies.

You could perhaps create 2 new test OU's for 1, The WIndows 10 target computer, and 2, a Windows 10 Test user account, disable policy inheritance on both, manually link the default domain policy and user policies to the user OU, then manually link the default domain policy to the computer OU.

I will go a bit more into detail on a suggested GPO for example, you might be very well aware of this all, but other readers might not be. Hence I abbreviate and detail :)

When done create perhaps a new power plan at Computer level, target the WIn10 test OU, and enforce the plan via Computer Configuration, Policies, Admin Templates, System, Power Policy, Specify a custom active power plan such as for example High Performance


Once that is set go through whatever else under power management you might wish to enforce.
Another thing is that you could just set the before mentioned option, and then under computer, preferences, control panel, power options, create a Windows 7 power plan to update existing power plans with your desired settings. Lets say you don't like Hybrid sleep? Then lets turn it off, and use F6 on that selection to highlight it in green and activate it.


Once that has been done ok out of the policy windows, and either wait 15+ minutes, or manually replicate the changes between your DC's and test.

Besides this, there is not that much which I can think of right now that could prevent the workstations from being unable to inherit the policies. If you have any more information perhaps on an example GPO that you are applying, I might be able to get a better understanding regarding whether it should work or not.

First off, I do not have any server 2012 machines on my domain.

So, it appears only certain computer policies aren't applying - but the ones that aren't applying are fairly standard.. for example I have a policy that adds an Active Directory group to the Local Administrators group on domain computers...  that is not applying.  I tried What you suggested, created a new OU, and made a brand new policy, specifically a GP Preference for power, set to high performance and that is not applying either.  There is nothing in the scope that would prevent the GPO from applying either.

No worries on the 2012 R2. Merely mentioned it that if you had one, and did not wish to use a Windows 10 machine with RSAT tools, then that would be an option,

On the Windows 10 machine, in the event logs, does it report any warnings or denied GPO's EventID's which might shed light on the issue?

Also had a quick look. Found this article which touches the same as I wrote, but might be worth a read for additional suggestions. However I think you likely covered these area's, but no harm double checking.

Can you also see which domain controller the PC is obtaining its GPO's from? (From elevated CMD type echo %LOGONSERVER% and press enter) it might pay to check if that server is reporting errors in its logs as well.

Maclean, thanks for the help so far, I appreciate your time.

I was able to verify that the GPOs are actually being applied.  The reason they appeared as if they weren't being applied is that some of the polices that I thought were linked, were not actually linked.

Also, another reason I went on assuming they werent being applied is the fact that I am unable to view RSoP data for computer settings on clients running windows 10.

If I do gpresult /R no computer settings are displayed, only user.  This is what made me think no computer settings were coming over.

So I went a step further and did gpresult /R /scope computer and I get access denied.  If I run as a the domain administrator it works, but not as my regular domain account.  The regular domain account has local admin access, so I am puzzled why I do not see computer RSoP info - especially because it works for windows 7 computers.

Not technically the solution, but it is - I was overlooking something and taking another look helped me realize what was wrong.

Because my solution was the correct solution.