RDP connection "Access Denied" after Microsoft Cumulative Security rollup KB4343897

[m200]

After WSUS rolled out the Microsoft cumulative security rollup KB4343897 (August patches), all of our virtual desktops using RDP connection are having problems. Whenever the virtual desktop is "locked" either by choice or due to inactivity the View Agent pops up with an error "access denied" and the desktop session is closed back to the client computer. If you try reconnect you get the same session and error, and then the connection closes to the client computer. Using Blast or PCoIP works fine, and the session is re-established. On our network however Blast and PCoIP are not working optimally (thats another story), and are laggy. Our users therefore prefer RDP. If you have reestablished the session with Blast or PCoIP, and then just disconnects, you can then reconnect with RDP without problems (becuase the desktop is now no longer locked) - but if you are inactive for too long, or lock your desktop, the error emerges and your session crashes.... So, the problem is spesific with RDP connections, and ONLY when the desktop is locked. (We are running Windows 10 desktops. Build 1709. The error happes with both 7.4.0 and 7.5.1 agent) Uninstalling KB43439897 immidiatly solved the problem, so there is no question that the WSUS upgrade, and indeed this exact patch, is the culprit. Problem here turns out that uninstalling this KB is only possible on older desktops that have gotten a few/some of the security-patches individually installed at earlier dates, before MS released the security rollup in the midst of August. For the newest and latest desktops (most of them), they now only get the cumulative rollup, and on these desktops uninstall is not possible. Why I'm not sure, but I've successfully removed the patch on 12 desktops, all of which have been in use for a while. While on all new desktops, uninstall fails. Comparing them on the "add remove programs" the older systems have 12 patches, the last one beeing KB4343897, while the newer systems only have 5 patches, the last one beeing KB4343897 - and it's not uninstallable (it fails with an error). On the older systems however, uninstall works just fine.... But nevertheless, uninstalling this security fix is not a solution, nor just a workaround while waiting for an actual fix.... either by VMware or Microsoft..... and It's kinda inconvenient to the users to in the meantime switch protocols back and forth because of this. Anyone else that are seeing this exact behaviour? Or is able to replicate it? Or having some tips to what I can try to maybe work around this in a better way for all our users while waithing for the support-case.... At the moment I have 12 happy users that have been lucky enough to get the patch uninstalled... and I have several more unhappy users asking me to get this fixed....