SOLVED

Remote Desktop Connection (Remote App) behavior problems

Copper Contributor

Hello, running 1803 (build 17134.1) and have been running into a "Remote App" behavior problem for a while (not sure what version it started on). 


We have a remote app installed on our desktop that is connected to an application we use hosted by someone else. It is hard to describe the behavior, but when other windows are open on our host machine (Edge, Teams, MS Office, etc.) and when a user has multiple screens (remote app only using one), when we call for something to happen in the remote app (like run a report), the remote app appears to freeze, and the only way to get it to refresh, is by clicking on one of the other programs that are open on our host machine (on the task bar) and then back to the remote app. 

 

Right clicking (trying to call a right click command) also is not working in this scenario. 

 

My gut tells me it is something related to the insider build of Windows and not the company that is hosting the application, because it is working fine on all the machines running the currently released version of windows and it is showing this behavior in 2 machines I have running the insider build. 

 

Any ideas?

 

38 Replies

I installed that update this morning and the RDP is still broken. Uninstalling it again will fix the issue.

 

MS your May updates are flawed.

best response confirmed by Derrick Rieke (Copper Contributor)
Solution

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.  

June updates are coming fast. Let's hope this gets in the cumulative!

If you don't want to wait for the next Insider Preview version this TechNet thread offers a community provided powershell script that'll apply the 17677 build version of the RDP client components on Win10 1803, which appears to address some of the issues people are seeing with RDP.
If you don't want to read the whole thread (it's quite long), skip down to posts starting on 5/30 where you'll see the first offer of a solution. 

As highly recommended, you should install in a test environment first to see if it fixes your problem.

The June 1803 Cumulative Update seems to have fixed this for me.

 

Update: It worked for a minute, then quit. Weird...


@Ryan Cooley wrote:

The June 1803 Cumulative Update seems to have fixed this for me.


Unfortunately I just checked on one of our systems and this Rollup did not make a difference here.

Same here this patch did not fix our RDP issue.

 

Will have to pull it from my patching cycle, again. This is now 2 months my network isn't patched.

 

MS what is going on??????????

Actually, it seems to work for the first little while and then quits. Strange...

 

This is VERY disruptive to my work as a server administrator. I built the RDS environment here at work and now it's practically unusable! This needs full attention!

Totally agree on the FULL ATTENTION

 

We use RDP to access our ERP system. Broken RDP = no access

 

Rolling back to April and things are fine.

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!

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.

I'm not sure if these are related but My problem with win 10 remote app is when minimising and maximising windows the rendering gets all screwy. 

outlookoutlookIEIEexcelexcel

The late June update seems to have fixed the RDS context menu problem in 1803.

I've only seen this problem if RemoteFX is disabled.

This helped! Thanks a bunch! (Originally, I was going to do a clean install, but I knew there had to be a few "quick fixes: before I started the LOOOOONG process of a clean install)   AND your fix was it!!! 

@Ryan Cooley 

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.

 

@CT_CAID-IOPS 

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.