ISL AlwaysOn 4.4.1823.27 for Windows and macOS (2018-11-20)
General Information
On 20th of November the following was released:
- ISL AlwaysOn 4.4.1823.27 for Windows (release_date=2018-11-15, build=c77581ce86c27c1cefff5852120e4c89ee1a2ff8, platform=win32, os_version=0x06010000-0x7fffffff)
- ISL AlwaysOn 4.4.1823.27 for macOS (release_date=2018-11-15, build=c77581ce86c27c1cefff5852120e4c89ee1a2ff8, platform=mac, os_version=0x0a0800-0x0affff)
All updates have release date set to 2018-11-15. Your ESS will need to be same or higher to be able to update your server. This release is available to all countries except Japan.
Upgrading to new version
Hosted service users please check Upgrading Hosted Service.
Server license users please check Upgrading Server License.
Improvements
When connecting to an ISL AlwaysOn computer with the option 'Connect to an existing RDP session', restart&resume functionality is enabled by default. For RDP session, restart&resume is disabled by default. In other cases, GUI menu requests to enable restart&resume are disabled.
Added packet_handled to port_forward transports. ISL AlwaysOn will no longer crash when queued network data in port forward exhausts memory.
Added support for disabling restart&resume functionality using a command line argument. The command line argument is in the following format:
--on-connect "desktop?norestart=all"
When enabled, restart&resume will not be enabled, and users will not be able to enable it.
Fixed an issue where a session would not stop when connected to an ISL AlwaysOn computer with "Connect to existing RDP session" option enabled and user was signed-off in the RDP session. The issue was fixed, session is now stopped correctly when connected to an ISL AlwaysOn computer with option "Connect to existing RDP session" and user signs-off in the RDP session.
The defect was fixed.
Added additional security to NamedPipes so that ISL AlwaysOn pipes cannot be accessed remotely.
The defect was fixed.
Fixed an issue where ISL AlwaysOn would crash when using simple network on windows and when connect_timeout was set to 0. The same crash occurred when the client established the connection at the same time the timeout occurred.
The defect was fixed.
