locked
How does the FastConnectTimeout registry setting work? RRS feed

  • Question

  • Hi! I've been trying to figure out how to go into disconnected mode for the App-V 4.6 RDS client in a fairly fast way. By default it appears that our terminal services Win2003 and Win2008R2 servers take about one and half minute to 2 minutes to understand that the stream server is unavailable. This appears to be either due to the systems tcp stack timeout or the connecttime out registry setting with iteration of somekind (says 20 seconds by default). After studying the article http://technet.microsoft.com/sv-se/library/dd464849.aspx I discovered the registry setting FastConnectTimeout that by default have a value of 1000 (and exists in the registry). According to the article that should be in milliseconds. The way I interpret it is that disconnected mode should be invoked after 1 second... this is obviously not the case for my environment at least. I played around with it and lowered it to 300. That made it slightly better but it was still a long time for the application to launch. Anyone got any idea how this registry setting is working and does it depend on anything else? I have the setting RequireAuthorizationIfCached set to 0.
    Monday, December 6, 2010 9:22 AM

Answers

  • Allowing work offline is not enabled by default on Terminal Servers and it's obviously something that you don't want users of a multi-user system to be able to do.

    If you set this setting too low you could potentially cause more issues when the system is under load. Have you also tried modifiying the values of ReestablishmentRetries and ReestablishmentInterval?

    • Marked as answer by Jonnw Monday, December 6, 2010 1:29 PM
    Monday, December 6, 2010 10:15 AM
    Moderator
  • Hi!

    Changing the ReestablishmentRetries and ReestablishmentInterval seems to work. Putting the values low enough the startup time is much faster. So my experience of the matter is...

    FastConnectTimeout detects (within a second) that the stream server is down, however that event is then handled down to ReestablishmentInterval and ReestablishmentRetries.

    Thanks for making the connection Aaron and taking time to read the posting.

    Monday, December 6, 2010 1:29 PM

All replies

  • Hello,

    Any reason that you have not set it to work offline?



    /Znack
    Monday, December 6, 2010 9:24 AM
  • Well I want the client to run when my stream servers are down for any reason. To my understanding work offline is not invoked automatically. I don't want my users to toggle it themselves and also I want it to switch back as soon as possible when the stream servers are back online so new applications can be released.
    • Edited by Jonnw Monday, December 6, 2010 9:32 AM Added further info
    Monday, December 6, 2010 9:29 AM
  • Allowing work offline is not enabled by default on Terminal Servers and it's obviously something that you don't want users of a multi-user system to be able to do.

    If you set this setting too low you could potentially cause more issues when the system is under load. Have you also tried modifiying the values of ReestablishmentRetries and ReestablishmentInterval?

    • Marked as answer by Jonnw Monday, December 6, 2010 1:29 PM
    Monday, December 6, 2010 10:15 AM
    Moderator
  • Hi! Hmm just to be clear...I don't want offline. Just like Aaron points out it's a poor idea for multi-user environments.

    Aaron what do you mean by "set this setting too low you could potentially cause more issues...". I interpret that as if I set FastConnectTimeout too low this could happen http://blogs.technet.com/b/appv/archive/2008/11/13/app-v-client-immediately-enters-disconnected-operations-mode-on-startup.aspx

    To me it seems that this FastConnectTimeout doesn't work. I mean if I bring down my stream server it takes between 1 1/2 minute to 2 minutes to start the first application. Not one second (1000 milliseconds). I interpret this as the registry valued is not beeing used.

    I suppose I could try to modify ReestablishmentRetries and RestablishmentInterval. While I test it I'd like to rephrase the question a bit...

    Anyone got the disconnected mode feature working in a fairly fast fashion?

    I'll post the outcome of the test asap :)

    • Edited by Jonnw Monday, December 6, 2010 11:55 AM Bad spelling.
    Monday, December 6, 2010 11:53 AM
  • Aaron what do you mean by "set this setting too low you could potentially cause more issues...". I interpret that as if I set FastConnectTimeout too low this could happen http://blogs.technet.com/b/appv/archive/2008/11/13/app-v-client-immediately-enters-disconnected-operations-mode-on-startup.aspx
    I would assume that if the client does not receive a response soon enough it will go into disconnected mode - but in a scenario where the streaming server is under load, it might take a little extra time to respond. It's not unavailable, just taking longer to service requests, so if the value was too low, the client may go into disconnected mode when you don't expected it to.
    Monday, December 6, 2010 12:27 PM
    Moderator
  • Hi!

    Changing the ReestablishmentRetries and ReestablishmentInterval seems to work. Putting the values low enough the startup time is much faster. So my experience of the matter is...

    FastConnectTimeout detects (within a second) that the stream server is down, however that event is then handled down to ReestablishmentInterval and ReestablishmentRetries.

    Thanks for making the connection Aaron and taking time to read the posting.

    Monday, December 6, 2010 1:29 PM
  • Great stuff. That's good to know that it worked.
    Monday, December 6, 2010 1:38 PM
    Moderator