The User Role accessing the KLC endpoint must have the following access rights:

• Live Connect > Home > Home
• Audit > Asset > View Assets > View
• Audit > View Individual Data > Machine Summary (Machine Status OR View Single Machine Interface)

Depending on features used within Live Connect, some, or all, of the following permissions may also be needed:

• Module Permission
• Agent Manage Agents
• Agent Agent Logs
• Agent Procedures Schedule Agent Procedure
• Agent Procedures Get File
• Agent Procedures Agent Procedure Status
• Agent Procedures Schedule / Create
• Audit Installed Applications
• Audit Software Licenses
• Audit Accounts
• Audit Groups
• Audit Members
• Patch Management Scan Machine
• Patch Management Machine History
• Patch Management Machine Update
• Patch Management Patch Status
• Quick View Edit Procedure List
• Quick View Change Settings
• System Machine Groups

Domain watch for Kaseya agent install has issues both in the deployment and scalability.

Here is an alternative option for deploying Kaseya through AD Group policy using a msi package file created with a free tool.

MSI Wrapper (free version) by https://www.exemsi.com/

1. Download and install MSI wrapper
2. Download the latest Kaseya Agent generic installer exe : KcsSetup.exe
3. Unblock the executable:
4. Run MSI Wrapper:
5. Add the path to the Kaseya setup exe:
6. Set to Windows Installer:
7. Makeup your own Application ID and generate new upgrade code:
8. Accept Defaults:
9. Leave Blank:
10. Add install arguments: /e /c /g=v200.hybrid.acme /j /s g= is the Kaseya agents will place themselves in when they check-in. Add /v in VDI environments to reuse the computer account in Kaseya so duplicates are not created.
11. Next, Next Build
12. Place the MSI into a network share with domain read only permissions to the new msi file.
13. Create a new group policy in AD: Create a new package, browse to the share and select the new msi file.

Profit! You now have an automated way of pushing the Kaseya agent into an AD Domain without Domain Watch and vbs scripts

Make sure your Anti-Virus doesn’t mess with your VSA agents.  Here’s the link to the Kaseya KB article with regards to exclusions:

https://helpdesk.kaseya.com/hc/en-gb/articles/229014948-Anti-Virus-Exclusions-Trusted-Apps

One of the most important things in today’s IT support world is remote access.  I mean, hardly anyone even knows what “rolling trucks” means nowadays, am I right? (Showing my age even saying that, I know.)

We all know that there’s some way to get “there” … but which way should we use?   Oh, and sure, this whole remote monitoring thing is great, but how do we get remote access to a device to install a remote monitoring agent that … has our remote access service?!?

Hello, Chicken?
I’d like you to meet the Egg?

Enter: Live Connect on Demand
The Kaseya agent can be deployed pretty easily, as long as an end-user is present to do at least one installation (the “first one”).  But not all end-users have the ability, or maybe the access to do it.  So, we like to get in and help.

Let’s do this.

 Remember the first time you connected to an agent in Kaseya? It was so easy? First there was Quick Connect that showed all that information just by hovering over the icon.  Then in the toolbar was the button:  Remote Access!! (admit it, you heard the sound of angels singing – just for a second!) BOOM

Even better was the Live Connect button that connected you to that device without jumping into the middle of something you shouldn’t see, or worse, something you didn’t want to see.  Yeah, Larry knows what I’m talking about … (shiver)

But when you click these buttons the first time, nothing really happened.  Oh, wait – that window in the middle – click here to download.  Gotcha; now I’m connected to a machine and everything is alright. (and no unexpected – unwanted – images searing into your brain).

Well, guess what?  You’ve installed a program (congratulations – & there was much rejoicing) – a program that can be useful outside your VSA dashboard.  It’s the full-blown Kaseya Live Connect console. You’ll find it in the usual place: the Windows Start Menu.  (Mac? Mac-what? Big Mac?  well, you’ll figure it out)

Opening the application you’ve found presents a different interface you may not have seen before.  What do you do here?

Pretty simple: your credentials are your credentials.  Add the server and add your connectivity to VSA here!

Now you can LAUNCH the session; and up will come a list of devices that should look pretty familiar.  Heck, even the first column looks pretty familiar. Well, not as many pretty colors, but familiar nonetheless.

In the upper left-hand corner, you will notice an icon.  One, lonely, icon – there’s no other icons next to this one:

There you go – click and you’ll get all the information you need to remote into any device.  Even a place to add an email address to automatically have it emailed.  (According to the Live Connect On Demand Settings under the Agent menu).

Send it along, and the Live Connect interface will let you know when you’re new device is installed and ready to connect to.

If you don’t end up getting a new client for agent deployment, (I’m sorry) then you need not do anything because the (default) configuration will automatically uninstall the Live Connect software automatically.

But since you’ve now impressed this potential customer, I’m sure deployment of a full-blown agent will be coming forthwith!! Just a simple “sign on the line that is dotted” …

Booya.  Next? 

Have you ever had a machine that is online but trying to remote into it seems to show otherwise? What the heck is going on here?

It’s a simple explanation: it does happen, but isn’t really a bug.  Just a computer being a … well, a computer.

Sometimes programs running on a computer … stop.  Even ones that automatically start when the computer starts up.  Sometimes it just happens.   Come on … you know you’ve said that to a client and at the same time were secretly proud of your wizardry when you could restart it without the customer even seeing anything… That’s what’s happening here: there are 2 Services Kaseya uses:

1. Kaseya Agent – This is the service Kaseya uses to check into the VSA server.  The process name is AgentMon.exe.
2. Kaseya Agent Endpoint – This service controls Live Connect on the client.

The 1st service can be running, thus the machine checking in and for all monitoring purposes is “Happy”.  However the 2nd one can be stopped or hung, causing the condition you are seeing.  Machine reports online, but Live Connect says it’s offline.

Here’s a procedure to import into your dashboard to help kick start the Live Connect service if it isn’t allowing a connection.

NOTE: This should be used on-demand only.  There no reason to have this run on a reoccurring basis.

Alternately (or additionally) you could create a Monitor Set to automatically restart the service if it ever stops.

Download XML:  https://orbitalfire.net/TechsTogether/Procedure-Start-RestartKaseyaAgentEndpointService.zip

Import the Procedure under System -> Server Management -> Import Center.

If you have an endpoint that seems to continually need its service restarted in order to connect via Live Connect, please perform a “Force Update” on the agent.  A Force Update will perform a refresh install of the agent and the Live Connect components.  This should eradicate the issue.

• Navigate to Agent>Agents>Managed Agents. 
• Select the machine and click on Manage. 
• Choose Update Agent. 
• In the pop-up window, check the box “Force update even if…”
• Change the Distribution window to accommodate the number of machines you are performing the force update on.
• Click on Save
• You can watch the Agent Procedure log for the machine to see when the update is complete.  It should only take a few minutes.

https://helpdesk.kaseya.com/hc/en-gb/articles/360014667811-Creating-Limited-User-Roles-Scopes-for-VSA-Users-on-SaaS-

Now what?

Bitdefender’s integration comes with deployment scripts that are used in conjunction with your new module, but what about after that? Wouldn’t it be nice if you could see if Bitdefender was installed on those devices without having to open your GravityZone dashboard? 

There’s a quick setup you can use.  The cool thing about it is it makes a great example of how the pieces of Kaseya work together.

NOTE: The following setup is only as accurate as the last Audit that was run on the system.

Custom Field
     View
          Procedure
               Policy

Custom Field

View

Enable Advanced Filters and enter “Installed” or “Missing” depending on what you want shown.

Click to view:

Policy

Schedule to get response “quicker” than your Latest Audit schedule to create a new listing of devices.

In this image you can see the schedule set that looks for the file on each device. EPAG.EXE is the End Point Agent for Bitdefender, and will be present after a successful installation.

Remember to Save and Apply your changes for the policy so that it will be able to be distributed.  If the Policy you’ve set is already Assigned to a group or devices, please “Allow the Scheduler to apply” the changes over a distribution window.

You can take this a step further by creating a 2nd View to use in the “Manage Agents” view.  This view would be for people who don’t create or apply policies, and thus shouldn’t be editing a view with a “Policy – xxxxx” name / prefix.  This is totally up to you, of course.

Questions? Comments? Help? Contact us at service@techstogether.com.

If your users are getting a ‘not approved’ message when they create VSA procedures and then try to run them, and you go there yourself, create a procedure and it’s approved automatically, you need to disable Policy Signing.

The signing and approval of user saved agent procedures is enabled and disabled

using the System>Default Settings> Enable Agent Procedure Signing.

Set it to “No”. It is set to “yes” by default.

This should solve the issue.

Kaseya VSA provides their own 2FA now. So, if you would like to switch from AuthAnvil to VSA 2FA, here are the steps to follow:

1. Setup an account that is whitelisted in AA so you don’t lock yourself out of your VSA.  (Or just make sure our account is active and whitelisted so we can get in if you lock yourself out.)

2. In the AA module, replace the current info in the AuthAnvil SAS URL with this:  https://localhost/AuthAnvil/sas.asmx

3. In the AA module, check the box for Disable Two Factor Auth during Kaseya server logons.

4. Click Save.

5. Setup the new 2FA and verify it works.

Once you have everything working, let us know so we can remove your AA account from our server.

Wondering what you can do reports on in the VSA – here is a useful website that shows the database views. They allow clients to directly access data within the Kaseya repository. These views can be used to bring data into a spreadsheet for analysis or to prepare reports.

http://help.kaseya.com/WebHelp/EN/VSA/9050000/#3480.htm

Here are detailed instructions, how to use the Reporting feature in the Kaseya VSA.

Go to Info Center -> Reporting -> Reports

Click New -> Report on the top bar

Category doesn’t matter because we are making a report. In any category choose **New Custom Report** and click next.

Now your report window to make a report appears. You are going to need to name it, and add things to it.

Report Parts contain the datasets you are going to want to add. If you want to see what info exists in a report part in advance, you can see all report parts in Info Center -> Configuration & Design -> Report Parts. For example:

For this example we will use that report part. In your creation window, expand report parts, expand logs, and click and drag Kaseya Remote Control Logs into one of the boxes to the right.

We want a table, so in that box click the far-right icon. You can also make the table bigger by clicking the double window symbol and choosing expand right.

We need to add data to the table now, so click the gear in the top-left and a new window will open.

You can see here we are working with the Dataset Kaseya Remote Control Log. You need to add a name to this table too.

Columns you can add are to the left. Click and drag the ones you want to appear in the report to the right.

When you have all the columns you want. Click next.

In the next page you can set up the way your data is ordered or grouped. If you ant to order by computer name you can do that. If you want to group the data by the name of the administrator you can do that. You can order and group by any column even if you didn’t include it in the report itself. Click next when you are done on this page.

The final page lets you add filters. If you only want to see a certain computer, administrator, dates, etc., this is where you can filter that.

When you are done, click finish. If you want to have your report come out in a different format, such as for excel, you’ll need to click on the general tab and choose excel. PDF is the default.

You can add more report parts to other boxes in your report if you want to have other data in it. It is not possible to directly merge report parts so depending on what you need it might be best to make a separate report for each report part you are interested in.

Once you are happy with your report, click save.

Now find your report, select it, and click run.

Choose the group you want to run it for, and run your report.

As a note, Kaseya stores different remote control info in different sections. You might need to make and run more reports to get everything you want.

Kaseya Remote Control Log, Legacy Remote Control Log, and Agents KLCAuditLog might all contain data relating to remote connections.

Whenever you want to get Policy to apply, pay attention to the View that is used in the Policy. 

Whenever a Policy does not get assigned to the expected machine, it’s because the View used in the Policy, does not include the machine.

Make note of the View assigned to the Policy in question, navigate to the Machine list, change the View filter at the top of the page to the View used in the Policy, and refresh the page.  If the machines are no longer listed, the View is your issue. 

Correct the View, then once the machines are listed as part of that View, Reprocess Policies and they will apply.

If you can get the user to install Live Connect, by having them download it here: https://serverus01.techstogether.com/ManagedFiles/VSAHiddenFiles/KaseyaLiveConnect/win64/KaseyaLiveConnect.exe , they can run the LC app on their desktop. Once they’ve downloaded and installed LC, have them search for Kaseya Live Connect on their machine. They will be presented with the Manage Servers window which will be empty. Have them click on the “Add Server” button and enter the server URL: https://serverus01.techstogether.com Once the server is in the list, click on the Launch button and enter their creds. This will launch LC and present them with the machines that are in their Scope. They can then launch remote control from there.

Please be aware that this app currently does not use the 2FA.

The agent needs to communicate with the VSA server on TCP/UDP port 5721.

If you’ve installed the agent, and verified the “agentmon.exe” process is running in the task manager, but the agent isn’t showing up in the VSA,

there is an easy fix. Install Telnet on the machine, if it isn’t already.

Open a command prompt and type the following, based on which server you are on:

MyRmm – telnet storedtech.myrmm.com 5721

TT US – telnet serverus01.techstogether.com 5721

TT EU – telnet servereu01.techstogether.com 5721

If you get a message that the connection was refused, you need to make sure TCP/UDP port 5721 is allowed OUTBOUND in the firewall.

A successful connection will just present a blank screen. Once you get a successful telnet connection, the agent will check in and show up in the VSA.