Kaseya Documentation States that Changing the check in control Period does not affect agent responsiveness
Best Practices: The agent maintains a persistent connection to the KServer. As a result, quick check-in times do not effect response times from the agent. The quick check-in time sets the maximum time to wait before re-establishing a dropped connection. Setting all your machine's quick check-in time to 30 seconds guarantees each agent recovers from a dropped connection within 30 seconds, assuming connectivity is successful.
However this does NOT seem to be correct. Increasing or decreasing this time seems to directly affects the MAXIMUM time it takes to responded to requests from the VSA. While I have not tested every function of Kaseya I have tested a few and can confirm that this is the case
The time it takes to establish a remote control session
The time it takes to establish a live connect session
The time it takes to run scripts
The time it takes to responded to an alarm condition on the target machine
Once we accepted that changing the agent checkin time does affect agent responsiveness, we can then understand that changing the agent checkin time will have an affect on server load which is what we believe has happened in our case.
While testing I have also discovered that with largish checkin times live connect doesn't seem to work at all and Kaseya probably should look into this further
Thanks Michael Dixon
For this example I have changed the check in time to 3 minutes I have tested 60minutes but that takes too long to create a document like this
Below is two pictures. One when I clicked on the remote control button and the second showing the time it took to run this script or establish the connection.
This took just under 3 minutes to connect as expected
The next example is how long it takes to establish a live connect session
Now live connect is an interesting one, while the script takes approximately 3 minutes to run the session is never actually established. Whereas when I change the check in to 10 seconds the script is competed very quickly as well as the connection established
I have now changed the check in time to 1 minutes since live connect never worked at 3minutes
As you can see it connected and took the approximately the checkin time I specified of 1 minute
Now for scheduling an Agent procedures. For this I changed the check in time to 5 minutes and it took approximately 5 minutes to complete the procedure.
Now for monitoring and alarming . for this I created a monitor set to monitor for a process I don't have. I also ensured the re-arm time as set to 0. I changed the check time from 10 seconds through to 3 minutes and changing the check in time changed the occurrence of alarms
4:44:35 pm 12-Dec-11
Set Name: (IND)HallsSVC
Log Value: Process Does Not Exist
4:40:38 pm 12-Dec-11
4:36:34 pm 12-Dec-11
4:35:31 pm 12-Dec-11
4:33:45 pm 12-Dec-11
Here are a couple of things to bear in mind regarding check-ins.
1. With each check-in, the agent will keep the connection alive between the agent and the server after the check-in. This means if the server has commands for the agent, the server can use that connection to initiate communications with the agent.
HOWEVER, if you set your check-in time to be too long, either your firewall, or the customer's firewall, or perhaps even windows will eventually close the connection due to inactivity. The time it takes the connection to time-out can vary between different routers etc. This means if you set the check-in time to be too long, the connections will time out and your VSA will have to wait for another check-in before processing a command.
2. There are such things as quick check-ins and full check-ins for the Kaseya agent. A quick check-in simply says hello to the agent, asking if it has anything for it to do, and keeps that connection alive as mentioned. A full check-in will process commands from the VSA, as well as uploading any logs (Windows events etc) to the VSA. A full check-in seems to occur when there is a command for the agent, or otherwise at set intervals. This information is useful for understanding the impact a 30-second check-in will have on your server, although if your VSA is very busy 30 seconds will have an effect on response times.
I have no idea if the agent will initiate a full check-in when it notices something that is alarm worthy or if it waits. I also do not know how often a full check-in occurs if nothing is scheduled on the VSA end. This being said here is a little story:
We run a report daily which shows all the backup events for all servers. We had problems with some servers not appearing in the report even when backup events had occurred and the windows logs were being collected by Kaseya. I fixed the issue (bar one stubborn server) by running a "Force check-in" procedure ("The shortest script in the world") on all the servers about 30 minutes before the report runs. Scheduling this empty procedure forces a full check-in and the data is then available for my report.
I hope this helps understand check-ins a little more. For the record we are running 30 seconds on all our agents and everything is fine.
i understand all of that and it has nothing to do with my point. My point is changing the check-in time WILL affect agent responsive.
Of course. This all comes down to firewall configurations I guess.
Yes it would be interesting to test with no firewalls in the way