Forum Discussion
Remote Desktop Connection (Remote App) behavior problems
My device did an update this morning to Windows 10 Pro Insider Preview - 17677.rs_prerelease.180520-0940.
I think the issue has been resolved with this Windows Insider release! Not sure when the GA of this update will be. My guess is that Microsoft will issue a separate update to fix this problem fairly soon.
I have to roll all the way back to 1709 to get it to work, for some reason. Nothing I do in 1803 helps! 1709, fully patched, works fine for me.
I called Premiere Support. They suggested copying the MSTSC.exe and mstscax.dll file from 1709 and registering that dll (Regsvr32).
Of course, there is the whole mess of taking ownership of the files, etc and replacing them, which takes some work, but I got it to work!
Posts like this were definitely on the right track, and with 3 weeks of user group testing I found that the Remote Desktop Protocols are the underlying cause of the instability that people are reporting about. Screen freezing, right-click sub-menu faults, apps not launching, black windows of the app, temporary profiles becoming corrupt, and many more.
If most of these posts worked on the baseline of what RDP version they are working with, I think it would help in finding out what other interventions are in play to cause an issue. I have noticed managed service providers for clients issuing VDI Desktops as a service because of these RemoteApps issues - not good!
The resolve for our organisation was to: Ensure the Remote Desktop Client on server and client are the same 'Remote Desktop Protocol' version.
I took the exe. and dll files from a Windows Server 2019 because they tested and deployed well to both the RDS Session Hosts and W10 1511/1803/1903 clients. The results were fantastic. We aim to deploy Remote Desktop Client 10.6 (10.7 does not work on Server 2016) on our client images moving forward. My observation from many of these posts is that the protocol session communication has not been considered as it is the foundation of the RD services. Keep the versions the same until Microsoft recognise this and take action to provide the updates separately. There is currently to many tweeks and registry adjustments being made for this out there.
Now 2019, I have posted this finding in the Social Technet as Diverga-Tech, and think it would be helpful advice to many suffering from this long-term (3/4 years in some forums) issue.
Has your testing compared running matching versions compared to just sticking with 1703's version on the client side? I don't want to monkey with our servers running in Azure, but I'm perfectly willing to accept that Microsoft still has no clue of this issue on Windows 10.
- The protocol version that was released with 1703 would be far to old and would not cover much of the fixes over the years. The protocol updates are deployed to address the reported imbalances in the RDP experience, especially when application z-index window scripts can alter, and TLS security now moves on from 1.0/1.1.
It makes no sense to leave the clients who are the most exposed many RDC versions behind the server. The protocol should talk the same in the session handshaking, otherwise the clients will get odd results on some published apps, not all. We know not the long-term outcome for companies that chose to stick with clients on 1703, and what server published apps they used.
I would recommend testing first on a non-production Session Host in Azure, create another Collection in System Manager called Test, assign the test server that has the misbehaving app, and then see the performance difference on the RDC matching. With the script it takes 2 minutes to do server and client, no monkeying actions should participate if they are not confident on the approach.
See the reply from Rob Thayer above, links a (long) post but one poster has a script that does all that, i.e. replaces the driver users rights then puts them back etc.
