none
User Profile Disk cannot delete cached profile eventid 1533 svchost.exe RRS feed

  • Question

  • I have a RDS farm consisting of several Server 2012 R2 session hosts. I'm utilizing user profile disks and folder redirection.

    The problem is as follows:

    When a user logs off a session on one of the RDS session hosts, an eventID 1530 is logged, followed by an eventID 1533. The user's locally cached profile remains on C:\User of the session host with only the links to the folders that are specified in the user profile disk configuration (everything checked in "store only the following folders on the user profile disk").

    Running process monitor (on the RDS session host) after the user has logged off the session host shows that svshost.exe still had open handles to the top level folders in the user's temporary profile:

    So, the result of this behavior is that the next time the user connects to that RDS session host, a new local profile directory is created "c:\users\username.000", "c:\users\username.001", etc.

    This is quite problematic because we are utilizing Google's G-Suite Outlook Sync connector and it would appear that at least some of the configuration for that points to hard-coded paths starting with "c:\users\username\", so if the cached profile is mounted in another folder, like "c:\users\username.000" Outlook cannot load the G-Suite profile.

    I don't understand what is causing these handles to remain open after the user logs out of the session. The handles that remain open include:

    c:\users\username\Appdata\Local

    c:\users\username\Appdata\Roaming

    c:\users\username\Desktop

    c:\users\username\Documents

    The only way to actually delete the local cached profile folder is to either force these handles closed (via process explorer) or reboot the RDS session host server, after which the locked folder can be deleted.

    Has anybody else encountered this behaviour? It makes the setup with user profile disks unusable.

    Tuesday, November 5, 2019 6:23 PM

All replies

  • Hi,

     

    There is a similar bug occurred recently that Users that logon to RDP environments that have deployed and configured User Profile Disk (UDP) to "only the selected folders" receive a temporary profile after installing latest microsoft updates.

     

    To confirm further, could you please help to check the patches you've installed recently?

     

    If we confirmed this was exactly the same bug, please expect the fix being targeted around middle of 2019 November.

     

    Thanks and looking forward to your reply.

     

    Best Regards,

    Jenny


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Wednesday, November 6, 2019 6:05 AM
  • Same situation here

    The same situation on two customer RDS Server 2012 R2 RDS Serverfarms!
    Bug must be in Windows-Updates in October 19 (including Optional Preview Updates/Rollups).

    Locally cached Profiles are not removed entirely. E.G. Links to special folders persist.
    GPO set for Special Folder redirection and "Delete locally cached profiles"

    Please fix soon! Educational environment with 5000 reps 1400 users.
    (Now Profile mess up in RDS c:\users Directory).

    Thanks, Bruno


    • Edited by brupo Friday, November 8, 2019 2:58 PM
    Friday, November 8, 2019 2:56 PM
  • Hi Bruno,

    Thanks for your details. Please keep an eye on the Patch update for server 2012 R2.

    I will also keep you posted here if any update received.

    Thanks,

    Jenny


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 12, 2019 1:52 AM
  • Hi Jenny,

    I confirm problem exist also in our environment. It seems its related to setting "Delete cached copies of roaming profiles" and roaming profiles. Cached profile are created each time user log in and are not removed. We also noticed  svchost.exe does not release handles after user log out so next time new local profile is created. The solution was to uninstall KB4520012. Waiting for update or hotfix from MS to resolve this issue.





    • Edited by john_doe_23 Tuesday, November 12, 2019 8:46 AM
    Tuesday, November 12, 2019 7:41 AM
  • Hi Jenny,

    There is, since Windows updates from October, the same problem on a 2008 R2 RDS Server (i know, it will die in January '20...). Only means for releasing locked user profile folders is reboot of the server.

    Regards, Hansueli

    Tuesday, November 12, 2019 9:58 AM
  • Dear Forum,

    I have faced the same issue after updating Windows Server (W2K12R2) in October, somewhere around the 22th. Though yesterday Microsoft released an update (KB4525243) that should fix the problem.

    You do not have to delete the previous update (KB4520012) for the new roll-up to fix the problem. If you did remove KB4520012 previously, this should not cause any problems, just install KB4525243. Do note that the update requires a restart of the server. Also, all profile folders will still be present on the server, but have been release due to the restart of the server. All unnecessary profile folders can now be removed (manually or automated).

    I hope this will have someone.

    With kind regards,

    Bob Lauteslager


    Wednesday, November 13, 2019 11:40 AM
  • Hello,

    it's not working for me. I installed the KB4525243 on 13 Nov. But i still got the problem.

    I got roaming profiles and some users (not all and not everytime) get their c:\users not deleted after logoff.

    Yesterday at 17:31 in app event log

    "Windows cannot delete the profile directory C:\Users\<username>. This error may be caused by files in this directory being used by another program.

    DETAIL - The directory is not empty."

    And when i open the C:\users i can see that it's always the same file remaining

    \c$\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\counters.dat



    • Edited by jUMPOFF Thursday, November 28, 2019 9:29 AM
    Thursday, November 28, 2019 9:28 AM