Weird Issues with AD GPOs


I am having sparatic problems with Active Directory, in particular the Group Policies. I have a couple of policies (folder redirection, drive mapping) that just will not get to the users/computers in question. If I do a Group Policy Modeling it says the computer applied the policies in question, but when I do a GPRESULT /R its not listed, not even in Denied section. I have other policies that map folders and drives and they are working no problem. Here is what I did to diagnose so far:

Checked security ACL on the affected users home folder locations, all good (tested manual mapping the folder and accessing it with the user credentials not issues)

Reapplied Permissions to the affected users in questions, no effect

Deleted and Recreated the Group Policies in question, no change

Checked Group Policy OU for security delegation issues, none found

Checked Event Log on Server/Workstations found these event:

The Group Policy Client Side Extension Folder Redirection was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.

On some computer accounts -----> The session setup from the computer HS-RM146-34 failed to authenticate. The name(s) of the account(s) referenced in the security database is HS-RM146-34$.  The following error occurred:
Access is denied.

I did find this on the the DCs :

]This is the replication status for the following directory partition on this directory server.
Directory partition:
This directory server has not received replication information from a number of directory servers within the configured latency interval.
Latency Interval (Hours):
Number of directory servers in all sites:
Number of directory servers in this site:
The latency interval can be modified with the following registry key.
Registry Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Replicator latency error interval (hours)
To identify the directory servers by name, use the dcdiag.exe tool.
You can also use the support tool repadmin.exe to display the replication latencies of the directory servers.   The command is "repadmin /showvector /latency <partition-dn>".

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 cleartext (non-SSL/TLS-encrypted) connection
This directory server is not currently configured to reject such binds.  The security of this directory server can be significantly enhanced by configuring the server to reject such binds.  For more details and information on how to make this configuration change to the server, please see
Summary information on the number of these binds received within the past 24 hours is below.
You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind.  To do so, please raise the setting for the "LDAP Interface Events" event logging category to level 2 or higher.
Number of simple binds performed without SSL/TLS: 0
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 3902

Following is the summary of warnings and errors encountered by File Replication Service while polling the Domain Controller for FRS replica set configuration information.
 The nTDSConnection object cn=986cb6b1-98dd-4e0f-a8f3-fcc735f37d7b,cn=ntds settings,cn=pr-dc01,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=prsdnj,dc=org is conflicting with cn=9a21485c-2617-48bc-9edc-627e9b92d57b,cn=ntds settings,cn=pr-dc01,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=prsdnj,dc=org. Using cn=986cb6b1-98dd-4e0f-a8f3-fcc735f37d7b,cn=ntds settings,cn=pr-dc01,cn=servers,cn=default-first-site-name,cn=sites,cn=configuration,dc=prsdnj,dc=org

Any help would be greatly appreciated!
Jonathan JonesNetwork AdministratorAsked:
Who is Participating?
Michael OrtegaConnect With a Mentor Sales & Systems EngineerCommented:
Ok, so the folder redirection policy is beeing seen by the client. This seems like a permission issue on the user share you're redirecting to. Can you verify permissions?

If the actual user folders were set up manually (manually is any process that wasn't the result of the actual GPO creating the folder) then the owner of the folders would not be set properly. The default configuration of the folder redirection setting is to "grant exclusive rights", so if the folders in question were created manually the owner would not be set to the user and the policy would fail to complete redirection...because grant exclusive rights would attempt to change ownership and it would fail doing that.

Couple things you can do:

1. You can remove all the user folders in the share and let the GPO create the folders for you, setting the exclusive rights to the user, or

2. You can remove the checkmark in the policy to grant exclusive rights, but you have to make sure that the users' in question have modify rights at least so they can create folders and redirect their data.

Michael OrtegaSales & Systems EngineerCommented:
Make sure the GPO is scoped for "Authenticated Users". If you don't want it to apply to all "authenticated users" go into delegation and set the "authenticated users" to not apply GPO. The rule is that "authenticated users must be a part of every GPO though.

In the past it hasn't mattered, but a recent client side update has turned this into an issue (recent, as in within the last couple months). Microsoft's response on it is that the "authenticated users" group, which default for any new policy, should not be removed, but should be managed in delegation if you don't want a particular policy to apply.

I guess they figured that everyone was applying policy by OU linking and not via security groups.

Jonathan JonesNetwork AdministratorAuthor Commented:

Thanks for the quick response!

I just checked the scope on the GPO's inquestion, they do have the Authenticated Users with READ on all the suspected OU's. Just delegated control of Authenticated users to the entire domain to be sure, with Read and Password change checked. I reran Group Policy Results and Modeling, what I am seeing is that the descending OU that contains the users gets and processes the GPO without issue, BUT the actual users are not getting it at all now. I am starting to think its a security permission on the AD forrest, its been passed down since 2003 with multiple Net Admins... Is there any Powerscript or way to reset the entire forest back to a default security state, and I could then just scope and the GPOs to security groups again?

BELOW is the error the users get now:

Folder Redirection did not complete policy processing because the user needs to log on again for the settings to be applied. Group Policy will attempt to apply the settings at the user's next logon.

Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 9/12/2016 8:48:05 AM and 9/12/2016 8:48:05 AM.
Jonathan JonesNetwork AdministratorAuthor Commented:
Awesome info! Thanks sooo much it was the Folder permissions, as soon as I reset them it worked
Michael OrtegaSales & Systems EngineerCommented:
Glad that worked for you.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.