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.
Hi,
Is this link helpful to you?
https://social.microsoft.com/Forums/windows/en-AU/5576733a-0b88-4f2c-a3b2-72232f621448/quotno-workspace-is-associated-with-this-urlquot-error-when-trying-to-connect-to-remoteapp?forum=winserverTS
--please don't forget to Accept as answer if the reply is helpful--
Hi PhoebeLu,
I saw that when searching around but ignored it since I'm not going through any WAPs... but I figured I'd check anyways since you brought it up...
I have no updates installed, I haven't patched these systems. Doing so now. I don't expect it to resolve the issue but will report back.
I updated my Connection broker/gateway server and my hosts and had one of the affected users test. There is no change in behavior. This is impacting ~4-5 out of around 30 apple users out of our total of 120 RDS users. We had no problem with this in Microsoft Remote Desktop version 8.
Some further complications-
My setup uses the Azure AD Application Proxy in passthrough mode (pre-authentication is not supported at all in the Mac Microsoft Remote Desktop App).
Created a record that bipasses the Azure AD Application Proxy, and just punches right into our network. Using this address... the problematic devices connect without issue. This is interesting since MANY users are connecting using this app just fine through the proxy, it's just a random sampling who aren't.
I have no intention of keeping a non-proxied route open into my organization's network, there's got to be a fix for this.
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.
Hi,
Thank you for your reply.
if we install Microsoft Remote Desktop Beta for macOS version 10.4.1(1815),will the same issue happen?
Microsoft Remote Desktop Beta for macOS by Microsoft Remote Desktop
https://install.appcenter.ms/orgs/rdmacios-k2vy/apps/microsoft-remote-desktop-for-mac/distribution_groups/all-users-of-microsoft-remote-desktop-for-mac
--please don't forget to Accept as answer if the reply is helpful--
Hi PhoebeLu,
I found the beta version a few days back and asked a user to test it. The behavior stays the same, they still get that error. The version they are on is newer than the one you listed- it's Version 10.4.1 (1816).
Thanks