Server 2012 and The task you are trying to do can't be completed because Remote Desktop Services is currently busy.
We have experienced this in the past on 2008R2 servers and have resolved it by installing: kb2661332
This is occurring on Server 2012 and I do not see any hot fixes specific to this issue.
I believe we have exclusively seen this occur to users reconnecting to disconnected sessions. New users can login fine. The disconnected users cant until the server is rebooted. It appears to be erratic as to when it occurs.
Any help would be appreciated.
-
Edited by
JasonS17
Thursday, October 17, 2013 5:22 PM
October 17th, 2013 5:14pm
i've seen this as well but only for external users, do you have RDGW or UAG/TMG?
October 17th, 2013 7:36pm
Using a remote desktop gateway for all connections.
October 17th, 2013 7:54pm
Yes, it is working correctly. No errors in the event logs on it. Again it's a very sporadic issue. We have quite a few terminal servers using it.
October 21st, 2013 2:59pm
i know in 2k8 they had the hotfix for this, but in 2012 there isn't one, so i'm wondering if it's something you have to address from the network side. TTL values or sticky session values? are the timeout values on your network equipment shorter
than your idle disconnect values on the server?
October 21st, 2013 6:03pm
Yes, I am familiar with that hotfix. I was hoping there was one for 2012.
I did verify all our configured timeouts on load balancers etc for idle ip sessions exceeded that of our currently rdp policies.
I am playing with disabling chimney currently just based on a hunch.
October 21st, 2013 8:09pm
Hi JasonS17,
Have you tried what armin19 suggested? Is there any update?
Thanks.
October 23rd, 2013 6:45am
Yes, but still no luck. It still happens randomly.
When this occurs if you look in TM, for a disconnected user you should see their user name. Which I normally do, except when this issue occurs. Then a disconnected user looks like below.
You can't log it off or get rid of it unless you reboot the server,
-
Edited by
JasonS17
Wednesday, November 06, 2013 9:03 PM
November 6th, 2013 8:45pm
i've been blaming my issue on the UAG but if you don't have a UAG and just using RDGW, then the issue has to be the RDSH, which goes back to the point that if this was previously resolved via a hotfix issued for terminal servers running 2008, either
it's still a problem in 2012 or we need a hotfix for 2012 - again this is happening for external clients only in both our environments i think?
Jeremey, this issue is not very uncommon in 2012, i think we've seen a few posts here already, maybe open cases with MS as well, are you seeing anything in the internal VKB about this problem, is there a fix in sight? Thx.
November 6th, 2013 9:22pm
All our users connect externally via a RDG so I am not sure if it happens to local connections. Yes I agree this issue is almost identical to that of the one they issued a hotfix for in 2008R2.
November 6th, 2013 9:41pm
Still seeing this issue occasionally. I have even upgraded to 2012 R2 hoping that would fix it.
January 20th, 2014 5:51pm
Hi Jason,
Do you still have this issue? We are having the same problem. We are not using RDG.
So I believe the problem is not related to RDG. Also, we have it on clients running windows XP, 7 and 8. Happens with all users, so not profile related (or all users have corrupt profiles...).
I was thinking of upgrading to 2012R2 but as this is still a problem, maybe we better downgrade and install a clean Windows 2008R2.
Still, hope this (big) issue is getting resolved soon.
Regards, Pieter
February 6th, 2014 2:50pm
Pieter,
It appears that initially upgrading to Windows 2012 R2 and Applying KB2661332 to Windows 2008 R2 resolved the issue, but now it has recurred on both. It appears that the recurrence has been showing up as the April Windows Updates have been applied.
Anyone else have any insight?
Regards,
Martin
May 7th, 2014 6:07pm
We have experienced this in the past on 2008R2 servers and have resolved it by installing: kb2661332
This is occurring on Server 2012 and I do not see any hot fixes specific to this issue.
I believe we have exclusively seen this occur to users reconnecting to disconnected sessions. New users can login fine. The disconnected users cant until the server is rebooted. It appears to be erratic as to when it occurs.
Any help would be appreciated.
Does anyone have a solution?
i am having the same experiance. Not really anything helps.
Only a reboot does, but then the reboot takes a long time. More then an our. Users are ramdomly experiancing this problem. Sometimes the release it afther an our, sometimes we have to reboot. its getting worse again after the last updates.
Is there a hotfix from MS?
May 21st, 2014 7:57am
I am also seeing this issue intermittently on Server 2012 R2. The only solution I have found so far is to reboot the session host which has the affected (locked) session, but this is far from ideal. Has anyone found a way to reset the affected
users session without rebooting, as the normal methods to log off the session through Server Manager or Task Manager or even identifying the session with 'quser' and then using 'reset session' have no effect.
As a side note remoteapp shell is consuming about 13% CPU resources in the affected session.
May 27th, 2014 4:45pm
Still seeing this issue occasionally. I have even upgraded to 2012 R2 hoping that would fix it.
I saw it today with Windows 2012 R2 and Windows 8.1 clients (two separate computers). In both cases, I had disconnected the session by clicking close on the remote desktop session. Both computers (one desktop, one laptop) had the same issue on the same day.
A third client session on Windows 7 through Hyper-V was OK. Restarting Remote Desktop Services on the server did not unlock the client logins.
For both of the stubborn computers, I went in with another admin login. In both cases, it shows the other user was taking up memory but was "disconnected" and the programs were still active. I could even see the programs using CPU and memory.
Sending a message to that user did not help "wake up the session". In the end, using the second admin login, I disconnected the first login, but that action still did not allow me to login using the first account (same story with both computers).
I therefore issued the "shutdown /r" command to reboot each machine.
I saw an earlier message about potentially being an antivirus program: in my case, I just dropped Windows Defender in deference to the superior Avira. Though, I tend to side with the majority sentiment that this issue sounds like some type
of bug.
I like the idea of using an explicit "lock" before disconnecting, and I'm going to try that to see if it proves to be a workaround. In the meantime, I'm making sure to save anything in the session before going away.
June 4th, 2014 4:01am
Just for info...
I've had this problem a few times with 2012 R2, it typically occurs after the loss/re-establishment of network connectivity to the server.
In my experience its just been a case of patience - seems to sort itself out after 5 - 10 minutes.
I have yet to experience any issues reconnecting to disconnected sessions without a loss of network connectivity in between.
Phil
June 10th, 2014 3:13pm
All,
Completed a support case with Microsoft on this issue. In our instance it appears to have been related to vsepflt.sys -
"Winlogon is notifying user logon and calls into profsvc (Profile Service) to load the profile. As the user profile is roaming its doing a Reconcile of the profile and the calls lands up with NTFS who starts to wait on the oplock for close to 1 hour and
29 min.
The Oplock owner thread vsepflt is waiting to acquire a lock which is already owned by the oplock thread. Hence threads are deadlocked.
Deadlock is caused by Trend Driver vsepflt.sys. We have seen multiple similar issues and all were resolved by either updating to latest version of the driver or removing it."
Regards,
Martin
June 13th, 2014 1:08pm
I am seeing the exact same thing.
Has there been any resolution to this issue?
Thanks!
June 23rd, 2014 10:55pm
Hi All,
The issue Ron mentions sounds like this is related to idle sessions.
has any one tried to reducing the Idle limit using Group policy. I have seen a number of cases like this relating to duplicate sessions, and reducing the idle session settings resolved this.
Best regards
June 25th, 2014 8:38am
Does anyone know if Microsoft plans on releasing anything for this? I have a TS box set up that this is happening left and right on, a reboot really isn't an answer for users trying to get work done.
July 1st, 2014 2:26pm
It is almost September and we are still experiencing this issue on multiple servers. The only fix is a reboot, which isn't a fix at all. I would settle for at least a way to manually resolve it without making everybody that isn't having an issue log off
for a server reboot. Somebody mentioned something about a trend driver of vsepflt.sys. We don't use
trend micro if that's what that was in reference to. MS please fix!
August 21st, 2014 4:13pm
Hi All,
The issue Ron mentions sounds like this is related to idle sessions.
has any one tried to reducing the Idle limit using Group policy. I have seen a number of cases like this relating to duplicate sessions, and reducing the idle session settings resolved this.
Best regards
A
August 27th, 2014 4:31pm
i would just do a full out windows updates as well, make sure you get all those monthly update rollup patches in there as well, ton of fixes included in them...looks like the April patch is a requirement for the hotfix you noted above anyway
August 27th, 2014 8:28pm
Not sure if this will help, but I was getting the same error message when trying to access my remoteapp services on server 2012. I was able to work around by opening task manager as admin on the server, and on the users tab ending the desktop window
manager process for the affected user.
November 21st, 2014 8:37am
Any progress with this bug ?
We have the exact same problem on diffrent server and i have no idea what's causing this problem.
Tanks you
February 25th, 2015 4:44pm
We are experiencing the same problems on 2012 R2.
Has anyone a solution for this problem? Because rebooting is not a solution.
We found out a workaround for 1 user: we logged in as Admin on the console, right click connect (@ Task manager > User) and from there the sessions stops and the user is able to login. Only the next user who disconnects and connects will have the same issue
again.
The hotfixes Oasysadmin mentioned are already installed.
Stopping the "Desktop Windows Manager" doesn't work for us either.
Hope there is a solution!
-
Edited by
ppscherm
Thursday, June 25, 2015 9:38 AM
June 25th, 2015 9:35am
I was experiencing this on two new Server 2012 R2 boxes this week. The cause might not be the same for you but in our case we had a group policy which pushes a shared fax modem on a Windows Server 2008 R2 Server. It's a policy that has been around for
years and no-one thought anything of it.
If you're having the same problem, when you try to add the fax printer manually on the affected server you'll get a "Windows can not find SYSOCMGR.exe" message which you have to accept UNLESS you have installed Desktop Experience, Fax Server, Printer
Server and Ink Features first. You wouldn't know this unless you try to add it manually.
Because the printer is being pushed via group policy, the "Windows can not find SYSOCMGR.exe" prompt appears in the group policy thread and cannot be accepted and results in the problems everyone has described here [disconnected session (4) with only
4 processes running: Client Server Runtime Process, Desktop Window Manager, Windows Logon Application, Windows Logon User Interface Host - cannot reboot the server without a cold power off/on]
As soon as I excluded the affected servers from that one policy, the login/logoff problems completely stopped. If it can happened with one policy, wouldn't surprised me if others could cause it. It's a pain but if you're able to reproduce the problem fairly
easily, you could just disable all policies and enable them again one at a time.
I'd argue that this is a bug - especially considering the server cannot be rebooted cleanly when it happens. A group policy preference shouldn't be able to cause that.
July 11th, 2015 7:15am