none
GPO for User Redirected Folders works only on Domain Controllers

    Question

  • Okay, I'm going to do my best to describe this bizarre situation. I've used GPOs to redirect user accounts for years, both by specific users and by security groups. We updated an existing redirection GPO sometime back in the mid of 2015, all went well until about a month or two ago when we started noticing that some user's were not redirected even though they were added to the same security group we've been using for almost a year now. Upon further investigation, we found that quite a few users had undergone a move back to local storage an event log entries that stated the the GPO was removed and folders were successfully redirected back locally.

    This "redirect back to local" was part of the GPOs design but the GPO was NOT removed. We have found that now, for some reason, every user login to any computer on the network that should be scoped to this GPO no longer see's it and thinks it was removed and, as such, moves the contents back.

    The weird things is that the GPO DOES work if you log into any of the Domain Controllers but not workstations or member servers. I've ran RSOP tests from GPMC and from command line on numerous servers and workstations in attempts to find a pattern and cannot for the last three weeks. .

    What I know:

    • GPO's scope has not changed and yet, when RSOP is ran from anything other than a DC, it does not show that the GPO even exists (not denied or filtered, just nothing at all). RSOP does show the user to be a member of the RedirectedFolders user group.
    • When running RSOP from a DC, all looks like it should and folders properly are redirected.
    • NO eventlog errors about GPOs or folder redirection . .  its just as if there was NO GPO at all
    • All other GPOs properly update and replicate and work. I've tested both computer policy and user policy changes and they are all being applied as normal.
    • A second Redirected Folders GPO was created in like of the first. It does not work either and took almost 48hrs to replicate the SysVol ACL's to the member DCs. Other GPO changes replicated in minutes.
    • All diagnostics on DFSR show propagation is working properly
    • All dcdiag shows perfect
    • Everything I've tested shows to be in proper working order . ...Except this one GPO type of Folder Redirections.

    What really bothers me is the lack of any logging as if there just is no GPO to log an error for applying it. . .I've double checked the scope of management too and it is the same as always: GPO applied top level OU (custom OU of course, not system) with all sub OU's accounting for groups of users and computers by department level.

    Any ideas?

    Tuesday, July 26, 2016 5:22 PM

Answers

All replies

  • Am 26.07.2016 um 19:22 schrieb ClintJohnHall:
    > Okay, I'm going to do my best to describe this bizarre situation.
     
    Your Problem is: MS16-072
     
    DoaminControlers are functional, because they always have "read"
    permissions on the GPO.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    • Marked as answer by ClintJohnHall Tuesday, July 26, 2016 7:20 PM
    Tuesday, July 26, 2016 6:29 PM
  • Okay, so applying the update patch for the specific server (2012r2) that are my DC's is to correct this?

    I've also noted many errors such as this:

    During the previous 24 hour period, some clients attempted to perform LDAP binds that were either:
    (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or
    (2) A LDAP simple bind that was performed on a clear text (non-SSL/TLS-encrypted) connection

    Is this related? Why do the rest of my GPOs work fine, just not the redirected folders?

    Tuesday, July 26, 2016 6:36 PM
  • or better yet, REMOVE this update? I see I have it installed in early June which would coincide closely with when I was able to track back to closely when this started happening.
    Tuesday, July 26, 2016 6:40 PM
  • or even better yet, read more about it .... seems adding the computer account now may be necessary. This is using a custom security group, not Authenticated Users which included authenticated computers before like most of my other GPOs. . .

    Sound right?

    Tuesday, July 26, 2016 6:47 PM
  • Here is a nice explanation of the issue:

    To fix the issue, you need to give the computer accounts Read access to the GPOs. If you're using security filtering, when you removed authenticated users, it removed Read and Apply permission.

    Quick fix is to give Authenticated Users Read permission to the GPOs. Because they don't have apply permission it won't change your security filtering results.

    MS script to add Authenticated Users with Read permission to GPOs:


    Byron Wright (http://byronwright.blogspot.ca)

    Tuesday, July 26, 2016 6:58 PM
  • This has proven to be the case here. I have temporarily added a few computer accounts to the security group and the GPO is now working for users who log in on them; however, this is not as easy as just adding authenticated users to the GPO for us. We were using the security group as a method of filtering who had redirected folders and who did not.

    Current plan is to put the authenticated users group back on and apply the GPO on a per OU basis instead of across the entire "All Local Departments" OU as our domain has multiple OU's for various departments in different states.

    Bottom line though, THANK YOU all for showing me the update causing this issue, the rest is now a logistics issue :)

    Tuesday, July 26, 2016 7:24 PM
  • Ah, wait, I see the difference now between scoping of a GPO and permissions to a GPO. All I need to do is add authenticated users to the permissions of user security group scoped GPOs. ..
    Tuesday, July 26, 2016 7:28 PM