0

Background

We have a few applications on Windows 2008 R2 servers, presented via RemoteApp, via links from TS-Web. These apps have been running this way for years (~8 years I think).

One of our users is having issues logging in, with it hanging for a couple of minutes at the "configuring remote session" phase before it exits with no explanation / error / etc. We've done all the obvious fixes (disable bitmap caching, delete local cache, ensure low resolution, delete her profile, check no TS server holds a copy of her profile, check firewalls are off or have the required exceptions, etc. but with no joy. We've also confirmed the issue only occurs with the unique combo of her account on her machine.

Since we have a farm of servers, and the login takes minutes, I've not yet been able to capture her login attempt with procmon in time to get clues...

In order to dig deeper (and avoid the inelegant solution of replacing or rebuilding her entire machine), I'd like to know more about what's going on under the covers...

Questions

  1. What happens during an RDP connection; i.e. when the system says configuring remote session, what is actually happening (also interested in other phases; though only for academic reasons)?

  2. Are any logs created which may give a clue to the fault / do you need to enable this logging somewhere? NB: I've checked the event log but at present can see no difference between her (failed) attempt and any other user's.

Community
  • 1
JohnLBevan
  • 1,134
  • 7
  • 20
  • 44
  • 1
    Hi John, On your Session host, you have the log "TerminalServices-LocalSessionManager", look in the "Operational" log for logs in relation to connections/logins. It's not the most informative in itself but it will provide reason codes for disconnected sessions etc. On your Broker you also have a "TerminalServices-SessionBroker" log which gives info on timeouts on the brokering – Mikael Dyreborg Hansen Jan 30 '18 at 10:17
  • 1
    And adding to @MikaelDyreborgHansen: if it's really _only_ one machine and _one_ user on _this_ machine, I'd say reimaging/reinstalling this said machine is far from "unelegant", but simply the most effective way of handling the problem. Of course learning what's going wrong is never...wrong :) – Lenniey Jan 30 '18 at 13:14
  • @MikaelDyreborgHansen; thanks for the pointer; digging around there has shown a few errors which I wasn't aware of (don't seem to be causing any real issue; but suggests something's wrong)... No smoking gun yet, but definitely good logs to know about, so thank-you. – JohnLBevan Jan 30 '18 at 13:44
  • @Lenniey; Agreed that it's probably less effort for IT to rebuild the user's laptop; but I hate taking that approach since it inconveniences the user, impacts on all their other work, and gives no guarantees that the issue won't come back... So whilst I can see where you're coming from for me that's more of a last resort. – JohnLBevan Jan 30 '18 at 13:46
  • 1
    @JohnLBevan - I actually just had a kind of similar issue, for me it was some clients taking up to 50 seconds to have a session fully started whereas some started within 10 seconds. The solution, in my case, was to copy over mstsc files from one of the working clients to the ones with issues. I'll write a blogpost on it as soon as I can as well. – Mikael Dyreborg Hansen Jan 31 '18 at 08:48

1 Answers1

0

We seem to have found the answer. Since the issue was intermittent we looked for patterns and found that it worked when:

  • the user was at home
  • the user was at a hot desk
  • the user was anywhere but her own desk

Additionally, we checked whether the issue was wifi vs cable (i.e. since she'd be more likely to be plugged in by ethernet when at her own desk), but found that had no impact.

Eventually she realised that it was here docking station / by switching this with another she could consistently stop or cause the issue exactly correlating with which dock she used.

We don't have a good explanation beyond this; best guess is that some hardware fault caused the part of the session which checks for local devices to fail due to some corruption or unexpected response.

Hopefully this answer will help others hitting this.

JohnLBevan
  • 1,134
  • 7
  • 20
  • 44