Because of OSX "Catalina" (10.15) it will be required to update the AADS Client for OSX.
OSX "Catalina" requires 64 bit (x64) software and does not allow anymore for 32 bits (x32) software.
Because of this, our AADS Client for OSX is a 64 bit (x64) client.
This change to 64 bit (x64) does also imply that our AADS Client for OSX will not run on old 32 bit (x32) OSX versions.
The oldest OSX version supported by AADS, is Mac OSX 10.9 "Mavericks".
Various Linux distri's as available have updated (or not...) both OpenSSL and rDesktop. Specifically the most recent version of rDesktop can give you trouble. It seems that recent developments in rDesktop are done because of the newest Windows versions, Windows 10, Server 2019. It seems that due to those recent developments in rDesktop, the most recent version of rDesktop can not be used anymore against older Windows versions like Windows XP or Server 2003.
Because of this we have updated our AADS Client for Linux:
Our AADS Client for Linux has the following 4 options for the RDP binary:
It is possible to use installed (OS) versions of rDesktop and xFreeRDP as they are available on your Linux distri of choice, or to use the "included" versions of rDesktop and xFreeRDP.
Currently we test against the following Linux distri's:
The "included" versions of rDesktop and xFreeRDP work OK on these distri's and work OK against any AADServer.
AADS Client now offers the user a selection of "shared" clipboard or "off"
RDP+ File Transfer did sometimes crash. Specifically this could happen on Server 2003.
In case AADS Strict Application Control was used, in case of Windows Vista and newer, it was not possible to start the ScreenSaver settings.
It is possible and OK to disable IPv6 support for an AADServer in case IPv6 is not needed:
Although if IPv6 is not enabled, AADS Maintenance & Control will show IPv6 in the logging, because it might happen that "something" or "someone" is attempting to do unexpected connections thru IPv6...
When an user does a Session Logoff, the user is presented with the message "Signing out". And while this message is shown to the user, the Server stops all user processes, close files, closes applications, close the session, etc, etc.
Since Windows 10 build 1903 it can take 10 seconds before Windows has closed and cleaned up a session. System software like AntiVirus software can also be a reason why it take a long time before the Session is closed and Logged off.
This implies that it can take 10 (very long...) seconds that the user is looking at the message "Signing out", or for 10 (very long...) seconds is looking at a black screen.
AADS offers a Time Out setting. If the Time Out is set to 3 seconds, the user will see the "Signing out" message for 3 seconds.
It might take longer before the session is indeed cleaned-up by Windows, but the user does not have to wait for this; after the short time-out the session is disconnected and the user can continue to work on his/her Client PC.
In case the short timeout for the "Signing out" message does result in problems, choose (system default) and wait for the Session Logoff to finish as long as it is needed...while the Client PC / MAC shows the message "Signing out" or shows a black screen...
AADS build 164.8 (8 Aug 2019) already had a similar function, and did disconnect sessions after 3 seconds. Unfortunately this was not properly implemented, due to which RDP clients on Windows Client PCs did show a "Disconnect error" message. Clients on MAC OSX might do a re-connect after the Session Logoff, as if the user wants to login again.
When starting Applications, AADS did translate the Environment Variables in the Command Line to their actual values prior to starting the Application.
However, it is not for AADS to handle the Command Line; that should be done by the Application that is started. Therefore AADS will not change the Command Line prior to starting an Application.
AADS will use the default system font on Windows, OSX and Linux for its applications.
The built-in PDF printer did sometimes not associated the right printjob / document with the correct user.
AADS Client for Windows as included in AADServer Classic/Small did not show the option for entering an IPv6 ScopeID.
Once again we have to do effort within AADS, such to restore our EXE files, because failing, over-active Anti Virus software deletes our EXE files, although there is no problem whatsoever:
© 2012-2023 AADS WorldWide. Terminal Server | Application Server | Remote Desktop solutions | Firewall