Link to home
Start Free TrialLog in
Avatar of bryanchandler
bryanchandlerFlag for United States of America

asked on

VNC, GoToAssist, TeamViewer all extremely slow. RDP OK

A few months ago, whenever I started a session using GoToAssist to connect to a Windows Server 2003 Std. server, it becomes so unresponsive as not to be usable. However, straight RDP sessions work fine.
I've tried GoToAssist, VNC and now Team Viewer. All with the same behavior.
The session connects at normal speeds, and I'll see the console login screen, but after the initial screen appears, controls are unresponsive.

- I've tried removing each service & re-installing, only having one installed at-a-time.
- I've removed & re-installed the latest video drivers rebooting in between.
- I've added all three's program directories to the exclusion list in Kaspersky AV and had it ignore all program activity & network traffic for these programs.

There's no other software on the server that would have any effect on these program's network behaviour (ie. windows firewall is off.) GTA & Teamveiwer both can transverse NAT, and work flawlessly on my other servers/workstations I've used them on.
I've tried running these services under the domain admin account, but this doesn't work.

It seems to start working for half a second (I'll see the curson blink or CTRL-ALT-DEL brings up the login screen) but after this it freezes.
What in the world is going on here?
Thanks.
Avatar of pwindell
pwindell
Flag of United States of America image

I have no specific answer to your specific problem, but...

RDP is always going to be faster.  It is a different technology than the others and more efficient.  RDP is just the Protocol, it is not the Application. The Application is Terminal Services that has been around since NT Server 4.0 (or 3.5?) and has only recently been renamed "Remote Destop Services".   It is designed as a Remote Access Multi-User Environment where each user has their own distinct environment,...it is not designed as a Desktop Sharing product.  Because it has been around a long time it is well matured and has had a long history to be "perfected" in.

All the other products are designed as a Desktop Sharing tools for two users to see the same desktop at the same time (hence, Desktop Sharing).  So they are designed differently and are not as efficient.  Their performance is directly tied to the "quality" settings and the bandwidth available and require higher bandwidth than Terminal Services does.

VNC has always been the worst performer of the bunch, in my opinion,...however it is also probably the least complex.

One thing that you should do is have another person physically at the machine while you are doing this.  You should both see the same screen since that it the purpose of these non-RDP tools.  This other person can verify if the lockup is only an illusion caused by the tool or if the local machine truely is unresponsive.  In other words the tools may make the things appear locked up but the person physically at the machine may be able to use it just fine and the server is running with no problems. That is an important distinction to know about.  If the CPU or RAM is being choked up that can easily be seen by the person sitting at the local machine by looking at the graphs on the Performance Tab within the Task Manager.
Avatar of Davis McCarn
Or, since RDP works, connect using it, bring up the Task Manager, and try logging in with one of the other three though I wouldn't be at all surprised if they seriously fight with each other so I hope you've only got one running at a time (which means you need to kill their services and disable their drivers).
Avatar of bryanchandler

ASKER

@pwindell:
The remote desktop is not "locking up." I've used these tools while on-site & observed my actions from the viewer on the desktop are updating in real-time, but it's not returning the display of my actions to the viewer's side. CPU & memory usage are low while this is happening.

@DavisMcCarn
I've only run one of the remote tools at a time. Both GTA & Teamviewer will boot an RDP session when they begin theirs so there won't be a conflict.

We use TeamViewer as a component of our monitoring solution we use, and at this site all workstations work fine with it.  Only their server has the issue.
ASKER CERTIFIED SOLUTION
Avatar of pwindell
pwindell
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yes; but, all three install video, keyboard, and mouse redirectors along with services to recognize incoming session requests.  Any confusion between those items and you'll get what you describe.
There isn't some process visible in the Task Manager that goes wild when you attempt the connection?
@DenisMcCarn
No. I've been trying to fix this for a while, so I've looked at this from any angle. There just something blocking the screen updates coming back to me.
I'll have to live with it then. Not worth a whole server OS reload to fix this one issue.
The issue is not sufficient enough of problem to warrant the resolution of re-installing the server OS.
The "grade" is supposed to reflect the correctness of the solution,...not on whether or not you want to do it.  And at this point, it is the only solution given that would work.
I also have this issue on Windows Server OS.  Some are 2003 and some are 2008.  Not all servers are affected.  It makes it difficult to use teamviewer.  RDS and local console are ok.
We have found some video drivers to cause this issue so a reload of the OS would not solve the problem for us.  We uninstalled the video driver and left it with the default windows VGA driver.  This has worked for us quite a few times now.