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:
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:
|
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:
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.
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.
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:
|
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 Procedure Commands |
|
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 |
|
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 |
|
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:
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:
|
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.
|
Patch Mgmt > Reboot Action |
Added the ability to configure:
|
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 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:
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:
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
Power Management
New feature -> Remote ISO Boot
|
Machine Filter Views |
|
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:
|
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 |
|