RDP problems with SBS 2008 R2

[Mick]

As regular readers may remember (ahem!), I've recently taken on an SBS 2008 server with Exchange and AD. It is also a DC. As this set-up is about ten miles away, I was hoping to do most routine stuff on it via RDP. However, just recently attempts to RDP to it have just produced a blue screen (similar to the normal log-on screen) with the message "The requested operation cannot be completed because the terminal connection is currently busy processing a connect, disconnect, reset or delete operation." There is no error code shown.

I can't run tasklist/taskkill on it as it says 'the RPC service is unavailable' and in any case, I'm not even sure which process to kill, if any. For that same reason, I can't get into it to run Process Explorer - or anything else. I was going to try pskill, but without knowing what to actually stop, it seemed a bit of a slap-dash approach. Interestingly, I have installed Teamviewer on this machine in unattended access mode and if I try and access via this means, I get a) 'Could not Connect' [instantly] or b) it shows me the exact same screen as I get via RDP. If I go on site and physically log all users out - including, lastly, myself, it makes no difference. So far, the only thing that works - and that only temporarily - is a re-boot, but this is obviously not a viable long-term solution. The event logs show absolutely nothing - not even a failed log-in attempt - so no help there. The machine is virus-free and fully patched. Clients can continue about their day-to-day business with no problems on the local network. Email is functioning just fine. BPA is giving me the OK. Obviously, I've Googled, but although lots of folks seem to have had this (or similar) problems, I haven't found a solution. I can log-in fine if I'm actually sitting in front of the thing, but that's not really much help.

Grateful for any suggestions - a bit stumped.

 

[Markverhyden]

No hints in the logs?

 

[Mick]

I'm afraid not - not even my old friend 'an unknown error'

 

[Markverhyden]

LOL!!!! That's an old friend none of us can seem to get rid of. Got to love some of those messages.

Been wanking around trying to get a VPN back up and running. All that happened is they moved to a new office so there is a new fixed IP.

"publish_entry SCDSet() failed: Success!" Scratching my head over that one.....

 

[DMC Unlimited]

Have you tried a different user account to login remotely? Also, was this ever used as a Terminal Server in the past/currently?

 

[Mick]

@Mark: You have my sympathies! I did find this, in case it's any help: http://serverfault.com/questions/520071/sonicos-enhanced-5-8-1-2-l2tp-vpn-authentication-failed

@DMC - thanks for the reply. Yes - tried more than one account, with the same result. I took this server over from someone else a while back. Whilst it hasn't been used as a TS to my knowledge, I could not say for certain that it never has been in the past. Do you think that might be relevant?

 

[YeOldeStonecat]

I recall a certain service that is resource intensive and gets lazy, and affects this...on machines that are on lower spec hardware and haven't been maintained. At the moment I forget which service it is, I want to say it was Exchange related or maybe IIS.
Do you log off from prior RDP session? Or just disconnect? If another session is left running..trying a second session can jam things up..ensure another session isn't still running. (I know servers allow 2x remote consoles...but, since SBS is bloated and heavy, often it doesn't like it).
Did you try the remote web workplace portal? Go in via your browser instead of via RDP...then it will launch an RDP proxy (via tsgateway) to let you in. or just manually whip up an RDP profile with the TSGateway settings plugged in.
No RMM tool to load on there? Hopefully it's secured well (good Admin password and other passwords) since port 3389 is open, and the setting turned on to stop RDP listen mode after XX amount of failed logins. Having port 3389 exposed on the firewall to a DC can be risky unless you take extra steps to secure that.

 

[Markverhyden]

@Mark: You have my sympathies! I did find this, in case it's any help: http://serverfault.com/questions/520071/sonicos-enhanced-5-8-1-2-l2tp-vpn-authentication-failed

@Mick, thanks but I've seen that. Seem to be a lot of entries for sonicwall as well as pfsense. This is OS X so it's just another *nix.

Back to your issue. I'd fire up some of the Sysinternals tools to see if they can shed some light on the matter. Like procexp and procmon.

 

[Mick]

Hi StoneCat - thanks for jumping in. Tried RWW and get exactly the same result/message. This hardware is not exactly state-of-the-art. I can't get to it remotely to check, but from memory it has 12 GBs RAM, which I have already recommended be increased - although not yet done. Disks are showing good under Crystal Mark. I already changed the RDP port number and corresponding firewall setting, some weeks ago, and it worked fine for a good while after that. I'm pretty religious about logging-out as opposed to disconnecting and in fact made a point of logging everybody out on my last visit. Mark has just made the point about having a look with ProcMon etc and I guess that's going to be my next step. Will have to wait until I'm next on-site, but If I get a resolution - or even pin down the likely cause - I'll post back here. Meantime, if you wake up in the middle of the night and suddenly remember the name of that rogue service - I'm all ears!

 

[Mick]

Well....I wouldn't say I fixed it, but it now works. Arriving on site, I was able to gain some sort of access (which I hadn't been able to remotely by any means). Despite me religiously logging every single user/session out on my last visit. I find the same user (not even an admin) hogging three sessions. I asked her why she was signing in to the server. She said she couldn't find some file or another on her own workstation, but could find it on the server. When I look at her machine, I find the shortcut to their shared file store in the Recycle Bin.... Restore shortcut, log her out of all server sessions and administer kindly bollocking. Touch wood, no problems since!

 

[YeOldeStonecat]

Sounds good....so it was another user just disconnecting that left an RDS session running in the background.
In the earlier days we'd over ride that by launching RDC from the start line mststc /console
Which, after one of the RDS updates a few years ago, got replaced by mstsc /admin

This can often kick out remaining non-admin sessions.

 

[Mick]

Yeah - I was a bit surprised she'd somehow managed to achieve three disconnected sessions all under her own name, but... anyway - this server has a monitor attached, for ease-of-use. I've unplugged it now, so they can't see the screen