Otdfbt

I'm trying to setup a lab with a VM hosting all the roles for Windows 2016 Server Remote Desktop Services (CB, SH, WA) to publish few apps to be delivered to Windows 10 Professional Clients.

All machines are joined to a domain. There is an Active Directory Certification Autority installed in the domain who issued trusted certificates for all the roles of the RDS server. The certificate issued has proper Subject Name and Subject Alternate Names.

The _msradc DNS records (TXT type) point to the web feed of the published apps: https://rds.lan....biz/rdweb/feed

A Group Policy Object provide the address of the web feed to the clients:
https://rds.lan....biz/RDWeb/feed/webfeed.aspx

Indeed I checked in the registry o the client machine and under HKCUSoftwarePoliciesMicrosoftWorkspaces there is the proper value "DefaultConnectionURL". The key HKCUSoftwareMicrosoftWorkspacesFeeds is empty.

But in the Start Menu there is no RemoteApp.

If I go through the Control Panel, Manually Login to RemoteApp & Desktop, and I add input something@lan....biz I'm asked for credentials.

This is a bit surprising because:

1. SSO is not effective at this level?


2. how the RemoteApp can be delivered to my Start Menu automagically if the the list of those published RemoteApp (the web feed) is not accessible without prior authentication?

Because the list of RemoteApp is customized per-user it is logical that authentication is required to get this list. So I suspect there is some setting/policy to be applied so that credentials of currently logged on users are passed automatically to IIS and RDS. I hope that solving this solve also the problem of missing apps in the Start Menu.

I think I got a result. To summarize:

• Windows 10 Pro v1709 seems mandatory for RemoteApp publishing through WebFeed works properly; it's very disappointing that an update is not available for previous versions of Windows 10 considering the fact WebFeed publishing is the official way of publishing RemoteApp;




• in my case the update to v1709 wasn't enough; but at least some error message appeared at the event log; after reinstalling the RDWA role, things gone better;




• despite what written above, the membership of RDWA server to Local Intranet Zone of Internet Explorer seems not necessary for SSO;




• but it's mandatory to add "TERMSRV/*.lan.mydomain.com" to SPN list allowed for default credential passing through CredSSP;




• it's also advisable to add the thumbprint of the certificate used to sign .rdp files to the proper policy.