Windows Server 2016 is now out. We should verify that ThinLinc works with it and start officially supporting it.
*** Bug 5401 has been marked as a duplicate of this bug. ***
We should update the screenshot in the profile chooser when adding support for Windows Server 2016.
Without going to deep into details, these are the main things presented as new and exciting for Remote Desktop Services in Windows 2016: - Making it easier to deploy both RDSH and VDI to Azure - Improved graphics performance and quality - Better scalability for the connection broker We should keep a close eye on understanding the business needs driving these changes as they somewhat mirror our own development from a few years ago. Stuff that we should keep tabs on from a technical standpoint are: - Improved GPU acceleration (RemoteFX, Discrete Device Assignment) https://blogs.technet.microsoft.com/enterprisemobility/2014/11/05/remotefx-vgpu-updates-in-windows-server-next/ Improved graphics support - run native graphics drivers inside VDI machines. https://myignite.microsoft.com/videos/2794 even mentions sharing GPUs across users in Session Host scenarios. - Improved GPU acceleration features https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/ - Pen remoting support https://blogs.technet.microsoft.com/enterprisemobility/2015/07/22/introducing-pen-remoting-for-windows-10-and-windows-server-2016/ RDP now allows pen input from devices such as the Surface Pro 3. This allows inputs with pressure sensitivity, barrel buttons, etc. Read more at these links: - https://docs.microsoft.com/sv-se/windows-server/remote/remote-desktop-services/rds-whats-new - https://blogs.technet.microsoft.com/hybridcloudbp/2016/11/15/new-rds-capabilities-in-windows-server-2016-for-service-providers/ - https://myignite.microsoft.com/videos/2794 - https://technet.microsoft.com/en-us/library/dn765476(v=ws.11).aspx - https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/
Known problem from upstream is that the mouse pointer is not working out of the box. Added #5020 as dependency for this issue.
(In reply to comment #4) > Known problem from upstream is that the mouse pointer is not working out of the > box. Added #5020 as dependency for this issue. Changing mouse theme to simpler theme eg. non alpha, will make the cursor work as expected.
While testing dynamic session resize I find the same problem as described in bug ##5290. Adding that bug as dependency.
(In reply to comment #6) > While testing dynamic session resize I find the same problem as described in > bug #5290. Adding that bug as dependency. I have now tested with upstream built binary with the fix mentioned on bug #5290. It seems to work as expected.
I have tested reconnnection to a RDP session and did not find any problems at all. One note thou, when using rdesktop to reconnect to an already connected session using ThinLinc, the exit code 5 could be handled and a nice message be presented to the ThinLinc user. From current message: "The connection to the Remote Desktop failed with error 5" to something like: "The connection to the session was replaced by another client" I found this [1] reference of disconnect codes used by RDP published at 3 May 2017. [1] https://social.technet.microsoft.com/wiki/contents/articles/37870.rds-remote-desktop-client-disconnect-codes-and-reasons.aspx
Investigating disconnect reason codes I found that rdesktop implements and handle 25 out of 35 as found in this [1] list. Added bug #7032 as blocker to handler this. [1] https://social.technet.microsoft.com/wiki/contents/articles/37870.rds-remote-desktop-client-disconnect-codes-and-reasons.aspx
(In reply to comment #9) > Investigating disconnect reason codes I found that rdesktop implements and > handle 25 out of 35 as found in this [1] list. Added bug #7032 as blocker to > handler this. > > [1] > https://social.technet.microsoft.com/wiki/contents/articles/37870.rds-remote-desktop-client-disconnect-codes-and-reasons.aspx Added bug #7033 for handling of disconnect reason codes in tl-run-rdesktop
Tested installation of WTSTools and it worked fine except for that the installation path is wrong, see bug #7034. tl-loadagent works as expected and the host shows up nicely in tlwebadm with proper numbers.
(In reply to comment #11) > Tested installation of WTSTools and it worked fine except for that the > installation path is wrong, see bug #7034. > > tl-loadagent works as expected and the host shows up nicely in tlwebadm with > proper numbers. Installation worked good using 4.8.0 release, trying to install 4.7.0 and test upgrade to 4.8.0.
(In reply to comment #12) > (In reply to comment #11) > > Tested installation of WTSTools and it worked fine except for that the > > installation path is wrong, see bug #7034. > > > > tl-loadagent works as expected and the host shows up nicely in tlwebadm with > > proper numbers. > > Installation worked good using 4.8.0 release, trying to install 4.7.0 and test > upgrade to 4.8.0. Installed 4.7.0 and upgrade to 4.8.0, works as expected, still affect by bug #7034.
I have now tested ThinLinc load balancing between two 2016 RDS servers. The balancer works as expected under the hood, the correct server is choosen to connect to however, you will be redirected by RDS session broker on windows side so do not expect to end up on what server ThinLinc wants to place your session. This is a problem known for 2012r2 and onwards, were the session broker is a required component when deploying a RDS cluster. Added bug #7035 for this problem.
Testing Seamless RDP: - Black borders around window #7027 - seamlessrdpshell.exe is require to be a published application with no restriction on command line Testing winapp: - cmd.exe is required to be a published application with no restriction on commandline, this means that and administrator is forced to shortcut the security / control of what application that can be run remote. I couldn't find any information in our TAG about the need for adding seamlessrdpsehll.exe and cmd.exe without restriction to get this to work. We should definitely mention this.
(In reply to comment #16) > > - seamlessrdpshell.exe is require to be a published application with no > restriction on command line > > - cmd.exe is required to be a published application with no restriction on > commandline, this means that and administrator is forced to shortcut the > security / control of what application that can be run remote. > Added bug #7036 for missing documentation about this requirement.
Tested printer redirection and it works fine AFAICT. All printers are enumerated and exported, and it worked well printing to the thinlocal queue.
Local drive redirection summary: Bug 7046 caused a rather poor experience for us.
Smart card redirection: It's frustratingly difficult to get this going. We don't mention anything in particular about setting this up in the Administrators Guide. The Linux client (on Fedora) is extremely prone to locking up it's smart card tunneling. We was successful in maybe 5% (1 in 20) of the tests we did, but we did eventually manage to log in to minpension.se with a smart card once.
Smart Card Authentication for Windows RDS ----------------------------------------- 1. Auto-enroll certificates for Smart Card Authentication to users using AD Certificate Authority and Group Policies. 2. Install Aventra ActiveSecurity MyClient on all Windows servers and clients. 3. Using the MyClient software, initiate a blank smart card. Upload the certificate issued to the user.
(In reply to comment #20) > Smart card redirection: > > It's frustratingly difficult to get this going. We don't mention anything in > particular about setting this up in the Administrators Guide. > > The Linux client (on Fedora) is extremely prone to locking up it's smart card > tunneling. We was successful in maybe 5% (1 in 20) of the tests we did, but we > did eventually manage to log in to minpension.se with a smart card once. Another day passed, more tests performed. There were no apparent issues with smart card tunneling using the ThinLinc Client on Windows. Smart card SSO worked fine onto a Windows 2016 RDS infrastructure. With our earlier testbed of Fedora 25 but with all updates applied, Gnome settings daemon tried to interfere when inserting smart cards. This was temporarily disabled by "gsettings set org.gnome.settings-daemon.plugins.smartcard active false". Whether it was the updates or the gsettings fix that made things better, I'm not sure. However, we managed to make 3 out of 4 successful login attempts with Smart card SSO to the same infrastructure as mentioned above.
I tested performance by playing some videos and browsing to web pages with many animations. In general the performance was at least as good as with 2012 R2, probably better. However comparison with Microsoft's client revealed audio sync issues (bug 7051), and it is a noticeable difference in performance (probably bug 4779).
Closing this bug now when there is no more to do.
