Never closing open file handlers RRS feed

  • Question

  • Hi,

    We have the following setup:

    Two RDS session hosts with NLB, one session broker, and one domain controller which also holds the user profiles and home folders. All servers are fully updated Windows Server 2012 R2 servers.

    The problem is that about once every week, a user is able to logon to the RDS servers but all their settings and documents on the desktop etc is gone.

    Looking on the domain controller containing the RDS roaming profiles under Computer Management - Shared Folders - Open Files, the user has hundreds of files open against their profile folder. Looking under sessions these can sometimes be a few days old. These open files prevents the user to synchronize the profile while doing the new logon again.

    Closing these open files and trying to logon again and the files appear on the desktop etc.

    This is happening against both RDS servers, with multiple users, and the files/folders that are open seems to be every single one in the users profile. I've monitored this behavior and seen that sometimes these open files seems to never close after the user logoff, even after multiple hours. I can't find an RDP session on any of the servers, but there still are a file session against them.

    Things I've tried:

    • The domain controller containing the profiles are newly installed.
    • Disabled antivirus on the file server.
    • Removing the user profile on the RDS servers to re-synchronize.

    I've out of ideas, and would love some input on what I could try next time it happens. Is it possible to see what process is locking these file somehow, on the file server och RDS server presumably locking these?

    Any ideas would be highly appreciated, even thou I cannot replicated the problem.

    The problem is also described in this thread, but without a solution. Some of them thinks these is isolated to using Windows Server 2012 R2 as file server:


    • Edited by snokjo Tuesday, April 5, 2016 8:49 AM
    Tuesday, April 5, 2016 8:44 AM

All replies

  • Hi snokjo,

    Thanks for your post.

    >Two RDS session hosts with NLB, one session broker

    As far as I know, if you have set session broker, you don't need to set with NLB, not sure if it related to the issue.

    I suggest you could confirm in Our RDS server.


    Usually, you could use process explorer to see if anything has the file open. download it here ->https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

     search for the name of the file, see if anything has an open handle on the file.  Close the handle and then a try.

    And  also you could follow Shaon's idea,  set logoff scripts to disconnect all access. But for that I'm afraid you may need to get support from our scripts forum.

    Best Regards,

    Mary Dong

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

    Wednesday, April 6, 2016 2:19 AM
  • I have thought about removing NLB and using only DNS round robin, just to be sure. Even though someone in the old thread mentioned before have tried this already without success.

    I will try using Process Explorer next time it happens, the process might give some clue to why this i happening.

    The workaround Shaon suggested does not work due to the logoff script breaks roaming totally. I have also tried the one suggested by a1ex8, by closing open file handlers on the file server at night. This does help if the user logoff during the day, locks the file and won't login again before next day. But as the customer is working both day and night, users is experiencing the problem even at daytime.

    Wednesday, April 6, 2016 12:13 PM
  • Hi snokjo,

    Any clue for using process explorer to narrow down the issue?

    Best Regards,

    Mary Dong

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

    Monday, April 25, 2016 9:08 AM