We are experiencing problems with our roaming profiles on our Windows 2008 domain. We re-directing users profiles to shares which are part of a DFS namespace across 3 sites. All Windows 2008 one site is R2. When some users logon their profiles are not copied to the server share. We note event id 1521 “Access Denied” source “Userenv”. Reproduced below: Event Type: Error Event Source: Userenv Event Category: None Event ID: 1521 Date: 23/06/2011 Time: 08:13:14 User: User Computer: computer Description: Windows cannot locate the server copy of your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you logoff. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator. DETAIL - Access is denied. On the R2 server we notice that a padlock is displayed on the affected users profile folder. We also note that when viewing the Sharing options for a user’s profile folder the option to ‘Share…’ is greyed out. However, it is available on other user’s folders that do not experience the problem NTFS Permissions: These have been set as per best practice as far as we can tell and are consistent across all 3 sites. The Shared folder containing the profiles has following NTFS permissions: SYSTEM – Full Control – This folder, subfolders and files <USER GROUP> - List folder / read data, Read attributes, Create folders / append data – This folder only CREATOR OWNER – Full Control – Subfolders and files only Administrators – Full Control – This folder, subfolders and files Share Permissions for profiles folders: Everyone – Full Control User profile folder when created: When the user profile folder is created permissions are as follows: SYSTEM – Full Control – This folder, subfolders and files <username> – Full Control – This folder, subfolders and files Administrators(<localservername>) – Full Control – This folder, subfolders and files Help! This issue seems to affect users who have logged onto our domain on our site that contains the R2 server, but we are at a complete loss as to the cause. The vast majority of users experience no problems. Your help is much appreciated. Thanks.

Hi, Can you access the namespace target with the \\computer name\sharefolder\username from a user session? You can try these the DFS path as well as the path on each server (the DFS target paths) to make sure all are accessible. This should test for permission or name resolution issue. Also, here is some steps for troubleshooting DFS you can try. How to troubleshoot Distributed File System Namespace access failures in Windows http://support.microsoft.com/kb/975440 The Case of the Random DFS Access Denial http://blogs.technet.com/b/askds/archive/2009/06/04/the-case-of-the-random-dfs-access-denial.aspx BrentPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Brent, Thanks for your quick response. Our GPOs prevent browsing the namespace. However, as newly created users profile folders are created with the correct permissions and users are able to access their home drives via the same namespace we presumed all was ok with sharing and NTFS permissions. Your second link, "The Case Of...", pointed me towards the solution. Although the sharing permissions on all servers managing the namespace were correctly applied, it made me re-check the security permissions. For some reason, (Who knows what?), Authenticated Users did not have an NTFS permissions to the namespace root folder on one of our servers (coincidently the R2 server). Obviously, this was preventing users from ultimately being pointed to the folder target successfully as access to the 'shortcut' was denied. Restoring the Authenticated Users permisions seems to have done the trick. Thanks for pointing me in the right direction, i.e. towards DFS. Regards, Martin