Next Topic

Previous Topic

Book Contents

VSA (v6.0.0.0) - 2 February 2010

Navigation

The module tabs and function lists have been combined into a single expandable-collapsible explorer like navigation pane.

Selector Pane

Many Kaseya 2 VSA functions display a middle pane to select one or more records. The middle pane can be scrolled, filtered and sorted independently from any other pane. A menu bar displays just above the selector pane. Typically the menu bar can add, edit or delete a selected record in the selector pane, based on the type of data and the user's access rights.

Folder Trees

Certain functions display a folder tree in the selector pane (middle pane). The folder tree is used to navigate, select and share user defined objects. The following functions use folder trees:

  • Logon Page
  • Agent Procedures
  • Monitor Sets
  • SNMP Sets
  • Reports
  • Report Sets
  • Service Desk Procedures

Folder trees are typically organized beneath a Private cabinet and a Shared cabinet. Service Desk Procedures, Monitor Sets and SNMP Sets only have Shared cabinets.

Share Rights

If an object is defined within a folder tree, share rights are assigned by tree folder, not directly by the object within the tree folder. If you drag and drop an object to a new shared folder, the shares rights to that object are changed to the reflect the new folder the object is in.

Some objects exist outside of folder trees that can be assigned share rights directly.

Private folders or objects are normally only visible by the user who create them. (See Preferences below for an exception to this rule.)

Shared folders or objects can be shared by role or user.

Share rights include Execute, View, Edit, Create, Delete, Rename, Share

Master users can take ownership of a shared folder or object. This feature provides complete access to the folder or object, regardless of assigned shared rights.

View Pane

Many Kaseya 2 VSA functions display a third pane on the right hand side of the screen. The third pane is designed as a series of tabbed views, providing quick access to each property or data view no matter how complex a function might be. A menu bar displays at the top of each tabbed view. The tab menu bar lets you perform typical actions related to the view, such as assign or remove child records or save changes to just one tabbed view. Views can have multiple regions. Each region can be expanded/collapsed independent of any other region. Additional instructions display, when appropriate, for each tabbed view.

Enhanced User Control Objects

Many of the controls in the new user interface allow you to right click and select additional options. Each control displays its own tooltip. Column headings, unless otherwise restricted, let you sort and filter row data as a standard capability as well as show and hide columns in the table. Table grids are "lively" meaning they can be stretched or narrowed by dragging the object's borders.

Bookmarks

You can bookmark any item on the navigation pane. If you work with the same set of items each day, this can save you navigation clicks.

Color Schemes

You can change the look and feel of Kaseya 2 VSA using Color Schemes. Changing color schemes changes the colors displayed by Kaseya 2 VSA panes and dialog boxes. These color schemes are set independently of themes in the Windows operating system and are set by user preference.

Site Customization

The legacy 5.x Customization function has been redesigned and renamed Site Customization. Three tabs provide options for customizing the Kaseya 2 VSA user interface:

  • Logon Page
  • Site Header
  • Agent Icons

Application Logging

A new function called Application Logging controls the logging of application activity on the application server. This function is only visible to master users. This is mostly used by Kaseya technical support to investigate MessageSys service activity.

Outbound Email

A new System >Outbound Email page maintains settings for routing outbound email generated by the Kaseya Server to a host email server. The host email server accepts outbound email and delivers it to recipients on your behalf. If the email server host requires authentication you can include a username and password. These settings are typically set during the install process. You can modify them after the install using this page. Previous to Kaseya 2 VSA a smart host had to be configured on the Kaseya Server's IIS Default SMTP Virtual Server after the VSA was installed to perform this same function.

Legacy Integration

Existing 5.x legacy functions display inside the new user interface. These legacy functions look the same and are used in exactly the same way as they were before. This means you can easily transition into the new Kaseya 2 VSA user interface without having to learn how to use each function all over again. Kaseya is committed to migrating selected modules and functions in phases on a case by case basis.

Info Center

The Home module has been renamed the Info Center. The Info Center module serves as the business intelligence center for Kaseya 2 VSA.

Inbox

The Info Center includes a new function called the Inbox. The Inbox holds messages generated by other users or by Kaseya 2 VSA. Much like email, you can use it as a method of system notification or to communicate with other VSA users.

Reporting

The Reporting folder, located inside the Info Center module, replaces the previous Reports module in 5.x. All reports generated by Kaseya 2 VSA are located in this folder. All reports share a common definition and scheduling user interface. The Reporting folder comprises three functions:

  • Reports - Defines and schedules reports.
  • Report Sets â€" Defines and schedules sets of reports. Useful for running the same sets of reports periodically.
  • Report Scheduling â€" Displays and provides access to each report, based on user access rights.

Defining reports and reports sets includes enhanced output options and specialized parameters for each type of report. Scheduling reports and report sets include enhanced options for filtering and distribution. Reports are delivered to each recipient's VSA InfoCenter > Inbox and/or email address.

Organizations

Organizations and organization types are being introduced in conjunction with User Security. Typically an organization is a customer, but an organization could also be a business partner.

  • Machine groups are child records of organizations.
  • Organizations have child records called departments. A department is a division within an organization.
  • Departments have child records called staff members. Staff members are independent of machine ID accounts, although the two can be associated with each other.
  • Organizations can be child records of other organizations.

Note: Upgrading to Kaseya 2 VSA from 5.x or 4.x creates organization records for you. The upgrades associates the newly created organizations with the appropriate machine groups. You are asked to carefully consider which one of two methods to use to make the associations during the install of Kaseya 2 VSA.

User Security

User access control has been enhanced by adopting a matrix of permissions called roles and scopes.

  • Users are created using a function called Users.
  • Access to machine groups and machine IDs are controlled by Scopes. Scopes also control access to several new data objects: organizations, departments, staff members and service desks.
  • Function access remains controlled by User Roles. Function access is far more granular. You can control access to each control within a function by role.
  • Roles and scopes are defined independently of each other.
  • A user must be assigned to at least one role and one scope.
  • Only one role and one scope can be active for a user at any one time. You select the active role and scope using the selector panel at the top right corner of the screen.
  • Machine Roles determines access to Live Connect functions on a per machine basis.

Note: Upgrading to Kaseya 2 VSA creates the appropriate role and scope records for you.

Live Counter

The legacy function Monitor > Live Connect has been renamed Live Counter to distinguish it from the new Live Connect function described below.

Live Connect

Live Connect is a significantly enhanced single-machine-interface that goes beyond the Machine Summary page. Double-click any check-in icon next to any machine ID in the VSA and a Live Connect window opens. The Live Connect window displays the following menu options for the selected machine ID when the agent is active:

  • Home
  • Agent Data
  • Audit Information
  • File Manager
  • Command Shell
  • Registry Editor
  • Task Manager
  • Event Viewer
  • Ticketing
  • Chat
  • Desktop Access
  • Video Chat

Machine Summary

The legacy Machine Summary single-machine-interface window is now displayed by Alt+Clicking the check-in icon next to any machine ID.

Portal Access

The User Access and Edit Profile functions have been removed from the Ticketing module. Both are still found in the Agents module. Agents > User Access has been renamed Portal Access.

Procedures

Kaseya 2 VSA uses the term procedure instead of script. Both serve the same purpose of automating tasks. Here are some differences between procedures in Kaseya 2 VSA and scripts in earlier versions of the VSA.

  • Agent Procedures Module - The Scripts module in 5.x and earlier has been renamed the Agent Procedures module, making it clear that these procedures target agents.
  • Non-agent procedures - In contrast, new procedures in certain modules such as Service Desk do not necessarily target a particular agent or machine group. These non-agent procedures are run by the Kaseya Server and target other types of records.
  • Module-specific procedures are listed with each module - For example, Service Desk has six types of procedures used to automate Service Desk business processes. Since these procedures apply only to Service Desk, they are listed in the Service Desk module instead of the Agent Procedures module.
  • Procedures serve dedicated purposes - In earlier versions of the VSA you could run any script from any function that allowed you run a script. In contrast, the procedures in Kaseya 2 VSA can only be selected if they are designed from the beginning to support a particular function. For example, each procedure drop-down selection list in Service Desk configuration tables only shows procedures of the appropriate type for that drop-down list.
  • Specialized IF-ELSE options - Each type of procedure provides only the subset of IF-ELSE commands available that make sense for that type of procedure. This guides users to workable procedure solutions faster.
  • Events-based vs Scheduled - Types of procedures can be distinguished by whether they run immediately (event-based) or run a specified time after an event has occurred (scheduled).
  • Procedure Editor - The script editor has been replaced by a new procedure editor that lets you drag-and-drop IF and STEP commands in a procedure. All of the previous commands available in 5.x have been preserved.
  • Import and Export â€" Procedures can be exported and imported as XML files. Scripts created prior to Kaseya 2 VSA can be imported.

Agent Procedure Commands

  • Added an Update System Info command. Updates the selected System Info field with the specified value for the agent this procedure runs on.
  • Added "Begins with" and "Ends with" arguments to the following IF commands: Test File, Test File in Directory Path, and Check Variable.
  • Added a "Prompt When Procedure is Scheduled" argument to the Get Variable command. Enables a VSA user to enter a different value each time a procedure is run.
  • Added five new 64-bit only commands and one new 64-bit parameter:
  • Check 64-bit Registry Value
  • Test 64-bit Registry Key
  • Delete 64-bit Registry Value
  • Delete 64-bit Registry Key
  • Set 64-bit Registry Value
  • 64-bit Registry Value parameter in the Get Variable command

Update System Info Command

A new Update System Info command has been added to Agent Procedures. This command enables you to use an agent procedure to update any column in the vSystemInfo database view except the agentGuid, emailAddr, Machine_GroupID, machName, and groupName columns. vSystemInfo column information is used by Audit > System Info, Agent > System Status, the Filter Aggregate Table in View Definitions, and the Aggregate Table report. You can update a System Info field using any string value, including the value of any previously defined agent procedure variable.

Validation Error Feedback

Kaseya 2 VSA provides enhanced validation feedback. If a field validation error occurs, the field is highlighted with a red border. A red exclamation icon displays next to the field. Hovering the mouse over the icon displays the message describing the field validation error in detail.

Database Views

  • Added new vPatchConfiguration database view to provide access to machine patch configuration data.
  • Updated vPatchStatus for v6.0 changes
  • Added vAddRemoveList - Add/remove application list returned by the latest audit.
  • Added vUptimeHistory - Data collected for the uptime history report. Use in conjunction with the getMachUptime web service.

Multiple Agent Installation

You can now install multiple agents on a single machine from different Kaseya Servers. The new agent can update the existing old agent using the Update Agent page, or install the new agent side-by-side with existing old agents.

Preferences

  • You can now set the delay used before displaying detail information when hovering over the information icon . If you find tickets are popping into the preview window too quickly for you when on the View Tickets page, extend this value. The default is 500 milliseconds.
  • A new checkbox Show shared and private folder contents from all users enables master administrators only to display all private folders and their contents.

Scheduler

A single, consistent Scheduler window has been implemented across the entire VSA for the scheduling all tasks. Schedule a task once or periodically. Each type of recurrenceâ€"Once, Hourly, Daily, Weekly, Monthly, Yearlyâ€"displays additional options appropriate for that type of recurrence. Periodic scheduling includes setting start and end dates for the recurrence. Execution options include:

  • Distribution Window - Reschedules the task to a randomly selected time no later than the number of periods specified, to spread network traffic and server loading.
  • Skip if offline - If checked and the machine is offline, skip and run the next scheduled period and time. If blank and the machine is offline, run the task as soon as the machine is online again.
  • Power up if offline - If checked, powers up the machine if offline. Requires Wake-On-LAN or vPro and another managed system on the same LAN.
  • Exclude the following time range - If checked, specifies a date/time range to exclude the rescheduling of a task by the distribution window.

Note: Certain options may be hidden, depending on the specific task being scheduled.

Patch Management

Added the ability to load a machine's settings into the configuration options in the control frame of selected functions. This allows the user to click an icon next to the machine name to copy that machine's configuration into the input controls in the control frame of that page to make it easier to add/change machines' settings to be like a specific machine. This feature has been added to:

  • Pre/Post Procedure
  • Reboot Action
  • File Source
  • Patch Alert (if an alert is configured)

Patch Mgmt > Patch Scan

When a new agent is created, a new set of agent procedures (Initialize Patch Scan) will automatically be scheduled. These agent procedures will determine if Windows Installer 3.1 has been installed, install it if it does not exist, and then update the database for the machine to simplify the selection of the appropriate patch scan script when scheduled by an admin.

  • Beginning with this version, Windows 2000 SP3, Windows XP (RTM), and Windows XP SP1 will be able to use the WUA Patch Scan rather than the Legacy Patch Scan. The only prerequisite is that Windows Installer 3.1 has been installed on the machine. The next scheduled patch scan will determine if these machines are eligible to use the WUA Patch Scan and will automatically transition these machines as appropriate. Only the patch scan data and scan engine is changing. Microsoft no longer supports these systems, so there still will be no new patches available for these systems.
  • Beginning with this version, the Office Detection Tool (ODT) scan will only be used to identify Office 2000 updates when called from the WUA Patch Scan agent procedures. All other Office updates will be identified from the Microsoft Update Catalog via the WUA Patch Scan. The ODT Scan agent procedure will still be observed as being executed, but the actual scan will only occur if Office 2000 or any of its component applications exist on the machine. Microsoft no longer supports Office 2000, so there will be no new patches available for the Office 2000 applications.
  • There is a delay of several minutes from the time the patch scan scripts are executed on a machine until the patch scan results are actually processed and the results are visible in the application. An indicator has been added to selected patch pages to alert the user that the patch scan results are pending. On the Patch Status page, when a machine's patch scan results are pending, the patch totals will be displayed as bold, italic, dark red text on a gold background. On the Scan Machine page and on the Patch Mgmt tab of the single machine interface, the last scan date/time will be displayed as bold, italic, dark red text on a gold background. Once the scan results have been processed and these pages refreshed, these text values will return to their normal display.
  • The processing of patch scan results has been redesigned and implemented as a new background process in the new MessageSys asynchronous processing engine. This eliminates the previous method of polling for changed patch scan results that required throttling to prevent server scripts from becoming backed up. This will result in improved performance and faster response times for reporting patch scan result changes.

Patch Mgmt > Reboot Action

Added the ability to configure:

  • An optional agent procedure to be executed immediately prior to the reboot action in the Patch Reboot agent procedure.
  • An optional agent procedure to be executed following the Patch Reboot agent procedure.

Patch Mgmt > Pre/Post Procedure

Added the ability to execute an agent procedure before an Automatic Update and/or at the end of the Automatic Update similar to the existing ability to do this for Initial Update. The Auto Post-Agent Procedure, if configured, will be executed immediately after the final patch execution and BEFORE the post installation Reboot.

The Auto Pre-Agent Procedure can be used to determine whether the Automatic Update should be executed or not. After executing the Auto Pre-Agent Procedure, a registry value is checked on the machine. If this registry value exists, the Automatic Update installation scripts will be skipped; otherwise, they will be executed. To invoke this feature, the Auto Pre-Agent Procedure must include a procedure step to set the registry value below:

HKEY_LOCAL_MACHINE\SOFTWARE\Kaseya\Agent\SkipAutoUpdate
Note: Any data type and any data value may be set. The test is for existence only.

If this registry value exists, a procedure log entry will be made to document that the Automatic Update was skipped, and then this registry key will be deleted.

Patch Management â€" Patch Installation Procedures

In prior versions, patch installation scripts were generated at the time of scheduling for manual updates (Patch Update, Machine Update) or shortly after midnight on the scheduled day for Automatic Update and Initial Update. This prevented a change in configuration such as Reboot Action or File Source from becoming effective until the next time a patch installation script was generated. This has changed in this version with the addition of the new Scheduler engine. Now, patch installation procedures are not actually generated until the actual schedule date/time. This allows changes to installation specific configurations to be included in scheduled but not yet executed patch installation scripts. This eliminates the previous method of polling to determine if Automatic Update or Initial Update are scheduled. This not only improves performance, but makes the processing of Automatic Updates and Initial Updates more reliable.

Since the patch installation procedures are dynamically created at the scheduled date/time, the "Pending" status for patch installations will be displayed differently:

  • Automatic Update and Initial Update: "Pending" will only be observed starting when the scheduled event has started through the end of the processing of the post-installation patch scan results. This is because the approved patches are not selected for installation until the installation procedures are created at the scheduled date/time.
  • Machine Update and Patch Update: "Pending" will only be observed from the time the user manually selects the patches for installation and uses the Scheduler to schedule their installation. "Pending" will continue to be displayed through the end of the processing of the post-installation patch scan results.

To improve reliability in the patch installation process, patch installation procedures scheduled for installation while a previously scheduled patch installation is being processed will NOT be executed. An entry in the Configuration Log will document these cases. This will ensure those cases where a set of patch installation procedures that are being executed will be allowed to complete before another set of patch installation procedures can be processed.

Patch Management â€" Patch Installation

For various reasons, some patches are displayed as "Manual Install Only", "Windows Update Site Only", or "Product Upgrade Only". Patches that have these warnings cannot be installed using the standard patch installation methods (Automatic Update, Initial Update, Machine Update, and Patch Update).

Beginning in this version, a new warning has been added â€" "Internet-based Install Only". This warning is displayed for patch data obtained from the Microsoft Update Catalog (via the WUA Patch Scan) that previously was marked as "Manual Install Only" or "Windows Update Site Only" or that had a patch download location for a CAB file rather than an executable file. Patches that have the "Internet-based Install Only" warning can now be installed using the standard patch installation methods. However, the installation of these patches will not use the File Source configured for the machine. These installations are accomplished using the same Windows Update Agent API used to perform the WUA Patch Scans. Use of this API requires a direct connection to the Internet in order to perform the required download and installation. This change has been made to eliminate the additional effort required to identify and install "Manual Install Only" or "Windows Update Site Only" patches and to permit the use of the standard Kaseya patch installation methods to install these patches.

Patches that have been reported by the Legacy Patch Scan will continue to display "Manual Install Only", "Windows Update Site Only", or "Product Upgrade Only" where required. Since these machines use the Legacy Patch Scan engine, they cannot access the Microsoft Update Catalog (via the WUA Patch Scan); therefore, they cannot make use of "Internet-based Install Only" installation feature.

Beginning in this version, machines having their File Source configured for "Download from Internet" will use the Windows Update Agent API to perform the download and installation. In most cases, this will shorten the total time to install patches on a machine. This is due to the elimination of the "get" scripts used to download the "full file" patch files and the fact that use of the Windows Update Agent API uses a more efficient background download process and will usually only download exactly those components that the machine requires for the update. Since the Windows Update Agent API will control the download and installation of updates, the options for "Copy packages to temp directory on local drive with most free space" and "Delete package after install" are ignored for Download from Internet".

Patch Management â€" Canceling Patch Installations

With the addition of the new Scheduler engine, the patch installation procedures are not actually created until the actual scheduled date/time. So, cancelling patch installations is really just cancelling the current schedule. Therefore, to cancel scheduled patch installations:

  • Cancel Updates page will only cancel all updates for the selected machines that have been scheduled by either Machine Update or Patch Update.  Initial Update is no longer canceled on this page!
  • To cancel a scheduled Automatic Update, users must go to the Automatic Update page.
  • To cancel a scheduled Initial Update or an Initial Update this is in process (not yet completed), users must go to the Initial Update page.
  • Cancel Updates page will display a Terminate button next to a machine to allow the termination of a currently running patch installation process.

Additionally, the Cancel Updates page has been modified. There are now two views: (1) machines with patches that can be canceled, (2) patches that can be canceled with the machines on which they are scheduled. In previous versions, cancelling scheduled updates was an all or nothing procedure. It is now possible to select individual patches/machines, depending on the selected view for cancellation.

Patch Management â€" Patch Approval Policies

In previous versions, when a patch became inactive (no longer reported by any machine), it was deleted from all patch approval policies. If it later became active because a new machine reported it, it was re-added to all patch approval policies based on the policies' default approval status. This could result in requiring an administrator to re-approve/re-deny the patch. Beginning in this version, inactive patches will no longer be deleted from patch approval policies; they will only be hidden. If the patch is re-activated, it is unhidden retaining the original approval status.

VSA API Web Service

Added 30+ API web service operations, most of them supporting the newly added features of user security and organizations.

App Version Filter in Views

The application filter in Views has always supported an optional version string check. With this release, we have added a wildcard search capability. Select the Like radio button and time in any version string with a * as a wild card character.

PCI & Disk H/W

The option to enable / disable PCI & Dsk H/W drivers that might cause conflicts with older Windows machines has been removed from Audit > Run Audit. PCI & Disk H/W audits are performed automatically on Windows XP and later operating systems.

Assign Monitoring / Assign SNMP filter

A filter feature has been added that filters the drop-down list of monitor sets and SNMP sets to select from in Assign Monitoring and Assign SNMP in the Monitor module.

SNMP Traps Alert

A new SNMP Traps Alert page triggers an alert when an SNMP Trap event log entry is created on a selected managed machine. SNMP event log entries are created in response to the managed machine receiving an SNMP trap message from an SNMP device on the same LAN as the managed machine.

vPro

Hardware Assets

  • Added agent icon to grid if the vPro machine has an agent installed
  • Modified the asset information and how it is displayed in the hierarchical grid
  • Added the ability to create a .CVS file for participating in the Intel vPro Rebate program
  • Added a link to the Intel vPro Rebate program website

Power Management

  • Scheduler has be modified
  • The grid has be changed to be hierarchical displaying the power management information
  • Each vPro machine can now have scheduled one type of power up, power down and reboot
  • Added agent Icon to grid if the vPro machine has an agent installed

New feature -> Remote ISO Boot

  • Allows a single time (not scheduled) boot of a vPro machine using an ISO image found on the network
  • Network credentials must be provided, ie UNC and network credentials (these are not the vPro credentials)
  • Has agent Icon if the vPro machine has an agent installed

Machine Filter Views

  • Added the option to create machine filter views that include machines that are suspended or not suspended.
  • Added the option to create machine filter views that include machines based on Agent Credential status (missing, not tested, failed test, passed test)
  • Updated the option to create machine filter views that include machines based on Patch Test Status (added options for test failed â€" credential and for test failed â€" non-credential)

Split Ticket

When splitting a ticket, you now get an additional option to leave the status of the original ticket unchanged. Previous releases automatically closed the original ticket.

LAN Watch

Added an independently sortable vendor column to View LAN and Install Agents function under LAN Watch. Use this column to help identify newly discovered devices.

Uptime History Report

Uptime history has been completely re-written and now provides the following:

  • Compute % uptime for each machine
  • Excludes suspended alarm times (maintenance windows) from % uptime calculation
  • Uptime chart displays when users logged on and off
  • Emailed report no longer looses scaling in Outlook 2007
  • Full integration with the Executive Summary report â€" summary table and network health scores for servers and workstations
  • Provides uptime data via API (views and web service)

Reset Password

Passwords generated with this function are now set to never expire.

Agent Country

The agent status function and the Aggregate table report now can display the country the agent is located in. Country location is determined by the connection gateway IP address of each agent.

Working Directory

The Agent > Temp Directory function has been renamed Agent > Working Directory. The new system default for Working Directory is "c:\kworking". The new default does not affect agents already installed using the "c:\temp" directory. Warning: Do not delete files and folders in the agent's working directory. The agent uses the data stored in the working directory to perform various tasks.

Ticketing Associations

Tickets in the Ticketing module can now be associated with machines, machine groups, organisations, departments and staff records.

Mac OS X Features

  • Added support for Mac OS X 10.6 Snow Leopard
  • LAN Watch
  • FTP
  • Remote Installation via SSH to Mac computers from the Mac OS X agent that performed the LAN Watch
  • Improved Remote Control using native Apple VNC server on Leopard (10.5) and Snow Leopard (10.6)
  • Improved application audit information