Things to try when Kaseya Live Connect (KLC) doesn't seem to be working...
In July I wrote a blog article about how to improve the performance of KLC by pre-installing the KLC modules on a scheduled basis. With the release of 6.2, this is still a best practice. If you have your own on-premise KServer (or you are on our K2 server), you should schedule the “Execute Deploy Live Connect” script every Friday between 3am-8am. If you are on one of Kaseya’s hosted servers, you should schedule this to run every Saturday afternoon (> 3pm). This will ensure that all your systems are already up to date when you need to remote control them.
This all works really well most of the time, but this blog is about what to do when things don’t seem to be quite working they way you want them to.
It takes two to tango as they say, and it is very true when trying to connect remotely to a computer using KLC. The problem could be on your side (Admin), or the remote side (Agent).
While Kaseya supports all the major browsers (latest versions preferred!), but our recommendation is to use Chrome or Firefox. These two browsers make it fairly easy to un-install and re-install plug-ins. For IE, it is a little more complicated. Kaseya has a guide on how to do this for the first two here. For Internet Explorer, refer to this KB Article.
The simple troubleshooting step here is to switch browsers and see if it works. If it works well on a 2nd browser, then follow the above referenced steps and remove and re-install the plug-in on the first one.
You start KLC and get the dreaded “Live Connect is updating the agent-side code….”? Here is what you do next.
STEP 1: BE PATIENT! It is possible that the modules are not completely up to date, and Kaseya has to download and update them. There are rare times, depending on bandwidth, that this could take over 10 minutes to install. The problem is that the Live Connect process will time out after 10 min, so if you find it going longer, refresh your browser, it may have just timed out.
STEP 2: Check to see that the Agent Procedures relating to installing KLC have executed, and executed successfully. Inside KLC, click Agent Data module, and on the “Pending Procedures” tab, check to make sure that “Start KLC on xxx” has run, if it has, check the status and make sure that it was successful. If both are true, try again, your browser process probably timed out. If it is still yellow (pending), try to wait it out.
STEP 3: Make sure that you have the latest version of the Kaseya agent installed (I wrote about this here). Update it if necessary and try again.
STEP 4: On the remote machine, kill the AgentMon.exe process, and restart it.
STEP 5: If that doesn’t work, reboot the whole machine. (Heck reboot your machine too while you’re at it!)
STEP 6: Last Draconian measure… uninstall and re-install the Kaseya agent.
If none of the above steps work, you are probably dealing with an unusual situation, and taking troubleshooting further requires collecting log files and reviewing them for errors. There is no easy explanation on how to do this, so open a ticket with us (or Kaseya) and we can help.
I hope this helps!
Friday, October 21, 2011
Saturday, August 6, 2011
One of the best ways to keep your agents working at optimum levels is to keep them updated. There are several types of updates that come out… major version and minor updates.
Major version updates are changes to the 1st or 2nd numbers in the version chain (i.e. 5.1 to 6.0, or 6.0 to 6.1). As a general rule, you ALWAYS want to update to the latest major version.
Updating to a minor version is normally not required unless you are experiencing problems with the agent, although if you see that your minor update is 4 or more updates behind, go ahead and update anyway!
I have noticed on several of the K2 servers that there are still quite a few agents that are one (6.0) or two (5.1 Yikes!) generations old, and need updating.
HOMEWORK: Log into the Kaseya server, go to Agent tab, Upgrade Version, and click Update Agent. Look at the results for your machines (see sample below). Anything that is in RED needs to be updated.
To update the agents, simply select the agents to update from the list by checking the box(es) (#1), then select “Update Agent” at the top (#2).
If you want to upgrade your agent to a “minor” release, then check the “Force update even if agent is at version 184.108.40.206” box before you click “Update Agent”.
WARNING! For the sake of a shared system, if you have a number of upgrades, do a few at a time so as to not overload the system!
Special note for Migration clients (others may ignore)
If you have migrated from an older version of Kaseya (5.1), I have noticed a situation where there are still multiple agents showing up on a system. Now it may be that only the K2 (v6) agent is actually running, but it does appear that there are remnants of the old version still on your computers.
To look for this, create a View called “Old Kaseya Agent”. Check the box next to “Contains” and fill out the section as below:
Apply this view to all of your computers. With this view in place, any computers that show up will have an old version of the AgentMon.exe on the system.
To verify this information, you can go to the Audit Information tab inside Live Connect, and select the “Installed Apps” tab. As seen below, you will see two versions of the AgentMon.exe and the KaUsrTsk.exe showing versions of 220.127.116.11
If you don’t actually have two agents running on the system, you can clean this old stuff out and keep your machines in great shape!
Monday, July 25, 2011
Here is a quick tip on how to save some money and at the same time get some free agents on your IT Center account.
It all has to do with price breaks.
Kaseya’s IT Center is sold on-demand with no commitments or requirements. You can change the quantities at any time and the price gets better as your quantities increase. One of the things often overlooked is price breaks. Because there are significant price breaks at 10, 25, 50 and 100, you should be paying attention to how many agents you are purchasing.
For example, if you need 40 agents, you would pay 40 * $4.95 per month for a total of $158.00, however if you bumped your purchased quantity to 50 agents you would only pay $147.50, a savings of $10.50 AND you would get 10 more agents to use for “free”.
Below is a cheat sheet to use showing where the breaks are:
|Price Breaks on Kaseya's IT Center|
Another tip: Set a calendar reminder 2 days before your billing date, and review your quantities every month. Your billing date is the date you first paid for agents. Adjust quantities of all purchased services then.
Saturday, July 23, 2011
The midnight oil is burning over at Kaseya’s KLC dev team, and every release makes the product better and better, however, one of the downsides is that the code has to be updated more frequently, and many report delays in connecting to their machines. In this blog article, I am going to share with you a great tip to improve your experience with KLC.
First a little background:
KLC is comprised of 7 modules wrapped up into one 15MB download. Currently if ANY of the sub-modules change, the entire module must be downloaded, thus delaying the time it takes to connect. (Note: this is likely to change in future release). Since download speeds vary, connection times can be unpredictable.
Because of the consistent updates and upgrades to the Kaseya Live Connect module, you will find yourself waiting for these downloads pretty frequently, but there is a solution.
Enter the “Execute Deploy Live Connect” script. Kaseya’s dev team created a script that does the same basic thing that happens when you try to connect using KLC… It checks to see if the latest KLC code is up-to-date, and if not, updates it. Except now you can SCHEDULE these updates on a regular basis.
To completely change your experience with KLC, simply search for “deploy live” from the Agent Procedures tab, and schedule ALL of your computers to be updated on at least a weekly basis. (I would suggest sometime over the weekend).
|Kaseya Deploy Live Connect Script|
If for any reason you can’t find the script, simply download it from here, save and import.
Once you get the code updated, connections should take about 20-30 seconds. This is because each module needs to be checked to see if it is up to date, and it takes on average about 3 seconds per module, thus about 21 seconds. In future release Kaseya hopes to reduce that time by using a checksum total, so that only 1 check needs to happen.
Saturday, April 16, 2011
Some of you may have seen our Webinar on using Kaseya K2 to audit your machines, to verify the versions of 3rd party software. In short, you run the script(s) on the machines you are auditing, and the script writes a series of tags to the Procedure Log, and we use those tags to generate a report.
So we thought, “This is great, but how can we automatically identify all the machines that need an upgrade?” Normally you would use a View to help segment a part of your installed agent base, and focus attention on just those results, however there is no way to create a View based on the results of a Procedure log, but there is a way to generate a view based on having run a script.
This is a great way to create a list of machines that need some type of follow up later. We demonstrate this using an Audit script, but you can do this with any script.
Here are the steps:
We created a “dummy” script for each audit we wanted to track. All this script does is write an entry in the script log.
We modified our Audit script to call this dummy script anytime it was going to record that an application was out of date. (In the picture below, notice the tags in the line above the highlighted one. $Audit$ means this was done with Audit script, and allows us to report on all audits. $Reader$ means this is Adobe Reader audit, and allows us to report on ALL Adobe Reader results, up-to-date or not, and last $OOD$ means we found this version to be Out-Of-Date, this is the key we use to list only those applications that are out of date.)
Create a View to show the machines that have run the “dummy” script.
a) Do this by setting View to <No View>, then clicking Edit.
b) “Save As” to create a new view, give it a name, and save.
c) Scroll down and click on “Agent procedure... “ (#1)
d) Select “has” radio button (#2)
e) Click “select agent procedure” (#3)
f) In the pop up box, locate the “dummy” script that you ran in Step 2, and select it:
g) Verify that the correct script shows as a link (#4)
h) Change the “executed in the last ‘x’ days” (#5) to the period of time that is appropriate. This will depend on when you ran the Audit script. Change this as needed.
You are done! The next step is to run your audit script on the desired machines. Wait for them all to finish, and then use your new View to identify all the systems that have out-of-date software. You can then use this View and run the correct installation/update Procedure on only those systems that need it.
If you have any questions or comments, please let us know.
Friday, March 4, 2011
Troubleshooting Monitor Sets that are Not Responding
Jim Bulger, Sr. Engineer - Virtual Administrator
Monitor sets are an important part of Kaseya's ability to maintain the health of your servers and workstations. Monitor set can perform three separate tasks, monitor Windows PerfMon counters (Counter Thresholds), monitor services (Services Check) or monitor a Process (Process Status).
Kaseya monitor sets are fairly easy to setup, and normally work just fine, but in cases where they are not working, hopefully this article will help you troubleshoot them.
Virtual Administrator default monitor sets
Monitor Sets have one or more counters associated with them. Each counter will have a corresponding value when viewed through the Monitor> Agent Monitoring> Monitor Log. When we set up your account Virtual Administrator added two monitor sets to your server templates (a_server_template).
a_VA - Base Server Performance (monitors Avail memory, CPU Utilization, and Paging)
a_VA - CM2-Critical 2 % Low Free Disk Space for all Drives
These two monitor sets are automatically applied to machines that have the agent installed using the Server Deployment Package. You can review the status of a monitor set by going to Monitor tab -> Agent Monitoring -> Monitor Log. Then click on the machine ID that you want to review.
How a monitor set gets applied
When a Monitor Set is applied at least two files are created in the agent working directory (usually C:\kworking). There will be the XML file with a file name like "KMON$1234.xml" in the kMonitorSets folder (i.e. C:\kworking\kMonitorSets\ KMON$1234) and one or more CSV file with a file name like "KLOG$1234.csv" (i.e. C:\kworking\KLogs\KLOG$1234).
To figure out which XML file belongs to which monitor set, go to the Assign Monitoring function, and hold the cursor over the "pencil/graph" icon to the left of the Monitor Set and look at the bottom of the page. In the example below Monitor Set “ZC-SV2-Machine Health” creates KMON$1063.xml.
Determining the KLOG$ files requires a little digging. Open up the KMON$ XML file in Notepad, and you will see which KLOG$ files are being used by that monitor set. In this case KMON$1063 created KLOG$1076.csv, KLOG$1078.csv and KLOG$1080.csv
Troubleshooting Monitor Sets
Step 1. - Check Agent Version
As with many problems in Kaseya the first step is to make sure you have the most current version of the Kaseya agent installed. Go to Upgrade Version> Update Agent. Check the “Force update” box and click “Update Agent”. Older agents versions will be in red letters.
Step 2. - Remove and re-apply Monitor set
Also try removing then reapplying the Monitor Set. It’s possible some of the files are missing or corrupted. Reapplying the monitor set should recreate the files. The monitor sets can take 20 minutes to start returning data.
Step 3. - Check permissions and credentials
If the monitor sets are still not working check to make sure the XML and CSV files are created in the agent working directory. If they are not, the most common cause is the credentials on the agent do not have read/write permission to the agent temp folder AND the sub folders. By default the agent uses the system account credentials. To add other credential go to the Agent> Configure Agents” Set Credentials page and add. Make sure to run the Test to verify that they work. You should get “Passed”.
Step 4 - Check PerfMon
If the files are created but the Monitor Set is not responding, look at the Performance Monitor (Start> Run> type “Perfmon” press Enter). Look for counter with the corresponding Monitor Set number with KCTR$xxxx. These are the logs that perfmon is saving the data to. If it is green it is running. If it is red try to start it by right clicking on it and clicking “Start”.
Windows XP and Server 2003
Windows 7 and Server 2008
Step 6- Check Event Logs
If the Perfmon counter doesn't start, open your event viewer and see if there are any errors created. Research and resolve those errors. Kaseya can't report on it, if it doesn't work in Windows directly.
Step 7 - Check Performance Logs and Alerts Service
If the proper files are being created by the monitor set and the Monitor Set is still not responding the problems is most likely the Perfomance Logs and Alerts service. Research any errors you find and get the service running. Then reapply the monitor sets.
If the Base Server Performance monitor is working but the 2% free space is not try running the diskperf –yv command to enable the counter.
Hopefully this will help you troubleshoot any monitor set problems you might have.