Roaming profiles not deleting

[thebook]

Have TSE SP6 with Metaframe 1.8SP2. Authenticate to Novell with Client 4.81. Have profiles stored on file server with terminal server profile path defined but after the users logs off the profile remains on the Citrix box (local I guess) and does not copy back to the profile share on the file server. Used to work but now nothing. So users always get the "Your local profile is new than your....Download..etc".

Any ideas?

Thanks

 

[gray2002]

I have also been experiencing this problem in a windows-only environment. The profile locking doesn't occur for all users.

W2K + Metaframe XPe + Office 2K + IE 5.5 on the servers. Profiles are stored on W2K file servers.

I've been using Delprof.exe on a regular basis while I investigate. I have been able to reproduce this in a lab environment. I am removing pieces one by one in an effort to isolate the culprit. The solution cant be far.

Has anyone else experienced profile locking on W2K servers?

Gray

 

[Highland]

You should be able to do this if you are defining Policies for your servers....???? We have a Policy defined for each Server. Within the Policy there is an option set to delete cached copies of roaming profiles when each user logs off....

 

[gray2002]

Yes, we have defined policies on each server and the option is set to delete cached copies of roaming profiles when users log off.

The problem is: the profiles are still there after the user logs off. If you go into system properties and look at the list of user profiles, the profiles are shown to be in use - you cant delete them.

And yes, the idle time has expired and the user is no longer listed in the management console. As far as Citrix is concerned, the user has been logged off.

In our lab we have replicated the problem on a W2K box with Terminal Services and Office 2K installed (in other words: without Citrix installed). This leads me to believe that it is not a Citrix issue but a M$ issue instead.

I will continue to investigate and post any news. Any thoughts/comments are appreciated.

Thanks,

Gray

 

[Highland]

Could be temp folders...??? There's another option in the policy to delete temp folders....??? Sounds like the server thinks they still have a file open..?? Are you running anything in the logon scripts that isn't being closed properly...???...maybe from Office...???

 

[gray2002]

Yes, I believe the server still thinks that there are files open. It looks like the screen saver logon.scr is still running after the user is kicked.

Unfortunately, we'd like users to be able to be idle for more than fifteen minutes and we'd like the workstation to lock up with the logon.scr if they are idle for a while.

There may be a work-around but I'd rather find a fix.

Gray

 

[gray2002]

Well,

Microsoft finally admitted that it's a problem with their product. For weeks they were telling me it was the anti-virus or the backup software. Suddenly, they turn around and say: "Oh yeah. Here's an article that was never published on technet."

The profiles were locking because the screen saver wouldn't stop running after the user had been kicked for idle time.

Microsoft has provided a hotfix which we are testing. Initial tests successfully prevent profile locking.

For anyone interested, here is the article from M$:

SYMPTOMS
========

Calling ExitWindowsEx() may not completely log off the currently logged on user in a workstation locked state. This happens if the workstation is locked manually by a user and ExitWindowsEx() is called while a screen saver is also running on the system.

STATUS
======

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION
================

If the workstation is locked manually by the user and a screen saver is also set in the Control Panel (with or without password protected) ExitWindowsEx() may not completely log off the current logged on user. This can occur if ExitWindowsEx() is called either from an application launched by the logged on user or from an interactive service running under LocalSystem account.

ExitWindowsEx() closes the screen saver if it is running and shutdowns all the processes running in the security context of the logged on user. But it will not complete the logoff sequence and the workstation is in a state where the default application desktop will be active indefinitely. When this happens, WinLogon waits for a SAS (CTRL+ALT+DEL) to complete the logoff sequence. To complete the logoff operation in this state, the user needs to press CTRL+ALT+DEL and then cancel the Windows NT Security dialog box.

Calling ExitWindowsEx() in the following situations completely logs off the currently logged on user:

1. The workstation is not locked manually by the user irrespective of the screen saver setting.

2. The workstation is locked manually by the user and the screen saver is set to None.

3. The workstation is locked automatically by WinLogon after a lock grace period while a password protected screen saver is running.