How to resolve Roaming Profile 256k ntuser.dat Win2k3 domain with DFS
Posted on 2009-12-16
Hi, we have an ongoing problem on one of our clients networks that we have been unable to fully resolve. Any help in resolving the problem would be much appreciated.
Initially a single site running SBS 2003 with ten or so XP clients.
There were more users than PCs so roaming profiles were implemented to allow users to hot-desk. Over time two satellite offices were added. They each initially had a single PC that created a VPN connection to the office. Since then the number of users increased so additional PCs were rolled out at all three sites. The two satellite offices now have a Windows Server 2003 DC each and a site-to-site VPN back to the main office. There are various shares in DFS that store user data and profiles.
All clients and servers have Windows Desktop Search installed. Clients have Office 2007.
The user profiles point to \\domain.local\dfs\profiles\%USERNAME%\
My Docs, Desktop, App Folder redirected to \\domain.local\dfs\users\%USERNAME%\redirected folder name\
Caching disabled on Profile share(s).
The problem experienced is that when some users log on they get a blank profile no Start Menu icons, no email config etc. PC gets stuck logging off. Looking on the server(s) and on the PCs the users ntuser.dat is 256k (when it is normally 2-5Mb). More often than not on both the PCs and on the server there are (many) prf*.tmp files that are the same size as the ntuser.dat before the profile corruption. Error messages in the logs indicate the file was locked or in use. When the system works (which it does for most users, most of the time) the prf*.tmp gets automatically deleted when the ntuser.dat is copied to/from the server share.
To work around the problem we getting the users to get their PCs back to the Ctrl+Alt+Del screen and then restoring from Volume Shadow Copies or recent backups ntuser.dat, ntuser.ini and ntuser.dat.log and deleting any prf*.tmp files.
When possible we allow replication of the restored files to propagate before allowing the users to log on, however, this is not always possible. Some users log on at different sites more than once a day.
Steps we have taken thus far to troubleshoot the problem:
New Group Policy: domain custom search policy.
Prevent indexing of local folders and shares that contain user profiles.
Exclude from Symantec Antivirus 10 scanning of *.dat, profile and Application Data directories.