RDS – Accessing your RemoteApp – Part V

Hello World,

Today, we will continue our introduction about Windows 2012 R2 RDS solution.  In the previous parts (Part I, Part II, Part III, Part IV), we have seen the basics of RDS technology and Topology. We have seen how to deploy RDS roles (using the Quick deployment approach) and you should be familiar with the new “centralized” management console for administering your RDS deployment (i.e. RDMS).

Today, we will see how you can use the RDS solution to make applications available to your users from a central location.

Let’s do this !


When installing the RDS components using the Quick deploy approach, the wizard will automatically publish some applications.  These applications can be consumed by the user community in 2 different ways: 

  • through a web interface
  • through shortcuts “published” to the user’s computer.


Accessing RemoteApp through the Web Interface

A user can access a web site where these applications will be available.  When installing an RDS infrastructure, the RDWeb component is mandatory and the installation process will install and configure automatically the following web site : HTTPS://<%HostName%>/RDWeb

When the user connects to this web site, the following screen will be displayed.


This is because the server is using a self signed certificate that is not trusted by the computer.  To proceed and have access to the login form, you should click on “Continue to this web site (not recommended)”.  You will then be able to access the Loginn page for the RDWeb server.


The user needs to provide a valid user name and password and click sign in.   Once signed in, the user will be able to see a list of applications which it has been granted access.  Using the Management console, you can decide which applications will be available to the user.


When the user clicks on one icon, if you have performed a standard installation, the user will be prompted with the following warning message.  For the moment ignore this message and click Connect


Note :

You might some additional popups. Simply click ok to go through and access your application. 


After some time, you should see that your application is presented to you.  The first connection can take some time because the user needs to effectively log into the RemoteApp server.  With RemoteApp, as you can see, you have only access to the application and not to the full remote desktop infrastructure.

So, using RemoteApp, you can provide access to virtually any applications without performing installation on each computer. However, as you have seen, the user experience is not quite straight forward when using default configuration of the RDS.

To avoid all these popups and confusing screens, as you can see we will need to configure additional settings in order to improve the user experience.  What we would like to do is the following

  • providing a simplified url to access the RDWeb web site.  instead of using https://netbiosName/RDWeb  we want to use a simpler url that would be easy to remenber  for the users.  For example, you could use the url  https://remoteapp.rds.lab/   or https://WebApp.rds.lab
  • We want to get rid of the warning message when connecting to the web site.  To perform this, we will need to issue a valid certificate.
  • Finally, we want to get rid of the warning popup message when connecting to the RemoteApp via the Web interface.  At configuration level, we will need to trust the publisher in order to not having this annoying popup
  • (optional) – In certain situation, you might want to use the Windows integrated login method instead of the Forms authentication mechanism.  The Windows integrated login can be used when you are using remoteApp within a AD forest/Domain.  If you are planning to publish your RemoteApp server to the external world, the form mechanism seems to be a better option

We will cover these additional configuration steps in the next post.

Accessing RemoteApp through RemoteApp and Desktop Connections.

Aside the web interface, you can decide to publish shortcuts to the RemoteApp applications using the RemoteApp and Desktop Connections applet available in Control Panel.  Using this tool, you can basically publish shortcusts on the start menu of the user.  There is no need for the user to go through the web interface. 

To configure this, you will open your control panel and look for RemoteAPP.  In the RemoteApp And Desktop Connections, on the left side, click on the access Remoteapp and Desktops


In the form, you have to provide one of the following information,  an specify url or the email address of the user (see note below about using email address).


In our scenario, we will be using the url feed server.  Based on the url we have configured for our RemoteApp Web site, the url we will need to use here would be something like https://remoteapp.rds.lab/RDWeb/Feed/webfeed.aspx. Press Next

Read the information and Press Next



You might be prompted for credentials. Provide your credentials and go to the next step


If your credentials are valid, you should see the success connection page. Press Finish


If the RemoteApp and Desktop Connection control Panel Applet, you should see a information pane where you can see how many programs have been published to you and if you are connected or not


If you click on resources link, windows explorer will open and you will see the applications’s shortcuts that have been published to you.


If a user is browsing on its start menu and look for applications, you should see a new section that will be displayed called Work Resources RADC.  These are actually your remoteapp applications shortcuts that have been published to your start menu.  



 Important Note :

We have seen that we can use the feed server url. We have mentioned also that you could use the email Address of the user.  However, note that the email address can be used only if you are running Windows 8.   In order for this to work you need to create a new DNS TXT record which points to the RSS feed path (but not including the webfeed.aspx).  Within your DNS console, select the zone where the records needs to be published.  Right-click on it and select create new TXT Record.    Provide the following information 

After registering the record, you should check that name resolution is working as expected.  Using the command line utility called nslookup, you can ensure that your record has been created succesfully. Open your command prompt, type nslookup. then type set querytype=TXT. Check the returning result and ensure that the name _msradc is resolved as expected.


Automating RemoteApp and Desktop Connections Access through GPO.

Publishing RemoteApp to the start menu might assumes that the user knows the url of the feed server and that the user goes through the RemoteApp and Desktop connections Wizard which might not be optimal in certain environment.  Using Group policies (GPO), you can actually automate the process and have these shortcut published automatically.

Based on the operating system you are using, the operation might be more or less complex.  We go for the easy way. If you have Windows 8/windows 2012 machines on your network, you can use a native group policy that’s available within these operating systems. Let’s assume that you are creating a GPO called called RemoteApp Publishing.  If you edit your newly created GPO, and you navigate under the user configuration nodes>Windows Components>Remote Desktop Services>RemoteApp and Desktop Connection


 Select the only option available and double-click on it.  The following screen should be displayed.  Provide the feed server url and you are good to go.


When the policy would apply through your organization, users will have RemoteApp applications published automatically.


Note :

If you check any of your RDS Server, you will see that this policy does not apply.  It seems to be by design.  So, if you need to check that GPO is working you need to go to a Windows 8 client or any other Windows 2012 R2 server not hosting the RDS role 


If you have Windows 7, you cannot use this policy. If you google a bit, you will see that some people came up with some solutions still based on GPOs.  You can even find a script to Configure RemoteApp and Desktop Connection on Windows 7 Clients.  The difficult part here is to obtain/create your wcx file. We might describe how to perform the automation of the RemoteApp and Desktop Connections if there are enough requests.


Final Notes

As you have seen, granting access to your remoteApp is quite easy.  You have basically two choices.  The user can initiate the action by access the RD Web interface and click on the requested applications.  You can also decide to silently publish the RemoteApp to the user start menu. When the user needs to access the application, there is no need to open the browser, login and search for the application.  The publishing option offers a more familiar way for the users to  access these “virtualized” applications.

That’s it for this post.  In the next post, we will describe how to improve the user experience while access remoteApp through the Web interface. 

Till next time

See ya  





14 thoughts on “RDS – Accessing your RemoteApp – Part V

  1. From the Web Access Portal, is there anyway to load an app directly without going to the Remote Apps and Desktops landing page after logging in?

  2. Hello Isaac,

    Out of the box, i do not think this is possible. I do not know what you are trying to achieve. Why do you need to have the application started just after login into the login page ?
    As a workaround and based on your infrastructure, you could “publish” the application on the desktop. this way the user does not have to go through the web portal and users can start they applications.

    Technically, It might be possible to achieve what you wanna do but this would mean custom coding.

    Hope this help
    Till next time
    See ya

  3. Hey there,
    When promoting an application, (say MS Word), and a user opens Word remotely, is it possible to automatically save their document to their corporate “my documents” folder?

  4. Hello Shane,

    I would say..it depends on your infrastructure….I do not have much time to blog lately…but let’s try to provide some input….

    are you using roaming profiles/Folder Redirection/home Folders ? If yes, you can configure the system to have the user profile / folder redirection to be available during login on the remoteapp server. By default, Save location should be My Documents. If you are using Home directory (shared folder on network), you can use GPOs settings related to Office (you need to obtain the ADMX templates), to define default location where you want to save the documents..

    hope this help
    Till nex time
    see ya

  5. Hello Carsten,

    As far as I know, there is no builtin settings or way to hide the RDP onnection dialog box.. This is part of the remoteApp functionality
    However, maybe there might be a way to create your own utility that would launch the ActiveX and make it not visible to your users…But this would be custom coding

    Hope this help
    Till next time

    See ya

  6. Its like you read my mind! You seem to know so much about this, like you wrote the book in it or something. I think that you could do with a few pics to drive the message home a little bit, but other than that, this is great blog. An excellent read. I will certainly be back. ceegbakgbaebakkc

  7. @Smithe248,

    Thank you for the visit and positive feedback….We have indeed worked a lot with RDS Technologies….

    Till next time
    See ya

  8. Is it possible to connect a client computer to two different Web feed URL through out a script or GPO? In our environment we’ll need to use two different rdweb servers and the clients we’ll need to connect to both.

  9. @Pat,

    Technically, I do not see any problem on what you wanna do. if you have 2 RDWeb Servers -> this means they have different urls and thus different Feed urls….
    Using gpo (or script), you can then assign the proper url to the proper community you want to target…. T

    Hope this help
    Till next time
    See ya

  10. Hi,

    Firstly, thanks for this helpful series of articles.
    I have a slightly different config to implement though and am wondering if you could provide some insight (I haven’t managed to find the answers via google yet!).
    Basically we’re creating an RD farm in a DMZ (as part of a new DMZ AD forest) and we want internal users to receive a RemoteApp (on their start menu) from this farm. We’re implementing a one-way forest trust so that the DMZ forest trusts the internal forest.
    What I’m struggling to understand though is the authentication traffic flow involved (as there’s a couple of firewalls between the internal and DMZ forests as well).
    My current best guess is this:
    internal user clicks on remoteapp on their start menu, this connects to the RD Web Access service in the DMZ RD farm and they need to authenticate to proceed. To do this I think the server running the RD Web Access service would do a kerberos request to the internal forest domain controller (after a referral from the DMZ forest domain controller).
    Following that the RD Web Access service talks to the RD Connection Broker to find the best RD Session Host to serve the RemoteApp from. Then (again a guess) the internal forest user authneticates again to the RD Session Host to actually get to the app and for this authentication to work the RD Session Host again needs to do a Kerberos request to the internal forest DMZ.
    Is that right?
    I understand cross-forest kerberos quite well when it comes to a client connecting to a network resource in a trusting forest (in this case the onus is on the client to obtain a Kerberos service ticket for the network resource) however I believe RD is different in that it’s not a network resource authentication but a remote interactive logon authentication that needs to happen and therefore it would be the RD server itself that the kerberos ticket request originates from. But even if that is correct I’m also not sure in the case of a RemoteApp access whether both the RD Web Access server and the RD Session Host both need to do the kerberos ticket request or is it just one of them (e.g. the Web Access server and this then does kerberos delegation to the RD Session Host).
    Unfortunately I’m not in a position at the moment to be able to test this in a lab environment but need to complete a design that fully documents the authentication flow

  11. @Nick,

    Thank you for your feedback and positive comments. for you question/issues, the best would be probably to setup a test lab with your envisioned configuration and then use a tool like wireshark so you can specifically identify kerberos traffic and you should be able to see which authentication token is generated and from which computer

    Hope this help
    Till next time
    See ya

  12. I needed to thank you for this good read!! I certainly enjoyed every little bit of it. I’ve got you bookmarked to check out new stuff you post cfcbbdgaaeaccdga

  13. @Smithk857,
    Thank you for visiting our blog and for positive feedback…
    Stay tuned as new stuff about RDS is coming….:-)
    Till next time
    See ya

Leave a Reply