Odd issue: Folder Redirection in Windows Domain works fine on some machines but not others

So I have two servers. Both are connecting to the same Domain Controller. Both are being logged in as the same Domain User. However, one will load my Folder Redirection policy correctly while the other will not.

In the Event Viewer for the server where it works, I get the typical “Successfully applied policy and redirectred folder <folder> to <path>.”

In the Event Viewer for the server where it doesn’t work, I get “Folder redirection policy application has been delayed until the next logon because the group policy logon optimization is in effect.”

In an even stranger twist, it doesn’t even work on the Domain Controller that is being used by both servers it works on, and servers it doesn’t. On the DC, I get this error: “Failed to apply policy and redirect folder <folder> to <path>.”

Same user. Same path. Same folder. Different server -> Different results.

So confused.

I just delt with the same thing at a customer’s location, but for the life of me I can’t find the Microsoft page that explains what happened. That being said, may not be the exact same problem…

Microsoft released an update that requires the computer to be added to the GPO security filter, as well as the user group. Customer had some computers with the update, and others that hadn’t received it yet. Added the computers to the GPO security filter, problem was solved.

Not sure what’s more annoying, the fact that Microsoft did this (at this point I don’t even care why), or the fact that I can’t find the solution page…

So I’ve noticed that the path to the folders isn’t being updated somehow?

For example, I once had a share called User Account Folders$. Now it is UAF$ for simplicity (the first one was for testing purposes). The event log for servers where it is failing has it trying to use the long version but still lists the short version as well?

Here’s an example:

Failed to apply policy and redirect folder “RoamingAppData” to “\server\uaf$\user\profile\AppData\Roaming”.
Redirection options=0x1001.
The following error occurred: “Failed to build the list of regular subfolders under “\server\User Account Folders$\user\AppData\Roaming””.
Error details: "The network name cannot be found.

I’ve checked, and I can’t find a GPO applying the old long version. All inherited GPOs either use the short version or don’t affect Folder Redirection.

If only there was a way to see what GPO pushed a specific setting on the client side. :confused:

“gpresult” will do what you want. Run it on the client under the target user (not as Admin): https://technet.microsoft.com/en-us/library/cc733160(v=ws.11).aspx
This is what I use:

gpresult /h c:\gpresult\gpresult.html

Also, try this on the server and the client first (as Admin):
gpupdate /force

1 Like

So, that lists the GPOs that were applied and those that were denied. Of the two being applied, one is using the short version (UAF$) while the other doesn’t involve Folder Redirection.

I get this:

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.
Computer Policy update has completed successfully.

Having restarted the machines, this hasn’t worked yet.

I want to point out this is happening on the Primary Domain Controller itself. We only have a PDC and a SDC and both the DCs do this.

So, AFAIK, it is both the server and the client?

Huh…I’m out of ideas at this point. Especially considering this:

Yup, in this situation it is both, which should make this less likely to have problems. I’m not in front of a Windows server at the moment; does yours have a seperate “Local Group Policy”? Could the long directory be stuck in there somewhere?

Might be time for someone with moar Windows Server chops to step in…

1 Like

DCs do not as that snap-in is disabled, and the only local policy I find is for security. Unfortunate.