none
TS WEB Slow logon

    Question

  • Hi ,
    I've setup a configuration with a TSGateway/TSWeb server in the DMZ and one , at the moment , Terminal server in the internal lan publishing application.
    All servers are running windows 2008 .

    All seems to work properly , users can log on to the TSWEB select the published app and use them .
    However I noticed a slight delay in the authentication process , it takes at leat 1 minute , both at the TSWEB level and when starting the remoteapp.

    Anyone had this problem ?
    thanks
    Tuesday, April 07, 2009 1:10 PM

Answers

All replies

  • IIS does the authentication.  An IIS forum may be of more help.

    Thanks

    Rong

    Wednesday, April 08, 2009 5:55 AM
    Moderator
  • I'm seeing the same problem. I'm just setting up TS Web and TS Gateway for the first time. I've finally got everything working properly, but logon times are EXTREMELY slow. This is after the IIS authentication, so an IIS forum is not going to be of help. I can browse to my TS Web site, authenticate, and i get my list of RemoteApps immediately. I then click on a RemoteApp and it may take about 15 seconds to get a login prompt, then after entering my information it will take another 30-45 seconds for the remote session to actually start. So I can't see this being an IIS issue. Anyone else have any insight?
    Tuesday, April 21, 2009 4:28 AM
  • have you tried disbaling Kerberos Authentication in IIS?
    Tuesday, April 21, 2009 9:57 AM
  • Mike, is the login time slow only for the first app and then fast for subsequently launched applications, or is it always slow?

    Thanks,
    Christa
    Christa Anderson [MSFT]
    Tuesday, April 21, 2009 11:53 PM
    Owner
  • I was just troubleshooting this a bit further. I have a dedicated Terminal Server, and a dedicated IIS server which has the TS Gateway and TS Web roles. These servers are on a completely separate domain/subnet from the client I'm connecting from. In testing this I put both the IIS and TS servers in a DMZ. Port 80 and 443 is allowed to the web server, all traffic is blocked to the terminal server. When I browse to the TS Web site, I enter my credentials and the RemoteApp tab appears immediately. I created a RemoteApp for Adobe Reader and MS Word. When I click on either, it will take about 15 seconds before I get a login prompt (sidenote: I get a generic login prompt which defaults to the domain the client is on). Then after I enter my credentials, on average it takes 20-30 seconds for the app to appear on screen. From this point everything is fast as it should be. If I close the app and open another, it's the exact same process with the same delays.

    Here's something I just figured out. If I open up port 3389 through the DMZ to the terminal server, the whole process is lightning quick. When I click on a RemoteApp I get a login box right away (sidenote: this time the credentials defaults to the domain which the IIS and TS servers are on). I enter my credentials and the application pops up almost immediately. So for whatever reason, if the RDP port is directly open to the terminal server this whole process works flawlessly. If I close that port to ensure that the traffic is properly tunneled over SSL, the whole process is severely delayed.

    I don't know what else to test at this point. Let me know if you have any ideas or if you need any additional configuration info.

    Thanks.
    Wednesday, April 22, 2009 12:29 AM
  • Mike,
       I think you have 2 issues, one is the delay for the login prompt to show up.  The second is the time it takes for the app to start on the Terminal Server.  When you opened up port 3389, it may have helped the first issue (but I am not sure), but it wouldn't have fixed the second issue.  The reason the first app launch on a server takes so long is a session needs to be created and the user logged in and so the first app launch will take as long as it takes to login to a machine and then start an app (20-30 seconds is not unreasonable in this case since, anything in that is started at login has to be started as well, for example anti-virus software).  Additional launches of the apps re-use the session that is already created (assuming that app is being launched on the same terminal server) and so will pop up very quickly.  I am guessing you already had a disconnected session when you opened up port 3389 and that is why the app launched quickly.  You can set various settings on how long sessions will stay around when you disconnect and you can use this to change the behavior to provide a quicker start of apps. 

    I am not sure why you are seeing the delay of the login prompt, but I would guess that the reason is you have to authenticate with the Gateway server and then it tries connecting to the Terminal server (and doing server auth) before popping up the User cred prompt.  I will see if I can find you someone to give you a better answer, but I am guessing that opening up port 3389 was a red herring and isn't why you saw quicker response times (most likely cached authentication, etc...).

    Cheers,
    Kevin

    Wednesday, April 22, 2009 12:43 AM
    Moderator
  • Personally, I think opening port 3389 to the terminal server is a clear symptom of the problem. In your first paragraph you state reasons for why the first login would be slower than normal, but after the session is created it opens more quickly. This is not the case for me. The delays are the exact same every time. If I open the port, the entire process is lightning quick. If I then close the port, in your example the session would still have been created, but the delay reappears and takes just as long as the first attempt before opening the port. I think that if the port is open it just sends you directly to the terminal server over port 3389 without tunneling the communication. If the port is closed, for whatever reason it takes a while to realize the port is closed, tunnels the communication, then passes you through...after a pretty good delay.

    I can only speculate at this point. Hopefully you know someone else that could chime in and hopefully shed some light on this. If you read through this forum, you'll see a handful of people stating the exact same problem. I just haven't seen people state much in the way of configuration details or tests they've tried, let alone a solution.

    Thanks.
    Wednesday, April 22, 2009 11:57 PM

  • I took some snapshots of network traffic with port 3389 open and closed. They show pretty much what I've speculated at this point. Hopefully someone can chime in and explain why this is happening...whether it's a configuration issue or just the way TS Gateway/TS Web handles the traffic (hopefully the former).

    IIS Server (TS Gateway/TS Web) = 192.168.100.140
    Terminal Server = 192.168.100.120
    Client = 192.168.254.100

    Port 3389 Open -
    2009:04:22-20:05:01 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:05:01 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:05:01 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:05:01 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:05:02 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:05:06 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"

    Here you can see the traffic when I connect to TS Web, select a RemoteApp, authenticate, and then the remote session starts. This process takes all of 6 seconds, and shoots me right over 3389.

    Thursday, April 23, 2009 1:36 AM
  • Port 3389 Closed -
    2009:04:22-20:06:25 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:06:25 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:06:25 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:06:25 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:06:26 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:06:29 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:06:32 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:06:38 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:06:56 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:06:59 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:07:05 name="Packet dropped" action="drop" srcip="192.168.254.100" dstip="192.168.100.120" dstport="3389"
    2009:04:22-20:07:17 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"
    2009:04:22-20:07:17 name="Packet accepted" action="accept" srcip="192.168.254.100" dstip="192.168.100.140" dstport="443"

    Here you can see the same process, exept after I click on the RemoteApp it repeatedly attempts to connect over port 3389 which fails, then it starts communicating over SSL. This process takes about 50 seconds (just a *tad* longer than 6 seconds).

    Someone help! I need to get rid of this login delay.

    Thursday, April 23, 2009 1:36 AM
  • Well, I fixed my own problem. Here's what I did in case this helps anyone else out:

    1) Open up RemoteApp Manager on the terminal server
    2) Click on the Change link next to TS Gateway Settings
    3) Uncheck the option "Bypass TS Gateway server for local addresses"

    That option was forcing traffic over the RDP port instead of through TS Gateway. Everything is working nice and quick for me now. Authentication prompts come up with no delay at all, then after entering credentials it takes about 7 seconds for the app/terminal session to start.
    Wednesday, April 29, 2009 7:07 PM
  • Mike,

    Just want to thank you for posting the solution.  I ran into this annoying problem and traced it down to the ports but somehow i read that "checkbox" and to me it seems reverse somehow.  For those applying this fix, do not forget to recreate your RDP file, cause using one that was create prior to the change,  will do nothing.

    Kevin
    Tuesday, May 26, 2009 7:19 PM
  • Thank you Mike for sharing that information with us.

    For my case, it cut the waiting time between clicking on the application link (in the Web Access Website) and the login promt. But it takes 30 seconds until he really starts the login-process.

    A little offtopic:
    I want to criticise Microsoft for "accepting" it's own answers in there forums! The real solution is unrewarded this way. "Look in some other forum" is everything but a solution!

    Christoph


    Christoph Schmidt || IT Consultant || Germany || MCITP Enterprise Administrator
    Monday, June 15, 2009 11:19 AM
  • The problem is also present for connections from the Remote Desktop facility.  The reason is that the client checks via a DNS lookup the entered hostname itself, to determine if it is local and this is the cause of the delay.

    Hence the same bypass-for-local setting needs to be adjusted, buts it's hidden away on the TS Web server at

    C:\Windows\Web\ts\en-US\Desktops.aspx

    Amend line
                            RDPstr += "gatewayusagemethod:i:2\n";

    to read
                            RDPstr += "gatewayusagemethod:i:1\n";


    Also can add the default internal domain name to that file so the users only need to type the name of (eg) their desktop PC, rather than it's FQDN,

                        var RDPstr = "full address:s:" + GetParam("MachineName", true, "") + ".yourdomainname.co.uk\n";



    Also, with IE8 (at least) the "Options" button on the Remote Desktop page doesn't work as it executes a post-back immediately (i.e. shows the options and then immediately refreshes), this can be resolved by changing the line in the file

    onclick="jscript:hideshowOptions();"

    to

    onclick="jscript:hideshowOptions(); return false"



    Hope that helps someone :)
    Wednesday, October 14, 2009 1:15 PM