We are on K2.
We are connecting to an SBS 2003 server. With KES/AVG. No firewalls on server.
From the Remote Control tab in Kaseya, we have been unable to initiate a session in either RDP, KVNC, or VNC. It fails everytime. We can connect to other servers/desktops on the same LAN just fine.
We can however connect through the tab in KLC, but we have been avoiding this, since it seems to cause the agent to stop communicating with Kaseya.
I have: Rebooted the server. Tried a different remote control type. Uninstalled VNC/KVNC (Through Kaseya) and reinstalled it.
Just an off question, if you can remote to another server in that subnet, what happens if you try to use the Windows RDP from that server to target server?
Try the following:
From the Agent Status screen, Alt-Click on your server's icon. That will open the old version of the computer popup. We have had better success than with KLC or through the Remote Control tab. No idea why that should be, since it is theoretically connecting with the same software. But it is much faster then KLC.
We're not happy with VNC/KVNC. Security through the tunnel is better than native VNC, but performance and features just aren't there. We prefer LogMeIn. You can use either Pro2 or Free (with the appropriate LMI Central contract). You can even push a LMI Free install via Kaseya.
I would sure like K2 to have more extensibility so that we could choose other vendors non-standard Kaseya tools and embed them into Kaseya.
Unfortunately, the ALT-Click does not work as well. :(
I have seen certain AV programs flag VNC / LiveConnect processes as exploits. You might want to check your AV solution's logs to see if the VNC executable or the KLC executable have been flagged for quarantine or non-execute. I have seen MS's ISA server block it as well. Keep posting and let us know how its progressing.
Have you double-checked to make sure that the server you are connecting to has the right check-in IPs and/or hostnames set? We had this problem with one particular server for the longest time. When I finally dug into it, it turned out that the server wasn't resolving the hostname of our primary check-in address. Our secondary check-in address was set to an IP address, so the server we were connecting to would check into the secondary check-in address, and run scripts... But remote control sends everything to the primary check-in address. If the server can't resolve/can't see the primary check-in address, RC won't ever work.
Ah! Great catch!
I've just set up a number of agents in a Neverfail environment, where we have trios of systems that all have exactly the same name and IP address on their primary interface (which connects to their default gateway), but only one of them has that interface turned on at any given time. I had to set up "route" commands to provide access to our K server, and edit the KaseyaD.ini to tailor the agent name and reset the GUID. I also had to make sure they had a raw IP address as a secondary, because the DNS doesn't work without the default gateway, and adding to the 'hosts' file isn't working as well as it should so far.
I may have to try swapping the primary and secondary server addresses in the ini.
FWIW, it seems the machines with the older agents installed seem to connect better, as does the quick-connect. The systems that work well are running a 5.x agent, and the problem ones are running a 6.x one.
The Alt-click technique Dave mentions (above) doesn't seem to work for me, and using the "Preinstall RC Package" option doesn't seem to work -- it just sits there saying preinstall pending.