This release requires agent version 9.5.0.12. Be sure to update your Windows, Mac, and Linux agents after installing this release.
This release requires .NET version 4.7.2 or later. The installer should automatically update .NET, if necessary.
New VSA User Interface
This release introduces a new VSA User Interface. These requirements must be met to use this feature:
For On-premise customers, the installer confirms whether the VSA is HTTPS ready and, if so, displays the new UI by default.
For SaaS customers, the new UI is enabled by default.
The following considerations apply to the new UI:
To check whether HTTPS is enabled, launch a browser and connect to the VSA UI. If you see Not secure, HTTPS is not enabled:
How to enable the new UI if you’re HTTPS capable
1-Click Access for Live Connect & Remote Control
This release introduces a new 1-Click Access feature that enables administrators and other authorized users to log in to a Windows agent right from the Live Connect > Remote Control menu or from the Quick View window. (VSA-4380)
See the topics below to get started with 1-Click Access.
How it works
The 1-Click Access feature attempts to run when the 1-Click Access button is clicked (either from the Live Connect > Remote Control menu or from the Quick View window) to any authorized Windows 9.5.0.12+ agent. An agent or a user role can be authorized from the VSA, under Remote Control > Policy Settings > User Role Policy/Machine Policy. Once the machine or user role has been authorized, the 1-Click feature becomes enabled in Quick View and Live Connect.
The feature starts by checking whether the KaseyaAdmin account exists on the target endpoint. If the account does not exist, then it is created with a randomized password. For additional security, the password for the account is then randomized during each subsequent login onto the 1-Click Access session and every time the session is disconnected. For more on private sessions, see Kaseya Remote Control in the VSA User Guide.
Note: If a KaseyaAdmin account exists on your system prior to activating 1-Click, your KaseyaAdmin account password will be changed and it will become inaccessible.
Next, KaseyaRemoteControlHost verifies that the account is part of the Administrators group and the Remote Desktop Users group and, if needed, moves the account into these groups. Once these steps have been completed, the account name and password are given to the RDP remote control process so that the KaseyaAdmin account is automatically used to log in. If another user is logged into the machine, there may be a message indicating that the other user will be disconnected from their session if the 1-Click user continues. If there isn’t another user logged in, this does not happen and the session begins immediately.
At this point, the private 1-Click session has been successfully connected. In the event that any of the above steps fail, 1-Click Access is aborted and a private session is used instead. If the private session fails, the user has the option to fall back to a shared remote control session. Once the session is connected, it is logged to the Agent Remote Control logs located in Agent > Agent Logs > Technician Logs > Remote Control. This information, like other remote control sessions, can be included in reports (Logs > Kaseya Remote Control Log report).
Note: Connecting two 1-Click sessions to the same machine is not supported. If two people attempt to open 1-Click sessions to the same machine, one or the other may be kicked off of the machine, or both sessions may fail entirely.
For more on private sessions, see Kaseya Remote Control in the VSA User Guide.
1-Click Access requirements
The following requirements must be met to use the 1-Click Access feature:
Note: We do not recommend 1-Click Access be allowed on a domain controller.
Note: Mac and Linux agents are not yet supported.
Note: There is a known issue (VSA-6807) that may affect the Machine Policy’s precedence over the User Policy. This will be addressed in an upcoming release.
To authorize an agent
Use these steps to enable 1-Click Access for an agent:
To authorize a user
Use these steps to enable 1-Click Access for a user:
To run a 1-Click session from Live Connect
In Live Connect, you can run a 1-Click session from the Asset Summary tab or from the Remote Control menu.
To run a 1-Click session from the Quick View window
To run a 1-Click session from the Quick View window, click 1-Click Access:
Reporting for 1-Click
1-Click session activity is included in these reports:
Handling 1-Click connection failures
If 1-Click cannot connect to an agent, this message displays:
Connection couldn't be established. Please verify that Windows Remote Desktop is enabled on the remote machine. Do you want to connect to a console session instead?
Do one of the following:
Account Security Notifications
There is a new User Interface for account security notifications. The new menu item is only visible to master- and system-level users running version 9.5.0.21 or higher.(VSA-5490)
When sending out email notifications, there is now an option to deliver the message to ‘all admins’ or define specific email addresses. When specifying addresses, a user can add up to 5 email addresses (comma or semi-colon separated) with a maximum limit of 1000 characters in total.
The notification features in the new UI include:
The number of lockouts is set by the administrator on the System > Server Management > Logon Policy page.
Enhancements
BMS Integration
REST API
Security Audit
Software Management Module
VSA UI
Bug Fixes
Agent - Windows
Anti-Malware Module
Antivirus Module
Audit Module & REST API
Cloud Backup Module
The fix and customer impact:
The invalid include/exclude save format was corrected so that our third-party vendor, Acronis, can parse the backup request.
For customers who have already created a backup profile that does not contain at least one include filter and one exclude filter, the following is recommended:
Acronis released Cyber Cloud version 7.9 to their AU and EU data centers. This new release introduced several security improvements, including enhancements to their public facing APIs that required changes in the way VSA retrieves an 'activation access token' from Acronis via an API.
The incorrect API that was retrieving the 'password reset access token' was removed and replaced with the correct 'user activation access token' API. This change works with both 7.8 (US) and 7.9 (AU and EU) Cyber Cloud data centers.
Error message: Exception has been thrown by the target of an invocation. Failed to activate User "XXXXXXXX" in "1234567890'
Database & Schema
KServer
Remote Control Module
Security Vulnerability
Service Desk Module
System Module
Security Vulnerability & Software Management Module
VSA Core
Updated DEV on Wednesday and Prod (via full reinstall) last night. Woke up this morning and 98% of my online agents were updated, my LiveConnect issue was resolved, and all the sample views & monitors were gone (did it finally honor the reload settings? Hooray!)
Look forward to this fixing our KCB bug whereby we cannot add new Orgs!
I will be upgrading from version 9.5.0.15 on prem. Any additional install notes to follow?
Upgraded Test on Friday (7/19) - implementing on Production Wednesday (7/24) - will keep you posted. gbarnas - how is it going 72 hours in with the .22 build?
We are just making a short hop from .21 to .22
We went from .20 to .22. Actually opened a Sev-1 on Saturday morning when every policy controlled by a custom field view applied in an uncontrolled manner to every agent. Worked with engineering team to confirm that the problem was localized (none of our customers on other SAAS platforms that were updated to .22 were affected). Simple but tedious fix - edit/save every view that referenced a custom field in each tenant partition. Only around 200 views per tenant (Ugh!) that required this.
Aside from that excitement, everything else seems OK, and we've heard nothing from the MSPs on our multi-tenant system or any other customer running the .22 release.
Only weird thing for us was all of our Windows 2003 agents (yes I know...) went offline when the upgrade started on the server and didn't check back in. It required a manual restart of the Kaseya service on each to bring them back online.
Stephen, that's a common thing for us. Anytime the KServer locks up or reboots, the 2003 agents stop checking in until we manually do a restart of the kaseya servers on each box from another system on the same network.
Yeah, It was problem for us too. I ended up creating a scheduled task to restart the services 10 minutes after a reboot
Upgraded yesterday from .20 to .22. So far so good. We have not used policy manager due to past horrific issues after each patch update.
Upgrade from .21 to .22 went quick. Minor issue as it gave an indication during the "Starting Kaseya Services" that one of the services was not starting up quick enough (Network Monitor), simply clicked to have it wait for the service and it finished the process. Did not need to reapply schema but did reboot the server for good measure. Looks good!
Can you skip applying the SSL cert if you are only doing an addon upgrade for on prem? or is it recommended to install the cert for the kaseya edge services to continue working?
Yes you can skip the ssl cert install if you already have a valid cert configured. There is a skip button on the ssl setup step.
So is the 9.5.0.22 experience so far proving to be a good one. I have been holding off upgrading from 9.4.0.37 but have been keen to upgrade for the last two releases but each time a release is pulled I get nervous again. Thanks in advance for any feedback.
Andy
We have been holding off as well so, same question as Andy...... Is it safe?