Roaming Profiles...delete cached copies....

[PreviousPoster]

I am in the process of incorporating roaming profiles in my organization for use with Thin Client devices and Virtual Machines. We have been using the roaming profiles for a small pilot group for about 6 months now. I am seeing an issue that has me stumped. The GP setting "Delete cached copies of roaming profiles" is enabled. This is so that the local copy is removed from the VM when they log off so that we don't end up eating away the already small hard drive space configured on the VM when multiple users have logged into the machine over time. My problem is this....sometimes is works and sometimes it works not so well. What I mean by that is that it does delete the local copy of the profile except the local settings folder. I know that the local settings folder does not roam by default and I understand that. The real stumper here is that when it doesn't delete the local settings folder is DOES delete all subfolders and files within that directory, so what I am left with is a local settings folder as the only thing in the user's profile and it has a 0 byte size. This, of course, causes problems for that particular user the next time he logs in. It creates a new profile folder such as <username>.<domainname> and appends 000, 001, 002 etc to any further logons after that. This has caused us issues with the user's ability to open things like Outlook, etc. Once I have the user log off and I manually delete the old copy of the profile(s) the problem goes away. To further complicate things I don't see this behavior on all of my VMs and I don't see it for all roaming users. Some don't have any issues. I have found a post on the internet about the possibility of an Outlook .pst file causing this but for one particular user that has been working with me on testing, he does not have a pst yet he sees this problem. And, just to reiterate, he doesn't always have a problem with the local settings folder being deleted. My environment is W2K3 servers and Windows XP desktops.

So there's my dilema for today. Any assistance I can get would be GREATLY appreciated.

[PreviousPoster]

Some additional information to add since yesterday's post that hopefully spurs some response to this thread. I noticed in troubleshooting this matter yesterday that some of the permissions are wacked up. I'll admit up front that what I am about to describe may be the consequence of another issue. Let me start by stating the obvious. The user logs on and has full control of his/her profile as well as being explicitly named in the security tab of the profile. In other words there is an entry for the particular user in the security tab list of users or groups. When the issue occurs that originated the post, the security membership on the remnants of the profile no longer have the user named in the security list and the permissions have changed. When working the following users/groups are listed; administrators, user, SYSTEM, all of which have full control. When it isn't working the users/groups listed are; administrators, everyone, power users, SYSTEM, users. The user who owns the profile is not listed. Administrators and SYSTEM have full control, everyone else has read & execute, list folder contents, and read. I don't know if this is the issue or the result of another issue that is causing this. ????????

[Hypocrisy]

uphclean is an awesome tool for that. there are two versions of it out there... 2.0 and the original 1.6... are you using that?

[PreviousPoster]

Yes we are using UPHClean and I believe it is version 1.6. It has been a while since I deployed that so I'm not sure. But anyway we were able to determine that it was a third party application that was causing the issue. In this case it was a set of tools that we deployed to the virtual machines that were used in conjunction with our connection broker. Removed the tools and all is well now. Thanks for your reply. Have a good one!!!