www.cendio.com
Bug 6096 - Add support for Windows Server 2016
: Add support for Windows Server 2016
Status: CLOSED FIXED
: ThinLinc
| rdesktop (deprecated)
: trunk
: PC Unknown
: P2 Normal
: 4.9.0
Assigned To:
:
:
: 5020 5290 5886 5887 7027 7032 7033 7035 7036 7046 7068 7094 7095
: 6150 6179
  Show dependency treegraph
 
Reported: 2016-11-23 10:44 by
Modified: 2018-02-28 10:06 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2016-11-23 10:44:18
Windows Server 2016 is now out. We should verify that ThinLinc works with it
and start officially supporting it.
------- Comment #1 From cendio 2017-05-10 10:57:37 -------
*** Bug 5401 has been marked as a duplicate of this bug. ***
------- Comment #2 From cendio 2017-05-30 10:07:10 -------
We should update the screenshot in the profile chooser when adding support for
Windows Server 2016.
------- Comment #3 From cendio 2017-08-31 14:26:57 -------
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/
------- Comment #4 From cendio 2017-09-05 09:13:49 -------
Known problem from upstream is that the mouse pointer is not working out of the
box. Added #5020 as dependency for this issue.
------- Comment #5 From cendio 2017-09-05 09:15:23 -------
(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.
------- Comment #6 From cendio 2017-09-05 09:30:56 -------
While testing dynamic session resize I find the same problem as described in
bug ##5290. Adding that bug as dependency.
------- Comment #7 From cendio 2017-09-05 09:39:25 -------
(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.
------- Comment #8 From cendio 2017-09-05 10:18:47 -------
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
------- Comment #9 From cendio 2017-09-05 10:32:50 -------
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
------- Comment #10 From cendio 2017-09-05 10:40:16 -------
(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
------- Comment #11 From cendio 2017-09-05 11:18:19 -------
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.
------- Comment #12 From cendio 2017-09-05 12:00:35 -------
(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.
------- Comment #13 From cendio 2017-09-05 12:06:06 -------
(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.
------- Comment #14 From cendio 2017-09-05 14:19:31 -------
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.
------- Comment #15 From cendio 2017-09-06 09:17:46 -------
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.
------- Comment #16 From cendio 2017-09-06 09:17:48 -------
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.
------- Comment #17 From cendio 2017-09-06 09:41:38 -------
(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.
------- Comment #18 From cendio 2017-09-07 14:34:01 -------
Tested printer redirection and it works fine AFAICT. All printers are
enumerated and exported, and it worked well printing to the thinlocal queue.
------- Comment #19 From cendio 2017-09-14 13:32:42 -------
Local drive redirection summary:

Bug 7046 caused a rather poor experience for us.
------- Comment #20 From cendio 2017-09-14 13:35:26 -------
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.
------- Comment #21 From cendio 2017-09-19 17:23:18 -------
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.
------- Comment #22 From cendio 2017-09-19 18:02:00 -------
(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.
------- Comment #24 From cendio 2017-09-21 15:01:32 -------
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).
------- Comment #27 From cendio 2018-02-28 10:05:47 -------
Closing this bug now when there is no more to do.