In our typical VSA implementation, we create four distinct access levels, and several sub-types for MSP employees, plus three roles for customer access. No user has Master role rights in our deployment configuration. These roles should have a “NOC” or “MSP” prefix to designate them as internal roles.

Level 0 – Support A role designed for support staff to access VSA for running reports, getting agent counts, or checking use and available licensing. No access to automation is available, but these users can view agents and have virtually unlimited access to the reporting functions.

 Level 1 – Technician This role, which we name “NOC-1-Tech”, grants the ability to perform basic agent administration, view audit and other configuration settings, and access remote control features. This provides the ability to perform about 80% of what a technician would do on a daily basis for end-user support.

Level 2 – Administrator Named “NOC-2-Admin” in our system, it grants additional capabilities to run procedures, deploy AV and AM, and perform most agent configurations. Neither of the above roles permit changing the configuration of VSA-wide settings.

Level 5 – Specialist These roles grant VSA administration rights to specific features, distributing the administration tasks among multiple users. In our practice, we use the following specialist types:

• Security – provides the ability to perform all Auth Anvil configuration and management tasks.
• AV-Malware – grants access to administer the Antivirus and Malware components, including definition of profiles, policies, and assigning them to customers.
• Updating – allows administration of all Patch Management and Software Management components. It may also allow access to other application updating components.
• Backup – Allows configuration of all VSA settings related to backup operations.
• Manager – grants a combination of roles, usually assigned to the Dispatch, helpdesk or Technical Manager(s).

Implementing these security roles will allow for better security and organization within your VSA infrastructure. To learn more, schedule a demo for MSP Builder’s RMM Suite!

Since you are already in a protected environment (you lock your doors and have a firewall and other logical and physical security – right?), you don’t need to require MFA. Most MFA solutions provide one or more methods of “whitelisting”. Which method you choose will make the difference between being secure and not…

User Whitelisting

User whitelisting is used for application accounts that would not be accessed externally, or support accounts that need to be used by external support teams. You would never whitelist your employees! Unfortunately, we see this configuration all too often. When we point it out, the response is typically “yes, but we trust our team!”

Sure – you can trust your employee, but you can’t trust their credentials! That’s the distinction that MFA makes. If an employee’s credentials are compromised, any bad actor can try to log in. If their account is whitelisted, there would be no Multi-Factor authentication and access would be granted!

Network Whitelisting

Network whitelisting identifies the internal network range(s) that you trust – typically the office network public addresses. In most situations, this would be the public IP address assigned to your external firewall (or firewalls if you have redundant Internet connections). This is the preferred way to allow your techs to work without MFA when in the office, but require it when they are at home, customer sites, or otherwise outside of the office.

MSP Builder Tools

Many of the MSP Builder tools utilize the VSA APIs to perform their tasks. While these tools use the API to authenticate over an SSL connection, there are some processes that we follow to improve the security of these tools. As each tool runs, it requests an authorization token to do its work by authenticating to VSA. The tasks that the tools perform take anywhere from a few milliseconds to about 3 seconds to complete. Once the task completes, the tool closes the session, invalidating the authorization token.

Another level of security that we use is MSP Builder License Authorization. All tools that utilize the APIs must first authenticate to the MSP Builder licensing server. This authorization is such that it is extremely difficult (if not impossible) to circumvent, requiring multiple data parts to complete a license validation. In a sense, this is a form of MFA for the tools that utilize the Kaseya APIs. Our API account does not require the password to be distributed to the systems that use it, and is designed to be changed on a 24-hour cycle, increasing the difficulty of a brute-force attack.

Summary

Multi-Factor Authentication is an excellent method to improve the security and integrity of your environment, but it requires careful and correct configuration. Incorrect settings will negate the security you’re trying to deploy, so take your time, double and triple-check your configuration, and use whitelisting options properly!

Many MSPs have complained recently about policies (and possibly other objects) disappearing when they are moved within a specific group, or moved and dropped into a group. If you are on On-Prem VSA user, the following SQL queries can be used to recover these objects. The queries can also be provided to support if your VSA is hosted in SaaS - they will need to be adjusted for the proper tenant ID.

The problem

...occurs when you try to move an object within a folder (change the display order) or move an object into a different folder. This causes the object to "disappear". The problem, specifically, is that the objects within a folder are identified by a folder path and a parent ID. The two usually match, but the current bug seems to change the parent ID value. This prevents the object from appearing in the folder location even though it is identified as belonging in that folder path.

Workarounds

Until the problem is fixed, don't manually re-order objects within a folder, no matter how much it bothers your desire for order and structure! :)

If you need to move an object into another folder, drop it onto the folder icon directly, not into the folder in-between other objects. If you hold the object over the folder icon momentarily, you'll notice a small flash - the text switches to italic and back to normal. This indicates that the target has been validated - that's when it is OK to drop the object.

Recovery

There are two methods for recovery, and both work equally well. Choose one or the other based on your comfort level with performing SQL Queries on your VSA.

Non-SQL Method

This method takes a bit longer and is a bit more invasive, but requires no skill with running SQL update queries.

1. Export ALL the objects from the folder containing the missing object via Import Center - the missing object should be visible there!
2. Edit the exported XML - compare the "missing" object with the other objects - the "parentId" will probably be different for the missing object. Update the parentId value to match the other records.
3. Delete the original folder with all objects. Deleting the folder will also delete the hidden objects.
4. Import the edited XML file. It should return all objects, including the missing one.

SQL Update Query Method

This method is fast and the results immediate, but does require understanding of the SQL commands to locate and then update the "parentId" field with the correct value. Please be sure you have good backups and are familiar with SQL queries before choosing this method!

1. Run the following Query to list all of the objects in the specific folder where the missing object should be:
   SELECT * FROM tree.treenode WHERE treeFullPath LIKE '%<FOLDER_PATH>%'
   where "<FOLDER_PATH>" contains enough of the folder path to uniquely identify it. In our case, the folder's unique name had "Agent Settings (" in it, so that's what we used. This will return a list of all of the objects in that folder, including the missing one(s). Take note of the objects that have matching treeNodeTypeFK values, then locate the missing objects. These will have a different parentID value from the other objects that are visible in the folder. Identify and record the parentID value of a visible object.
2. .Define the following query, but do not execute it yet!
   UPDATE [ksubscribers].[tree].[treenode] SET parentId = <parent>
WHERE ref LIKE '<policy name>'
3. Edit the query:
   • Replace "<parent>" with the parentID value determined in step 1 - this is the Parent ID of the visible objects.
   • Replace "<policy name>" with the name of the missing policy.
4. Confirm that you are replacing the parentID value on the record where the ref field matches the specific missing object, then execute the query.
5. Re-run the query in step 1 to verify that the missing object now has the correct parentID value.
6. Check the VSA to confirm that the object is once again visible in the correct folder.

Steps 3.2, 4, and 5 can be run for additional missing objects in the same folder. Repeat all of the steps to recover missing objects from other folders.

In our testing with System Policies, the missing policy reappears  in it's original location after performing the above steps and the VSA page is refreshed.

NOTE
MSP Builder does not assume any liability for issues that arise through the use or misuse of this process. It is assumed that you are comfortable with VSA administration and qualified to perform the techniques presented herein.

These are the essentials for creating a VSA platform that is "automation friendly". If you read my article on Monitor Sets, you'll recall that our monitors utilize a machine-readable subject line. This allows our automation to break down the alert, attempt remediation, and ultimately route the alert properly. This is possible because every header has the same structure, and every field has the same kind of data in it. It's time to apply this logic to the Machine Groups and create a hierarchy.

Kaseya defaults to a machine group below the Customer ID called "root". This meaning may have become lost over time, but it's intent is the root where an object hierarchy is built. This is the point where System Policies are linked. Using a rooted machine group with subgroups is the only way to apply a policy to all agents for a specific client and easily differentiate between managed and unmanaged locations. Important concept #1 – Organization is critical for effective automation!

So often when working with an MSP, I find the default "root" group present and containing most of the agents, and then other groups at the root of the Customer ID representing different locations, machine types, or other groupings. This, sadly, is not a good plan as any policy common to all agents must be linked multiple times. This introduces risk through the possibility of not linking critical policies to all groups or linking them to the wrong group. The primary purpose of a machine group is very similar to Active Directory OUs - organize objects to apply policies. To do this effectively, you need to design a hierarchy based on how you might apply policies. Important concept #2 - System Policies are the Heart of Automation. To effectively use policies for automation, the machine groups must form a reasonable hierarchy. Consider how you might automate things and how policies themselves work. A policy can run procedures when a condition is met, schedule procedures, and define configuration settings. Configuration settings is a big consideration, since they are often different between workstations and servers, right? So - you should have groups that allow linking policies based on the class of system.

Our Core Automation Suite depends upon a standardized machine group structure, and we leverage the Dickens out of it. We can configure and schedule patching & application updating, configure AV and AM products, apply monitor sets, and much more, all with a minimum of manual involvement. (In fact, for almost all customer onboarding, all we do manually is define the server patching sequence.)

Change is Bad Good!

Almost every MSP we've worked with to help optimize their platform has had their staff initially complain about the changes to the structure. Not because the structure was bad or confusing, but simply because it was - change! Every MSP, after using the new organizational hierarchy for a couple of days, universally agreed that it was easier to find agents by type, site, and class of service, and that the automation that this organization allowed reduced everyone's workload. Of course, this takes effort - whiteboard the structure based on policy linking, accommodate requirements of different customers, and different kinds of clients, and a method to define sites that works globally, not just in your back yard. Once the planning is complete, you can create the machine group structure for the clients and move the agents, cleaning up old groups when the last agent has been moved.

Oh, remember "consistency"? If you create a site group for a customer that has 10 sites, you should create the same structure for a customer with one site. Why? CONSISTENCY, of course. It's all about the ability to automate and know exactly what the data format will always be in! And - should the customer expand and add a second site, you simply create a second site group and add the new agents there - no need to restructure, add 2 groups, and move agents before you can add agents from the new location. To simplify the decision process and remove any “emotion” from the process, we utilize the United Nations LOCODE standard for identifying the locations – they have IDs for virtually every town or city on the planet.

Why have a workstation and server group – I use Views to handle that!

Sure – we use over 300 views, and around 150 of those just for policy management, but we strongly recommend separate groups for workstations and servers in each client group. This allows you to accommodate situations where a developer might use a server O/S for their workstation, or – more commonly – a workstation O/S is used as some kind of “server”. I can link a view to a policy that alters the monitoring or configuration settings simply because an agent is in a “*.servers.*” group – it’s a workstation, but should be monitored or configured like a server! This can’t be done if you simply apply views based on the O/S type. We also recommend the use of a group called “special”. Any view should exclude this group – it is a simple way to temporarily stop all automated processing by simply moving the agent into that group.

So, to summarize, we create a root group that identifies whether the customer is managed or unmanaged, then subgroups for servers, workstations, and special. The servers and workstations groups have subgroups for each location that the customer has, and only the location groups and the special group contain agents. This took time and energy to design and define, but the payback has been extensive. When an agent checks in, the automation runs, figures out what the agent has, where it is, and automatically applies monitors, schedules patching, daily maintenance, and application updating. This is all made possible by using a consistent structure that the automation can leverage.