none
RemoteAPP after windows 10 update 1803 are slow and right mouse button is not responding (it reacts only sometimes)

    Pertanyaan

  • Hi,

    our workstations with Windows 10 pro are in this weekend updated to version 1803. For main system we use RemoteAPP aplications on Windows server 2012R2 (Windows server 2012R2 is full updated). After update on client station are RemoteAPP slower, and  right mouse button is unresponsive, or react verly long time... 

    It is a big problem for us.

    PS: after replace mstsc.exe and mstscax.dll from older version Windows 10 is all OK. but this is not a solution.

    Thanks.


    02 Mei 2018 14:30

Semua Balasan

  • Hi,

    We are also noticing the same issue within our organisation. After upgrading to Win 10 Enterprise to 1803 we have noticed that right click is not functioning correctly when using applications in RemoteApps. To right click you need to click multiple times and even then it very slow (at least 5 seconds) and react all of the time. Our RDWebApps is running server 2012 R2. We have attempted to reboot both server and client machines and this has not helped. 

    Any suggestions would be greatly appreciated. 

    Thanks

    • Disarankan sebagai Jawaban oleh fabdu06 13 Juni 2018 7:37
    • Saran Jawaban dibatalkan oleh fabdu06 13 Juni 2018 7:38
    02 Mei 2018 22:50
  • I'm seeing the same fault. Upgraded Windows 10 Pro 1803 on multiple machines. The applications top bar menu is extremely slow to drop down and general app performance is degraded. If I establish a full remote desktop session, instead of running it as a remote app, performance is fine. Redmond...we have a problem.
    03 Mei 2018 1:21
  • Hot fix now: dislable on Windows server 2012 R2 "Use advanced RemoteFX graphics for RemoteApp" in gpedit.msc...
    03 Mei 2018 8:06
  • Same problem here. Disabling "Use advanced RemoteFX graphics for RemoteApp" not solve
    03 Mei 2018 9:44
  • Hi,

    We also see this problem with right mouse click- and also with left mouse if we left click on a menu button that should open a sub menu - clicking an action button that initiate an action (!) there is no problem!?

    Replacing with older (1709) version of mstsc (+ mstscax) did not solve the problem.

    03 Mei 2018 15:15
  • We use RemoteAPP to present our ERP and after spending two days troubleshooting "Slow issues" i've finally narrowed it down.

    I shadowed a user while they worked and every time they were saying it was slow I could see the popup or changes that they were waiting for but they couldn't see it yet on their client side.

    I've now reimaged a few computers back to before 1803 and the problem doesn't exist.

    What is the fix other then disabling Advanced RemoteFX (which I am trying but thats not really a fix)

    03 Mei 2018 21:04
  • We're currently facing the same issue as well. Over 1000 users affected! 

    We're currently testing some fixes suggested above, and opening a case with Microsoft. If anyone finds anything related to a working solution or a workaround, we would greatly appreciate an update. We will do the same on our end. 

    03 Mei 2018 23:25
  • Hi,

    I want to confirm with you if such problem happens on all published RemoteApp?

    If possible, please try to re-publish or publish system built-in software, such as Calculator, and confirm that if same problem happens.

    Also, please check Event Viewer on client, confirm that if there is any relate event has been logged:
    Applications and Services Logs – Microsoft – Windows Server – RemoteApp and Desktop Connections

    Also, please check Application and System event log to find helpful information. 

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    04 Mei 2018 7:09
    Moderator
  • We are a cloud provider and disabling  Use advanced RemoteFX graphics for RemoteApp on Windows server 2012R2 is working....

    Then you must RemoteApp sing off...

    04 Mei 2018 9:43
  • Server 2016 has the same Problem. It is very slow und sometime Rightklick and Leftklick is not working.
    04 Mei 2018 18:11


  • Will test that out.

    Meanwhile, and as a workaround, I can confirm that replacing the mstsc.exe and mstscax.dll with the older version works fine.

    Also, rolling back is a possibility and doesn't nearly take a long to complete. (In case you're really stuck)
    04 Mei 2018 20:52
  • Yes, we have had similar issues.

    We opened a support case with MS the morning of the first release when it was reported by an external remoteapp client. Have spend a fair amount of time with MS support and have submitted video etc.

    I would be interested if others find that if you start "Step Recorder" that remoteapp starts to behave. We found this by chance and hoping it helps MS pinpoint the issue quickly.

    06 Mei 2018 8:49
  • Hi,

    @ all

    Please check Event Viewer and confirm that if there is any relate event has been logged.

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    07 Mei 2018 9:20
    Moderator
  • Just adding my experience to this.  Update to 1803 on all our Win 10 Pro Clients.  Immediately noticed Remote Apps were behaving erratically.  When opening some drop down menus, they seem to just not open but in fact they ARE opening as you can click on any selection in the drop down as if it were being displayed.  If you muddle with clicking in an out of a drop down OR contextual right click menu it may or may not display. 

    This appears to be a RDP issue as older versions of RDP seem to work just fine.  Microsoft NEEDS to patch this IMMEDIATELY!

    So I had to teach my clients how to click on imaginary buttons/menus.

    UPDATE:

    Change the following group policy either locally or via GPO in an AD environment on all Terminal Servers/Remote Session Hosts:

     Set the following to Disabled

     Computer Configuration/Policies/Admin Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Remote Session Environment: Use advanced RemoteFX graphics for RemoteApp – Disabled

     

    This appears to have worked in our environment.


    07 Mei 2018 15:16
  • Thanks, disabling RemoteFX works, now I'm barely able to work again but every time I minimize my remoteapp window - it turns all black next time i maximize it. Restoring and maximizing it again helps. I hope Microsoft will fix it soon.
    07 Mei 2018 16:28
  • Although, this worked for my workstation to fix the slow right click issue, if you set this option at the RDP servers, then users who use multiple displays with AX have an issue where if they have a pop-up from AX (ie on-hand screen) and drag that to another screen, that window becomes unresponsive.  

    This is obviously a frustrating issue because the "fix" works for me, but then breaks other users' RemoteApps.

    08 Mei 2018 15:45
  • We had similar issues where windows either went black or if they moved the window to another display, it then becomes unresponsive.  If anyone hears of a fix, I would love to know.  Thanks!
    08 Mei 2018 15:46
  • Just an update. This morning, we got a report of the problem with a user still on build 1703. So we're not sure if the issue is in some other KB. we'll be connecting to the user to compare the file versions of the mstsc.exe and mstacax.dll files. (This is a brand new situation, so will update as soon as we find out more)

    Also, Steve, you mentioned you opened a case with MS about it, it appears that Windows 10 support is via chat, and they directed us to post the issue in answers.microsoft.com , which isn't nearly enough given the urgency. I'm willing to pay (and probably get re-funded the fee, given it's an MS bug), to get higher level of attention. Can you share where you opened the case specifically?
    08 Mei 2018 16:08
  • If anyone finds the solution, my company is also affected!  Disabling the RemoteFX at the RDP servers just caused more issues for us.
    08 Mei 2018 16:25


  • Will test that out.

    Meanwhile, and as a workaround, I can confirm that replacing the mstsc.exe and mstscax.dll with the older version works fine.

    Also, rolling back is a possibility and doesn't nearly take a long to complete. (In case you're really stuck)

    I'm doing this at the moment since there aren't that many clients.

    But I really hope an actual solution from Microsoft very soon.

    08 Mei 2018 18:43
  • We're opening an actual case with MS as we speak. The first one, we had opened inadvertently for Home Users, so they weren't really on it. 

    Will keep you all posted on our findings as well. 


    08 Mei 2018 19:57
  • Ok all. someone was asking regarding whether enabling the Steps Recorder fixes the problem. We tested this, and it does in fact resolve it. 

    However, not sure if this is the best solution, as the Steps Recorder doesn't merely need to be open, but also actually recording, which I'm assuming will drain the workstation's memory, and will show a little red dot on every click. For those desperate, that is in fact a work around.

    Also, in more testing we found that the problem is exactly ONE, and nothing really random:

    Anything that produces a menu or a window, being modal or not, simply pops up behind the active Window. including drop down menus. 

    The fact the user clicks on the menu and nothing shows simply means that the menu is behind, but all the items are ghosted, but clickable. In our testing, moving the mouse down to the task bar after clicking the drop down will reveal the needed item. 

    We have test so far with the following apps, all with the same behavior:

    - Sage 100

    - Crystal Reports

    - MS Excel - Happens in the Ribbon Drop downs, on every other clicks, but is not as consistent in actually showing the menu when moving the pointer to the taskbar. 

    - Notepad - Seems to work on the actual menu bar (File, Edit, View, Help), but the issue shows itself when right-clicking within notepad. 

    Will post updates as we have them. 

    • Disarankan sebagai Jawaban oleh Joost Vocke 13 September 2018 21:32
    08 Mei 2018 20:08
  • Ive tested Windows 10 1803 on Remote Apps via Windows Server 2012 and Windows Server 2016. It only appears to happen on Windows Server 2012 Remote Apps.

    Also try the second work around here (https://support.gotomyerp.com/portal/kb/articles/critical-advisory-applications-are-slow-after-windows-10-update-to-1803). I used my original files from 1709. I wouldn't trust the download files. Replacing both mstsc.exe and mstscax.dll fixed the menu issues.



    09 Mei 2018 0:04
  • haha @Zenithtwc ... I'm actually one of the owners at gotomyerp. 

    The downloads are safe, grabbed from a clean OS right before the upgrade to 1803. 



    09 Mei 2018 1:10
  • We can follow up on this - have the same issues with update 1803 and no issues with 1709. Tried the fix with the old files from the site and then the right click works again.

    So far we are facing issues with

    - Excel 2016

    - old VisualBasic applications

    Working apps.

    - Navision 2013
    - Active Directory MMC (A bit slow response though)
    - Outlook 2016
    - PowerPoint 2016

    Just what we have quick-tested and users reporting.

    Waiting for a MS hotfix for this


    • Diedit oleh MrStaun 09 Mei 2018 7:02
    09 Mei 2018 6:44
  • I've tested with Server 2016 and problem presists
    09 Mei 2018 9:23
  • Having similar problems with Win 10 10.0.17134 and RemoteApps from a 2008 R2 server. Tried copying an earlier build's RDP files but I'm met with a screen filled by the "Preparing Your Desktop" message.

    Going to attempt to roll back to an earlier version of Win 10 as machines on 10.0.15063 don't have the issue.

    09 Mei 2018 15:07
  • We have a GPU assigned to our 2016 RDSH servers. This might be why its working for us. 
    09 Mei 2018 22:59
  • KB4103721, KB4103727, and KB4103731  doesn't fix the issues. But if you apply these patches, there is group policy that will need to be applied to at least the servers. 

    see: https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018


    10 Mei 2018 0:00
  • We have just solved the CREDSSP issue with appropriate patches, however this does not solve the 'slowness' issue. Both 2012 (R*) and 2016 services are effected. Appears to occur post 1803 clients update.

    We need a solution, as we'll have 1000+ clients effected, once the 1803 rolls-out completely.

    Bob

    10 Mei 2018 1:14
  • Has any one had any more permanent success with this, aside from the workarounds? 

    My understanding is that the 1803 update can only be blocked for 60 days? 

    Thoughts ideas? 

    On our end, we still have the ticket with MS, and we'll update you guys also as soon as we hear back.

    11 Mei 2018 22:46
  • Hi,

    I want to confirm with you if such problem happens on all published RemoteApp?

    If possible, please try to re-publish or publish system built-in software, such as Calculator, and confirm that if same problem happens.

    Also, please check Event Viewer on client, confirm that if there is any relate event has been logged:
    Applications and Services Logs – Microsoft – Windows Server – RemoteApp and Desktop Connections

    Also, please check Application and System event log to find helpful information. 

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Dear Eve,

    I think that problem is in the rendering of (context) menus - if I click on the menu, it rolls down, but it isnt visible, however if I move the mouse or keyboard cursor down, it is roaming thru (invisible) menu, and if I click, desired action runs. 

    It is working well If I'm connected thru remote desktop (not RemoteApp).

    Problem is the same in our ERP as well as in ActiveDirectory Users and Computers (for example).

    My environment is three day old Azure VM with updated Windows 2016 Datacenter, as a clients we have Windows 10 Pro, on the 1709 version RemoteApp is working well, since I upgrade client to 1803 it is broken.

    Best regards,

    Jan

    14 Mei 2018 9:00
  • We are seeing same issue.  Across all workstations after 1803 update is installed.

    We are also seeing that default applications are "broken" where is a remote app is the default app.  So accessing an app by double clicking on a file in explorer or double clicking an email attachment is not working.

    I also hope this gets resolved quickly as users are now working but in a very crippled manner.

    Rob

    14 Mei 2018 22:47
  • We have exactly the same problem.

    We disable FX and it's work for part of them. But if user have some screen all is block, and app is too little, and block.


    15 Mei 2018 10:15
  • We're opening an actual case with MS as we speak. The first one, we had opened inadvertently for Home Users, so they weren't really on it. 

    Will keep you all posted on our findings as well. 


    Hi GTMERP,

    please do you have any response from MS? Error was posted on the second of May, I think it was pretty lot of time to take the action…

    It seems that Microsoft stop testing of their updates… In every update this year was some serious bug...

    Thank you for your effort in this...

    15 Mei 2018 10:30
  • Hi,

    We also have this issue. Look forward to any updates from MS that anyone receives.

    I've also escalated it with the software partner which we use (Wise Tech Global / Cargowise) in the hope that they can escalate it also with MS as they probably have more clout than we do.

    Would also encourage anyone else to do the same where you use RDP in a cloud environment with a software provider.

    Thanks,
    Stephen

    15 Mei 2018 10:49
  • Hi All, 

    we have not heard back from MS at all yet. WE're going to follow up with them today to see what we can find. Will let you know of any developments. 

    The problem is very much still there, and the clock is ticking, as, if updates can indeed only be blocked for 60 days, then it's only a matter of time before we're stuck with a disaster with our clients. 

    Forcing everyone to replace system files is doable, but not a small task for the average user, especially given permissions and ownership changes are required before anything can be replaced (even while admin on the workstation) 

    15 Mei 2018 14:10
  • Possible light at the end of the tunnel. 

    Microsoft has developed a fix, which we are currently testing out. Will update you if we have access, and how to obtain that fix. 

    15 Mei 2018 17:13
  • GTMERP, that's great news. Please follow up as soon as you can. I'd love to get my hands on it. We're in a very bad spot at the moment.

    Thank you!

    15 Mei 2018 18:48
  • Is this patch client side or server side?
    15 Mei 2018 20:23
  • It's a client side patch. 

    Unfortunately, it failed to install on our first attempt, so we're waiting for MS to send us a different version of it... 

    15 Mei 2018 21:49
  • I tried using the older version of the mstsc files, which I have done successfully in the past, but this time it did not fix the issue.

    I then disabled "Use advanced RemoteFX graphics for RemoteApp" in group policies like suggested in these threads and it fixed the issue immediately on both my Windows 2012R2 and Windows 2016 remote desktop servers. I didn't have to reboot the servers for it to take affect for new sessions.

    What a life saver! That setting also solved a couple other long standing issues that we've had with Windows 2016 servers where certain pop-ups would always appear behind the main screen. It also fixed a unique bug where if we maximized the RemoteApp, then minimized it, and then clicked on it in the taskbar to pull it up, the screen would appear frozen even though when we shadowed it, we could see things happening such as links highlighting when we put the mouse over them. Those issues didn't happen in 2012R2 but now they don't happen in 2016 as well. Bonus! I'll have to test it with different screen resolutions to be 100% sure that these other issues were fixed. Now what did we lose by disabling RemoteFX....? We've gone a whole day without any issues.

    15 Mei 2018 23:41
  • Disabling RemoteFX graphics as mentioned above seems to have solved this issue for us aswell. The affected terminal server is Windows 2016. We also have some 2008R2, but we haven't had any reports of problems there yet.

    Our program is based on Visual FoxPro, and the main problem was that the "pop-up" that appears when you click on a combo-box doesn't show. You can click the combo-box, then click in "thin air", and the selection that should be there is selected.. But you cannot see the selection-list.

    16 Mei 2018 6:34
  • Is it possible for you to make the fix Microsoft provided public?
    16 Mei 2018 8:17
  • Disabling RemoteFX graphics  - its not working in our case, please - other solution!
    16 Mei 2018 9:36
  • Hi

    Disabling RemoteFX helped us. BTW the application seems to be little bit faster after the change. I don't understand why.

    But MS please fix it.

    16 Mei 2018 12:40
  • Disabling RemoteFX "fixed" this particular problem for us but it creates many more display issues that are unacceptable to the number of users we're supporting to the point that having RemoteFX enabled might be the better option. 

    I'm really hoping we can get access to this hotfix today. 

    16 Mei 2018 13:08
  • Please loop me in to this hotfix as we desperately need it for Dynamics AX.
    16 Mei 2018 13:19
  • Hey guys, I'll make sure to share the HotFix as soon as we have a working one. Yesterday's test they sent us did not work, and wasn't the detecting the OS properly, we're waiting for them to send us another one, and as soon as we verify it's working, we'll post to let you know where to obtain the HotFix from.
    16 Mei 2018 14:00
  • Hi,

    We have also those problems with our remote apps on a 2012R2 server. Because we use grafhical CAD programs, we can not work without Remote FX. These Graphical programs are used by all our dealers so, this is verry bad for us as a company. So come on with the (hot) Fix.  

    16 Mei 2018 14:05
  • Hi GTMERP, thanks for the update on this.  We have had to push out some emergency GPO workarounds.  Ultimately the "fix" is to fix this RDP/RemoteFX issue itself.  Thanks for keeping us all in the loop!
    16 Mei 2018 14:09
  • Thanks GTMERP for the update. I'm refreshing this thread every few minutes hoping for a solution. 
    16 Mei 2018 14:28
  • Same issue with us...

    Server 2012 R2, All Clients Windows 10, pre 1803 work ok, anything updated to 1803 breaks Remote apps. Problem we find are any internal windows opened within the main program don't appear unless you click on any other program running locally on the client machine, then the hidden internal window appears until the next internal window is opened and you have to repeat the process of clicking outside the remote app again...

    In this instance, copying the 2 files mentioned previously to both system32 and syswow64 folders has temporally resolved the problem.

    we also have a test windows server 2016, and if copying the files doesn't work, then disable remotefx as this has solved it with our test setup.

    16 Mei 2018 15:45
  • Thanks GTMERP, we just ran into this same issue yesterday with Dynamics AX running as a remote app. Glad to see others are experiencing the same issue and I'm not the trail blazer. You guys have made my support life much easier. Will wait with anticipation for your update on the issue. 
    16 Mei 2018 15:54
  • Thanks GTMERP Watching and waiting for you to be the hero today
    16 Mei 2018 17:31
  • Nice day, as I write colleagues above. Yes, the problem with disable RemoteFW will only be solved in some cases, but as well as in my case when a customer uses a touch-based HW application and a graphics application, that's a step back.

    Please if someone comes up for a functional solution or write a patch update please write

    well thank you
    16 Mei 2018 17:51
  • we're at the same point as you guys, using WiseTech | CargoWise and already tried most tricks but nothing, please if someone have any patch or how to do it on client side...

    will be here awaiting for a hero

    Regards,
    16 Mei 2018 18:04
  • We've just got reports from a handful of our clients who've updated to 1803 that they're experiencing the same problems. Looking forward to a response from Microsoft on this one. 
    16 Mei 2018 18:18
  • While I'm waiting I've also replaced the mstsc.exe and mstscax.dll files in both the System32 and SysWOW64 folders with versions from the previous build of Windows 10 and it's resolved the issue on our end. I also downloaded a utility called "SysMate System File Walker" from snapfiles.com to help make copying the files a bit easier. Since they are system files, you have to take ownership of the files before Window will allow you to copy over them. This utility helps automate that process a bit. For folks with more than a few systems to take care of, I'd wait for the hotfix from Microsoft, but if you only have a few this will help. 

    • Diedit oleh BCS-MAN 16 Mei 2018 19:15
    16 Mei 2018 19:12
  • No problem guys, we're on it. 

    Also, for those interested, we did create this KB for our clients, feel free to peruse it:

    https://www.gotomyerp.com/blog/windows-10-update-to-build-1803

    and also, if the thread is TL;DR, we also discovered that the "Steps Recorder" running while in a RemoteApp actually fixes the problem, but, is probably not going to be too kind on your RAM. :) 

    Stand by for more updates as we receive them.



    16 Mei 2018 20:01
  • We also opened a case with MS. Disabling the Use Advanced RemoteFX graphics... made the remote apps responsive again, but like some of the others mentioned it introduced a new issue and that is if the RemoteApp is minimized, it turns black if you try to go back to it again (does not repaint).

    Steve J.

    16 Mei 2018 20:12
  • Steps Recorder prevents the slowness/drop down menu/right click problems? Interesting. I can't have that running on our servers but I wonder if there's some clue in that fact. 

    Thanks again GTMERP for keeping us in the loop. Microsoft seems unable to do that. 

    Did you get a new hotfix version today?

    16 Mei 2018 20:19
  • Just saw your KB on the gotomyerp site right before I saw your updated post here. Liked the visuals, makes it much more user friendly. Good job! :) 

    After seeing your URL and your username here, put 2 and 2 together and got 6... must be that new math! Lol 

    16 Mei 2018 20:26
  • @StopForcedUpdatingYouAreMakingMyLifeDifficult (phew, that was a "type"full ) :) ... The screenrecord would actually run on the user's workstation, not on the server, but the problem, is that it only works when you actually begin recording, and the longer you leave it, the more resources it's going to consume, so it's probably not the greatest solution. 

    @BCS-MAN: Thanks! Glad you found it helpful.

    IMHO, and until a fix is in place, as painful as it might sound, the best solution so far is to replace the file with an older version. doing that, does indeed brings back normal functionality without losing anything.

    16 Mei 2018 20:34
  • I did notice that after my Windows 10 system updated to 1803, every time I would drag a Remote Desktop window over to my second monitor it would cause it to reset the video connection to that monitor. My second monitor is connected to an external USB adapter that has a DisplayLink video connection. I just thought it was the USB device flaking out on me, until I ready some of these other posts.

    Because we all know that Microsoft couldn't possibly put out a bad update that would cause goofy hardware issues. ;) 

      
    • Diedit oleh BCS-MAN 16 Mei 2018 20:54
    16 Mei 2018 20:52
  • In the Microsoft Store install the "Remote Desktop App".

    It works well.

    Remote app is also possible.

    Greetings

    17 Mei 2018 11:10
  • There are no peripherals available in the store application. It is not possible to use printer and other peripheral devices, such as serial port mapping.

    so it's just a problem for users who work as viewers :-(
    17 Mei 2018 11:23
  • If we already know that we can roll back the remote desktop client files to the version prior to the 1803 update and get back full functionality. Why can't Microsoft simply push out an update that does this for us until such time that they can get their poo straightened out. Bad form Microsoft, for making your users deal with this problem for so long when their is an obvious immediate fix.

    Some companies actually use your remote app technology for business critical applications. This is not just a minor annoyance, it's a major business buster. I've been dealing with different bugs in the May 8th update for the past week and starting to get a bit irritated at the lack of urgency.   

      
    17 Mei 2018 12:32
  • We too are experiencing this issue with 1803. Disabling RemoteFX graphics helps but limits the app's other features. Eagerly awaiting fix.

    Doug Kinzinger, MCSE

    17 Mei 2018 13:30
  • We are also affected, how can we add to the same ticket so they are aware of how far reaching this issue is?
    17 Mei 2018 13:35
  • Microsoft isn't communicating and they are making it worse day-by-day with pushing this update out to users. If you have a moment, please tweet @MicrosoftHelps, @Microsoft. Post it anywhere you can on social media. I've tried talking to them on several occasions and get no response other than a vague acknowledgment that they know there's an issue. 

    17 Mei 2018 14:39
  • if you don't need any special things. Just use the app "Remote Desktop" from the Microsoft Store.

    You can add your feeds and keep using the remote app.


    • Diedit oleh Numb13 17 Mei 2018 14:54
    17 Mei 2018 14:49
  • @Numb13 thanks for the recommendation but this isnt a workable solution in a business environment.
    17 Mei 2018 15:26
  • What do you think we use it for.

    We are running "Microsoft Dynamics NAV".

    About 50users.

    All using remote app.

    Now because of the update we are all using the app from the store.


    • Diedit oleh Numb13 17 Mei 2018 15:31
    17 Mei 2018 15:28
  • Unfortunately that doesnt work when you require full device integration. We also have several thousand users that rely on this to function. Hopefully Microsoft gets this figured out soon.
    17 Mei 2018 16:08
  • Hey guys, 

    An update for now: We heard back from MS, and they are now asking us to deploy a 2016 to test to make sure that the issue happens there. I did send them a pretty snippy response, since I feel like it is their responsibility at this point to perform their testing now that we've actually proven this is an actual bug.

    We don't feel that building that server is necessary based on what you guys reported here. Since we don't have any 2016 available, the issue is in fact happening on 2016, correct? 

    I would appreciate a confirmation.

    17 Mei 2018 16:30
  • I can verify that the issue is happening on 2016 server as well. We have many 2012 R2 servers it's happening on, and several 2016 servers too.

    17 Mei 2018 16:45
  • The recommended way to report this to MS apparently is to use the Feedback Hub.

    If you have Windows 10 please send a feedback issue using these steps: 

    - Start | Feedback Hub

    - + Add New Feedback

    - What kind of feedback is it? Be sure to select 'Problem'. 

    - Provide info that you can. 

    Thanks guys. Hopefully if we all send in reports this will be bumped in priority. 

    17 Mei 2018 17:22
  • We are noticing the same issue under ax 2009. 

    Please let me know if you find a better workaround.

    thanks,

    17 Mei 2018 19:07
  • The same issue with SVR2016 and 10Pro clients. Rolling back clients to old version 10.0.15063.0 (1703) of mstsc.exe and mstscax.dll solves temporarily the problem, until next second Tuesday, of course :(

    What do we want?
    The whole case starting with Windows 8 is some kind of public beta test... The quality also equals the price - mostly "free" upgrade from Win7/8.
    I must say, for "free" is Win10 too expensive. MS should pay us. We all are free MS's test rats...

    And what about dialogs layering and RDA windows maximizing?
    This is a complete disaster...



    17 Mei 2018 19:10
  • We can verify this as well on Server 2016.
    17 Mei 2018 19:40
  • Thanks all. I had responded to Microsoft with that in the morning (just so that we don't waste any time). But thanks for confirming. I've actually sent the engineer the link to this thread... hopefully it'll help light a fire under them.  

    (Also submitted feedback via the Feedback hub, to support the cause) :) 


    17 Mei 2018 20:10
  • Headed to feedback hub now, thanks guys for staying actives, nice to have a community behind this. 
    17 Mei 2018 20:52
  • Same here.  Thanks guys.

    18 Mei 2018 1:14
  • Have reported on the feedback hub also. Look forward to any updates...
    • Disarankan sebagai Jawaban oleh Catano 18 Mei 2018 10:18
    • Saran Jawaban dibatalkan oleh Catano 18 Mei 2018 10:19
    18 Mei 2018 8:16
  • Same problem here using Server 2016 and Windows 10 Pro.  Update 1803 caused mouse commands to be delayed or not work at all (especially right click) when accessing Remote Apps.  We're stuck using Remote Desktop until this gets fixed, which has caused the productivity of dozens of users to decrease given the fact that not all application they need are hosted, and the need to switch between the Remote Desktop environment and the local machine.

    Very surprised and let down that this has taken so long to fix.  

     
    18 Mei 2018 9:31
  • Following...we have the same for 2012R2 and 2016.

    Interestingly Windows 2019 Insider preview 17666 does NOT have this issue. RemoteApps hosted on this server exhibit none of the issues

    18 Mei 2018 12:07
  • I came in this morning after rolling back the remote desktop executable and .DLL file on a couple clients yesterday and was greeted with a user that had the popup window on their screen that said "The Remote Desktop Services ActiveX control (mstscax.dll) does not match the version of the client shell." I had to reapply the older version of the files again to get it to go away and allow her to connect. Grrr!

    Hope you guys don't start experiencing this as well. 
    • Diedit oleh BCS-MAN 18 Mei 2018 12:58
    18 Mei 2018 12:55
  • We are asking our clients to roll back the Windows updates using "Recovery Options" until Microsoft fixes this.  We are also asking them to type MSTSC.EXE in the reason why apps are not working.  If they get enough people not installing or uninstalling the update due to an error that should prompt a more urgent response.
    18 Mei 2018 14:49
  • Same problem here. Have had to roll back mstsc.exe client manually or using scripts... please fix asap!
    18 Mei 2018 15:17
  • Hey @BCS-MAN. That's an interesting, and crappy discovery! Thanks for the heads up on it!

    We haven't started experiencing, but I wonder if you ran into some variable that we haven't run into yet. Will test out.

    Re: Microsoft, they still haven't gotten back to us since yesterday. Sent another request for update this morning.

    18 Mei 2018 16:36
  • Yeah, I did look at her Microsoft updates list in Control Panel under Programs and Features just to see if anything had gotten applied over night, but it only showed the May 8th update as the most recent which was applied on 5/14. So nothing ground breaking to report other than that. 

    The other user that I applied the updates too on the same day had no ill effects, so your hypothesis of an odd variable seems plausible. +1 for the crappy discovery. :)

    Now if we can just tilt the crap meter in the right direction on the Microsoft side, maybe we can finally flush this one and move on to the next clog!
    • Diedit oleh BCS-MAN 18 Mei 2018 17:01
    18 Mei 2018 16:54
  • @BCS-MAN: YAY for tilting the crap meter LOL 

    As for an update. This was from a couple minutes ago from Microsoft. They're just being completely useless. I keep sending them links to back to this thread where you guys have already tried all the suggestions they're giving to no avail. (I'm pretty sure they're not even clicking on the link).

    By the way: Can anyone confirm whether the 1803 update can be blocked for more than 60 days?  Someone told me that was the limit?  If it is, this makes this matter all that much more urgent!

    18 Mei 2018 17:35
  • And another reply from them... apparently, we're sitting ducks at this point. They do apologize for the "inconvenient" though :-D 

    I think at this point, the best route is to hammer them with reports about the problem, and if you can even open a case with MS yourselves. (you will get refunded, 100%, since this is a bug). But it will put some more pressure.

    18 Mei 2018 17:41
  • All, not sure if you have also been part of another thread which I just discovered: 

    https://social.technet.microsoft.com/Forums/windows/en-US/cdf12bbc-ff78-4d6e-9e12-63f99ae4d511/w10-1709-remoteapp-popups-hidden-behind-main-window?forum=winserverTS


    18 Mei 2018 17:52
  • Thanks GTMERP, though the news is disappointing (not unexpected). We have to keep the pressure on. I've made accounts on twitter, reddit, facebook, HN to try and get this more attention. Bit ridiculous I have to act like this to try and get information. 
    18 Mei 2018 19:01
  • I have Dynamics ax 2009, Windows server 2012R2.  Remote Desktop App for the Dynamics.

    The same issue, I click in the botton and it is not display the information.

    In this moment, I RollBack the update 1803 to my users and works.  
    I hope that Microsoft solve it soon.

    This recommendation no work for Dynamics Ax:Computer Configuration/Policies/Admin Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Remote Session Environment: Use advanced RemoteFX graphics for RemoteApp – Disabled

    18 Mei 2018 19:06
  • So, this is major bug number 2. Check this one out https://social.technet.microsoft.com/Forums/en-US/cdf12bbc-ff78-4d6e-9e12-63f99ae4d511/w10-1709-remoteapp-popups-hidden-behind-main-window?forum=winserverTS

    Basically since November 2017, RemoteaApp had totally, completely and utterly been broken. Microsoft - I have no words for this level of incompetence. Remoteapp is a business/mission critical tool, and if you manage to keep this one f-ed for months at a time, it's almost like you're forcing your paying customers off this platform. 

    What's going on?????????

    Do you not have funds for a stable testing department? Do you even test your updates out just a little bit before you push them out? 

    It's imperative that you fix all these bugs ASAP. ASAP. 

    18 Mei 2018 19:40
  • It looks like remote apps are not the only issue with 1803. Check out this forum, apparently Microsoft put the 1803 update into the wrong channel initially and it was force installed for folks who didn't want it right away. What the heck Microsoft???

    https://social.technet.microsoft.com/Forums/en-US/bd7fc697-9417-434b-b90f-d1b6597a3087/1803-skipped-semiannual-channel-targeted?forum=win10itprosetup


    • Diedit oleh BCS-MAN 18 Mei 2018 20:13
    18 Mei 2018 20:13
  • So while we're on the topic of crappy patches, and while we're waiting :)   What do you guys use to stay abreast of what's coming up? 

    I have this: https://portal.msrc.microsoft.com/en-us/security-guidance which is useless, as it release information about patches on the actual day they're released, and then there's this:

    https://www.askwoody.com/tag/patch-lady-posts/

    Which seems a bit more hopeful, but still relying on random searches for stuff. 

    Anyone have any good resources they use to keep on top of what's coming up with patches? 


    18 Mei 2018 21:13
  • Pretty much same for me. wait and see approach and search the typical media sources for anything that looks promising. I actually think Microsoft doesn't even know what they are putting out or what will make the cut until the last minute anyway. This is evident by their lack of quality control and in house testing.   
    18 Mei 2018 21:21
  • I was afraid of this answer. 

    The "wait and see" approach, caused us 100 tickets in a matter of 4 hours on Wednesday morning after Patch Tuesday.... 

    We're just trying to find ways to be more proactive, but I can't seem to find any reliable sources to do so.

    p.s: I submit we categorize the term "Patch Tuesday" as a cuss word :-D 


    18 Mei 2018 21:23
  • There is this option, but I've not used it myself and it would require you to touch every machine unless you could somehow push out the install and settings in the background somehow. 

    https://www.rizonesoft.com/downloads/windows-10-update-switch/

    It allows you to set every connection to metered which would stop all background downloads of Microsoft updates until you wanted to let them through. It would be nice if they had a networks version with an admin console you could turn on and off yourself.

    18 Mei 2018 21:41
  • Our role, as it relates to the Windows 10 machines (or clients) is actually more an advisory one. We only have control of our own servers. (we're a cloud hosting provider), so the end user's workstations connecting to us are within their own domains, and controlled by their respective IT departments (Or the owner's cousin, Tommy :) 

    We're just trying to give advisories to issues that could interrupt connectivity to our service due to changes that are out of our control, so that our clients can appropriately address them.

    Thanks for that link, will check it out. We can always make it available as a recommendation for them to use in case they're not running central patching of some sort.

    18 Mei 2018 21:46
  • Still no news from Microsoft. I'm still asking affected users to make bug reports. Let's keep it up, I really don't think Microsoft is concerned with this problem or has a full understanding just how many people are affected. 
    19 Mei 2018 15:35
  • Good monday everybody. Have anybody found something new about this?

    1803 spreading and causing lots of troubles in our organization...

    It would be really nice to get hotfix from Microsoft, because I would not like change permissions of files in system32.(Replacing mstsc.exe and mstscax.dll-2- )

    Please, take this serious...


    21 Mei 2018 5:54
  • I was thinking over the weekend, another option might be if your router has the ability you could block the Microsoft update URL'S from the router side just to get past the 60 day limit before the operating system forces the update. That is of course, unless Microsoft gets off their rear and fixes this issue.  
    21 Mei 2018 11:56
  • @GTMERP It looks like your article on your web site is tracking pretty high in the search topics. I'm wondering if you should post another one with a topic heading of "Microsoft Leaves Users In Limbo After Update 1803 Breaks Remote Desktop". Maybe that would get their attention!  

    This just in... users all over the web have been reporting serious issues with remote desktop usability after the latest Microsoft 1803 update. Microsoft on the other hand has basically gone dark on the issue after asking users to repeatedly try mundane tasks to try and correct the problem. Users have had to attempt troubleshooting on their own and report their findings back to Microsoft who doesn't seem interested at all in rolling back the problem forced upon their customers to help afflicted users.

    Other users have reported that the bugs affects all currently supported versions of remote desktop accept the current beta version of Windows 2019. Could this be a way for Microsoft to force users to the new platform? Or is Microsoft leaving their current user base to search for other alternatives while they put their heads in the sand?    


    • Diedit oleh BCS-MAN 21 Mei 2018 13:54
    21 Mei 2018 13:41
  • Hello,

    We have the same problem at our company.

    We have 50/50 Windows computers and Mac.

    The Mac computers uses Microsoft Remote Desktop.

    So I tried it on the W10 machines and with sucess.

    So if you are like us, have no solution at the moment. Then I recommend to try Microsoft Remote Desktop until RDP is fixed so the users can do their work :)

    Best Regards

    Alexander

    21 Mei 2018 16:18
  • Hey @BCS-MAN: 

    Not exactly the kind of "fame" I'm after here haha.

    Anyway, that KB location is actually for our knowledgebase, so publishing such an article there doesn't seem like the right place, but I'm checking with our web team to see if we can publish something on our blog and social media. 

    MS is being way slow in responding to this issue. Quite disappointing. 

    21 Mei 2018 17:11
  • Hi all, 

    No good news or anything, but just an update from about 5 minutes ago from Microsoft:

    \

    Will keep the updates coming as we have them.

    21 Mei 2018 17:28

  • Hey all, I'm not sure if you are monitoring the other thread, but at least there is some response from someone at Microsoft on it, and this is the latest response. Ron seems to be monitoring this thread as well. (Thanks Ron... we see you! :) ) 

    "The RS3 fix is slated to release today. I will monitor and update this thread ASAP.

    Also, I am aware of the RS4 issue discussed here - https://social.technet.microsoft.com/Forums/en-US/f3e9852b-393c-4aa0-9d2f-961a82cfc603/remoteapp-after-windows-10-update-1803-are-slow-and-right-mouse-button-is-not-responding-it-reacts?forum=winserverTS&prof=required

    We are investigating this RS4 issue and I will have more news shortly. 

    Thanks,

    Ron Stock
    Sr. Escalation Engineer | Support Engineering -  Cloud & Infrastructure Solutions | Escalation Engineering"


    21 Mei 2018 19:06
  • Nice, glad to hear they are actively working on a solution. Communication is key, they should be more proactive about keeping folks updated. Does no good to let irritated customers stew in their own juices for days on end, but it's always nice to have folks to commiserate with. :)  

    We're not a huge company, but we do have a pretty significant investment in Microsoft technology to the tune of multiple 6 figures. We use remote apps for all of our users to access Microsoft Dynamics AX from a terminal server farm. This keeps us from having to manage client installs on every machine and makes remote access to the application a snap, since we can simply push out the remote apps and they will run externally just as well as they do internally. Or at least they did until this last update. Grrr!

    • Diedit oleh BCS-MAN 21 Mei 2018 21:00
    21 Mei 2018 20:13
  • Starting to get dire on our end. Only working solution for us has been reverting to 1709 and some users no longer have that option.
    21 Mei 2018 20:47
  • Hello - I've been working on the other RS3 thread here-  https://social.technet.microsoft.com/Forums/en-US/cdf12bbc-ff78-4d6e-9e12-63f99ae4d511/w10-1709-remoteapp-popups-hidden-behind-main-window?forum=winserverTS&prof=required

    With the RS3 issue addressed, I'll start posting here to discuss the RS4(1803) context menu, z-order issue. The good news is we understand the root cause and we will have mitigation. I will keep you posted as we work through the bug process.

    Thanks,

    Ron Stock
    Sr. Escalation Engineer | Support Engineering

    Cloud & Infrastructure Solutions | Escalation Engineering

    21 Mei 2018 22:10
  • Thank you @Ron Stock! We're all eagerly waiting! 

    Thanks for your work on this! 

    22 Mei 2018 0:04
  • Ron, thank you very much for the information. We're excited to hear this is being looked at. 
    22 Mei 2018 0:20
  • Dont worry about changing permissions before files swap. You can return them by

    icacls "C:\Windows\System32\mstsc.exe" /setowner "NT Service\TrustedInstaller"
    icacls "C:\Windows\System32\mstscax.dll" /setowner "NT Service\TrustedInstaller"
    22 Mei 2018 8:22
  • Damn! Should not have updated our users to 1803. This issue is even worse than the old Z-index problem. Now we cant use our CRM system at all.
    22 Mei 2018 10:18

  • Other than context-menu issue, anyone noticed the taskbar windows-preview not appearing as well for RemoteApps ?

    I am hopeful nothing else breaks after fixing the newly identified issues.


    22 Mei 2018 10:45
  • Thanks Ron for your attention to this issue, it's causing a lot of pain.
    22 Mei 2018 12:01
  • Thanks for the post @Fireballcz, that's good information, but you still have to change the permissions on the files before the operating system will allow you to overwrite them.
    22 Mei 2018 12:05
  • You guys can use the script on the "Knowall IT" blog, which can take care of all the permissions. (Can't vouch for the quality of the files downloaded, but you can always point them to your own source..) http://www.knowall.net/blog/known-bug-with-windows-10-and-remote-desktop-rds-remote-apps-selected-windows-do-not-respond-fix/
    22 Mei 2018 13:18
  • I have also received reports from some of our users that are experiencing the taskbar windows preview not working.

    Normally if a user has several windows open in our application, they will see stacked tabs in the taskbar and when they hover over the stack it will preview the open windows. 

    They are reporting that this is not working, in addition to all the other issues that are occurring.


    22 Mei 2018 13:31
  • Yes, that is the issue I'm currently dealing with.  Disabling "Use advanced RemoteFX graphics for RemoteApp" fixed the drop down and right click issues for us, but the taskbar/windows preview issue is currently causing a problem for us as not all windows are showing up for us.
    22 Mei 2018 15:32
  • Just wondering... am I the only one compulsively hitting "Refresh" on this thread? :-D 
    22 Mei 2018 21:49
  • I'm right there with ya
    22 Mei 2018 22:13
  • I feel like I have self control. I only check it about once an hour... :)
    22 Mei 2018 22:30
  • Refreshing every 20 min's

    22 Mei 2018 23:32
  • Two or three times a day for me
    23 Mei 2018 7:23
  • My finger is on button.

    Hot Fix when you come and save me....

    23 Mei 2018 7:24
  • Same problems. Following...
    23 Mei 2018 9:45
  • technology was designed to help us as I recall :D

    23 Mei 2018 9:49
  • Can you share please?? 

    Thanks!

    23 Mei 2018 11:11
  • @menjoy: the workaround was already provided. If disabling the remoteFX setting at the server does not help (here, it does not), then tell you users to start psr (Press winkey+r and enter psr), start recording and the problem is gone for the time it's recording.
    23 Mei 2018 11:31
  • The only acceptable solution is a new windows update or a rollback of the previous update. Not everyone has access to all of their client's computers.
    23 Mei 2018 12:34
  • The only acceptable solution is a new windows update or a rollback of the previous update. Not everyone has access to all of their client's computers.
    I concur. Client computer tweaks etc. do not make the cut for an ideal solution. Besides lack of access to client computers, need for coordination with X number of users etc., there is also the reputation factor to think of. People're going to be pretty unhappy if the IT department keeps changing stuff on their computers all the time. And, it's a significant time sink as well, lots of users may not be too tech savvy and may require hand holding to walk through the patch, thereby consuming valuable time. 
    23 Mei 2018 13:04
  • Yes, I'm f5ing this thing every few minutes. 

    There's no way I can ask our users to open PSR and record to avoid this bug. That's not a workaround, that's just adding more problems to the pile. (Not to discount its cleverness)

    23 Mei 2018 13:05
  • I've limited my thread refresh to about 4 times per day, but only because limited updates from the Microsoft crew has dashed my hopes for an immediate solution. However, I do still need to get my daily dose of sarcasm and disappointment, so full speed ahead Mr. Sulu, maximum warp!

    On a side note, my users are now starting to see the forced update screen where they have to pick a date and time for the 1803 update. I'll just wait for the update to be applied and then roll back the remote desktop files. Luckily most of our users are still running Windows 7. We were just planning a new hardware refresh and operating system deployment to Windows 10 over the summer. This issue has placed that scenario on hold.   

    #HoldingSteady
    • Diedit oleh BCS-MAN 23 Mei 2018 14:43
    23 Mei 2018 14:35
  • @BCS-MAN... One thing that could work, and that will only apply to those who might have central management of their workstations (i.e: KACE, ConnectWise Automate, etc...) , you can write a script to replace those 2 files on the workstations. You can do this for your all your users, and they wouldn't even be able to tell, and no reboot is even required. 

    I wish that is applicable for me, but I only have central management of my servers, but not the client's workstations.

    23 Mei 2018 15:01
  • Currently users who cant deal with these issues we apply the following fix 

    http://www.knowall.net/blog/known-bug-with-windows-10-and-remote-desktop-rds-remote-apps-selected-windows-do-not-respond-fix/

    this will roll back the MSTSC files back to a stable version.

    23 Mei 2018 15:19
  • Thank you for the feedback on this thread! We are currently working on an official fix for the RS4 (1803) context menu window issue. I will continue to update this thread with details.

    Thanks,

    Ron Stock
    Sr. Escalation Engineer | Support Engineering

    Cloud & Infrastructure Solutions | Escalation Engineering



    • Disarankan sebagai Jawaban oleh M. Janto 23 Mei 2018 15:55
    • Saran Jawaban dibatalkan oleh M. Janto 23 Mei 2018 15:56
    • Disarankan sebagai Jawaban oleh Jack Alacka 23 Mei 2018 16:09
    • Diedit oleh Ron Stock 23 Mei 2018 16:19
    23 Mei 2018 15:42
  • Hello Dale Kingston, Have you found a fix to this issue of <g class="gr_ gr_12 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="12" id="12">RemoteAPP</g> being slow with your ERP?
    • Diedit oleh AngeBee 23 Mei 2018 15:45
    23 Mei 2018 15:44
  • Hi Ron Stock, please also check the speed problem. The customer also has an ADSL service where, after the last update, the total work with the remote app is very slow. Especially when printing on POS printers. Very common error is a malfunctioning touch through the remote app, touching the remote app stops working, locally on the PC works ok. After logging out and signing in again, touching the remote app works

    Thanks


    • Diedit oleh M. Janto 23 Mei 2018 15:59
    23 Mei 2018 15:58
  • Hey Ron,

    we have this weird issue since updating to 1709 , but this only happens with Server 2012 "R1" as session host and not with all applications. As soon as we minimize the RemoteApp Window and then try to maximize it again we get a blackscreen. We never had this issue with earlier Win10 Versions (we rolled back to 1703)



    23 Mei 2018 16:15
  •  As soon as we minimize the RemoteApp Window and then try to maximize it again we get a blackscreen. We never had this issue with earlier Win10 Versions (we rolled back to 1703)

    This is exactly what has been happening with our RemoteApp windows from Server 2012 "R1" with clients running Windows 10 1803.  After minimizing them they drop to the lower-left corner of the screen and the application window can't be restored without closing and reopening the RemoteApp.  We are having to use the old versions (1703) of the mstsc.exe and mstscax.dll after multiple complaints from users.

    At first I thought it was related to the interaction between different local and remote DPI scaling levels, but it seems to be occurring on all Windows 10 1803 clients regardless of DPI settings.

    • Diedit oleh Dekertek 23 Mei 2018 18:46
    23 Mei 2018 18:39
  • Thank you for the feedback on this thread! We are currently working on an official fix for the RS4 (1803) context menu window issue. I will continue to update this thread with details.

    Thanks,

    Ron Stock
    Sr. Escalation Engineer | Support Engineering

    Cloud & Infrastructure Solutions | Escalation Engineering


    Ron, now that this has been established as affecting millions of users, mostly in business environments(that's who uses RemoteApp the most), what is the reasoning for leaving millions of people in an unworkable state instead of Microsoft admitting their mistake and rolling the update back? Maybe you think it's acceptable to leave millions of clueless users in a state of not being able to run their businesses but pretty much the rest of the world does not feel the same. Having to tell customers to do a windows update roll back, or, if they don't know what you are talking about, hire an IT professional at $90 an hour to do it for them, is not a acceptable solution. This problem has been going on for quite some time and here we are, still waiting for a solution from Microsoft when the solution is right in front of your face, roll this trash update back and when you can get all the bugs worked out, force it on people again.
    23 Mei 2018 19:15
  • You're saying that Microsoft needs to rollback the entire 1803 update for their entire userbase to fix a problem that a small subset of their users (who happen to usually be businesses) are experiencing, or are you suggesting that they push out the 1703 MSTSC files as a new update, or perhaps just venting? Not trying to get you riled up or anything. I'm just trying to understand what the suggestion you're offering entails.
    23 Mei 2018 19:46
  • I think he and myself would be satisfied with a simple update that rolls back the remote desktop files. This could be pushed out to the masses quietly and would effect no one, but it would allow the problem to be fixed momentarily while they work on the actual fix and would keep the System Admins from having to come up with alternate solutions that involve having to touch every machine individually.

    Sure you can somewhat automate the process if you know how to code, but the majority of System Admins are not coders.  

     He just said it with a bit more zest!
    • Diedit oleh BCS-MAN 23 Mei 2018 20:01
    23 Mei 2018 20:00
  • This has been a quick and easy "temporary" fix. Thank you! 

    Dear Microsoft,

    Please TEST your updates before releasing them to the hard working Americans.

    Thank you


    23 Mei 2018 20:12
  • This has been a quick and easy "temporary" fix. Thank you! 

    Dear Microsoft,

    Please TEST your updates before releasing them to the hard working Americans.

    Thank you


    Can we get an AMEN?
    23 Mei 2018 20:17
  •  As soon as we minimize the RemoteApp Window and then try to maximize it again we get a blackscreen. We never had this issue with earlier Win10 Versions (we rolled back to 1703)

    This is exactly what has been happening with our RemoteApp windows from Server 2012 "R1" with clients running Windows 10 1803.  After minimizing them they drop to the lower-left corner of the screen and the application window can't be restored without closing and reopening the RemoteApp.  We are having to use the old versions (1703) of the mstsc.exe and mstscax.dll after multiple complaints from users.

    At first I thought it was related to the interaction between different local and remote DPI scaling levels, but it seems to be occurring on all Windows 10 1803 clients regardless of DPI settings.

    Yep sadly noone seems to be still using 2012 r1 (especially not with remoteapp)  so they probably won't fix that I'm afraid. I already posted a few threads and comments and tried to contact Microsoft but noone could help
    23 Mei 2018 20:17
  • As a workaround (I know this forces you to touch each workstation unless forcing through GPO),  reverting to using Remote Desktop instead of RemoteApp works well.   Remote Gateway settings and/or Remote desktop settings need to be configured properly but this DOES work well for us for the time being and all of the apps work in the desktop mode. I hope this workaround works well for you too....

    23 Mei 2018 20:18
  • I am telling you that they cannot and should not be allowed to FORCE an update on people which then breaks every aspect of the software that they use to do business with and then just DO NOTHING for 3 weeks, then finally come in after the 3 weeks of stewing and leave a comment of "we are looking into it" while everyone is desperately waiting for a fix.

    I work at a small company that delivers software via RemoteApp to several hundred business's across our nation. Every single one of those businesses, each with 25-250 users, who uses Windows 10 and received this update can no longer use our software correctly. Every time one of them calls, we have to tell them to either Roll their windows 10 update back, hire an IT professional if they are not capable of doing that themselves, or to go without software that helps their business run. Does that sound reasonable to you? Now scale this up to companies that are SUBSTANTIALLY larger, 10x, 100x larger, not hard to imagine how widespread this can be.

    BTW, a small subset of 500 million Windows 10 users and we are still talking about millions of users, if not tens of millions.

    23 Mei 2018 20:58
  • This may be a little off topic, but I just saw online today where the new version of Microsoft Office 2019 will be supported on Windows 10 only. Since Windows 10 is said to be the last version of Windows and that Microsoft will just roll out feature updates from here on out, basically what that means is that over time we will all be pushed to Windows 10 while older operating systems and software get phased out. 

    One of the great things about older version of Windows, is that they were pretty bug free at the end of their life cycle. You could still run them for a while and wait for the next version to become more stable before betting the farm on the new version. We're past that model folks, from here on out it's beta city. New feature updates will be forcefully pushed and we'll have to wait while software developers fix issues in the operating system or fix incompatibility issues with the applications running on the operating systems once the new features are incorporated and all the bugs become known. Ugh!

        

      
    23 Mei 2018 21:04
  • There are many movies about AI that was doomed the mankind. It looks like the MSTSC.exe has a equal potential…

    Microsoft, come on! Its nearly a month, what I can say to my clients? How many programmers do you have for Windows? Two? Both on vacation?

    23 Mei 2018 21:27
  • This has been a quick and easy "temporary" fix. Thank you! 

    Dear Microsoft,

    Please TEST your updates before releasing them to the hard working Americans.

    Thank you



    This problem affects more than just Americans
    24 Mei 2018 7:14
  • Note: I'm about to rant, so please feel free to skip if it's irrelevant! 

    @Ron Stock:

    I understand that you are not in control or a decision maker in what I'm about to state, so please don't take it personally, but, what I would expect, is that you do your best to escalate this concern to the powers that be at Microsoft to improve this process. I believe that what I'm about to state will likely echo the feelings of everyone on this thread, and millions of unheard voices stifled by the Behemoth that is Microsoft.

    We, of all people, understand technology and that there are bugs. However, of all our expenses, I could safely say that Microsoft sits on top when it comes to paying for licensing. Even though we prefer that to be different and not so extortionist, we're accepting it, but here's the caveat, charging so much for your product comes with great responsibility, which is to deliver a product that doesn't cripple businesses from the ground up, with no ETA on problems that are so severe. 

    These problems, as a matter of fact should not be allowed to happen. What's worse is, we have no recourse for any reimbursement in any form, for any lost business that is caused by MS. Everything we do is always to Microsoft's advantage to make an extra buck. Want a couple examples? 

    - Any time I call for support, I have to pay $400 up front, and have to argue that my case is due for a refund due to a fault of yours

    - I over pay for licensing due to a mistake in reporting (which happens frequently to the nature of our business), We're unable to get any refund for more than 30 days (or 60, don't recall which) after the fact . But yet, if we are under reporting, also due to an honest mistake, we get slapped with ridiculous fines for doing so. 

    See anything one sided in this? 

    But yet, when we deal with situations that we hope that will get us our money's worth, i.e: Saving our business from a disaster due to a mistake that we have no control over, we get a response like this from our Microsoft support person. This is from yesterday, and quoted by the MS Support Engineer, about 14 days after opening the ticket about the issue:

    Really? that's all we get??? We are all hurting, and yet, can do absolutely nothing about it. As you can see in the thread, we're all coming up with workarounds, and getting black eyes from our customers and presenting them with unreasonable ways to solutions that they'll have to revert or further extend to permanently resolve later on. 

    You know what is the worst part about all this is? ... Microsoft is moving to the new - I'd say ridiculous - windows update model, which is forcing updates down our throats and making it harder and harder to avoid or control them. When you have a system like this, you need to have 2 things that are guaranteed, for one, because we're having to sell a kidney to buy your products, and two, because bugs like this will become absolutely crippling to us. 

    Here they are: 

    1- and that is ideal: Test Test and Test before releasing. We understand that sometimes a windows update can conflict with a 3rd party software, and that you can't test for all these variables with millions of software out there. However, today's situation is 100% Microsoft, and completely independent of any 3rd party, so there is no excuse for not having tested it fully. 

    2- Have some sort of notification system, or channel that has "upcoming updates", and what is changing. Sure, we have the Windows Update Security Guide here: https://portal.msrc.microsoft.com/en-us/ 

    But that doesn't release anything until the day of the updates. completely useless to help to be prepared.

    and some poor woman who everyone looks to, because she's the "authority" on patching here: 

    https://www.askwoody.com/tag/patch-lady-posts/ 

    and the rest is a bunch of random googling to see if anyone has an insight about what's coming. 

    What's worse is we even asked our MS Engineer to refer us to a place to check what is coming so that we can be better prepared.... Here's the response, verbatim: 

    Seriously? How are we expected to sleep at night when Microsoft is a ticking time-bomb sitting in our server farms every month. This can't happen, and needs to be addressed ASAP. The CredSSP issue was another disaster that happened less than a few weeks before this one as well. 

    Sorry for the long rant, but this needs to be said, as I'm sure a lot of people on this thread and elsewhere have the same concerns. I would encourage you to vote this up, and I would truly hope that Ron will take this and escalate it up the chain. 

    Thanks for your time. 

    /Rant

    on a more relevant and current note: What's the status of the patch for the 1803 issue, @Ron Stock?






    24 Mei 2018 13:08
  • The solution is simple, give us control back for Windows updates. As IT admins, especially those of us with large server farms will perform due diligence on making sure our environments are secure and patched after we also perform our due diligence on making sure it's not going to cripple our operations when applying updates.

    I can understand forcing updates on certain versions of Windows such as Home but professional versions of Windows should be left to the IT "pros" on determining the update schedules and selections.

    We have been a Citrix shop for the past 15 years and only started testing RDS as a replacement over the last month and what we've found has been alarming to say the least with one issue after another that has actually been introduced by Microsoft.

    RDS could simplify our lives tremendously and I'm still holding on to hope for a change of policy on updates but until then I think we'll stay the Citrix course.

    Microsoft - please listen to your customers.

    -Lanit

    24 Mei 2018 14:03
  • 1803 is being pushed harder today.  We will be rolling back many people.  We always report to Microsoft that apps did not work and use MSTSC.EXE in the box below to be consistent.   Microsoft should just sent a hotfix of the previous version.  Urgent problem solved.  Then go back to the drawing board on the "new version".  
    24 Mei 2018 14:36
  • Windows 10 Updates have become a dirty word in our organization.  If you delay patches you might end up with the CredSSP issue where an outside client got updated.  If you run them, you risk breaking a functional working system because Microsoft no longer (apparently) tests their patches prior to releasing them.  This year has been the absolute worst when it comes to Microsoft. And don't get me started on that Intel Nic bug Microsoft forced down our throats earlier this year.  It's kind of hard to get in and fix a system when the NIC has become effectively disabled due to a patch, that even when delaying you still get burned on (and don't get me started on "well derp derp you should have tested the patch thoroughly <g class="gr_ gr_3584 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling only-del replaceWithoutSep" data-gr-id="3584" id="3584">derp derp</g>".  These rollups DON'T LIST what is REALLY coming up in them.  So you don't patch anything at all, then get your hand slapped by the security officer for putting your systems at risk for zero-day/known exploits, or you're put in this position of supporting Windows 10 clients that are forcefully patching themselves, again out of anyone's control other than Microsoft. 

    If Microsoft is going to force the current patching mechanism where no one really gets to pick and choose, then they also need to OWN the testing at QA process.  Right now it's a huge giant fail on their part.


    24 Mei 2018 17:04
  • We've a few hundred RemoteApp customers across 4 continents and this is burning us.

    We've had conflicting information about customers getting round the problem. Backing out of the updates doesn't appear to help, some have used recovery to revert and had success and others not. It appears that recovery for Windows 7 works better than Windows 10.

    Our clients are shouting at us, no matter how much we try to explain this is Microsoft's fault. Ironically, those running Remote Desktop on Macs are running fine, but the majority run Windows and we're dealing with our clients' various IT support teams, internal or third parties, and they do not want to get involved with reinstalling Windows or installing old versions of exe or dll files. Conveniently, they can also point the finger at us.

    We have some legacy Citrix XenApp servers, which are working fine and have been looking for alternative RDP clients, but most have too many restrictions.

    Please, please, please Microsoft. The OP created this on 2nd May, how on earth can you have not fixed this yet?

    24 Mei 2018 17:25
  • I have posted and watched this thread and similar forums and just wanted to mention the same:  We upgraded our Remote Desktop gateway/connection broker / session hosts a month ago to Windows 2016 and have been pushing out Windows 10 Pro machines to many users.  We just upgraded 325 Remote Desktop user CALS to 2016.

    We're getting negative comments and unhappy tech support calls from users such as:

    "Ever since you put the new system in, I can't get my job done."

    "This system is slow.  Please fix it."

    "Please give me back the old system.  It was much better before ""you did something to it""."

    As an I.T. support shop, we're able to bear the brunt of the criticism, but it doesn't help the user to reply with "Yes, it's a known Microsoft bug and they're aware of it  Estimated time of repair:  unknown." 

    Please Microsoft -- estimated time of repair?  

    24 Mei 2018 17:44
  • Hey all, forgive my skepticism at this point, and attributing most everything unusual we see with RemoteApp to something related to the Windows update.

    Just wondering if anyone else is seeing this problem. 

    We had this happen a couple time before today, only for one user within an environment (so it's Workstation specific), today is the first time we thought to check the Build of Windows, and in this case, the user is in fact on 1803. 

    The RemoteApp is accessible from everywhere, even the client's other workstations, and other networks, just not that particular workstation.  

    The message pops up so quickly upon launching the remoteapp, which tells me that it's failing even before it attempts to even contact the RDGW. 

    The workaround we found so far is to open the RDP file, and remove the line: 

    workspace id:s:RDGW.hosted.local

    Of course this only allows the user to login by launching the icon on their desktop and they would no longer be able to launch it directly from the Application Portal.

    We're currently experimenting with uninstalling some recent patches to see if it makes any difference. 

    If anyone has any ideas, please chime in, and if not, at least it's a heads up just in case this ends up being related to some update.

    UPDATE (Solution?)

    Found a thread regarding this very problem. Don't be surprised if you start seeing it in your environments. Apparently the OP got from Microsoft that they have no idea what's causing, but somehow they're working on a patch? ... not sure how. 

    https://community.spiceworks.com/topic/2128551-remoteapp-connection-sets-up-but-apps-won-t-launch?page=1

    In any case, if anyone faces it, the solution that works for most apparently is the following:

    1) Verify there is no wksprt.exe process running on the machine

    2) Launch cmd as administrator

    3) Run regsvr32 wksprtps.dll 





    24 Mei 2018 19:13
  • @GTMERP did this message correlate to any events in that stations event logs? I'd ask about the Gateway logs too, but due to it's immediate display, I'm guessing nothing would have been logged on that end.
    24 Mei 2018 19:51
  • Nice find @GTMERP. So basically the update forgot to register the .dll file for the remote desktop runtime executable? That's just bad form! No wonder the box was popping up immediately, because it couldn't find it's underlying .dll code to complete the connection. Get your crap together Microsoft!

    I'm starting to believe they called up the remote desktop B team to write the code for this latest feature update because all of their best and brightest were working on Windows 2019. That would explain why 2019 doesn't have the issue.  

     
    • Diedit oleh BCS-MAN 24 Mei 2018 20:20
    24 Mei 2018 20:17
  • My guess is as good as yours @BCS-MAN. Problem is that there are so many false-positives in the logs that it's so hard to correlate to the actual problem. I'm just happy that we found yet another workaround. At least our users won't be dead in the water, and we won't be asking them to "rebuild their machines"... *smh*
    24 Mei 2018 20:23
  • I just finished reading through the fix you directed us to over at Spiceworks. It almost sounds like the original code is cached somewhere and then some event clears the cache and then the connection breaks and can't be resolved until the .DLL file is re registered which then completes the connections to the code once again.

    The only other possibility would be that something in the code would unregister the .DLL, or even remove or corrupt the CLSID entries in the registry, but that would just be idiotic.    

    Alternately removing the "workspace id:s" portion of the configuration file cause alternate functions in the code to execute, which allows the connection to complete successfully as well.

    Hmm, all roads lead to the code... fix it Microsoft!

       


    • Diedit oleh BCS-MAN 24 Mei 2018 21:07
    24 Mei 2018 20:55
  • Is this related to drop down menu or pop up window focus? I applied this but doesn't seem to be fixed. This was supposed to be done on the client side, right?
    24 Mei 2018 21:48
  • @JohnnyNguyenPP : This is not related to the drop down, but can be quite disruptive as it will literally prevent the user from connecting until that process is followed. So, I just recommend you keep it in your back pocket, my guess is you're going to see it in your environment as well.
    24 Mei 2018 22:14
  • Same issue here. Users with 1803 using our RDP hosted apps that have dropdown menu options. I'm experiencing this myself in our financial system. It's driving a few staff absolutely nuts as it's making the apps appear slow and unresponive. Any word on a patch?
    25 Mei 2018 0:21
  • @GTMERP : Noted. Thank you.
    25 Mei 2018 2:05
  • I've seen this in many places where ppl are recommending to Use advanced RemoteFX graphics for RemoteApp in GPO on the server side, but it sounds a bit strange as the issue is on WIN10 1803 but the recommendation is to fix the server side? 

    If you have 100 machines and 10 of them are affected (because they are on 1803) you have to fix the server side and hope that it doesn't affect the other 90 perfectly working clients. How challenging is that? 

    BTW, just will add this so that others can see, a workaround replacing two mtsc.exe and mstscax.dll files resolved the issue for me.

    • Diedit oleh AFXXX 25 Mei 2018 11:18
    25 Mei 2018 11:12
  • @AFXXX Disabling the RemoteFX resolved the "lockup" issues for us, however when you minimize and restore a RemoteApp application it may be black.  Full screen Remote Desktop seems to be fine.  Also screen updates aren't always correct, so your mileage may vary.
    25 Mei 2018 11:41
  • Clearly, rolling back mstsc.exe and mstscax.dll provides a workaround until Microsoft releases a fix, but does anyone know if rolling back those files will reintroduce any part of the security vulnerabilities that the recent updates were meant to fix?  I find myself pouring through Microsoft patches to try to figure that out...maybe someone else has done that already.
    25 Mei 2018 12:23
  • WSUS with a test group has saved alot of update headaches for us in the past year.  As much of a pain it is to maintain.  However this is not helping our Mobile users not connected to our internal WSUS server.   But looks like can hold off the update up to 100+ days if you log on with admin rights, you should see the option to delay the feature update.

    You should also see different update channels to choose from. I believe one of the update channels will delay any major updates for upto 4 months.

    • Diedit oleh rm304 25 Mei 2018 13:01
    25 Mei 2018 12:42
  • Clearly, rolling back mstsc.exe and mstscax.dll provides a workaround until Microsoft releases a fix, but does anyone know if rolling back those files will reintroduce any part of the security vulnerabilities that the recent updates were meant to fix?  I find myself pouring through Microsoft patches to try to figure that out...maybe someone else has done that already.

    From my experience, your better off rolling back the update than trying to replace RDP files with older versions.
    25 Mei 2018 13:20
  • Rolling back the RDP files seems to be the best option currently, because this will still keep your system at the current 1803 level and will not make you have to duplicate work in the event that 1803 gets reapplied. If you check the earlier posts, Microsoft made a mistake early on and put the 1803 update in the wrong channel on their side and folks were still getting the update applied even though they had their channel settings updated.

    So you can do what's best for your environment, but I'm sticking with rolling back the RDP files, because it's the only thing that is truly working on our end without the possibility of being undone by Microsoft.

      

    • Diedit oleh BCS-MAN 25 Mei 2018 14:00
    25 Mei 2018 13:59
  • @Swithin Chandler, rolling back the RDP files may reintroduce the CredSSP vulnerability. However, this vulnerability is minimal due to the fact that it's a man in the middle attack. If you have someone who is able to get between your network and your terminal server to capture network packets and issue this attack, then you have way more issues than CredSSP. 

    Fixing the usability issue at the moment is way more important than worrying if someone is sitting on the inside of your network or out at the telephone pole at the road capturing packets as they enter your Remote Desktop Gateway. 

     
    25 Mei 2018 14:09
  • So here is something odd.  I wanted to submit feedback to Microsoft using the feedback hub.  When I was in screen capture mode in the feedback hub the drop down menus worked, as soon as a stopped capturing the drop downs did not work.  
    25 Mei 2018 15:11
  • Rolling back the RDP files seems to be the best option currently, because this will still keep your system at the current 1803 level and will not make you have to duplicate work in the event that 1803 gets reapplied. If you check the earlier posts, Microsoft made a mistake early on and put the 1803 update in the wrong channel on their side and folks were still getting the update applied even though they had their channel settings updated.

    So you can do what's best for your environment, but I'm sticking with rolling back the RDP files, because it's the only thing that is truly working on our end without the possibility of being undone by Microsoft.

      

    ah, didn't see that post about the wrong channel.. That's ridiculous.    But you should still be able to delay the update for up to a year if wanted.   This way your are still on the secure latest RDP just not the latest feature.  I remember while back replacing RDP files and an update down the road caused some strange issues we couldn't track down and had to backtrack.  Sometimes I forget to go back and undo the workarounds. I think it was the RDP minimize window freeze issue in windows 7. 
    25 Mei 2018 15:36
  • @Swithin Chandler, rolling back the RDP files may reintroduce the CredSSP vulnerability. However, this vulnerability is minimal due to the fact that it's a man in the middle attack. If you have someone who is able to get between your network and your terminal server to capture network packets and issue this attack, then you have way more issues than CredSSP. 

    Fixing the usability issue at the moment is way more important than worrying if someone is sitting on the inside of your network or out at the telephone pole at the road capturing packets as they enter your Remote Desktop Gateway. 

     

    There are 2 security updates that resolve CredSSP issue. From what I tested, as long as the Servers have the correct updates, ( I forget which two security updates) the clients don't produce the CredSSP error, regardless if they have the 2 security updates installed. The error shows up when the clients are updated and the server is not. So you can resolve the CredSSP security issue without installing 1803 update. Unless I'm misunderstanding. 

    Also, Not sure if this has been posted,  but for our test group that updated to 1803, We have noticed for users with dual monitors,  the menus that are not visible on primary monitor are actually showing up on the 2nd monitor, but can't interact with it. I know it doesnt help anything, just though I would mention.




    • Diedit oleh rm304 25 Mei 2018 16:32
    25 Mei 2018 15:47
  • @Top Notcher: This is likely the same underlying functions as the Steps Recorder, which also solves the problem when you start recording. 

    Problem with this is that you can't run it for too long, or your workstation resources will likely get depleted.

    25 Mei 2018 16:46
  • @rm304: 

    You are correct, to elaborate with specific info for those who need it and are still stuck in this vicious loop: 

    These are the specific of the setups to make sure all works end to end:

    https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

    And here is the list of the updates which are appropriate for each of the operating systems:

    https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

    You can either install the "Security Only" update, which installs the CredSSP fix, if you install the roll up, then the security one isn't needed, as it'll be superseded by the rollup.

    Those 2 articles were very helpful when we were implementing the fix. Note that if you're running Remote App Server with a Gateway, make sure that the update is installed all the way through (including the connection broker), or the error will still show up.

    Hope this helps.

    25 Mei 2018 16:51
  • Following up on Ron's post: we do have a fix for this issue and it should be incorporated into the Insider build 17677 that was released yesterday. For the (many more) people who do not use Insider builds, we're working through the process to release a patch. I'd like to be able to give you an ETA but unfortunately I don't have one yet.

    Most likely it would work to copy mstsc.exe/mstscax.dll from build 17677 onto a machine running an older build as well (assuming the processor architecture matches, anyway). It's not officially supported but since a lot of you are copying binaries from older versions of Windows already, it's at least worth mentioning.

    • Disarankan sebagai Jawaban oleh Jack Alacka 25 Mei 2018 20:16
    25 Mei 2018 18:22
    Moderator
  • Hello Daniel, thanks for the update. I want to verify that when you say "release a patch" that you are talking about something that is going to automatically go through Windows Update? We have hundreds, if not thousands of customers of ours that are on Windows 10 that use our software through RemoteApp and we do not have access to their machines.

    Telling them to call an IT person to come out and apply a "patch" to all of their computers so they can use OUR software would not go over well. As of right now, we have been telling them to roll their computer's back to before the update or wait for a new windows 10 update to resolve their problem.

    I look forward to hearing back, thanks!

    25 Mei 2018 19:34
  • Yes, I am talking about something delivered through Windows Update. I expect it to work the same way as the fix for the 1709 RemoteApp issue that came out a few days ago.
    25 Mei 2018 22:32
    Moderator
  • GTMERP,

    Just wanted to say thanks for keeping this thread updated as new information becomes available from MS. It's much appreciated.

    27 Mei 2018 7:27
  • Hey Ron,

    we have this weird issue since updating to 1709 , but this only happens with Server 2012 "R1" as session host and not with all applications. As soon as we minimize the RemoteApp Window and then try to maximize it again we get a blackscreen. We never had this issue with earlier Win10 Versions (we rolled back to 1703)



    Can someone from Microsoft please respond to this? Do you plan fixing this issue with 2012 R1? It is obviously a refreshing issue in combination with 2012 R1 and the updated RemoteApp in W10 1709 and later.

    1703 wont be supported for much longer and we can't upgrade our server yet, so we are in a real dilemma and other people still using 2012 R1 are too

    27 Mei 2018 17:54
  • I'm a novice user and haven't the time to read all the above. Wouldn't know what it means anyway. However since upgrade to 1803 my computer is running very slow or hanging.  I have a piece of info - When my computer hangs I checked Task Manager with the following results - Disk 100%, Service Host Superfetch varying from 25 to 40 MB. Haven't any idea what this means but it doesn't seem normal. Hope this helps. Hope MS gets this fixed soon.
    27 Mei 2018 19:55
  • I'm a novice user and haven't the time to read all the above. Wouldn't know what it means anyway. However since upgrade to 1803 my computer is running very slow or hanging.  I have a piece of info - When my computer hangs I checked Task Manager with the following results - Disk 100%, Service Host Superfetch varying from 25 to 40 MB. Haven't any idea what this means but it doesn't seem normal. Hope this helps. Hope MS gets this fixed soon.
    This is specifically an issue with the MSTSC Program, if you are having issues on your machine then this will be a local issue and nothing linked to this thread
    27 Mei 2018 21:40
  • @SysAdmin1900: If the KB4103714 path for the RS3 (1703) is any indication, I would think that the upcoming patch will also have the same fix. 

    Here is what I found:

    Source: https://support.microsoft.com/en-us/help/4103714/windows-10-update-kb4103714 

    @STI Computer Services: No problem. I just wish we have some actual useful news instead of useless updates that really don't get us anywhere. Hopefully soon! 


    27 Mei 2018 23:05
  • By the way, @SysAdmin1900: I just re-read your post, and you are asking for the 1709 patch, which is what KB4103714 is exactly. 

    Here's a direct download for it, have you tried it? 

    https://www.catalog.update.microsoft.com/Search.aspx?q=KB4103714


    27 Mei 2018 23:07
  • Sorry. Shows how much/little I know about this stuff.
    28 Mei 2018 5:52
  • By the way, @SysAdmin1900: I just re-read your post, and you are asking for the 1709 patch, which is what KB4103714 is exactly. 

    Here's a direct download for it, have you tried it? 

    https://www.catalog.update.microsoft.com/Search.aspx?q=KB4103714


    We dont have any 1709 machines right now but I could set up a VM. We are not using two monitors though.

    Also I'm pretty sure someone from microsoft wrote in the other thread, that this fix is already implemented in 1803, and we still have the same bug in 1803

    Edit: I just set up a 1709 VM and installed KB4103714  and it actually fixed our problem :)

    Thank you GTMERP for the tip!! I hope this fix gets implemented in 1803


    28 Mei 2018 9:53
  • You are correct. It is implemented in the Insider build (17677)

    If you have access to that, you can probably grab the files from it, however the actual installable KB is not yet available for GA of 1803. 


    28 Mei 2018 16:38
  • You are correct. It is implemented in the Insider build (17677)

    If you have access to that, you can probably grab the files from it, however the actually installable KB is not yet available for GA of 1803. 

    Maybe they will include it with the June Update :)
    28 Mei 2018 17:00
  • Microsoft, will the patch be available for download? Waiting for this to roll out to all users is going to be rough. I don't relish the idea of telling users "at some point over the next few months this update that fixes your machine will be available to you". 

    Please make this available as a standalone patch. 

    29 Mei 2018 13:14
  • To support this.

    Our only option at the moment is to recommend each user affected is setup to use the Windows Insider program. 

    Please remember the PR disaster you have created for us and yourselves.

    29 Mei 2018 13:28
  • Anxiously waiting for the patch :)

    You guys have been great keeping this thread updated. I'm still bouncing out here 3 to 4 times a day just to see what's new.

    It just saddens me that pre release testing builds get fixes for important issues prior to the general public. If Microsoft feels confident enough that an issue has been fixed to make those statements here on the forums, then get the lead out and push the patch please!


    • Diedit oleh BCS-MAN 29 Mei 2018 13:34
    29 Mei 2018 13:32
  • I could not wait for updates any longer 

    I updated to the latest windows insider build that has the fix for the Z ordering issue.

    i extracted the binaries and edited the a powershell script from knowall.net pointing to my my own host.

    Copy the below and paste into notepad and save as a .ps1

    in my case i saved as mstsc.ps1 then run this command as powershell admin 

    powershell.exe -executionpolicy unrestricted -command .\MSTSC.PS1

    Hope this helps

    -------------------------------------------------

    #Create local folder
    if (Test-Path C:\MSTSC)
    {
        echo "C:\MSTSC" existing folder
    }
    else
    {
        New-Item -ItemType directory -path C:\MSTSC
    }


    #download files

    $url = "https://www.robert.network/wp-content/uploads/2018/MSTSC/mstsc.exe"
    $output = "C:\MSTSC\mstsc.exe"
    Invoke-WebRequest -Uri $url -OutFile $output

    $url = "https://www.robert.network/wp-content/uploads/2018/MSTSC/mstscax.dll"
    $output = "C:\MSTSC\mstscax.dll"
    Invoke-WebRequest -Uri $url -OutFile $output

    #taking ownship of files to change permission
    echo "Taking Ownership of files"
    takeown /f "C:\Windows\System32\mstsc.exe"
    takeown /f "C:\Windows\System32\mstscax.dll"


    #Applying permission changed to rename file.
    echo "Giving permission over files"
    $rule=new-object System.Security.AccessControl.FileSystemAccessRule ("$env:userdomain\$env:username","FullControl","Allow")
    $acl = Get-ACL C:\Windows\System32\mstsc.exe
    $acl.SetAccessRule($rule)
    Set-ACL -Path C:\Windows\System32\mstsc.exe -AclObject $acl


    $rule=new-object System.Security.AccessControl.FileSystemAccessRule ("$env:userdomain\$env:username","FullControl","Allow")
    $acl = Get-ACL C:\Windows\System32\mstscax.dll
    $acl.SetAccessRule($rule)
    Set-ACL -Path C:\Windows\System32\mstscax.dll -AclObject $acl

    #Rename Files
    ren C:\Windows\System32\mstsc.exe mstsc.exe.bak
    ren C:\Windows\System32\mstscax.dll mstscax.dll.bak

    #moving old MSTSC files into location

    copy "C:\MSTSC\mstsc.exe" "C:\Windows\System32\"
    copy "C:\MSTSC\mstscax.dll" "C:\Windows\System32\"

    #Giving Ownership back to file.
    icacls "C:\Windows\System32\mstsc.exe" /setowner "NT Service\TrustedInstaller"
    icacls "C:\Windows\System32\mstscax.dll" /setowner "NT Service\TrustedInstaller"

    ------------------------------------------------------------------------------------------------

    29 Mei 2018 13:35
  • @Oodog, Haha love it when a community comes together!

    So to fix a Microsoft induced problem caused by the implementation of a security fix which included other updates, it takes someone to host the fixed files on their own server and post a power shell script to download those files from an unknown site, which in it's own right should give any Administrator worth their salt pause.

    I'm not dogging you @Oodog and I commend you for offering a fix for a problem that Microsoft has yet to offer. However, it just shows our level of stress and utter disgust that we have gotten to this point due to the lack of urgency at the corporate end.      

     
    • Diedit oleh BCS-MAN 29 Mei 2018 14:11
    29 Mei 2018 13:50
  • Has anyone checked out KB4100403? I just ran another Microsoft update check and it shows as a cumulative Update for Windows 10 version 1803. Could this be what we have been waiting for??? I'll read through it and report back.

    UPDATE: Nevermind Ugh! This was released on May 23rd and doesn't mention any remote app fixes. :( 


    UPDATE TO THE UPDATE: After applying this patch I can confirm that it indeed DOES NOT fix the remote app menu issue.
    • Diedit oleh BCS-MAN 29 Mei 2018 15:14
    29 Mei 2018 13:52
  • How would you deploy this through GPO? 
    29 Mei 2018 14:01
  • So I'm curious if you sign up for the Insider Preview just to get this fix applied, does that mean you're tied to the program and will continue to be on pre release status, or is there a way to opt out of the program and tell Microsoft that you don't want anymore hot steamy piles of update goodness? 
    29 Mei 2018 14:22
  • No, there's a 'Stop Insider Preview Builds' button in the Windows Insider Programme setting.
    29 Mei 2018 14:26