none
Locked / Frozen RDP sessions?

    问题

  • I manage an environment of thin clients that connect to any one of 40 RDP servers depending on the load balancing.  In the past few months, I have seen 4-5 locked user sessions on in this environment.

    Explanation:  When a user logs into their thin client, the RDP session connects to a load balancing server, a license server, and a session broker....then connects to the lowest utilized terminal server.  On a handful of occasions, a users ID will get stuck on a server and they cannot log into the environment at all; the load balancer sees the ID on 1 specific server and tries to reconnect...but the session is hung.  The user can log into any of the other servers manually from a PC connection, but it does not load or write to their profile because it is locked on a different server.

    Using the terminal services manager, nothing I do to their ID will end the connection.  Disconnect, Log Off, and Reset do nothing....no errors, but they don't do anything to the session.  The only way we have found to kick the user off, is to reboot the server.  This has happened randomly, to random users, and on random servers. 

    I am looking for a possible reason why this is happening and a fix for it....I can't keep rebooting these servers to unlock one user.

    Thanks
    2010年1月30日 18:56

答案

  • IF, I understand your issue correctly it sounds like an issue that I had/have as well. The problem stems from user registry entries that get orphaned when Windows fails to clean up after itself when the user is dropped or disconnected.

    I only have 8 servers in my farm and it got old REALLY quick having to manually go and hunt down these issues. So I worte a script that searches for and deletes orphaned registry entries.

    Lets see if you have the same issue. Next time you get a user that can't load their profile or login, search each of the server registry's at:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\

    Ignore key entries like S-1-5-18 (also ignore the one ending in 500. This is the Administrator), these are system entries etc. Look at the longer entries. As you scroll through the entries on the left of the editor, you will see a sub key entry named ProfileImagePath on the right side of the registry editor. You should be able to find your users name there. When you find the correct user, look at the sub key (right side) named CentralProfile. Is this key blank or not there?

    If so, then you have found your culprit. You can delete that entire key entry and have the user try again to login.

    For example the key (to be deleted)

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-324928179-3145815797-3594970287-10188

    on my #5 server looks like this:  (exported so you could see the subkeys and data)

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-324928179-3145815797-3594970287-10188]
    "ProfileImagePath"=hex(2):43,00,3a,00,5c,00,55,00,73,00,65,00,72,00,73,00,5c,\
      00,74,00,38,00,36,00,35,00,38,00,34,00,38,00,6e,00,36,00,00,00
    "Flags"=dword:00000001
    "State"=dword:00000000
    "Sid"=hex:01,05,00,00,00,00,00,05,15,00,00,00,b3,02,5e,13,f5,56,81,bb,af,e4,46,\
      d6,cc,27,00,00
    "Guid"="{ebfc6e30-210a-4254-ad49-ed41ba53f1a4}"
    "ProfileLoadTimeLow"=dword:00000000
    "ProfileLoadTimeHigh"=dword:00000000
    "RefCount"=dword:00000000

    Notice there is no key named CentralProfile.

    The next time this user gets sent to server #5, they will not be able to log in. (I actually verified my script and it picked up this user on server #5.) The problem with orphans is that they only rear up when the user is redirected to a server that has an orphaned key for them.

    In my case if the user that has the key on server 5 is directed to server 1,2,3,4,6,7,8 fifty times before they come back to server 5, and until they do, we dont know it happens.

    Scripting this process is fairly easy and would be happy to share my script with the community. I cant imagine doing this manually for 40 servers. You would have to hire a full time trouble shooter.
    Let me know if this helps or if missed the issue with your post.

    Best regards,

    Bob

    2010年3月4日 21:29

全部回复

  • IF, I understand your issue correctly it sounds like an issue that I had/have as well. The problem stems from user registry entries that get orphaned when Windows fails to clean up after itself when the user is dropped or disconnected.

    I only have 8 servers in my farm and it got old REALLY quick having to manually go and hunt down these issues. So I worte a script that searches for and deletes orphaned registry entries.

    Lets see if you have the same issue. Next time you get a user that can't load their profile or login, search each of the server registry's at:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\

    Ignore key entries like S-1-5-18 (also ignore the one ending in 500. This is the Administrator), these are system entries etc. Look at the longer entries. As you scroll through the entries on the left of the editor, you will see a sub key entry named ProfileImagePath on the right side of the registry editor. You should be able to find your users name there. When you find the correct user, look at the sub key (right side) named CentralProfile. Is this key blank or not there?

    If so, then you have found your culprit. You can delete that entire key entry and have the user try again to login.

    For example the key (to be deleted)

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-324928179-3145815797-3594970287-10188

    on my #5 server looks like this:  (exported so you could see the subkeys and data)

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-324928179-3145815797-3594970287-10188]
    "ProfileImagePath"=hex(2):43,00,3a,00,5c,00,55,00,73,00,65,00,72,00,73,00,5c,\
      00,74,00,38,00,36,00,35,00,38,00,34,00,38,00,6e,00,36,00,00,00
    "Flags"=dword:00000001
    "State"=dword:00000000
    "Sid"=hex:01,05,00,00,00,00,00,05,15,00,00,00,b3,02,5e,13,f5,56,81,bb,af,e4,46,\
      d6,cc,27,00,00
    "Guid"="{ebfc6e30-210a-4254-ad49-ed41ba53f1a4}"
    "ProfileLoadTimeLow"=dword:00000000
    "ProfileLoadTimeHigh"=dword:00000000
    "RefCount"=dword:00000000

    Notice there is no key named CentralProfile.

    The next time this user gets sent to server #5, they will not be able to log in. (I actually verified my script and it picked up this user on server #5.) The problem with orphans is that they only rear up when the user is redirected to a server that has an orphaned key for them.

    In my case if the user that has the key on server 5 is directed to server 1,2,3,4,6,7,8 fifty times before they come back to server 5, and until they do, we dont know it happens.

    Scripting this process is fairly easy and would be happy to share my script with the community. I cant imagine doing this manually for 40 servers. You would have to hire a full time trouble shooter.
    Let me know if this helps or if missed the issue with your post.

    Best regards,

    Bob

    2010年3月4日 21:29
  •  

      Hello Bob,

         Do you still have this script and are you still willing to share it?

     

      TIA,

    John

    2010年8月19日 23:51
  • EXTREMELY late reply... but YES .. I do have the script and would be happy to share it.

    Bob

    '/On Error Resume Next

    '/ Define the five registry keys
    Const HKCR  = &H80000000 '/HKEY_CLASSES_ROOT
    Const HKCU  = &H80000001 '/HKEY_CURRENT_USER
    Const HKLM  = &H80000002 '/HKEY_LOCAL_MACHINE
    Const HKU = &H80000003 '/HKEY_USERS
    Const HKCC  = &H80000005 '/HKEY_CURRENT_CONFIG

    dim txt,arrName

    dim strTSsvr(9)

    strTSsvr(0) = "TS1-HUN-WSD"
    strTSsvr(1) = "TS2-HUN-WSD"
    strTSsvr(2) = "TS3-HUN-WSD"
    strTSsvr(3) = "TS4-HUN-WSD"
    strTSsvr(4) = "TS5-HUN-WSD"
    strTSsvr(5) = "TS6-HUN-WSD"
    strTSsvr(6) = "TS7-HUN-WSD"
    strTSsvr(7) = "TS8-HUN-WSD"
    strTSsvr(8) = "DIG-HUN-WSD"

    usrName = InputBox("Enter the User Name to search for:", "User Name")

    '/*** Traverse TS1 through TS8 to find the user entries
    For elemNum = 0 to 8

     remote_machine_name = strTSsvr(elemNum)
     Set objRegistry = GetObject("winmgmts:\\" & remote_machine_name & "\root\default:StdRegProv")
     strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
     objRegistry.EnumKey HKLM, strKeyPath, arrSubkeys
     
    '/ objSubkey is the users SID # in the registry - ID's individual users
     For Each objSubkey In arrSubkeys
    '/ extract the users name from the value found in the ProfileImagePath registry key
         strValueName = "ProfileImagePath"
         strSubPath = strKeyPath & "\" & objSubkey
         objRegistry.GetExpandedStringValue HKLM,strSubPath,strValueName,strValue

    '/Strip the USERNAME from the string
    '/ wscript.echo "string value " & strValue


         arrName = Split(strValue, "\")
         If usrName = arrName(2) then
    '/ There can be multiple occurances of the users regkey across the server farm. If a user reg entry is active
    '/ it will have the registry entry of CentralProfile (which points to the users profile location). This is the
    '/ active entry. If the CentralProfile registry entry does NOT exist, then that is the orphaned key and should
    '/ be deleted.

      strValueName = "CentralProfile"
             strSubPath = strKeyPath & "\" & objSubkey
      objRegistry.GetStringValue HKLM,strSubPath,strValueName,dwValue

      If IsNull(dwValue) Then
       DeleteSubkeys HKLM, strSubpath
       errMsg = "User Name " & arrName(2) & " was found on Server " & remote_machine_name & _
        " At Registry Path: " & strSubPath & ". The orphaned registry key has been deleted."
       wscript.echo errMsg
      Else
          Wscript.Echo "No orphaned registry keys found for User Name " & arrName(2)
      End If
         End If
     Next
    Next

    WScript.Echo "User Search Complete"


    '/ You cannot delete registry keys that have subkeys with script. This is a recursive call to drill down
    '/ to the bottom of the subkey list and start deleting the keys from the bottom up. It will finally pop
    '/ back up to primary registry key and delete it.

    Sub DeleteSubkeys(HKLM, strSubPath)
        objRegistry.EnumKey HKLM, strSubPath, arrSubkeys

        If IsArray(arrSubkeys) Then
            For Each strSubkey In arrSubkeys
                DeleteSubkeys HKLM, strSubPath & "\" & strSubkey
            Next
        End If

        objRegistry.DeleteKey HKLM, strSubPath
    End Sub

     

     

     

    2011年1月10日 20:46
  • Bob_Moodytx,

    Here is my environment: Four servers total. TS1 is the load-balancing, licensing, and session broker. TS2, TS3, TS4 are the servers the RDP users get connected to.

    I had the EXACT same issue as petergriffon.  I was so pleased to find this thread! However, when I went to look for the sub keys for the two users, they both had the Central Profile key. I proceeded to drain that terminal server and reboot it.  This of course booted them and everything was fine.  What I failed to do was to look at my other terminal servers for the missing sub key.  They were stuck on TS4. This is where I found them in TS Manager.  Could they have had a missing key in TS2 or TS3 that was causing the issue?

    Of course if this happens to me again, I will check all three TS servers for the sub key.  I really thought your proposal was going to solve my problem and then I found the darn CentralProfile key for them. lol.

    Have you ran across a solution that solves the problem if all servers have the Central Profile key?

    2012年8月8日 21:44