Your first screenshot shows the GPO under the OU TerminalServerLockdown - it should be under AR_Users_groups.
1 Like
that’s it??? 
To apply user settings the GPO needs to be assigned linked to users 
Admittedly this was a hard thing to wrap my head around back in the day, too.
Once you have it applied, log in as a user who it should apply to and run gpresult /h out.htm, expand all (top right black text), and then just search for the GPO’s name “TerminalServerLockdownn”.
1 Like
Ok should I just create a new “Folder Redirection” policy and link it to AR_Users_Groups?
Sure if that’s what you need - just use the delegation tab to limit the scope. If you want it to apply to everyone in that OU, just leave the delegate as default then.
There’s a balance between having too many GPOs and too big of GPOs - but is only really an issue when you have over 5,000 users / computers and a crap ton of policy to push.
1 Like
It’s been awhile since I’ve dealt with GPO’s but I believe there is a Hierarchy as to which GPO take precedence. I don’t think I’ve read where someone has checked a user’s workstation to see if the newly created GPO has been applied and if it has precedence over other GPO’s. There’s a command you can use to create an HTML document of what is currently being enforced on a workstation or user account on that workstation. I think it’s gpresult /r with some switch options to create the HTML.
Y-ASK
The benefit of having a nested OU is that regardless of the settings you may have in the scope, you are less prone to accidentally apply it to objects you didn’t intend. I think your method is a good way for seasoned admins though.
do a gpresult /h filename.html, and search it for “Folder Redirection” - see if it’s being denied or if it is applying but maybe a setting is wrong.
The other side of that coin is GPO inheritance and can quickly start getting conflicting policies. Then you have to start managing the GPO processing order and having some OUs block inheritance… which then if you need to apply a policy to “all” OUs you either enforce it or go into each OU and add it. In a very small environment this works, but when possible you want to setup environments to scale in case of growth. That way future admins aren’t pulling their hair out in 5 years lol.
Using OUs to manage / apply policy gets really wild after many years. Learning to use delegation / ad security groups is a quick method to pickup. Once it “clicks” it just becomes second nature.
You do ultimately end up with a S_ ton of ad groups, and if you start going down the RBAC hole they become super nested. However it’s so much easier to chase down groups than go into every single OU checking permissions. Where I work now, I still find where users were directly added to the security settings on some objects / OUs / shares.
So I see you logged in as administrator, which is not likely in the AR_users OU, but most likely under built-In. Please use one of the user accounts under the AR_Users_Groups to test with.
Or move your normal non-admin account into that OU, and log in with that.
