Documents Redirect via GPO

Associate
Joined
8 Jul 2004
Posts
1,818
Location
London
Hi all,

Yesterday I decided to move the users folder redirection to the new file server as the old one was filling up very quickly.

I changed the GPO so the files were copied to the local machine, then set up the NTFS Permission and Shares on the new server and changed the GPO setting to redirect.

Since the change, none of the users are able to access their files on the server.

Network structure is as below:

Code:
PDC-1 - Active Directory Domain Controller (Windows Server 2008)
FS-1 - New File Server (Windows Server 2008)
OFS-1 - Old File Server (Windows Server 2008)
USR-1 - Client PC 1 (Vista Business 64bit)
Code:
Share Info:

\\FS-1\Home\

Share Permissions:

Everyone - Full Control
SYSTEM - Full Control
Domain Admin - Full Control

NTFS Permissions:

    * Everyone - Create Folder/Append Data (This Folder Only)
    * Everyone - List Folder/Read Data (This Folder Only)
    * Everyone - Read Attributes (This Folder Only)
    * Everyone - Traverse Folder/Execute File (This Folder Only)
    * CREATOR OWNER - Full Control (Subfolders and Files Only)
    * System - Full Control (This Folder, Subfolders and Files)
    * Domain Admins - Full Control (This Folder, Subfolders and Files)
All the PC's are domain members and I can manually type in \\FS-1\Home and it connects with no problems after logging in.

The following error message shows up in Event Log:

Failed to apply policy and redirect folder "Documents" to "\\FS-1\Home\username\My Documents".
Redirection options=80009211.
The following error occurred: "Can not create folder "\\FS-1\Home\username\My Documents"".
Error details: "Access is denied.

Log Name: Application
Source: Folder Redirection
EventID: 502
Level: Error

Now that error message indicates its a permissions issue, I have deleted the share + folder, re-created it else where and set up as above but the problem persists.
 
Last edited:
Hi mate

Have you tried this for your re-direction?

\\SERVERNAME\SHARENAME\%USERNAME%
Policy set to create a user folder under the root.

for example I use \\PCT-FILER01\UserHome$\%username%

I assume you have also updated your AD Userhome field for the users concerned so its also maps under Explorer to the new location.

I would change your permissions to stay away from the everyone group as that is not good practice.

SHARE PERMISSIONS
Administrators FULL CONTROL
Domain Admins FULL CONTROL
System FULL CONTROL
CUSTOM USER Security Group - (FOR THE USERS) FULL CONTROL

NTFS PERMISSIONS
Administrators FULL CONTROL - THIS FOLDER, SUB FOLDERS & FILES
Creator Owner FULL CONTROL - SUBFOLDER & FILES ONLY
Domain Admins FULL CONTROL - THIS FOLDER, SUB FOLDERS & FILES
System FULL CONTROL - THIS FOLDER, SUB FOLDER & FILES
CUSTOM USER Security Group - (FOR THE USERS)
TRAVERSE FOLDER / EXECUTE FILE
LIST FOLDER / READ DATA
READ ATTRIBUTES
READ EXTENDED ATTRIBUTES
CREATE FOLDERS / APPEND DATA
READ PERMISSIONS
***Apply to this folder only***

That should work then, let me know how you get on mate? or if you need any more help!
Cheers
Baz
 
Last edited:
Hi Baz,

The GPO is already set up to auto create the necessary redirected folders when a user logs on. In this case it would be: \\FS-1\Home\%username%\Documents etc

I don't use the Everyone group under normal circumstances, I usually assign the correct user group from the OU but for the sake of troubleshooting, I kept the network layout and permissions as simple as possible.

I changed the permissions to match those in your post but the access denied error still rears its ugly head.

Made a interesting discovery last night, when I log into the client machine as a user, I am able to manually browse to \\FS-1\Home and create a folder there. However I am not able to rename the folder or any files.
 
I would use the EVERYONE GROUP THEN AND GIVE IT FULL JUST TO RULE OUT PERMISSIONS.

If that works at least you know its a permissions issue rather than a GPO.
Does seem a little odd, but without looking at it, not too sure.
I can have a browse using Teamviewer if you like to see what is going on?

Have you tried using GPresults wizards or RSOP.msc off the client? Any errors in the event logs at all?
 
Hey Baz,

Tried it with the Everyone group mate but still the same error.

Another funny thing I discovered, if I give the user group full NTFS permissions and full share permissions, they are able to read/write/change/create files/folders but not delete which seems odd when they have full permissions.

GP Results seems to be fine, nothing out of the ordinary there. I'm starting to think maybe the RAID array where they user files are going to be stored is fubered. It should work the way it is. I plan on re-formatting the FS-1 box tomorrow starting from scratch, it all just seems a bit fishy now.
 
So even if you create a folder outside of the GPO and root of the userhome and give the user full access and let them browse to it you still cant delete?

This server is on the same domain isnt it? and you arent working across domains using trusts?

presumably you have tried creating a new user from scratch outside the any of the OU's and just leaving them in default and then see if they can get in?
 
Hi Baz,

Thats right mate, even if the folder is not in the GPO as a redirect etc, the user is unable to delete any files/folders.

The server is on the same domain and within the same OU. I have tried a new user account "test", left everything in the default containers but the problem remains. I've even removed the FS-1 and Client machines from the domain and rejoined them.

I fired up a spare VMWare ESX box (after a tip from technet forums) and created a network near identical to the real one. It seems to work fine, the client is able to create the folder on the redirected network location, change names etc.

Like I said, accessing the folder is not a problem, neither is creating a folder, its just that will full permissions, users are unable to delete anything and with the "usual" permissions for the redirects, they are unable to rename anything.

Rebuilding the RAID array now on FS-1 :(
 
Last edited:
Aye I spent a good few hours last night using tcp viewer and a few of the sysinternals applications to see what was happening. Everything looked fine but the NTFS permissions were just not having it.

Event logs on the servers are clear other than to indicate a successful login attempt and successful connection from PDC-1 to FS-1 for the share. I used File Services Sessions on FS-1 to see current open connections on the share and I could see the client user was connected etc.

Ah well, one for the Windows Server mysteries now :P
 
Back
Top Bottom