This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 2%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESB%3C/text%3E%3C/svg%3E)
I have recently setup a RDS implementation on Server 2019, an upgrade over my old Server 2012 R2 RDS setup, it works perfectly for windows systems using the Web Access Portal (the IIS web page).
Mac users though have to use the Microsoft Remote Desktop App. This used to work fine in the Server 2012 R2 RDS environment with this behavior-
Remote feed setup for Microsoft Remote Desktop 8 - https://remote.domainhere.org/rdweb/feed/webfeed.aspx
Remote feed setup for Microsoft Remote Desktop 10 - https://remote.domainhere.org
Now on 2019 Microsoft Remote Desktop 8 will not connect at all, and some users get in fine with 10 using the address mentioned (https://remote.domainhere.org)... but a bunch of users when entering this string get this error: no workspace is associated with this url
If I configure a gateway pointing to our gateway address and a PC behind the gateway they can connect using the "PC" tab just fine, and if they go through Chrome to the Web Access Portal and download an RDP file for a connection to any Session Host those RDP files can be loaded into the Microsoft Remote Desktop app without issue...
I've had users uninstall the app, delete all the library settings for it, restart, reinstall the app and still no behavior change occurs.
Some possibly relevant information: This seems to be users who first loaded RDP files from Chrome before trying to configure the connection string for the Workspace (But I haven't confirmed that this is the case for all of these users)
If I edit the saved connection information loaded from one of these Chrome downloaded RDP files, either in the RDP file or in the Microsoft Remote Desktop app the app ignores the changes and connects to whatever the RDP file originally specified (really weird, it's like it's saving this info somewhere the user can't see and manual edits are not taking effect.
I've tried disabling the firewall in MacOS for these users (but they were all able to connect to the old environment fine and can connect directly to systems as described above so this doesn't sound like a firewall issue to me)
The RDS Environment is configured to use the Azure AD Application Proxy (in passthrough mode, since pre-auth isn't compatible with the Microsoft Remote Desktop App).
Hi，
How are things going now?
Hi PheobeLu,
After updating to the most recent updates available (Using "check online for updates" to bypass our SCCM based updates deployments to make sure I didn't miss anything) KB4534309 and KB4541509 were not present.
Updating the servers did not resolve the issue, but interestingly if I bypass the Azure AD Application Proxy (using a public DNS record that points directly to one of my companies' public IP's and routes directly to the connection broker) the feed can be found without issue.
This seems to be a problem between the Microsoft Remote Desktop App for apple devices and the Azure AD Application Proxy. As mentioned many of our users are still able to connect just fine with the address that goes through the Azure App Proxy, but about 1/4th of them cannot.
Do you have any suggestions for additional testing or maybe a way I can submit this as a bug? (Or is this forum where bugs go?)
Hi,
Thank you for your feedback.And for your issue:
1.Did you inplace upgrade all rds related servers(w2012r2) to server 2019 ?or you built a new w2019 RDS environment then migrate from original w2012r2 to it?
2.but a bunch of users when entering this string get this error: no workspace is associated with this url.
Did you configure "specify default connection URL"policy for your new w2019 RDSession host server ?
The default connection URL must be configured in the form of http://contoso.com/rdweb/Feed/webfeed.aspx.
3.What's your rds architecture of your new w2019?
4.Can issue Mac users ping and nslookup the FQDN of webfeed url on their Mac computer?
How to Ping on a Mac:
https://www.macworld.co.uk/how-to/mac/ping-test-mac-3524076/
Hi PhoebeLu,
The only really non-standard stuff is-1. The Azure AD Application proxy setup, and 2. Split domains required modifying the RDS published name, since our internal domain does not match our external public address- https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
.4. Test user still can't connect using the address that goes through the Azure AD Application Proxy (remote.addresshere.org) but still can without issue via the direct route (test.addresshere.org). I had them ping the address and both the main address and my direct route into the network time out, but they also both timeout from my machine (external from my network). Name resolution works fine though for our Azure AD Application Proxy address (cwap-proxy-nam1......cloudapp.net I'm anonymizing that slightly, but I'm pretty sure it's a generic address).
Thanks for your continued help on this!
It also occurs to me that the "specify default connection URL" setting doesn't really apply here since these users have not yet entered their account information (username and password prompt appears AFTER it finds the feed). So no group policy that impacts a user account will have an application at this point.
Hi,
How are things going now on your end?Is there anything I can help you?
Hi PhoebeLu,
Please see my responses to your last list of suggestions. Currently I'm still having this issue and have identified more users experiencing it.
Thanks.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(176, 95%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJD%3C/text%3E%3C/svg%3E)
I added an answer that may help you. I was facing the same exact issue and that resolved it.
So I'm going to assume this is just an unresolved bug. These new Q&A Forums really are dead. Thanks for trying PhoebeLu.
Instead of them using their email addresses, have them use this link instead: https://rdweb.wvd.microsoft.com
I was facing a similar issue and it is now resolved with that. It is coming from this article: connect-macos-2019