none
Win 7 client waits a long time at "initializing remote connection" when connecting to RDS Collection through Connection Broker

    Question

  • I have fully patched windows 7 clients with the RDP 8.0 client (Shell Version 6.2.9200) that take over a minute to connect to an RDS session host through a connection broker.

    All servers are 2012 R2.

    On the RDS Session Host it eventually gets connected to I get this warning

    ID 20499
    Remote Desktop Services has taken too long to load the user configuration from server \\myserver for user myuser


    edit:

    My windows 8.1 machine running RDP 8.1 in the same environment connects with no delay. That session connection also gets the warning ID 20499 so that seems to be another issue


    • Edited by seqteq Tuesday, November 05, 2013 2:04 AM
    Monday, November 04, 2013 6:41 PM

Answers

  • edit: ***I set NIC in VM to 100 full duplex, issue resolved***

    I am sorry, it appears VMware has sent me on a wild goose chase.

    I had been testing from my win 8.1 laptop and win 7 VMs in VMware workstation 10. I finally tested from some "real" clients and do not experience the issue.

    So thank you for your help.

    Lenovo w530 -- win 8.1 -- no issue

    VMware ws10 -- Win 7 no SP, RDP 7.0 -- presents issue

    VMware ws10 -- Win 7 SP1, RDP 8.0 -- presents issue

    Lenovo t500 -- win 7 no SP RDP 7.0 -- no issue

    Lenovo t500 -- WIn 7 SP1 RDP 8.0 -- no issue

    HP DX2400 -- Win 7 SP1 RDP 8.0 -- no issue

    Len Thinkcenter 72 -- WIn 7 SP1 RDP 8.0 -- no issue


    Saturday, November 09, 2013 2:27 PM

All replies

  • is this internal/external, are there roaming profiles, is GPO processing taking a long time?

    you have to look for more event logs to get a better idea of what's going on

    Monday, November 04, 2013 7:46 PM
  • this would be an external/off domain machine accessing over vpn tunnel. No GPOs are applied to the user or computer (client or host) in this environment.

    profiles are stored on user profile disks, which get created and accessed OK.

    My windows 8.1 machine running RDP 8.1 in the same environment connects with no delay.

    no other events in ServerManager>RDS seem significant



    • Edited by seqteq Tuesday, November 05, 2013 1:59 AM
    Tuesday, November 05, 2013 1:49 AM
  • Hi,

    Did you check with other user account, does it gives same issue?

    May be the issue caused by some network related. For that you can set the Auto tuning level. For this refer this link which will help to provide you more guide. You can try some command on client system (Quoted from Link).


    Run a command prompt (cmd.exe) as an Administrator

    Disable the autotunning feature
    netsh interface tcp set global autotuninglevel=disabled


    If you want to re-enable it:
    netsh interface tcp set global autotuninglevel=normal


    In some cases you may need to use this command in addition to the above, but I didn't have to:
    netsh interface tcp set global rss=disabled


    Run this command for faster Network
    netsh interface tcp set global autotuninglevel=highlyrestricted


    For more troubleshooting related to network issue, you can refer to “HSN for Windows Server 2012”. Also you can refer “Troubleshooting Slow Logons”.

    Hope it helps!
    Thanks.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Tuesday, November 05, 2013 9:53 AM
    Moderator
  • are the UPDs stored locally on the RDSH or are they hosted over the network on another server?  how big is this user's profile compared to yours which seems to be copying/loading faster, maybe he has a bloated profile.

    is he doing any redirection that you're not doing, Printers for example?

    i also recommend you check the event logs for user profile service and winlogon, i think you can also enable more verbose debug logging for user logons

    Tuesday, November 05, 2013 3:31 PM
  • Thank you very much for all the replies,

    The UPDs are stored on a separate file server. The UPDs are newly created accounts and contain nothing but what is generated automatically so they are as small as they can get and the file server has no other load.

    I have all client drives/printer redirection disabled in my RDS Collection properties.

    This hesitation happens for all 3 of my test user accounts and my administrator account when connecting from win 7 with RDP 8.0

    All 4 accounts connect quickly from Win 8.1 with RDP 8.1

    *

    I tried all the autotuning and RSS settings combinations listed above with no effect on this issue

    Wednesday, November 06, 2013 12:23 PM
  • Perhaps I should mention how I am initiating the connection. From the windows client PC, I logged on to https://myconnectiobroker-RDweb-host/rdweb and downloaded the RDP file.

    Since this is an off network PC and DNS won't resolve, I edited the RDP file to change the remote computer name from the hostname to the IP address of my connection broker/RDweb host

    This RDP file, I copied to my win8 and win7 machine for testing.

    Wednesday, November 06, 2013 12:29 PM
  • so a few odd things, if you're going in with VPN, why wouldn't the hostname resolve? obviously this may not matter if your win8.1 system is connecting the exact same way as the win8 and win7 clients.

    i'm not really sure how much has changed in RDP client v8.1 vs. v8.0, and until MS publishes the new RDP client for other OSes, while you're running 2012 R2 this may not work, i'm not sure how much longer it will take for them to make the package available.

    another thing you can try is instead of pulling down the .rdp file from RDWeb is to use the Connect to a remote PC section of the RDWeb page to connect to the IP of your server, see if that makes a difference when launching the connection through IE on the old workstations.

    you will need to check the logs i mentioned, without them you have no indications on what's going on and it'll just be a guessing game.

    Wednesday, November 06, 2013 3:02 PM
  • OK I think I pinned down the cause

    Look at this log:

    -------------------------

    Log Name: Microsoft-Windows-TerminalServices-SessionBroker/Operational
    Event ID: 801
    Level Verbose

    RD Connection Broker successfully processed the connection request for user TESTBED\test1. Redirection info:
    Target Name = RDS1
    Target IP Address = <LAYER 1 IP>, <Layer 2 IP>, <LAYER 3 IP>
    Target Netbios = RDS1
    Target FQDN = RDS1.TESTBED.local
    Disconnected Session Found = 0x0

    -------------------------

    The Layer 1 IP address is the only one the VPN client can reach, but since RDS Host terminal services service is bound to all IP addresses it is advertising them all.

    RDP 7.0 and 8.1 handle this OK, RDP 8.0 does not.

    I know this is the cause because in my test environment I stripped the RDS hosts down to 1 network and RDP 8.0 worked, when I added the other NICs RDP 8.0 chokes at "Initiating remote connection"

    So... how do I unbind Terminal Services from the other IPs in the stripped down RDS Host configuration. Can you do this in registry?

    Thank you

    Friday, November 08, 2013 5:55 PM
  • i remember you could do this in 2003 from the RDP listener settings, but i'm not sure about 2012.  the only thing that comes close is if you leverage windows firewall and make some changes to the inbound RDP rules, binding it to a specific NIC over port 3389 or maybe something similar on your network firewalls
    Friday, November 08, 2013 6:20 PM
  • edit: ***I set NIC in VM to 100 full duplex, issue resolved***

    I am sorry, it appears VMware has sent me on a wild goose chase.

    I had been testing from my win 8.1 laptop and win 7 VMs in VMware workstation 10. I finally tested from some "real" clients and do not experience the issue.

    So thank you for your help.

    Lenovo w530 -- win 8.1 -- no issue

    VMware ws10 -- Win 7 no SP, RDP 7.0 -- presents issue

    VMware ws10 -- Win 7 SP1, RDP 8.0 -- presents issue

    Lenovo t500 -- win 7 no SP RDP 7.0 -- no issue

    Lenovo t500 -- WIn 7 SP1 RDP 8.0 -- no issue

    HP DX2400 -- Win 7 SP1 RDP 8.0 -- no issue

    Len Thinkcenter 72 -- WIn 7 SP1 RDP 8.0 -- no issue


    Saturday, November 09, 2013 2:27 PM
  • I have this *exact* same problem (60 second delay accessing remotely through RDP Gateway, but no delay via RDP internally, same event ID of 20499).  I have no virtualized machines of any kind however (not VMware or other types, and not on the server or the clients).  Therefore, while I am glad you found a solution to this issue for you, that solution does not seem to apply to me :(

    I have been troubleshooting this problem extensively for a month, and nothing I try has helped at all.  Currently, I suspect GPO processing as the possible cause, but I am not sure that is the cause because, again, there is no delay for the same GPO to process when connecting via RDP internally.

    This 60 second login delay *seems* to be comprised of two 30 second delays (because the RDP client's status of "configuring remote session" briefly flashes at the 30 second mark, before hanging there again for 30 more seconds.  After those 60 seconds, all users get remote access, but I have been asked to get rid of the 60 second timeout, and I have been utterly unable to do so.  Therefore, if anyone has any additional ideas, I would be extremely grateful!!

    Monday, February 24, 2014 5:59 PM
  • Having the same issue - it was brought up in another thread here - also no resolution as of yet.

    http://social.technet.microsoft.com/Forums/en-US/bb2b8804-d68d-4951-b90b-e2aa9355ca68/rds-gateway-60-second-delay?forum=winserverTS
    Monday, February 24, 2014 9:39 PM
  • With the *big* help of a few users within the thread Adam linked to above, I finally solved my RDS login delay problem!!  I have already posted extensive details of what the solutions were in my case, within that thread Adam linked to above.  I hope that helps anyone else with these symptoms, both now and in the future!
    Monday, March 03, 2014 7:08 PM