Undeletable Profiles Due to hsperfdata, in the Profiles / User Environment forum on BrianMadden.com

Hi All,

I have a small farm running w2k advanced server with SP4. Over the last several weeks, I have noticed that the profiles on the server are not being removed by our nightly cleanup process. I also cant delete these profiles manually. It seems that in the local settings\temp folder in each users profile, a folder with a random name is created which contains a folder in this format: hsperfdata_username. This hsperfdata folder only has NTFS rights for the user, the Administrators group has NO rights. Inside this folder is usally a single file with no extension, again with some seemingly random name. I can delete this file and folder if I take ownership and then modify the NTFS permissions of them manually. Also, rebooting the system doesnt free the profiles up to allow them to be deleted. From searching the web, it looks like it is related to Java in some way. At any rate, it is preventing me from removing users profiles and is a royal pain. I am using UPHClean by the way. Has anyone else seen this kind of behavior? If so, how can I fix this problem?

Thanks in Advance!

Go to the Documents and settings folder. Right click the user profile and choose properties. Go to security and advanced. Change the owner to administrator and replace on all sub containers. Apply OK. Add admin group to folder with full permissions. You can now delete. You can script this if you like using vbs.

Almost forgot...When adding admin group permissions check the box for applying to all child objects. Do however remove the check for inharet permissions.

Thanks for the info. Acutally, what I am looking for is not how to remove these entries as I have already taken the action you have suggested. Rather, I am looking for an explanation as to why these folders would be created in the first place and why the NTFS permissions would be messed up like this in the first place. Seems rather odd that this happened at all.

This seems to be a bug in some Java tool:

http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=6223888

Are you running the latest version of the java client?

As a workaround, you could add a line in your nightly cleanup script which modifies the ACL on the folder, adding the Administrator account to the ACL. Then you can delete the profile. Use the CACLS utility to edit file and folder permissions.

Hi thanks for the info. To be frank though, I dont really understand what that bug report is talking about. Java was never my strong point. I do see it mentions trying to access the hsperfdata folder in the wrong location. I wonder what the right location would be? We are running build 1.5.0_04-b05 for Java so I guess we are a little behind. I find it strange though that a bug reported way back in February is still an issue now. Is this something you have seen before?

We have recently started using IBM Host on Demand so that was why we have Java installed. Strangely, once I completed a manual clean up of these profiles by changing the ACL and Ownership, it hasnt yet re-appeared. Very wierd in my books.

if ruuning limewire close it then u will be able to delete it.

ORIGINAL: Guest

if ruuning limewire close it then u will be able to delete it.

If someone is running Limewire on their terminal server, they've got bigger issues than profiles not unloading. [image]http://www.brianmadden.com/forum/image/s2.gif[/image]

Shawn

Has anyone found a resolution to this problem? We too are experiencing the same issue.

I never actually found out what caused this in the first place, and definitely no, we arent running Lime Wire on a Terminal Server. What we had to do was go into each and every users profile on the server and manually take ownership of the offending folders within the profile, sometimes several layers deep, and then give ourselves NTFS rights, and then we were able to delete the profiles. What a major chore! On the plus side, the problem has not re-occurred and nothing was changed on the server to explain that. I really wish I knew what caused it because it was a real pain. Sorry I cant help you with any better solution than the manual one but thats what fixed it for us.

I copy this file to an other directory-- this works
After this i could delete him.

I don't know this for sure, but it looks to me like the hsperf directory is created in the temporary directory specified by the environment variable "TEMP" or maybe "TMP", which by default are under "user\Local Settings\Temp".

So if you change the environment variables to point to something like c:\temp, the hsperf directory should be written there instead. It will still have messed up permissions, so you can't easily delete it, but it won't be under the user profiles anymore so it shouldn't prevent you from deleting the user profiles.

Good luck!
-Kevin

I also have had this problem but didn't connect it with Limewire which I recently installed. I followed your advice and I have now deleted it from the Temp folder. Thanks Grinner.

This file has been making me crazy.

Here is what I found, individual results may vary...


It is created by JAVA. Perhaps you didn't install Java. I didn't but Intel Server Manager did and that's where the trouble started.

It does create this folder in the Profile settings of the user who installed it. (Documents and Settings/User/Local Settings/Temp)

You can (sometimes) go in and change the securities and delete it but it will be back again next time you log in.

I think it is related to the Web update that is set as default within Java. This can be turned off, Start/Settings/Control Panel/Java. Click the Update tab and de-select "check for updates automatically."

Then restart into safe mode, log in as admin, go to C:\Documents and Settings\*User*\Local Settings\Temp and delete the HSperf folder. I would check all user profiles that are in the Documents and Settings Folder for good measure. Reboot normally and see what happens.

Some of that is guess work as I am currently trying it myself.

Will update.

Same problem here: Same solution. Cause in our case (a school in Wiltshire) was Star Office - which installs Java and other gubbins. Swapped over to MS Office, and these (and other) issues have now gone. Pity, because the open source concept is great.