Active Directory is a directory service used to store information about the network resources across a domain. Its main purpose is to provide central authentication and authorization services for Windows based computers. An Active Directory structure is a hierarchical framework of objects. The objects fall into three broad categories: resources (e.g. printers), services (e.g. e-mail) and users (user accounts and groups). The AD provides information on the objects, organizes the objects, controls access and sets security.
The VSA can reference information stored in Active Directory during a LAN Watch. Subsequently, agents can be automatically installed on machines using View AD Computers. Using View AD Users, agents can be automatically installed on each machine a AD user logs onto. Also the latest user contact information can be extracted from Active Directory and applied to the machine ID an AD user is currently logged onto. This provides VSA users with up-to-date contact information automatically.
The set of options that display when the user right-clicks the agent icon in the system tray of the managed machine. The agent menu can be customized.
To provide both flexibility and automation, the VSA enables you to specify different values for the following types of agent settings on a per machine basis:
The VSA manages machines by installing a software client called an agent on a managed machine. The agent is a system service that does not require the user to be logged on for the agent to function and does not require a reboot for the agent to be installed. The agent is configurable and can be totally invisible to the user. The sole purpose of the agent is to carry out the tasks requested by the VSA user. Once installed:
Agents can be installed on Mac OS X version 10.3.9 and up. Both Intel and PowerPC platforms are supported. For Macintosh machines, the VSA supports:
In graphical displays throughout the VSA, when an alarm condition exists, the VSA displays, by default, a red traffic light icon. If no alarm condition exists, a green traffic light icon displays. These icons can be customized.
Alarms, and other types of responses, are enabled using the following pages:
An alarm condition exists when a machine's performance succeeds or fails to meet a pre-defined criteria.
The Suspend Alarms page suppresses alarms for specified time periods, including recurring time periods. This allows upgrade and maintenance activity to take place without generating alarms. When alarms are suspended for a machine ID, the agent still collects data, but does not generate corresponding alarms.
Alerts are responses to alarm conditions. This differs from an audit, which simply collects selected data for reference purposes without regard to any criteria.
Alerts have two meanings, generic and specific:
Typically there are four types of alert responses to an alarm condition:
Defining an alert sets the ATSE response code for that machine ID or SNMP device.
Alerts are defined using:
The Alerts page enables you to quickly define alerts for typical alarm conditions found in an IT environment. For example, low disk space is frequently a problem on managed machines. Selecting the
Low Disk type of alarm displays a single additional field that lets you define the
% free space threshold. Once defined, you can apply this alarm immediately to any machine ID displayed on the Alerts page and specify the response to the alarm.
Alerts are one of several monitor types.
1 - Admin account disabled
2 - Get File change alert
3 - New Agent checked in for the first time
4 - Application has been installed or deleted
5 - Agent Procedure failure detected
6 - NT Event Log error detected
7 - KServer stopped
8 - Protection violation detected.
9 - PCI configuration has been changed
10 - Disk drive configuration change
11 - RAM size changed.
12 - Test email sent by serverInfo.asp
13 - Scheduled report completed
14 - LAN Watch alert type
15 - agent offline
16 - low on disk space
17 - disabled remote control
18 - agent online
19 - new patch found
20 - patch path missing
21 - patch install failed
23 - Backup Alert
Creating an alarm represents one of three ways to notify users of an alarm condition. The other two ways are to send an email or to create a ticket. In addition, alarm conditions can run an agent procedure to automatically respond to the alarm condition. These four types of responses are called the ATSE response code. Whether assigned to a machine ID, a group ID, or an SNMP device, the designation indicates which types of responses are active for the alarm condition defined.
None of the ATSE responses are required. The alarm condition and the ATSE responses, including no response, is reported in the Info Center > Monitor - Monitor Action Log report.
The same ATSE design applies to all methods of monitoring provided by the VSA.
Agents can be scheduled to automatically audit the hardware and software configurations of their managed machines on a recurring basis. Agents report the information back to the KServer so you can access it using the VSA even when managed machines are powered down. Audits enable you to examine configurations before they develop into serious problems. The system maintains three types of audits for each machine ID:
The VSA detects changes in a machines's configuration by comparing the latest audit to the baseline audit. The latest audit record is stored for as many days as you specify.
Most of the agent and managed machine data displayed by function pages and Info Center > Reports are based on the latest audit. The Machine Changes report compares a machine ID's latest audit to a baseline audit. Two alert types specifically address changes between a baseline audit and the latest audit: Application Changes and Hardware Changes.
You can enable Auto Learn alarm thresholds for any standard monitor set you assign to selected machine IDs. This automatically fine-tunes alarm thresholds based on actual performance data on a per machine basis.
Each assigned machine collects performance data for a specified time period. During that time period no alarms are triggered. At the end of the auto learn session, the alarm threshold for each assigned machine is adjusted automatically based on the actual performance of the machine. You can manually adjust the alarm threshold values calculated by Auto Learn or run another session of Auto Learn again. Auto Learn cannot be used with individualized monitor sets.
All files required for a full backup, including all incremental or differential backups, are saved together in a backup set.
The primary name for an object in DNS. Each object can also have an unlimited number of aliases.
Online chat is a text-based, instant messaging system. It is included with the KServer primarily to provide immediate technical support. VSA users can chat with machine users and/or chat with other VSA users currently logged on the same Kserver. VSA users can enable or disable the machine user's ability to initiate chat sessions with VSA users. Since Kaseya chats are relayed through the KServer, all chats are protected by the Kaseya 256 bit rolling encryption protocol.
These icons indicate the agent check-in status of each managed machine:
Online but waiting for first audit to complete
Agent online and user currently logged on. Icon displays a tool tip showing the logon name.
Agent online and user currently logged on, but user not active for 10 minutes
Agent is currently offline
Agent has never checked in
Agent is online but remote control has been disabled
The agent has been suspended
A full check-in occurs when an agent completes the processing of any and all outstanding tasks assigned to it by the KServer. These tasks can include processing an agent procedure, posting cached log data, or refreshing the agent configuration file. A full check-in occurs if 24 hours elapses without a specific task requiring it. A quick check-in occurs when an account checks in at the configured check-in interval, indicating to the KServer that the managed machine is still online. This doesn't require the completion of all outstanding tasks. Some functions require a full check-in before an agent can begin processing a new task. For example, System > Naming Policy. You can force a full check-in by right-clicking the agent icon in the system tray of a managed machine and clicking the Refresh option.
Collections are a free-form selection of individual machine IDs within a view. It doesn't matter which groups the machine IDs belong to, so long as the VSA user is authorized to have access to those groups. This enables the VSA user to view and report on logical collections of related machine IDs, such as laptops, workstations, servers, MS Exchange Servers, etc. Collections are created using the Only show selected machine IDs checkbox in View Definitions. Save a view first before selecting machines IDs using this option. Once the view is saved, a <N> machines selected link displays to the right of this option. Click this link to display a Define Collection window, which allows you to create a view using a free-form selection of individual machine IDs.
Note: The Filter Aggregate Table provides an alternate method of selecting machine IDs for a view definition, based on standard and user defined attributes.
Machine ID templates are initially used to create an agent install package using the template as the source to copy settings from. But even after agents are installed on managed machines, you'll need to update settings on existing machine ID accounts as your customer requirements change and your knowledge of the VSA grows. In this case use Agent > Copy Settings to copy these changes to any number of machines IDs you are authorized to access. Be sure to select
Do Not Copy for any settings you do not want to overwrite. Use
Add to copy settings without removing existing settings. Kaseya recommends making changes to a selected template first, then using that template as the source machine ID to copy changes from. This ensures that your machine ID templates remain the "master repositories" of all your agent settings and are ready to serve as the source of agent install packages and existing machine ID accounts.
A credential is the logon name and password used to authenticate a user or process's access to a machine or network or some other resource. See Agent > Set Credentials.
The current time used by the KServer is displayed in System > Preferences.
The dashboard is a summary display of the status of the entire system. The dashboard's data is filtered by the machine ID / group ID filter. Navigation: Info Center > View Dashboard.
The dashboard list is a summary display of the alarm statuses of all machines being monitored. The dashboard list's data is filtered by the machine ID / group ID filter. Navigation: Info Center > Dashboard List or Monitor > Dashboard List.
The Distribute File function sends files stored on your VSA server to managed machines. It is ideal for mass distribution of configuration files, such as virus foot prints, or maintaining the latest version of executables on all machines. The VSA checks the integrity of the file every full check-in. If the file is ever deleted, corrupted, or an updated version is available on the VSA, the VSA sends down a new copy prior to any procedure execution. Use it in conjunction with recurring procedures to run batch commands on managed machines.
An event log service runs on Windows operating systems (Not available with Win9x). The event log service enables event log messages to be issued by Window based programs and components. These events are stored in event logs located on each machine. The event logs of managed machines can be stored in the KServer database, serve as the basis of alerts and reports, and be archived.
Depending on the operating system, the event log types available include but are not limited to:
The list of event types available to select can be updated using Monitoring > Update Lists by Scan.
Windows events are further classified by the following event log categories:
Event logs are used or referenced by the following VSA pages:
Because the number of events in Windows events logs is enormous the VSA uses a record type called an event set to filter an alarm condition.
Event sets contain one or more conditions. Each condition contains filters for different fields in an event log entry. The fields are source, category, event ID, user, and description. An event log entry has to match all the field filters of a condition to be considered a match. A field with an asterisk character (*) means any string, including a zero string, is considered a match. A match of any one of the conditions in an event set is sufficient to trigger an alert for any machine that event set is applied to.
For details on how to configure event sets, see Monitor > Alerts > Event Logs > Edit Event Sets.
File Transfer Protocol (FTP) is a commonly used protocol for exchanging files over any network that supports the TCP/IP protocol. The FTP server is the program on the target machine that listens on the network for connection requests from other computers. The FTP client is the program on the VSA user's local machine that initiates a connection to the server. The FTP client machine requires user access rights to the FTP server machine. It is included with the KServer primarily to provide immediate technical support. Once connected, the client can upload files to the server, download files from the server, rename or delete files on the server and so on. Any software company or individual programmer is able to create FTP server or client software because the protocol is an open standard. Virtually every computer platform supports the FTP protocol. Since Kaseya FTP sessions are relayed through the KServer, all FTP sessions are protected by the Kaseya 256 bit rolling encryption protocol.
If 1000 events—not counting black list events—are uploaded to the KServer by an agent within one hour, further collection of events of that log type are stopped for the remainder of that hour. A new event is inserted into the event log to record that collection was suspended. At the end of the hour, collection automatically resumes. This prevents short term heavy loads from swamping your KServer. Alarm detection and processing operates regardless of whether collection is suspended.
Each agent processes all events, however events listed on a "black list" are not uploaded to the VSA server. There are two black lists. One is updated periodically by Kaseya and is named
EvLogBlkList.xml. The second one, named
EvLogBlkListEx.xml, can be maintained by the service provider and is not updated by Kaseya. Both are located in the
\Kaseya\WebPages\ManagedFiles\VSAHiddenFiles directory. Alarm detection and processing operates regardless of whether entries are on the collection blacklist.
Alert, system check, and log monitoring alarms are automatically assigned to a group alarm category. If an alarm is triggered, the group alarm it belongs to is triggered as well. The group alarm categories for monitor sets and SNMP sets are manually assigned when the sets are defined. Group alarms display in the Group Alarm Status dashlet of the Monitor > Dashboard List page. You can create new groups using the Group Alarm Column Names tab in Monitor > Monitor Lists. Group alarm column names are assigned to monitor sets using Define Monitor Set.
The text equivalent of an IP address. For example, the IP address
188.8.131.52 should resolve to the host name of
Kaseya frequently posts hotfixes to correct small problems in the latest release. If the Enable automatic check box is checked in System > Configure, your VSA periodically checks for new only hotfixes at
http://vsaupdate.kaseya.net. If any new hotfixes are available, the KServer automatically downloads and applies the hotfixes without any user interaction.
The hotfix mechanism addresses minor issues only, typically either cosmetic typos, or ASP page errors. The KServer, agents, or database schema are never updated via hotfixes. Any changes affecting system operation go into full product updates that you approve before installing. Hotfixes just correct minor issues without having to wait for the release cycle.
An ISO image (.iso) is a disk image of an ISO 9660 file system. ISO 9660 is an international standard originally devised for storing data on CD-ROM. In addition to the data files that are contained in the ISO image, the ISO image also contains all the filesystem metadata, including boot code, structures, and attributes. All of this information is contained in a single file. CD writers typically provide the option of writing an ISO file as an image when writing to a CD.
LAN Watch uses an existing VSA agent on a managed machine to periodically scan the local area network for any and all new devices connected to that LAN since the last time LAN Watch ran. These new devices can be workstations and servers without agents or SNMP devices. Optionally, the VSA can send an alert when a LAN Watch discovers any new device. LAN Watch effectively uses the agent as a proxy to scan a LAN behind a firewall that might not be accessible from a remote server.
The VSA is capable of monitoring data collected from many standard log files. Log Monitoring extends that capability by extracting data from the output of any text-based log file. Examples include application log files and syslog files created for Unix, Linux, and Macintosh operating systems, and network devices such as Cisco routers. To avoid uploading all the data contained in these logs to the KServer database, Log Monitoring uses parser definitions and parser sets to parse each log file and select only the data you're interested in. Parsed messages are displayed in Log Monitoring, which can be accessed using the Agent Logs tab of Live Connect > Agent Data or the Machine Summary page or by generating a report using the Agent > Logs - Log Monitoring page. Users can optionally trigger alerts when a Log Monitoring record is generated, as defined using Assign Parsing Sets or Parser Summary.
Logs collect event information about multiple systems, including the KServer. The different types of logs that can be generated are:
.inifile changes, and other information is captured. The date and time of each activity is also noted.
The unique media access control (MAC) identifier assigned to network adapter cards (NICs).
The Machine ID / Machine Group filter is available on all tabs and functions. It allows you to limit the machines displayed on all function pages. The View Definitions window lets you further refine a machine ID / machine group filter based on attributes contained on each machine—for example, the operating system type. Once filter parameters are specified, click the Apply button to apply filter settings to all function pages. By default, the Machine ID / Group ID filter displays all machine IDs in
<All Groups> managed by the currently logged on VSA user.
Note: Even if a VSA user selects
<All Groups>, only groups the VSA user is granted access to using System > User Security > Scopes are displayed.
Each agent installed on a managed machine is assigned a unique machine ID / group ID / organization ID. All machine IDs belong to a machine group ID and optionally a subgroup ID. All machine group IDs belong to an organization ID. An organization typically represents a single customer account. If an organization is small, it may have only one machine group containing all the machine IDs in that organization. A larger organization may have many machine groups and subgroups, usually organized by location or network. For example, the full identifier for an agent installed on a managed machine could be defined as
jsmith.sales.chicago.acme. In this case
sales is a subgroup ID within the
chicago group ID within the organization ID called
acme. In some places in the VSA, this hierarchy is displayed in reverse order. Each organization ID has a single default machine group ID called
root. Group IDs and subgroup IDs are created using the System > Orgs/Group/Depts > Manage page.
Machine ID template is a machine ID record without an agent. Since an agent never checks into a machine ID template account, it is not counted against your total license count. You can create as many machine ID templates as you want without additional cost. When an agent install package is created, the package's settings are typically copied from a selected machine ID template. Machine ID templates are usually created and configured for certain types of machine. Machine type examples include desktops, Autocad, Quickbooks, small business servers, Exchange servers, SQL Servers, etc. A corresponding install package can be created based on each machine ID template you define.
When discussing agents it is helpful to distinguish between the machine ID / group ID / organization ID and the agent. The machine ID / group ID / organization ID is the account name for a managed machine in the VSA database. The agent is the client software installed on the managed machine. A one-to-one relationship exists between the agent on a managed machine and its account name on the VSA. Tasks assigned to a machine ID by VSA users direct the agent's actions on the managed machine.
A monitored machine with an installed agent and active machine ID / group ID account on the KServer. Each managed machine uses up one agent license.
A master user is a VSA user that uses a
Master user role and a
Master scope. The
Master user role provides user access to all functions throughout the VSA. The
Master scope provides access to all scope data objects throughout the VSA. A
Master user role can be used with a non-
Master scope, but a
Master scope cannot be used with a non-
Master role. KServer management configuration and other specialized functions can only be performed by
Master role users.
Master role users have an additional ability to take ownership of user-defined data objects. The term standard user is sometimes used to indicate a user that does not use a
Master user role and a
Master scope. When VSA users are listed on a page, a background of two alternating shades of beige designates
Master role users. A background of two alternating shades of grey designates non-
Master role users.
For the latest instructions on migrating an existing KServer to a new machine see the article How do I move my Kaseya Server to a new computer? (270436) in the Kaseya Support Knowledge Base Portal.
A monitor set is a set of counter objects, counters, counter instances, services and processes used to monitor the performances of machines. Typically, a threshold is assigned to each object/instance/counter, service, or process in a monitor set. Alarms can be set to trigger if any of the thresholds in the monitor set are exceeded. A monitor set should be used as a logical set of things to monitor. A logical grouping, for example, could be to monitor all counters and services integral to running an Exchange Server. You can assign a monitor set to any machine that has an operating system of Windows 2000 or newer.
The general procedure for working with monitor sets is as follows:
Note: You must run Update Lists by Scan for each machine ID you assign a monitor set, to ensure a complete list of monitoring definitions exists on the VSA to monitor that machine.
0 - Counter
1 - Service
2 - Process
3 - SNMP
4 - Alert - Alerts are further classified using alert types.
5 - System Check
6 - EPS
7 - Log Monitoring
The Packager is a wizard tool used to create a package when a pre-defined install solution cannot be used. Packager evaluates the state of a source machine before and after an installation and/or resource change. The Packager compiles the differences into a single executable file—the package—that can be distributed via agent procedures to any managed machine. Distribute a package any way you choose. You can email it, or store it on a server where a custom procedure can perform a silent installation on any managed machine.
When configuring Log Monitoring it's helpful to distinguish between two kinds of configuration records: parser definitions and parser sets.
A parser definition is used to:
A parser set subsequently filters the selected data. Based on the values of populated parameters and the criteria you define, a parser set can generate log monitoring entries and optionally trigger alerts.
Without the filtering performed by the parser set, the KServer database would quickly expand. For example a log file parameter called $FileServerCapacity$ might be repeatedly updated with the latest percentage of free space on a file server. Until the free space is less than 20% you may not need to make a record of it in Log Monitoring, nor trigger an alert based on this threshold. Each parser set applies only to the parser definition it was created to filter. Multiple parser sets can be created for each parser definition. Each parser set can trigger a separate alert on each machine ID it is assigned to.
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.
Masterrole 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.
Service packs and patches are installed in the following order:
Note: Reboots are forced after each service pack and at the end of each patch group without warning. This is necessary to permit the re-scan and installation of the subsequent groups of patches.
When setting up counter thresholds in monitor sets, it's helpful to keep in mind exactly how both Windows and the VSA identify the components you can monitor:
Portal Access is a Live Connect session initiated by the machine user. The machine user displays the Portal Access page by clicking the agent icon on the system tray of a managed machine. Portal Access contains machine user options such as changing the user's contact information, creating or tracking trouble tickets, chatting with VSA users or remote controlling their own machine from another machine. Portal Access logons are defined using Agent > Portal Access. The function list the user sees during a Portal Access session is determined by the System > Machine Roles page. You can customize Portal Access sessions using the System > Customize: Live Connect page.
Primary domain controllers have full access to the accounts databases stored on their machines. Only primary domain controllers run Active Directory.
Objects you create—such as reports, procedures, or monitor sets—are initially saved in a folder with your user name underneath a Private cabinet. This means only you, the creator of the objects in that folder, can view those objects, edit them, run them, delete them or rename them.
To share a private object with others you first have to drag and drop it into a folder underneath the Shared cabinet.
Note: A master role user can check the Show shared and private folder contents from all users checkbox in System > Preferences to see all shared and private folders. For Private folders only, checking this box provides the master role user with all access rights, equivalent to an owner.
A Quick Status feature enables you to select any monitor set counter, service or process from any machine ID and add it to the same single display window. Using Quick Status, you can quickly compare the performance of the same counter, service or process on different machines, or display selected counters, services and processes from different monitor sets all within a single view. SNMP sets provide a similar Quick Status view for selected SNMP objects. Any Quick Status view you create exists only for the current session. The Quick Status window is accessed using Monitor > Dashboard > Monitoring Set Status, then clicking the Quick Status link or the Quick Status icon .
Silent installs, also called silent deploys, do not prompt the user for input. Silent installs may not require user input or else provide a typical configuration that serves the purposes of most users, or else provide command line parameters that enable users to configure the installation at execution. If an install does not support a silent install but still needs to be distributed automatically, users can use Packager to create a custom installation package. See Creating Silent Installs.
An SNMP community is a grouping of devices and management stations running SNMP. SNMP information is broadcast to all members of the same communiity on a network. SNMP default communities are:
Certain network devices such as printers, routers, firewalls, servers and UPS devices can't support the installation of an agent. But a VSA agent installed on a managed machine on the same network as the device can read or write to that device using simple network management protocol (SNMP).
The SNMP Info link page displays a list of SNMP objects provided by the specific SNMP device you selected. These objects are discovered by performing a limited SNMP "walk" on all discovered SNMP devices each time a LAN Watch is performed. You can subsequently define device-specific SNMP sets called quick sets and associate alerts with these quick sets. Quick sets can be individualized for a single device. The standard version of the quick set can be shared with other users and applied to similar devices throughout the VSA. The prefix
(QS) is used to distinguish quick set names from other kinds of SNMP sets.
A SNMP set is a set of MIB objects used to monitor the performance of SNMP enabled network devices. The SNMP protocol is used because an agent cannot be installed on the device. You can assign alarm thresholds to any performance object in a SNMP set. If you apply the SNMP set to a device, you can be notified if the alarm threshold is exceeded. The following methods can be used to configure and assign SNMP sets to machine IDs.
Typically the following procedure is used to configure and apply SNMP sets to devices.
The following additional SNMP functions are available and can be used in any order.
Most SNMP devices are classified as a certain type of SNMP device using the MIB object
system.sysServices.0. For example, some routers identify themselves as routers generically by returning the value
77 for the
system.sysServices.0 MIB object. You can use the value returned by the
system.sysServices.0 MIB object to auto assign SNMP sets to devices, as soon as they are discovered by a LAN Watch.
Note: The entire OID for
You can assign SNMP sets to devices by type automatically as follows:
system.sysServices.0and associated with each SNMP type using the SNMP Services tab in Monitor > Monitor Lists.
system.sysServices.0MIB object that matches the SNMP type associated with those SNMP sets.
You can also assign SNMP sets to devices manually as follows:
Kaseya provides "software as a service" (SaaS) deployment of Kaseya® Virtual System Administrator™. Service providers contract with Kaseya to access a VSA hosted and maintained by Kaseya and can install a specified number of their customer agents. Service providers only see their own organizations, machine groups, procedures, reports and tickets on the SaaS VSA. Service providers have full access to all the functions of the VSA except system maintenance, which is the responsibility of Kaseya.
Syslog is a standard for forwarding log messages in an IP network to a syslog server. A syslog server collects the messages broadcast by various devices on the network and integrates them into a centralized repository of syslog files. Syslog is commonly used by Unix, Linux and Macintosh operating systems and hardware devices such as Cisco routers. Log Monitoring enables you to monitor syslog files.
A typical format for a syslog file entry is:
<time> <hostname> <tag>:<message>
Oct 15 19:11:12 Georges-Dev-Computer kernel: vmnet: bridge-en1: interface en is going DOWN
System agent procedures are basic functions that are exposed by the VSA. You can schedule system agent procedures to run automatically. They cannot be edited nor can they accept parameters. A list of available system agent procedures displays in any Agent Procedure Search popup window. System agent procedures can be run from:
Because a system agent procedure can be run using an alert or parent agent procedure associated with a specific machine ID account, the scheduling of a system agent procedure can be copied, typically from a machine ID template to a machine using Agent > Copy Settings.
The VSA can monitor machines that don't have an agent installed on them. This function is performed entirely within a single page called System Check. Machines without an agent are called external systems. A machine with an agent is assigned the task of performing the system check on the external system. A system check typically determines whether an external system is available or not. Types of system checks include: web server, DNS server, port connection, ping, and custom.
The system tray is located, by default, in the lower right-hand corner of the Windows desktop, in the Taskbar. It contains the system clock, and other system icons.
See Machine IDs vs. Agents
VSA users use the VSA application to maintain the KServer and oversee the monitoring of managed machines by the KServer and its agents. VSA users are created using System > Users. Users also refers to machine users, who use the computers managed by the VSA. Master users have special privileges throughout the VSA.
The View Definitions window lets you further refine a machine ID / group ID filter based on attributes contained on each machine—for example, the operating system type. Views provide users flexibility for machine management and reporting. View filtering is applied to all function pages by selecting a view from the Select View drop-down list on the machine ID / group filter panel and clicking the Apply icon . Any number of views can be created and shared with other users. Views are created by clicking the Edit button to the right of the Views drop-down list.
A virtual machine (VM) is a software implementation of a physical computer (machine) that executes programs like a physical computer. Virtual machines are capable of virtualizing a full set of hardware resources, including a processor (or processors), memory and storage resources and peripheral devices. The Backup module can convert a backup image into a VM. See Backup > Image to VM.
Virtual Network Computing (VNC), also called remote control or remote desktop, is a graphical desktop sharing system which uses the Remote Framebuffer (RFB) protocol to remotely control another computer. It transmits the keyboard and mouse events from one computer to another, relaying the graphical screen updates back in the other direction, over a network. It is included with the KServer primarily to provide immediate technical support. VNC is platform-independent. A VNC viewer on any operating system can usually connect to a VNC server on any other operating system. The VNC server is the program on the remote machine that shares its screen. The VNC client (or viewer) is the program on the local machine that watches and interacts with the remote machine. The VNC client machine requires user access rights to the VNC server machine. Since Kaseya VNC sessions are relayed through the KServer, all VNC sessions are protected by the Kaseya 256 bit rolling encryption protocol.
Intel® vPro™ Technology provides hardware-based management integration independent of operating system software and network management software. The VSA can discover vPro-enabled machines during a LAN Watch, list the hardware assets of vPro machines, access hardware-based security use the power management and remote booting of ISO images capabilities provided by vPro.
Windows Automatic Updates is a Microsoft tool that automatically delivers updates to a computer. Windows Automatic Updates is supported in the following operating systems: Windows 2003, Windows XP, Windows 2000 SP3 or later, and all operating systems released after these. Patch Management > Windows Auto Update can enable or disable this feature on managed machines. While Windows Millennium Edition (Me) has an Automatic Updates capability, it cannot be managed as the above operating systems can.