Glossary

Credentials

A credential is a username and password used to authenticate a user or process's access to a machine or network or some other resource.

Agent Credentials

The VSA maintains a single agent credential with administrator privileges for an agent to use, using the Agent > Manage Agents page.

• Patch Management - If an agent credential is defined for a machine ID, then Patch Management installs all new patches using this agent credential. Therefore, the agent credential should always be a user with administrator rights.
• Patch Status - Patch Status resets test results every time a machine ID's agent credential changes.
• File Source - File Source may require an agent credential be defined for the machine ID acting as the file share.
• Patch Alert - Set up an alert to notify you if a machine ID's agent credential is missing or invalid.
• Office Source - A machine ID must have an agent credential to access the alternate Office source location, in case a patch is being installed when no user is logged into the machine.
• If-Then-Else - The useCredential() command in the agent procedure editor requires a an agent credential to run successfully.
• Backup > Image Location - If a UNC path is specified in Image Location, an agent credential must be defined to provide access to this UNC path. Without the agent credential, the machine will not have access to the image location and the backup will fail. When specifying a UNC path to a share accessed by an agent machine—for example \\machinename\share—ensure the share's permissions allow read/write access using the agent credential.
• View Definitions - Includes a Machines with Credential status option that allows you to filter the display of machine IDs on any agent page by their agent credential status.
• Desktop Management - Installing the client for this module requires an agent credential be defined.

Blank Credentials

Blank passwords can be used if the managed machine's Local Security Policy allows blank passwords. On the managed machine, open the Local Security Policy tool in Administrative Tools. Navigate to Local Policies - Security Options. Look for a policy named Accounts: Limit local account use of blank passwords to console logon only. The default setting is enabled. Change it to disabled and a credential with a blank password will work.

Managed Credentials

The VSA maintaines additional credentials at three different levels: by organization, by machine group and by individual machine or device. They are managed using three navigation items in the Audit module:

• View Assets - Use this page to create multiple credentials for an individual machine or device.
• Manage Credentials - Use this page to create multiple credentials for organizations and machine groups within organizations.
• Credential Log - This page logs the creation, display and deletion of managed credentials.

Once created, use managed credentials:

• To instantly lookup all the credentials that apply to a machine you're working on. The Quick View (Classic) popup window includes a View Credentials option. Access is controlled by role and by scope. You can add a description for each credential.
• As the source credential for an agent credential in a policy. Check the Use organization defaults checkbox in the Credential setting of the Policy Management > Policies page to establish the link.

  Note: A managed credential can not overwrite the agent credential maintained using the Agent > Manage Agents directly. The managed credential must be applied to a policy and the policy applied to the machine.

If multiple credentials are defined for a machine, then the most local level defined has precedence: by individual machine, by machine group, or by organization. At any one level, only one managed credential can be designated the source credential for an agent credential for Policy Management

myOrg

myOrg is the organization of the service provider using the VSA. All other organizations in the VSA are second party organizations doing business with myOrg. The default name of myOrg, called My Organization, should be renamed to match the service provider's company or organization name. This name displays at the top of various reports to brand the report. Agents installed to internally managed machines can be assigned to this organization. VSA user logons are typically associated with staff records in the myOrg organization. myOrg cannot be assigned a parent organization.

On Premises

An on premises hardware/software installation of the VSA is a maintained by a service provider and typically used only by the service provider. See Software as a Service (SaaS).

Org

The VSA supports three different kinds of business relationships:

• Organizations - Supports machine groups and manages machines using agents.
• Customers - Supports the billing of customers using Service Billing.
• Vendors - Supports the procurement of materials using Service Billing.

The Org table is a support table shared by organizations, customers and vendors. Each record in the Org table is identified by a unique orgID. The Org table contains basic information you'd generally need to maintain about any kind of business relationship: mailing address, primary phone number, duns number, yearly revenue, etc. Because the Org table is shared, you can easily convert:

• A customer into an organization or vendor.
• A vendor into an organization or customer.
• An organization into a customer or vendor.

Note: myOrg is the organization of the service provider using the VSA.

Patch Policy

Patch policies contain all active patches for the purpose of approving or denying patches. An active patch is defined as a patch that has been reported by a patch scan by at least one machine in the VSA. Any machine can be made a member of one or more patch policies.

For example, you can create a patch policy named servers and assign all your servers to be members of this patch policy and another patch policy named workstations and assign all your workstations to be members of this policy. This way, you can configure patch approvals differently for servers and workstations.

• The patches of machines that are not a member of any patch policy are treated as if they were automatically approved.
• When a new patch policy is created the default approval status is pending approval for all patch categories.
• The default approval status for each category of patches and for each product can be individually set.
• If a machine is a member of multiple patch policies and those policies have conflicting approval statuses, the most restrictive approval status is used.
• Initial Update and Automatic Update require patches be approved before these patches are installed.
• Approval by Policy approves or denies patch by policy.
• Approval by Patch approves or denies patches by patch and sets the approval status for that patch in all patch policies.
• KB Override overrides the default approval status by KB Article for all patch policies and sets the approval status for patches associated with the KB Article in all patch policies.
• Patch Update and Machine Update can install denied patches.
• Non-Master role users can only see patch policies they have created or patch policies that have machine IDs the user is authorized to see based on their scope.

Policies and Views

Assigning a policy to a view on the Policies page is required to assign a policy using the Organizations/Machine Groups page. This prevents the unintentional assignment of a policy to all machines in the VSA. A policy without a specified view displays as a red scroll icon in the policy tree of the Organizations/Machine Groups page, indicating that it cannot be assigned. A folder with a red exclamation mark icon displays in the policy tree if it contains at least one policy without a specified view. When assigning an entire folder of policies to an organization or machine group, policies without a specified view are ignored.

Policy Assignment Rules

• Multiple policies can be assigned to any organization or machine group or machine.
• A machine with multiple policies assigned to it has conflicting policies when both specify the same policy type.
  • Multiple policies are not in conflict if different policy types are specified.
  • Policy types that combine with each other include:
    • Event log alerts, distribute files, monitor sets, and agent procedures.
• Policies are assigned by organization/machine group using the Organizations/Machine Groups page.
  • Policies assigned to a child node in an organization hierarchy have precedence over policies assigned to a parent node in the same organization hierarchy.
  • Unless a child node policy conflicts with it, policies assigned to a node apply to all descendant nodes.
  • When multiple policies are assigned to the same organization or machine group, the assigned policies have precedence in the order listed.
• Policies can be assigned by machine using the Machines page.
  • Policies assigned by machine have precedence over all policies assigned to that machine by organization/machine group.
  • Policies assigned by machine have precedence in the order listed.
• All policy assignments can be overridden by changing agent settings manually throughout the VSA.
  • Manual changes have precedence over all policies assignments.
• A policy can be associated with a view definition in the Policies page.
  • When machine is assigned to a policy by organization or by machine group an associated view filters the machines associated with a policy. If a machine is not a member of the view definition, then the policy will not be propagated to that machine.
  • When a machine is assigned to a policy by machine, then the view associated with a policy is ignored and the policy will be propagated to that machine.
  • Associating a policy with a view does not, by itself, assign a policy to any machine.
  • The order of precedence for views depends on the policies they are associated with.

Policy Overrides

A Policy Management policy override condition exists if agent settings for a machine have been set manually, outside of the Policy Management module. For example, making changes to the agent menu of a machine using the Agent Menu page in the Agent module sets up an override condition for that agent machine. Policy Management policies will be ignored from then on. Clearing an override enables applied Policy Management policies to take effect.

Policy Status Icons

- In Compliance - The agent settings for this machine match the settings of all policies assigned to this machine. No user action is required.

- Marked for Deployment - At least one policy assigned to this machine has been changed and is scheduled to be deployed. No user action is required.

- No Policy Attached - No applied policies are assigned to this machine. Consider assigning applied policies to this machine.

- Out of Compliance - At least one agent setting does not match at least one active policy assigned to this machine. Use the Policy Details window to identify the specific policies and settings that are causing the mismatch.

- Overridden - At least one agent setting does not match at least one active policy assigned to this machine, due to a user override. An override occurs when an agent setting is set manually by any VSA user anywhere in the system. Use the Policy Details window to confirm the override of specific policies and settings are correct. If even an single agent setting is overridden in a policy assigned to a machine, no other agent settings in that policy are enforced on that machine. Other policies assigned to the same machine remain enforced.

- Inactive - This policy status only displays in the Policy Details window. When multiple policies are assigned to a machine and agent settings conflict, policy assignment rules determine which agent settings are obeyed and which agent settings are ignored. Ignored settings are identified as inactive. A machine can show an In Compliance policy status icon while the Policy Details windows shows specific agent settings in specific policies as Inactive. This is expected behavior. No user action is required.

Software as a Service (SaaS)

Sharing the capabilities of a single instance of the VSA is oftentimes called "Software as a Service". Service providers contract to access a VSA hosted and maintained by a VSA tenant manager. Service providers are allocated a unique tenant partition of a shared Kaseya Server and database. Within their assigned partition, service providers can only see their own organizations, machine groups, agents, procedures, reports, tickets, and any other types of user-defined data. Service providers in a tenant partition have full access to most functions of the VSA except system maintenance, which is the responsibility of the VSA tenant manager.

System Cabinets

Built-in data objects are provided with the VSA and addon modules. These built-in data objects—also called content—provide users with best-practice solutions for commonly required IT management tasks. In some cases these built-in data objects are organized by System cabinet in a data object tree. Examples include:

• Policies - Policy Management > Policies
• Agent Procedures - Agent Procedures > Create / Schedule
• Monitor Sets - Monitor > Monitor Sets

You cannot modify a system cabinet policy. To copy a policy, hold down the CTRL key and drag the policy from one folder to another.

Tokens

To enable multiple organizations to make use of the same built-in, standard policies in Policy Management, placeholder tokens are entered in policy fields requiring an email address. These token values are #patchAlertEmail#, #sev1AlertEmail#, #sev2AlertEmail#, and #sev3AlertEmail#. The VSA automatically replaces a token in a policy with the appropriate email address for a specific organization when an alert notification is sent out. The organization email addresses referenced by tokens are specified using step 1 of the System Management Configure Wizard. This wizard can be run during setup or anytime afterwards from the System > Orgs/Groups/Depts/Staff > Manage > Systems Management tab. The Policy Management policy categories that include email addresses are Alerts, Monitor Sets and Patch Settings.