We have this week, started having an issue on one or two of our remote desktop session host servers running 2012 R2, whereby when a user attempts to login, they are stuck on one of the login messages such as "processing group policy settings", "applying group policy printers policy" etc. This has happened to 3 different users, once each on three different days this week. It has only been seen to happen in the morning, and only once each day.

We then see on that server, a session with no user name, which is disconnected and stuck in a "signing out" state (confirmed by connecting to the session through task manager).

Rogue session in control panel

We can also see two locks on their user profile disk on our file server, locked by this same server. The user is unable to login at all. If we close the open files for their UPD, and they attempt to login again, they will instead get a message saying they couldn't be logged in because the remote desktop services service is busy (presumably signing out this phantom session).

Our only workaround, is to manually log them into a different specific server from our pool, and then have them connect to that session remotely.

Looking at events, I can see them in this order for this users first login attempt:

enter image description here

enter image description here

(Not unusual to see this, as we get one of these for almost every single user, on almost every single login, successful or otherwise).

enter image description here

enter image description here

I can then see many more login attempts by this user, each going through a set of events, ending with a disconnect with reason code 12 as below:

enter image description here

Anyone any thoughts on why this login attempt creates this rogue session, and how we can correct it?



  • We are rolling back VMware tools on these affected VMs from 10.2 to 10.1.10. By tomorrow we will know with a high level of confidence if this is effective. – James Edmonds Jan 31 '18 at 12:41
  • Rolling back tools on RDSH servers is ineffective, so we are now doing the same for our DCs. – James Edmonds Feb 1 '18 at 9:39
  • Rolling back tools on the DCs was also ineffective, so am now at a loss – James Edmonds Feb 2 '18 at 15:00

Seems to be related to deploying printers via group policy printer preferences, so we are moving to the other "Deployed Printers" model in group policy to work around this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.