Link to home
Create AccountLog in
Avatar of SMRHBousfield
SMRHBousfieldFlag for United States of America

asked on

Logon/Logoff errors related to roaming profiles - source: Userenv, eventID: 1504 and 1509

I have a happy/healthy Windows 2003 terminal server farm that many users log into without problems. I use Roaming Profiles - the profiles live on a file server that is not a Terminal Server. Two users have a reoccuring problem when logging in or out (sometimes in, sometimes out). They get a message indicating that their profile can not copy down (or up) a particular file - usrclass.dat or usrclass.dat.log - because of network problems or insufficient security rights, and that the file is being used by another process. This is a very common problem described in many forums. Here is what I've tried/discovered:
- It's the System process that is using the file (Process Monitor).
- Rebooting the server solves the problem, but a few days later it returns.
- I have User Profile Hive Cleanup 1.6d (the latest, I belive) installed and working fine.
- I have tried other utilities like Unlocker, but they can't unlock the file.

Thanks
Avatar of mdennis4422
mdennis4422
Flag of United States of America image

Is the user the owner of the roaming profile.  I have had this happen when ownership of the roaming profile has been changed.   Also the user should have full control of the profile.  
Avatar of SMRHBousfield

ASKER

Thanks for the suggestions, but the affected users are already owners of both files, and already have "Full Control" rights selected on the individual files and the parent folders. I checked that this is correct on both the server that contains the userprofiles, and on the terminal server.
Avatar of pzozulka
pzozulka

I have a similar ticket opened that has not yet been solved. The only difference between our issues is that our users use their Roaming Profiles in house. They occasionally login through Terminal Server.

I noticed a possible pattern: The error message at Windows Startup occurs after the user used Terminal Server the previous night.

Our "Work Around" is to delete the cached profile saved to the local machine after the user logs out. Causing the user to download a fresh copy of the profile from the File Server at next log on.

However, I have not yet found a solution for this. I tried downloading the latest patches and service packs with no luck.
I like your work around, but am wondering - do you delete them manually or have an automated process? It doesn't seem like this is something you could do in a logout script, as the profile is in use while the logout script is running.

Thanks
No, unfortunately this is done manually. This error is so annoying. Please don't take this advice as a solution. It is only a painful work-around, although takes about 5 minutes, it is tedious.

Can't wait to find a solution to this.
Do you have the group policy setting for delete temporary folders upon exit enabled?

I don't have the group policy setting to delete temporary folders upon exit (or can't find it), but it must be set somewhere, as I don't see any temporary folders/files on the fileshare where the userprofiles are stored. I do have a GPO setting enabled that is titled "Delete cached copies of roaming profiles".

I would guess that the GPO "Delete cached copies of roaming profiles" would do essentially the same thing as the Delprof.exe and batch files in that link - delete profiles that remain on the server. The problem is that nothing can delete the files that are in use - usrclass.dat or usrclass.dat.log. I know the batch file will fail because I've tried those DOS commands manually without luck. I'll try DelProf.exe, but if the system process is holding a file open then I'm betting DelProf.exe will fail also. If it works I'll update this comment and give you the points.

Thanks for the suggestions.
Below is a snipit from technet that explains where the GPO setting is.  I use the delprof.bat and I have it set to run via the Job Scheduler on the server.  I run it in the mornings before my users come in and after I have rebooted the server using the CItix reboot schedule.  I hope that this helps.



To delete or retain temporary folders when exiting
" Using Group Policies (best practice)
 
" Using Terminal Services Configuration
 

Using Group Policies (best practice)
1.
 Open Group Policy.
 
2.
 In Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Temporary folders, double-click the Do not delete temp folder upon exit setting.
 
3.
 To retain users' temporary folders when a user logs off from a session, click Enabled. To delete users' temporary folders when a user logs off, click Disabled.
 
4.
 Click OK.

 
Sorry to report that after trying all of the very good suggestions above, I still have two files in a user's profile which can not be deleted. The user is not logged in.
- I verified that when the majority of our users log out of the server, their profile is removed.
- I was able to delete everything else in the affected user's profile - just not usrclass.dat and usrclass.dat.log.

The next thing I'm going to try (but it will need to wait until next Monday) is to downgrade McAfee from 8.5 to 8.0. We have a single server on 8.0 which <b>might</b> not be experiencing this same problem.
We have had many issues like this at our place and I am yet to find a solution to it, but is there anything in the Event Viewer or the Anti-Virus currently running that could have these 2 files locked?
In the event log - nope. I reboot the server and manually delete the user's profile. The user logs in and there are no problems - nothing recorded in the event logs on the terminal server or the server that holds the roaming profiles. The user works fine, and then when they log off they get the error.

I have two terminal servers, and each have a different version of McAfee VirusScan (8.0 and 8.5). There is nothing in the logs for those programs. I have disabled the service - no change. I have added execptions - no change.

Thanks for the ideas. What I'm doing now is rebooting the servers every night at 3:00 am and then manually deleting the profiles the next morning. I'll eventually do a script like pzozulka suggests above.
ASKER CERTIFIED SOLUTION
Avatar of pzozulka
pzozulka

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Well, thanks for the info, and I'll give you the points, but that is not good news for me. We have two Terminal Server farms - and they need to stay very separate. One of them uses the TS Roaming Profiles tab in AD Users and Computers (and those don't have problems!). The other farm can not use those profiles for reasons I won't bore you with. I am using a GPO and a loopback policy with that farm.

I guess that is what I get for trying to be fancy and complicated.