RD Web Access session host URL (Server 2012) RRS feed

  • Question

  • Ok, ive been racking my brain over this for the last 2 days. I have finished setting up RD Web Access on a Server 2012 which is to replace our Server 2008 R2 box. 
    Everything has been installed and configured correctly, everything works except I get an annoying certificate name mismatch upon connecting. Now this does not affect users from connecting in anyway as they can just click on "yes" and carry on as if nothing has happened

    Everything is currently being hosted on the one server with internal FQDN and external FQDN I have an SSL certificate from GoDaddy registered to the external name

    Connecting to the website all works fine. The Certificate is showing as trusted and authentication happens with username and password. The user is able to log in and is given the list of web apps. Clicking on any of the applications proceeds with the following (which is all as normal):

    As you can see above the gateway is fine, however it connects to the internal server name and the user is presented with:

    Now ive gone up and down the net and Im 99% sure that ive got everything setup correctly

    Its important to note that I did not have this issue on our 2008 R2 server as the url for the connection is located in the remote app deployment settings. 

    So does anyone have any ideas as to how I can overcome this issue? 

    Id like to note that im preferring not to use an SSL with an internal SAN (due to security and the fact that this is being phased out over the next year or 2), however if this is the only way forward I may have to do this as a last resort (or just tell the users to click on yes).

    Thursday, February 7, 2013 11:44 AM


All replies

  • I too am running into the same issue.  In 2008 R2 you could specify on the RDSH, using RemoteApp Manager, the server name to be used for the connection settings.  This allowed you to specify instead of which was required for split DNS configuration and to eliminate the certificate errors.  Any guidance on using a third party cert and split DNS and how to change the connection settings for the RDSH would be appreciated.
    • Proposed as answer by tshabbir Tuesday, February 12, 2013 11:10 PM
    • Unproposed as answer by tshabbir Tuesday, February 12, 2013 11:10 PM
    Saturday, February 9, 2013 3:55 PM
  • We solved this by enabling HA on the Connection broker(even if you only want to use one server as connectionbroker you can still enable HA) then you can choose a FQDN of your choice(

    Hope this helps.



    Wednesday, February 20, 2013 2:18 PM
  • So you are local but entering the external name? You go to but the Gateway see you're local and let's you bypass the gateway and sends you to and there you have a mismatch.

    - maybe turn off "bypass gateway for local addresses

    - or create a local dns zone with a record to the same server

    - or just enter the local web access server name when inside the network

    Bart Scheltinga |

    Friday, March 15, 2013 12:58 PM
  • Did you solve your problem already? I'm running into the same.

    Please let me/us know.

    Thursday, March 28, 2013 10:45 PM
  • Fredrik's solution worked for us.  Even though we're only using one connection broker, setting up HA allowed us to make the necessary change.  I find this to be completely ridiculous though in that you need a full SQL server to enable HA just to make this change......
    Tuesday, April 16, 2013 8:58 PM
  • hey scott!

    do you know a guide to setting up HA?

    Monday, February 17, 2014 4:32 PM
  • All,

    For future reference you may change the FQDN without enabling HA on the broker using the cmdlet below:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment


    Monday, February 17, 2014 7:31 PM

    Im looking for this field... where is it in 2012?

    Monday, February 17, 2014 9:43 PM
  • Hi sam.xyx,

    The equivalent field is not available in the user interface in Server 2012 RDS non-HA configuration.  Please use the cmdlet I referenced above to change the published name.  The cmdlet works for both non-HA and HA configurations.



    Monday, February 17, 2014 10:02 PM
  • thanks TP I already used it! It works!!

    but what does it exactly do the cmdlet? I mean it worked it... but I dont understand how it works...

     thanks again!

    Monday, February 17, 2014 10:33 PM
  • The link you provided is not for 2012 R2 ? the command Set-RDPublishedName is not recongnized by my 2012 R2 server, do you know if the command has been changed ?



    Friday, March 28, 2014 3:08 PM
  • Hi Lars,

    Yes, Set-RDPublishedName works with Server 2012 R2.

    Did you download it to your connection broker server?

    What happens if you right-click on it and choose Run with PowerShell?

    An alternative is to run it from a PowerShell prompt.  First you would change to the directory that you downloaded the cmdlet to and then enter the following:

    .\Set-RDPublishedName ""

    For the above to work from a powershell prompt you will need to change the execution policy to something less restrictive.  To do this you would open a administrator powershell prompt by right-clicking on the powershell icon in the taskbar and choosing Run as Administrator, then running Set-ExecutionPolicy, something like this:

    Set-ExecutionPolicy Unrestricted


    Saturday, March 29, 2014 1:28 PM
  • What is HA ???

    Plus tu pédales moins vite moins t'avance plus vite

    Friday, April 11, 2014 8:26 PM
  • Hi Moule-a-Gaufre,

    HA = High Availability


    Friday, April 11, 2014 8:33 PM
  • Actually, it does not work. Or works not in all the cases. At least it did not work for me. Im accessing single RDP server/gateway (2012 R2) from Internet and not looking forward to reinstalling the system with SQL and faked HA to resolve this (really silly) issue with incompatible local name. So hoped the cmdlet would work. But no.

    That is the script did work in a sense it completed successfully and changed the name to which the user connects from the gateway - when clicking on published app the pop-up tells its going to connect to server (instead of myserver.localname.local). However, after acknowledging that I want to proceed instead of connecting to the Host service and running an app it tells it can not connect to the server. Looking further I can see that under Deployment properties the WebAccess still has the url of myserver.localname.local.

    Result - no more certificate error (peachy) but now I can't even connect to the server to run an app.

    (Using just regular RDP pointing to gateway and then to the old WebAccess name myserver.localname.local still works fine, though with cert error, of course).

    Don't get it why it should be that difficult to get things right. Don't see anything wrong from my side. So looks like should revert back to the old name and just tell users to live with cert error (and complain to Microsoft if they don't like it or concerned about security).

    Tuesday, September 9, 2014 12:44 AM
  • Hi vadim2,

    It is normal and expected for the url that shows for RD Web Access in Deployment Properties to stay the same.  The url that shows there does not matter.

    Do you have a DNS A record on your internal network for the published FQDN that points to your RD Connection Broker?

    In RD Gateway Manager, properties of RD RAP, Network Resource tab, do you have Allow users to connect to any network resource selected?

    Please start a new thread and post your precise error message and details about your configuration and we will assist you.



    Tuesday, September 9, 2014 1:40 AM