The latest Edge release now warns that XSLT support is being removed, and classic RDS RDWeb pages may eventually stop rendering correctly. The current portal provides features such as drive and device redirection, while the HTML5 web client has different limitations. What approach are others taking: switching to the HTML5 client, delivering .rdp files, using Remote Desktop feed subscriptions, or moving users entirely to a desktop client? MFA and authentication requirements may also affect the available choices.
3 Answers
Instead of relying on the XSLT-based landing page, users can subscribe to the Remote Desktop feed through the Remote Desktop client or the RemoteApp and Desktop Connections settings in Windows. Published RemoteApps and desktops then launch as normal RDP sessions with drive redirection and the other configured redirection options. Group Policy can distribute the feed address, and the HTML5 client can remain available for devices that cannot install a desktop client.
The HTML5 client may not work for environments that require Kerberos-only authentication or depend on MFA products that don’t support the newer web client. In those cases, replacing the classic portal outright could remove an important security control, so check authentication and MFA compatibility before migrating.
That’s our concern too. Our web access portal is publicly reachable and must be protected by Duo MFA, but Duo isn’t supported by the newer HTML5 client, so switching would not currently be viable.
A practical compromise is to publish the HTML5 client but configure resource launches to download an .rdp file. Users who need full device or drive redirection can open that file in the Remote Desktop client, while the browser client remains available as a fallback. The HTML5 client’s upload and download features aren’t equivalent to mapped drives, so I wouldn’t make it the only option.
A feed subscription would be useful, but it doesn’t solve our situation because access to the RD Web Access server is protected by Duo.