2008R2 Remote Desktop Server Profile Problems

We have 4 Windows 2008 R2 servers set up with RDS (session host, license manager etc).
Two are physical servers, one is a virtual ESXi 5.5 that was migrated from a physical, and one is a Virtual ESXi 5.5 built from scratch).  All of them are having the same problems.

I can log in locally with a domain admin to the servers with no problems.  (note - domain admin account does not have a roaming profile)

Users have a "Remote Desktop Services User Profile" specified in their account: EX: "\\ct01\root\RProfiles\JFanguy"

When I log in with either an existing domain user or a new one all goes swimmingly and the TS roaming profile is created on the share and the login time is a matter of seconds. All the network drives are available.  User is able to interact with file shares on our FILE server with no problems.

First time the user Logs off the remote desktop server is fine.

However on any subsequent logoff the process hangs (sometimes for hours or until I physically power off the server) on the "Please wait for the User Profile Service" and when rebooted the event viewer show their profile wasn't fully synchronized.

The errors in event viewer are:

Some version of Event 1530:
Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.  

 3 user registry handles leaked from \Registry\User\S-1-5-21-2000478354-1801674531-725345543-2662:
Process 668 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-2000478354-1801674531-725345543-2662\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
Process 2372 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-2000478354-1801674531-725345543-2662\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
Process 1728 (\Device\HarddiskVolume1\Windows\System32\winlogon.exe) has opened key \REGISTRY\USER\S-1-5-21-2000478354-1801674531-725345543-2662\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers

about 1 minute later:
Event ID 6005 - The winlogon notification subscriber <Profiles> is taking long time to handle the notification event (Logoff).

Here is where it hangs on "Please Wait for the User profile Service"  - most of the time i have to physically power off the remote desktop server.

When it reboots, i see a bunch of these:

Event ID 1509 - Windows cannot copy file C:\Users\JFanguy\ntuser.dat to location \\ct01\root\RProfiles\jfanguy.V2\ntuser.dat. This error may be caused by network problems or insufficient security rights.

 DETAIL - The network path was not found.

Event ID 1509 -Windows cannot copy file C:\Users\JFanguy\ntuser.ini to location \\ct01\root\RProfiles\jfanguy.V2\ntuser.ini. This error may be caused by network problems or insufficient security rights.

 DETAIL - The specified network name is no longer available.

Event ID 1534 - There are too many profile copy errors. Refer to the previous events for details. Windows will not log any additional copy errors for this copy process.

Event ID 1504 - Windows Windows cannot update your roaming profile completely. Check previous events for more details.

Once logged in the user can access all the shares and indeed clicking on the link produced in Event ID 1509 takes you to the correct location. I'm pretty sure the permissions are correct on the share (the profile creates initially after all). We have Dfs in operation but even on a non Dfs share this occurs.

Logging off again hangs at the User Profile Service and then give a message about partially synchronizing before logging off.

If I delete all trace of the TS roaming profile locally and at the share then the process starts again with a good initial login and logoff and hangs on subsequent logoffs.

Anyone come across this behavior before? DNS seems ok as far as I can tell.
I worked 6 hours with Microsoft yesterday, all they did was work on "scoping" the case - no actual help.

Note: 3 weeks ago, we migrated our physical file server (which houses the roaming profiles) to ESXi 5.5 Virtual.
This is the only thing I can think of that all of our 4 remote desktop servers have in common.

all 5 servers (File and remote desktop servers) have these settings:

TCP Global Parameters
Receive-Side Scaling State                    : disabled
Chimney Offload State                          : disabled
NetDMA State                                         : enabled
Direct Cache Acess (DCA)                      : disabled
Receive Window Auto-Tuning Level    : disabled
Add-On Congestion Control Provider  : ctcp
ECN Capability                                          : disabled
RFC 1323 Timestamps                            : disabled

TCP Window Scaling heuristics Parameters
Window Scaling heuristics               : disabled
Qualifying Destination Threshold  : 3
Profile type unknown                       : normal
Profile type public                             : normal
Profile type private                           : normal
Profile type domain                          : normal

Any help appreciated
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Do they really own their roaming profile folders? because this sounds like a permissions problem.

In a roaming profile situation, the "normal" permission set most commonly used is:
Share permissions - Everyone:Full Control
NTFS permissions at the "root" folder are:
is either users or Authenticated Users:Read [This folder and files, sub-folders and files]
System:Full [This folder and files, sub-folders and files]
Administrators:F [This folder and files, sub-folders and files]
Creator Owner:Create Folder/Append Data [This folder only]
Creator Owner:Full [Sub-Folder and Files]

This allows them to create the roaming profile directories on the fly and they will own it.

If this is not allowable, then you can precreate the directories for your users (don't forget the .v2 at the end of the path!) and assign the permissions you want (but your users really need Modify at least) for their folders. Now, they will not own their folders, so you need to enable the Group Policy to tell the system not to check for ownership of the roaming profile directory.  (Or you can use takeown.exe to give them ownership)

BFanguyAuthor Commented:
thank you Carolon,  I have made the changes you suggest and will monitor for a couple of days.

I did make one mistake.. the User/Authenticated Users should be "This Folder only".. It's easy enough to strip it out after the fact.

In the root folder, just cacls . /e /t /r users (or authenticated users) and then cacls . /e /g "authenticated users":r or do it graphically.

10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

BFanguyAuthor Commented:
no matter how many times I try this will not stick:

Creator Owner:Create Folder/Append Data [This folder only]

i.e.  once I apply, it goes away.
BFanguyAuthor Commented:
can't I just add that permission to users?
BFanguyAuthor Commented:
I have followed these instructions but when a new user log's on and then off, it creates the folder and subfolders, but administrators have no permission to even open their folder.  "You have been denied permission to this access this folder".    I have to take ownership of the folder, push down the premissions and then change owner back to the user.

what am I doing wrong.
If the Creator Owner is not sticking, then something is wrong.. some other set of permissions is being inherited and pushing itself down, or some automated task is stripping them.

There is also a group policy to add Administrators to the profile directory permissions, which will automatically add the Administrators permission.  It is under “Computer Configuration|Policies|Administrative Templates|System|User Profiles”.  The name of it is Add the Administrators security group to roaming user profiles.  

What you should see is that your user's directories are owned by them, and their accounts have full control of their directories.  


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
BFanguyAuthor Commented:
we moved the roaming profile folders to 20012R2.  the administrator group contains domain admins, but in 2012R2 you don't get access to folders owned by someone else, so i had to set up a different local group and put domain admins in that group and add that group instead of Administrators.   2012R2 UAC is what was affecting this (even though I had it turned off)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.