Magnus_CA Posted April 9, 2014 Posted April 9, 2014 (edited) Hi all, I have implemented Roaming Profiles for a few test users on Windows 7 PC's (Windows Server 2003) and everything is working well aside from one error I'm seeing at logoff ('Your roaming user profile was not completely synchronized. See the event log for details or contact your administrator.') The event log reveals event ID's 1504 and 1509. 1504 is flagging the fact that Windows cannot update the roaming profile completely. 1509 shows the following: 'Windows cannot copy file C:\Users\jtest\ntuser.pol to location \\server\Profiles$\jtest.V2\ntuser.pol. This error may be caused by network problems or insufficient security rights. DETAIL - Cannot create a file when that file already exists. Other observations: This issue occurs with all test users upon each logoff attempt except for the very first logoff, where there is no network share copy of ntuser.pol to get in the way. Prior to logoff, the network share copy of ntuser.pol has an older timestamp than the local copy. This is not a cause or symptom but it leads me to believe updating the network copy of the file at logoff is normal/required behavior. If I delete the network share copy of ntuser.pol prior to logoff the error does not occur. I don't suspect file permissions are the cause since I used the same user having difficulty logging off to delete the network share copy of the file. ntuser.dat has no problem overwriting itself upon logoff. I was able to repeat the problem with two windows 7 clients. Disabling A/V on the server has no effect. I've been all over the usual suspects (i.e. group policies affecting roaming profiles, file/folder permissions, installed every hotfix relating to roaming profiles and folder redirection, and googled every keyword) and came up empty. I confirmed offline caching for the profile share is disabled. Does anyone know what may be going on here? I'd greatly appreciate a point in the right direction. Thanks in advance. Edited April 9, 2014 by Magnus_CA
woreilly Posted April 9, 2014 Posted April 9, 2014 what if you delete the locally cached profile, then delete the profile from the server(s) and force it to re-create itself?
Magnus_CA Posted April 9, 2014 Author Posted April 9, 2014 No luck. It still won't overwrite the file. Thank you for the reply.
jaminben Posted March 26, 2015 Posted March 26, 2015 (edited) I've posted this here as it explains my issue exactly but I'm aware the OP is targeted at Win 7 / Server 2003. I'm having the same issue but with roaming Windows 8.1 profiles and Server 2008 R2. I've found that ntuser.pol read attribute is set to true and if I manually set it to false the error goes away until the next time the user logs in then the read attribute resets to true again... and I'm back to square one. I have thought about running a script to force the read attribute to false but I don't really want to go down that route. Anyone got any ideas? Edited March 26, 2015 by jaminben
Michael Posted March 26, 2015 Posted March 26, 2015 On your Profiles$ share, the permissions should be set to Everyone and System. If you're using/sharing the same roaming profile with all users or a group of users, you should rename the ntuser.dat file to ntuser.man, otherwise you'll get lots of roaming profile errors, as 10 users logging off at the same time are all trying write to ntuser.dat.
jaminben Posted March 26, 2015 Posted March 26, 2015 The share is set to everyone & system... each user has their own roaming profile so .dat should be fine and that updates correctly so I don't see why ntuser.pol isn't.
Michael Posted March 26, 2015 Posted March 26, 2015 I'd suggest making sure the Ownership on the whole Profiles$ share is set to Administrators. I can't think what else it could be.
jaminben Posted March 26, 2015 Posted March 26, 2015 The owner of the share is Admin... it's a bit strange as it only affects .v4 profiles. Thanks for the ideas
Magnus_CA Posted March 27, 2015 Author Posted March 27, 2015 Sorry to never have updated this with the silver bullet that took care of this but my issue was traced back to a windows hotfix I installed. After I uninstalled KB2918893 everything worked beautifully. Hope this helps!
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now