The LAUSER Account

Back in 2019, a customer related an experience of when a VIP user at a major customer was in an airport lounge. The user needed to print their presentation and needed admin access to install the print driver. The WiFi was limited to http protocol access, which prevented the MSP from using their RMM to provide support. They had no choice but to provide the user with their internal use password. This required changing the password throughout that customer environment. We suggested that a commonly named account ("lauser") could be created and our automation could maintain and update the credentials on a weekly basis. We rolled that process into ITP and began deploying this account for our customers soon after.

A few years later, MSPs are looking to improve security and decide to use the LAUSER account for their local access. This led to an additional improvement in this component, allowing multiple accounts to be created using this process.

One of the unique security features of this process is that the password is generated based on using the date, time, and hostname, along with other logic, to seed the password generation logic. This ensures that the password is machine-specific and impossible to re-synthesize.

The RAUSER & CAUSER Accounts

The RMM Suite has long supported the use of per-client accounts for the MSP (RAUSER) and the customer (CAUSER), first via Managed Variables in Kaseya VSA and now via self-ciphering Cloud Script Variables on all RMM platforms. These accounts offer the flexibility of selecting the actual login ID, display name, and password. These credentials apply to groups of agents, whether an entire customer organization or specific location or department.

RMM Suite Account Management Tools

The RMM Suite continues to support multiple methods of local account management.

• If the RAUSER (or CAUSER) Cloud Script Variable (CSV) is defined (both UserID and Password), the account will be created, added to the local administrators group, and the defined password will be set on the account. This happens automatically the first time that an agent checks in. These accounts can be updated at any time by updating the account password stored in the CSV and then executing the appropriate WIN-Local Account script on the RMM platform, targeting the endpoints where the account should be updated.
• The LAUSER technology has been enhanced and migrated into our Daily Maintenance tool. Simply create a Weekly or Monthly task to run the LAUSER command. This will generate a long, complex password; create the account and add it to the Administrators group if necessary; then set the password. The password will be ciphered and written to the system registry, where it can be collected by the Daily Audit tool, deciphered, and pushed into the RMM or your documentation engine such as Hudu or IT Glue. You can define multiple tasks in Maintenance with the LAUSER command to create any number of local admin accounts with unique credentials. 
  • If no argument is defined, the account name "lauser" is targeted. This maintains the process we implemented several years earlier and allows this account to be given to the user as necessary. It may be appropriate to update the frequency of this account change.
  • If an argument is provided, it will be used as the account name. This argument should be a single word without spaces, following the usual guidelines for user account IDs. 

Service Class Automation

Just to clarify the term, "Service Class" (or Class of Service) usually assigns a name to the delivery of specific services. A good example is the classic Bronze / Silver / Gold terms, where Bronze might provide basic monitoring and AV while Gold provides advanced monitoring, proactive maintenance, and comprehensive endpoint security services. This can related to several services within an MSP practice, including monitoring, software, maintenance, patching, and security.

The RMM Suite employs a basic Service Class of Unmanaged and Managed, which is used broadly to apply or block automation. 

Unmanaged - This can be a "break/fix" or "time and materials" customer with no automation. RMM Suite customers also use this mode to onboard new clients. Since an unmanaged customer receives no automation, it allows a period of time after deploying agents to perform discovery actions. This can lead to preparing custom configurations, setting up software licenses for automated deployments, and identifying any special monitoring requirements. Once all customer preparation is completed, a client can be switched to Managed. This is defined using either a Customer Custom Field or - in VSA - a Machine Group root name.

Managed - This represents a generic state where ALL automated services can be applied. The automation policies specifically look for the "unmanaged" status, treating all other status types as "managed". This allows a generic classification of "managed" as well as specific sub-classifications or Service Classes. The service classes can also be used to drive client billing.

Service Classes - These are codes - whether colors, metals, animals, or simply an alpha-numeric ID - that define a specific set of services. These codes can be distinct or cumulative - that's completely up to the MSP. Cumulative codes take a bit more planning and configuration effort, but can simplify certain aspects of the automation.

Distinct Code Mapping

Distinct codes will map a set of specific components and services to a single code. A system filter identifies the code and applies the appropriate services. Note that the same services can be associated with multiple Service Class codes.

Iron - Basic AV, Patching

Steel - Basic AV, Antimalware, Patching, Application Updating, Basic Monitoring

Titanium - Advanced AV, Endpoint Security, Antimalware, Patching, Application Updating, Basic Monitoring, Advanced Monitoring

There are three automation policies and three filters. The filter checks for the Service Level code and applies the automation policy. The policy applies the products and services that are part of the Service Class. You will see that two policies have Basic AV, Antimalware, and Application Updating, three have Patching, and two have products unique to that class, This is a simple mapping of code to services and works well when there are a small set of classes and products.

Cumulative Code Mapping

This method creates a filter and automation policy for each distinct product or service instead of the service class. The filter applies a specific product or service when it matches one or more Service Class codes. This is how it works:

Basic AV - Filter triggers at Iron OR Steel levels

Advanced AV - Filter triggers at Titanium level

Antimalware - Filter triggers at Steel OR Titanium levels

Patching - Filter triggers at Iron OR Steel OR Titanium levels

Basic Monitoring - Filter triggers at Steel OR Titanium levels

Advanced Monitoring - Filter triggers at Titanium level

While this is certainly more complex and requires distinct filters and automation policies for each service, it provides greater flexibility when there are additional Service Classes. Consider adding a new "Tin" service class that only provides patching, and an "Aluminum" level with Patching and Application Updating. By simply updating the filter associated with the products to trigger on these new service classes, the automation applies without the need to create both new filters AND automation policies. 

How the RMM Suite uses Service Class Mapping

Each day, when the Daily Audit application runs, it determines the Service Class code assigned to the customer. This starts by checking for a Customer Custom Field called CCOS. The value - if defined - is mapped to the "SC:id" tag and written to the System Roles Agent Custom Field, along with any other TAGs based on the applications and services found. The TAGs can be used to drive views to apply policies, which is useful for applying the monitors associated with these Service Classes. The TAG can also be used directly by the Daily Maintenance tool to install application components, either by local script or RMM script.

A second advantage of this method is the Service Class identity is added to a machine-specific field. Some RMMs do not expose the Customer Custom Fields to agent scripting and this circumvents that deficiency.

Detecting the Application

The RMM Suite provides a highly customizable Daily Audit feature that can identify applications either by registration with Add/Remove programs or as an installed service. The first step is to determine the best detection method. 

Application Name/Version Detection

Start by examining the SysInfo.INI file from the agent where the software is installed. This is the Daily Audit cache file and is located in the PROGRAMDATA\MSPB folder. Many RMM platforms will collect this file and store it in the agent's data folder automatically when the Daily Audit completes. Open the file in a text editor such as Notepad and locate the SWINFO section. This section lists all of the application / version / vendor data reported by Windows. Determine if the application is listed - if it is -  copy the application ID into the AUDIT.INI configuration in the APP VERSION ROLES section and define a unique TAG value. Tags should be 3-4 alpha-numeric values to identify an application and version.  Note that multiple detections are possible - a check for "Accounting - 12.6" can map to "AA126" while a generic "Accounting - " can map to "ACCT". The generic tag can be used to detect ANY version while the specific can identify a particular version. Once this entry is added to the Audit config data, detections will begin during the next daily operational cycle.

Service Detection

A Windows service provides a simple and direct detection method. Start by identifying the name of the service by running "Net Start" in a command prompt on the endpoint where the application is running. Identify the correct service name and add it to the SERVICE ROLES section in the AUDIT.INI configuration data, assigning an appropriate TAG value. This detection will begin during the next daily operational cycle. 

Leveraging TAGs in Daily Maintenance

Each task in Daily Maintenance can be tied to one or more System Role Tags. Actions can be taken when a tag is present or missing, and can be combined to require multiple related tags. Tasks can be used to directly upgrade software by looking for an outdated version TAG or can run multiple tasks to uninstall the existing version and then install the new version. The tasks can be local scripts or RMM Scripts run by API, or any combination. Daily Maintenance can directly unzip and execute packages deployed from an RMM script, or download a package hosted by MSP Builder. (MSP Builder packages utilize a security token to assure authenticity. We host your custom packages at no additional cost and add the security token when created or updated.) 

Note that Daily Maintenance tasks are executed in the sequence that they are defined, so be sure to order them so an uninstall is run before the update process. 

Summary

The RMM Suite automation provides a rapid and low-impact mechanism for application and endpoint maintenance with several significant advantages:

• Tasks run every day on every endpoint, providing maximum delivery exposure.
• Daily Audit runs immediately prior to Daily Maintenance, identifying software and services.
• Daily Maintenance can leverage the TAGs set by the audit to update components that are vulnerable or outdated.
• Daily Audit runs again, after Daily Maintenance completes, reporting on the now-current application and component status. This also updates the tags, disabling further update operations.
• No additional RMM automation is needed - no Filters/Views, automation policies, or scheduling, significantly reducing the load and complexity on the RMM platform.

Using a Standard Configuration

This concept starts by defining a set of configuration settings and software that needs to be deployed within your support stack. This should include settings and software that you deploy to most or all customers, then settings and software deployed to specific customers. The latter is usually LOB applications, as the RMM Suite install scripts can leverage Cloud Script Variables (CSVs) to both control the deployment globally while delivering customer-specific content.

As your product stack changes - either by adding or replacing products - your Standard Configuration changes. This has been a difficult process for many as configurations may need to change and software uninstalled before installing a new set of products. This is where the RMM Suite OBA tool can help.

Deploying the Standard Configuration

The OBA tool runs when an agent first checks in to deploy software and configure the endpoint to meet the Standard Configuration requirements. See this blog post for full information on using the OBA Tool and the Standard Configuration. 

Dealing with Change

Change is inevitable, but it should not be difficult! A typical change to a Standard Configuration is using a different product, such as Antivirus software. Let's assume your Standard Configuration utilized Iron-Man AV, but now you are switching to the more powerful Titanium-Man AV product. You need to remove the old product and then install the new one. This requires just 2 scripts and 3 changes to your OBA config file:

Script: Uninstall Iron-Man AV - Create an RMM script to uninstall the Iron-Man AV product, suppressing any reboots.

Script: Install Titanium-Man AV - Create an RMM script to install the new Titanium-Man AV product, suppressing any reboots

Change the OBA configuration file:

• Disable or Remove the definition that installed the IronMan AV product
• Add a definition to run the Uninstall Iron-Man AV script
• Add a definition to run the Install Titanium-Man AV script

Once these changes are in your OBA configuration file, the next daily cycle will discover that these two tasks have never been run and will run them on all endpoints (based on the Task Category where these are defined, of course). The next time the endpoint is online and runs the Daily Tasks, these changes to your Standard Configuration will be processed and the endpoint will be compliant with your new standards.

Summary

Despite the "Onboarding Automation" name, the capabilities of the OBA tool extend to helping you maintain a "Standard Configuration" without complex scripting or other RMM automation tools. The OBA tool also works hand in hand with the Daily Maintenance tool that can be used to deploy and update components on the endpoint, especially when using Customer Class of Service (CCOS) tags. Daily Maintenance could be used to deploy and maintain either Iron-Man AV or Titanium-Man AV based on the CCOS tag being "Iron" or "titanium" (or any other level-identification term). 

The RMM Suite provides an Onboard Automation tool that can fully automate the ongoing deployment of endpoint software and configuration tasks. It's a powerful tool that takes just a few minutes of planning and setup to effectively leverage. Follow along as we walk through a typical setup scenario.

General Concepts

The Onboard Automation (OBA) tool runs when an agent first checks into the RMM platform. If an alarm is configured (recommended), then this happens within 2-3 minutes of the agent first being installed and checking in. Without the alarm, it can take up to 24-hours for the RMM to schedule the daily automation tasks, so using the alarm is essential if you are going to deploy many new systems from your tech bench. 

The OBA tool consults a configuration file for a list of RMM scripts to run. It uses the APIs to run these scripts based on an agent's classification within several task categories. This initial run usually executes many scripts to deploy software and configure the endpoint, first for MSP tasks and then for customer-specific tasks. This provides a high degree of flexibility in a highly automated process.

Once the initial execution runs, the OBA tool continues to run each day, comparing the current task list with what has already been completed. If a new task is found, it is run and the process logged. This allows a "Standard Configuration" to be defined by the MSP for internal and client-specific settings that is maintained automatically. 

Task Categories

There are several categories of tasks that the OBA tool uses to decide what it should do. There are three "general" categories that allow the MSP to perform their tasks, called "All Agents", "All Servers", and "All Workstations". Scripts defined in these categories run on all endpoints unless specifically excluded for a particular customer. This allows, for example, to deploy a configuration script to every workstation, but exclude a specific customer that needs an alternate setting. The concept allows tailoring an otherwise broadly deployed process.

Additional categories are next tied to specific customers, allowing execution of scripts to all agents, just servers, just workstations, or even workstations in a specific site location. 

Automation Controls

The OBA configuration file simply defines each of the task categories, then lists the names of the scripts that should be executed. Each script has a control parameter associated with it - Yes | No | All - that controls how it will be run. "No" allows the script to remain in the config file but it is disabled and will be ignored. "Yes" will cause the script to be executed if the agent belongs to a "managed" group. This will skip any agent that is considered "unmanaged" (break/fix or not yet managed/onboarding stage). The "All" option allows the script to execute on all endpoints regardless of the managed/unmanaged status. This is especially useful for scripts that configure the endpoint or the RMM agent itself.

Preparation And Planning

Preparation mainly consists of creating the RMM scripts needed to perform the application installation and endpoint configuration processes. These should be created and tested before defining them in the OBA config file. Testing can be completed simply by manually executing the script from the RMM platform.

Planning requires an understanding of what processes should be performed globally, which customers should be excluded from global tasks, and then selecting the customer-specific tasks. Something to consider here - the RMM Suite app installers are often generic and employ a Cloud Script Variable to assign a license key or similar configuration setting. Customers that don't have a key will abort that script without a "failure", allowing this script to potentially be applied globally, yet executed only where a CSV value has been defined. 

Operation

This is the easy part! Depending on your RMM, you may need to enable the "New Agent" alarm to allow the onboarding process to run immediately after the first check in. Everything from that point onward is automated. Simply maintain the OBA config file to add scripts as the standard configuration changes, knowing that these will run automatically the next time the Daily Tasks are run.

Note that you can define scripts that install, remove, or update endpoint components, but once a specific script has run successfully, it will NOT be run again. Updates can be deployed by including some specific text in the name such as "Update XXX to V3.45" or "uninstall XXX V3.0". The RMM Suite maintains this tracking in the "init" sub-key of our registry path, so an alternative would be to clear or remove the key if you need to run a task again.