none
How do I change the URL to the Remote Web Access server in Windows Server 2012?

    Question

  • Hallo!

    I have set up a Remote Dexktop Service using the "Quick" deployment method in Server Manager and everything is working greate internally, but I cannot start an app published in Remote Web Access from outside our network.

    The problem is that it wants to start the using the internal URL, for example, server.domain.local, instead of the external one, for example remote.server.com.

    I therefore want to know how I can change the default URL for the Remote Web Access server and all the Remote Web Apps in Windows Server 2012?

    I have allready looked in Server Manager and I can change some of the deployment settings in server manager, but there is no way to alter the URL of the Remote Web Access server. See below images:

    Edit deployment step 1

    Edit deployment step 2 try to change the url

    Pressing the internal URL only results in opening the internal URL.

    This was very simple to do in Windows Server 2008 R2 using the tsconfig tool, but it does not seam to be any way of solving this in server manager.

    A possible sollution would be to alter the registry someware in HKLM->Software->Microsoft->Windows NT->Terminal Services. But this can easaly lead to problems due to wrong format, etc. and is probably not supported.

    Is there a simpler and supported way?

    Saturday, November 10, 2012 8:44 PM

Answers

  • Hi,

    1. Please configure the RD Gateway FQDN in deployment settings so that it is set to the external address for your server, for example, remote.yourdomain.com.

    2. Please forward TCP port 443 and UDP port 3391 to your server's internal ip address.  Port 3389 should be blocked for external.

    3. Please purchase a UCC/SAN certificate from a trusted public authority such as GoDaddy, GeoTrust, Comodo, Symantec, etc. with at least two names on it: remote.yourdomain.com and rdcb.yourdomain.local  Since you will be using this for all RDS purposes and you have a single server, it is essential that you have both the public name (remote.yourdomain.com) that you will use for your RDG/RDWeb and the internal name of your RD Connection Broker server (rdcb.yourdomain.local) as shown in Server Manager.

    4. Once you have your certificate installed on your server, please export it (and its private key) to a .pfx file, and then set this certificate to be used for all RDS purposes in deployment properties.

    5. Create a public DNS A record for remote.yourdomain.com that points to your public ip address.  When your external users connect they will browse to https://remote.yourdomain.com/rdweb

    6. Please update your Windows 7 PCs that will be connecting to your RDSH server to Remote Desktop Client 8 (6.2.9200) and for your XP PCs that will connect please update them to RD Client 7 (6.1.7600).  For Windows 7 SP1 PCs please install DTLS update before installing the RDP 8 update:

    http://support.microsoft.com/kb/2574819

    http://support.microsoft.com/kb/2592687

    7. After completing the above please test by connecting from an external PC using RD Web Access.  Test using the Private option selected as well as the Public option.

    Once everything is configured properly your users will connect to your RDWeb (remote.yourdomain.com) over tcp port 443, next when they launch a RemoteApp they will connect to your RDG (remote.yourdomain.com) over tcp port 443 and udp port 3391, and finally your RDG will make the connection to RDCB/RDSH (rdcb.yourdomain.local) over tcp 3389 and udp 3389.

    Thanks.

    -TP



    Monday, November 12, 2012 10:35 AM
  • All,

    You may change the published FQDN using this cmdlet:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

    http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

    The above gives you the same ability to change the name as exists in Server 2008 R2 RemoteApp Manager.

    -TP

    Friday, December 06, 2013 4:16 PM

All replies

  • We don't have a built-in way to change it.  You have a few options:

    1. Add an external interface to the RDWeb server and install it into the deployment using its external name instead of the internal name.
    2. Add a separate RDWeb server that uses the external name, so that you have one for internal users and one for external.

    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Monday, November 12, 2012 2:15 AM
  • Hallo!

    Let me see if I understand this correctly:

    • You have removed the functionality to change the URL to RDWeb server that existed in the previous version, i.e. Windows Server 2008 R2 (and probably since Windows Server 2003)?

    This does not seem to be very logical since:

    • Most companies use a domain.LOCAL address internally and therefore the RDWeb server will always get the wrong URL using the default deployment method, for example http://rdweb.domain.local, instead of http://rdweb.domain.com,
    • AND that the RDWeb service is almost never used internally?

    I will, however try your first workaround, but I want to verify that I understand it correctly:

    • By interface, I assume that you mean a network interface, i.e. a network adaptor? How am I then supposed to use that extra Network adaptor? Will that allow me to add the same server to the deployment as if it was a new RDWeb server and will I then be allowed to set the correct server URL? Please provide detailed instructions!

    About your second workaround: we have no need for adding another RDWeb server (i.e. a separate webpage) since it should only be used by users that connect from outside our network.


    Monday, November 12, 2012 9:18 AM
  • Hi,

    1. Please configure the RD Gateway FQDN in deployment settings so that it is set to the external address for your server, for example, remote.yourdomain.com.

    2. Please forward TCP port 443 and UDP port 3391 to your server's internal ip address.  Port 3389 should be blocked for external.

    3. Please purchase a UCC/SAN certificate from a trusted public authority such as GoDaddy, GeoTrust, Comodo, Symantec, etc. with at least two names on it: remote.yourdomain.com and rdcb.yourdomain.local  Since you will be using this for all RDS purposes and you have a single server, it is essential that you have both the public name (remote.yourdomain.com) that you will use for your RDG/RDWeb and the internal name of your RD Connection Broker server (rdcb.yourdomain.local) as shown in Server Manager.

    4. Once you have your certificate installed on your server, please export it (and its private key) to a .pfx file, and then set this certificate to be used for all RDS purposes in deployment properties.

    5. Create a public DNS A record for remote.yourdomain.com that points to your public ip address.  When your external users connect they will browse to https://remote.yourdomain.com/rdweb

    6. Please update your Windows 7 PCs that will be connecting to your RDSH server to Remote Desktop Client 8 (6.2.9200) and for your XP PCs that will connect please update them to RD Client 7 (6.1.7600).  For Windows 7 SP1 PCs please install DTLS update before installing the RDP 8 update:

    http://support.microsoft.com/kb/2574819

    http://support.microsoft.com/kb/2592687

    7. After completing the above please test by connecting from an external PC using RD Web Access.  Test using the Private option selected as well as the Public option.

    Once everything is configured properly your users will connect to your RDWeb (remote.yourdomain.com) over tcp port 443, next when they launch a RemoteApp they will connect to your RDG (remote.yourdomain.com) over tcp port 443 and udp port 3391, and finally your RDG will make the connection to RDCB/RDSH (rdcb.yourdomain.local) over tcp 3389 and udp 3389.

    Thanks.

    -TP



    Monday, November 12, 2012 10:35 AM
  • There was no ability to change the RDweb URL in Windows Server 2008 R2, can you clarify what you are referring to?  You could change the name of host server you were connecting to, but once you installed RDweb on a server you could not change the URL without editing all of the web code yourself.

    You can do some things in DNS to make sure the external name is used instead, or you can use a RD Gateway (as TP is suggesting).

    Another common deployment is to use RDG and RDWeb on the same server, in a DMZ that has an external interface.


    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Monday, November 12, 2012 2:35 PM
  • Just to clarify:

    • The URL I want to change is the one that is in the RDP files that are created when you click a program icon in the RDWeb portal.

    This was, indeed, possible in Windows Server 2008 R2, but I cannot provide screenshots of this since I currently do not have a Windows Server 2008 R2 installed at the moment that I can play with.

    I will try TPs guide in about 3,5 hours when we have scheduled downtime on this server allthough it does a bit odd to add a gateway service to the same server that I want to access. But, I have no problem doing this if that is the intended way to deploy a single RDS server with external access to RDWeb and Remote App.

    It would however be interesting to know how a DNS server could be used in this scenario, could you please clarify dgeddes.

    Monday, November 12, 2012 4:47 PM
  • I think you're talking about this?  If so, that's a not a URL, it's just the name of the Session Host that users will connect to:

    As for other options, if you want users to connect externally without going through a Gateway, you would need to open up 3389 to the internet and make sure the external FQDN resolves via DNS.  That is a really bad idea though....you should use RD Gateway instead. 

    So for example, your RDWeb and RD Gateway are the same server, with an external interface for your public FQDN.  Users connect to the RDweb site from the internet and are routed through the RD Gateway to your session host servers.  That way you don't have to publish your RD Sessions Hosts to the internet and they would only need an internal interface (on your .local domain).


    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Monday, November 12, 2012 11:07 PM
  • Hi!

    I have now followed the guide provided by TP and it is now possible to connect via the RD Gateway from the RDWeb portal to any of the published apps.

    I want to thank TP for taking the time to provide a thourgh guide.

    The only problem I now have is that I cannot connect to my server from an external network using the remote desktop client (mstsc.exe). I assume that this is beacuse the 3389 port is closed and the remote desktop client can (for some reason) not use the gateway. A simple solution would be to open the 3389 port, but that would, I assume, be insecure.

    Have I made an error someware, or is this by design?

    I could publish mstsc.exe as a remote app and specify the servername that I want it to connect to (for example mstsc.exe /v <IP of server>. Is this the way you are supposed to do this?

    Tuesday, November 13, 2012 12:56 AM
  • You just need to configure the RDC client to use your Gateway.  When you connect using RDWeb, these settings are embedded in the RDP file that you download from the RDWeb server.


    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Tuesday, November 13, 2012 2:58 AM
  • dgeddes, this works when connecting to the Remote Desktop server when using its internal servername, for example server.domain.local!

    Is it possible to create an RDP file that containd these settings and store it on RDWeb so that you only need to click the icon to get the correct settings and login to the desktop? I assume that this is possible since the first tab on RDWeb is called "RemoteApp and Desktops". Please provide detaild instructions if this is possible!

    I also want to add that I have tried connecting to the server using the "Connect to a remote PC" option", but this does not work.

    Connect to a remote PC

    The error message I get is "Remote Desktop cannot find the computer server.domain.local, This server might not belong to the network...". Perhaps this option is not supposed to be used for connecting to servers, but only for connecting to client computers? Is it possible to hide this option?

    • Edited by Thomas N_ Tuesday, November 13, 2012 7:41 AM
    Tuesday, November 13, 2012 7:22 AM
  • Hi,

    On your server, please modify the following registry value:

    HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<yourcollection>\RemoteDesktops\<yourcollection>

    ShowInPortal     REG_DWORD     0x00000001

    After making the above change please test by logging on to RDWeb and clicking the icon for your session collection.

    Thanks.

    -TP

    Tuesday, November 13, 2012 7:36 AM
  • Thanks again TP, this works!

    Is there any way to hide the option "Connect to a remote PC"?

    Tuesday, November 13, 2012 10:22 AM
  • That option can be used to connect to any machine that you want.  The error message indicates that the client machine cannot resolve the name "server.domain.local" to an IP address that it can connect to.

    You have several options for configuring that tab on the RDweb site.  You can even remove it entirely. 

    Customization of RD Web Site

    RD Web provides a number of customization options for the RD Web interface, including the ability to control default Gateway server settings and redirection settings. These settings are controlled by editing the web.config file located in %SYSTEMROOT%\Web\RDWeb\Pages.

    Displaying Local Help

    To display local help for users instead of the web-based help, edit the LocalHelp value and change the value from false to true.

        <!-- LocalHelp: Displays local help for users, instead of the web-based help. Value must be "true" or "false" -->

        <add key="LocalHelp" value="false" />

    When this value is changed, a user that clicks on Help in the upper right corner of the RD Web login page will open the local help file instead of web-based help.

    Hiding the Connect to a Remote PC Tab

    The RDWeb page Connect to a Remote PC tab can be hidden from users to prevent connections to any servers through RD Web other than the servers configured in a collection. By default, this setting is set to true and the Remote Desktops tab is displayed. To hide the tab, set the value to false.

        <!-- ShowDesktops: Displays or hides the Remote Desktops tab. Value must be "true" or "false" -->

        <add key="ShowDesktops" value="true" />

    When the value is set to false, a user will not see the Connect to a Remote PC tab when logged on to the RD Web page

    RD Gateway Settings

    If the Connect to a Remote PC tab is enabled, an administrator can configure RD Web to use a Gateway server when connecting to remote computers. To specify a gateway, edit the below value with the name of the RD Gateway server:

    <!-- DefaultTSGateway: Admin can preset this to a given Gateway name, or set to "" for no gateway. -->

        <add key="DefaultTSGateway" value="" />

    The default authentication method for the RD Gateway server can also be configured by editing the following section of the web.config:

            <!-- GatewayCredentialsSource: TS Gateway Authentication Type.

             Admins can preset this.

             0 = User Password

             1 = Smartcard

             4 = "Ask me later"

        -->

        <add key="GatewayCredentialsSource" value="0" />

    Devices and Resources

    By default, only Printers and Clipboard are redirected on connections made using the Connect to a Remote PC tab. If the user clicks the Options << button, the redirection settings for a specific connection can be modified

    To configure each specified redirection option to be enabled or disabled by default, edit the following section in the web.config file:

    <!-- Devices and resources: Preset the Checkbox values to either true or false -->

        <add key="xPrinterRedirection" value="true" />

        <add key="xClipboard" value="true" />

        <add key="xDriveRedirection" value="false" />

        <add key="xPnPRedirection" value="false" />

        <add key="xPortRedirection" value="false" />

    LAN Experience Defaults

    Windows Server 2012 RD Web Access can display a new user selectable option for optimizing the connection for a LAN experience. This option is displayed at the bottom of the RD Web page and can be controlled by the administrator using the following section of the web.config file:

        <!--  Checkbox to opt for optimized LAN experience -->

        <add key="ShowOptimizeExperience" value="false" />

        <add key="OptimizeExperienceState" value="false" />

    This value is set to false by default, but when changed to true, the following checkbox will display at the bottom of the webpage. The LAN experience checkbox can also be set as enabled by default.

    Each setting can also be modified using the IIS Manager user interface:


    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Tuesday, November 13, 2012 2:17 PM
  • Hi TP,

    From what i've read, (here's 2 example sites http://www.digicert.com/internal-names.htm and http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/) you'll no longer be able to add an internal server name into any certificates including SAN certificates.

    I've logged a case with Microsoft to investigate this issue because like Thomas N_ said and dgeddes has displayed, in 2008 R2 you are able to change the session host name to any name, including an external name. This way you can add external dns names to the SAN certificate, setup split DNS, and you won't get the certificate name mismatch box.

    Please correct me if i'm wrong

    Thanks

    Thursday, November 15, 2012 11:44 PM
  • Hi GForce76,

    Yes, UCC certificates will not solve this issue much longer.  I know of several of the major providers that have said they do not offer them with internal names any more for new certs, however, one person said just recently that they were able to purchase one from GoDaddy.  Even if you are able to obtain one it will likely expire in 2015.

    In Server 2012, you may change the published FQDN by enabling High Availability mode for RD Connection Broker.  You do not need to have additional RD Connection Broker servers to enable HA.  You may install SQL Express directly on the broker, enable HA, and enter the external FQDN that you need to use.  It is critical to enter the correct external FQDN because once HA is enabled you may not change the name via supported methods like Server Manager or PowerShell.

    In addition to enabling HA it is possible to change the name via SQL Stored Procedure and then refreshing the deployment settings, however, this method is likely to not be supported.  I will be making instructions available for both methods in the future.

    -TP

    Friday, November 16, 2012 12:43 AM
  • Hallo TP and GForce76!<o:p></o:p>

    I purchased a UCC certificate from GoDaddy and I was able to use an internal server name in the certificate and it solved my problem. But, as you wrote, internal server names will not be allowed anymore in a near future.<o:p></o:p>

    I therefore look forward to TPs instructions. Please post them in this thread.<o:p></o:p>

    A note: I think that this is a quite a lot of manual work for a 1 server deployment and that one will be using a lot of features that is not really needed. Any plans to simplify this, that is, to update the "Quick" deployment task in Server Manager so that all this will be done automatically?<o:p></o:p>

    This would be really helpful especially for Small Businesses that are not very likely to invest in a multi-server deployment for less than 20 concurrent users. <o:p></o:p>

    Would using the Windows Server 2012 Essentials server (as DC) + Windows Server 2012 (as App and RDS server) be a simpler way to do a small
    scale deployment?<o:p></o:p>


    Friday, November 16, 2012 1:05 AM
  • Hi TP and Thomas,

    Thanks for that update TP. I haven't setup broker HA yet and was wondering if there was a setting on the broker for this issues. I thought about it, and thought some more, but i had to deal with SQL and its friday so i shall try your suggestion next week.

    I agree Thomas, what small business can fork out $3000 + just for remote apps. I haven't delved into it why i couldn't install rdweb on a DC (2012) but to me that sucks also. Again, another server. Also, one of the guys i work with said he can't install a root CA on a 2012 DC either.

    What is going on in microsoft land.

    Friday, November 16, 2012 5:02 AM
  • Hi TP,

    I finally got around to testing your suggestion with great success.

    The only problem I had was after I installed SQL on the broker, i couldn't get the database setup to work. I had to install SQL on another server.

    Another issue was that I couldn't use the same external name for the gateway and broker dns names. If i did, when the client logs in and selects the published app, the client would try to connect using port 3389.

    I also came accross an article to change the broker dns name using powershell.
    http://social.technet.microsoft.com/wiki/contents/articles/14843.customizing-the-rdcb-ha-client-access-dns-name-using-powershell-on-windows-server-2012.aspx

    Thanks

    Thursday, December 13, 2012 4:47 AM
  • Hi all,

    Just an update to my last post.

    You can use the same external name for the gateway and broker. You just have to untick the box "bypass gateway for local addresses".

    Thanks

    Thursday, December 13, 2012 11:44 PM
  • Hello Don, I was indeed looking how to change the server name in the connection settings in RemoteApp for Windows 2012

    I hope you can help me because any remoteapp is connecting to server.domain.local instead of ra.domain.com (external URL) and I need to change the internal name in the RemoteApp connection to match the external one so that i don't have to purchase a SAN certificate

    Thank you

    Hani,

    Saturday, February 23, 2013 3:29 PM
  • Hi TP ,

    Its always worthy to find solutions and guides from you. I am struggling on your point # 3

    <<3. Please purchase a UCC/SAN certificate from a trusted public authority such as GoDaddy, GeoTrust, Comodo, Symantec, etc. with at least two names on it: remote.yourdomain.com and rdcb.yourdomain.local  Since you will be using this for all RDS purposes and you have a single server, it is essential that you have both the public name (remote.yourdomain.com) that you will use for your RDG/RDWeb and the internal name of your RD Connection Broker server (rdcb.yourdomain.local) as shown in Server Manager.>>

    We have wild card certificate from DigiCert for *.ourpublicdomain.com . I created remote.yourdomain.com pfx and applied to RDS Web/GW role . But for the rdcb.yourdomain.local , I really do not have any clue that how to create .local / Internal certificate for RDSCB & SSO role . 

    Please guide me in this step where we need certificate for .local /Internal.

    Regards

    tShabbir

    Monday, April 15, 2013 8:42 PM
  • Hi there,

    i got the problem that all my apps were redirected to the local name of the server e.g. <servername>.local

    But only in the .rdp which is executed when clicking in the RDWeb.

    How can i change this? Another problem is that our certificate is not matching the server name when pointing to the local dns name...

    It's in german: I want to change the name of the "Remotecomputer" which is actually pointing to the local name of the server. But i want it to point to the external domainname.tld

    Thanks for you help.

    Cheers

    Friday, April 26, 2013 8:54 AM
  • Come on Microsoft. We need to be able to use a public FQDN. We can configure split-DNS so that it resolves internally. The active directory domain, and the "computer name" will always be "server.domain.local", but we need the RDWeb and published RemoteApp feeds to use the public FQDN.

    Do we really have to install SQL & configure High Availability to achieve this ??

    Certificates for *.company.local is not viable.


    Friday, May 03, 2013 3:46 PM
  • Come on Microsoft. We need to be able to use a public FQDN. We can configure split-DNS so that it resolves internally. The active directory domain, and the "computer name" will always be "server.domain.local", but we need the RDWeb and published RemoteApp feeds to use the public FQDN.

    Do we really have to install SQL & configure High Availability to achieve this ??

    Certificates for *.company.local is not viable.



    No, you do not.  You simply need to use Windows Server 2012 RD Gateway and RDC 8 to make the connection. 

    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Friday, May 10, 2013 4:57 PM
  • But this doesn't fix the web access problem that we are experiencing currently. How are we supposed to get around this?
    Wednesday, May 15, 2013 9:58 AM
  • I have exactly the same problem. I've updated my application server from server 2008 r2 to server 2012. Now I find that I can't create msi. packages to install RemoteApps, ok I create it from a 2008 R2 server. Now I see that can not change url that RDweb use to generate rdp files. ??? Windows Server 2012 is not finished???
    Tuesday, May 28, 2013 11:04 AM
  • TP,  Really looking forward to seeing a post about how to use HA to achieve the goal of using one public FQDN for both the RD Gateway address and the internal server.  This was a piece of cake in 2008 and 2008 R2..  Not sure why Microsoft decided to rip this out.....
    Friday, June 14, 2013 8:24 PM
  • TP,

    So I have about 4 to 5 hours into this now and could never get passed the step of creating the HA database within the RD Connection Broker node of the config.  This is a single RDS server environment and the only purpose is to get the internal FQDN to match the external..  I attempted to install SQL Express 2008 R2 and 2012 locally.  I even tried creating the database in a named instance on the domain controller (Which was already in place), but no luck.

    Some posts I read said that this required the "Standard" sku of SQL as a minimum..  Will it really not work with Express?  Other posts I went over seemed to think the database could not be installed on the same server as RDS.  Not sure about all of that , but in this case it looks like I am getting a new cert for the server name itself, or changing the server name.  Luckily this deployment uses a public domain name for it's internal domain, but that won't always be the case.  Still a bit bewildered at why Microsoft would have removed this..  It was as easy as typing the desired name in with 2008/2008 R2..  Frustrating.

    Looks like our firm has elected to downgrade clients to 2008 R2 with this issue compounded with the different interface of 2012.  Difficult walking users through a Terminal Server experience in the first place without a Windows 8 start menu to navigate..  Lol.

    -Adam

    Monday, June 17, 2013 2:54 PM
  • that is exactly what this thread tries to avoid at all costs.
    Wednesday, June 26, 2013 10:49 PM
  • You can install ADCS in a DC. Not a CA and then a ADDS.Just to clarify future readers.
    Wednesday, June 26, 2013 11:15 PM
  • Hi Hani,

    I've found a work around but if anyone can help, it changes back as soon as a connection is made.

    Open the RDWEB HA database on the SQL server and edit the table “rds.Target”. If you change the Name and FQDN columns to suite the certificate (e.g. RDS.outside.com) it will work. But as I said, it changes back.

    Thanks

    Tuesday, July 23, 2013 4:49 AM
  • Hi all,

    I've worked out how to sort this out. Its similar to my last post but you don't have to change the Name column, just the Fqdn.

    Run this SQL code or create a SQL job for it.

    DECLARE @AllEmpty nvarchar(100)
    DECLARE @RDSH nvarchar(100)

    SET @AllEmpty = (SELECT Name
      FROM [RDWEB].[rds].[Target]
      WHERE Netbios='RDS01')

      IF @AllEmpty IS NOT NULL
      BEGIN
     
    SET @RDSH = (SELECT Name
      FROM [RDWEB].[rds].[Target]
      WHERE Fqdn = 'RDS01.Domain.External')
     
      IF @RDSH IS NULL
      BEGIN
     
    UPDATE [rds].[Target]
       SET Fqdn = 'RDS01.Domain.External'
     WHERE Netbios='RDS02'
    END
    END

    Friday, July 26, 2013 5:44 AM
  • This would suggest that you can no longer use a wildcard certificate?,  is this correct?

    I have been through everything else to get our RDWeb and RDgateway setup on Windows server 2012 but it still will not connect from an external source.  The only thing I have not done is replace the certificate.

    Dean

    Wednesday, October 02, 2013 3:30 PM
  • All,

    You may change the published FQDN using this cmdlet:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

    http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

    The above gives you the same ability to change the name as exists in Server 2008 R2 RemoteApp Manager.

    -TP

    Friday, December 06, 2013 4:16 PM
  • All,

    You may change the published FQDN using this cmdlet:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

    http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

    The above gives you the same ability to change the name as exists in Server 2008 R2 RemoteApp Manager.

    -TP
    Either this script has bugs (Though thanks for the effort), or I am applying it incorrectly. I ran it as the example given - ie Set-RDPublishedName "desktop.*.com". Perhaps I should be using -ClientAccesName or -ConnectionBroker, but it is entirely unclear to me which is causing the issue.

    We ONLY access from outside world, and always will - there is NO situation in which we need internal access. We get through to the RDS web page fine (desktop.*.com), no cert error (We have a 'proper' cert), click on the Desktop Icon to launch desktop, and get the following cert error:

    Clicking 'Yes' allows access.

    On running the script, I get through to the website as before. However, now I get:

    And no access.

    To clarify: I *only* want external, FQDN access. I have no desire to see rds-web.*.internal at any point. This is our first RDS roll-out, so entirely possible that there is configuration issue. Connection Broker, RD Web both on the same server. Any help greatly appreciated.




    • Edited by nphsmith Wednesday, December 18, 2013 10:09 AM
    Wednesday, December 18, 2013 9:55 AM
  • Hi nphsmith,

    In RD Gateway Manager, properties of RD RAP, Network Resources tab, please make sure you have Allow users to connect to any network resource selected.  Later, after you have everything working properly you can set it to a more secure setting.

    Please note that you need a DNS A record for desktop.yourdomain.com on your internal network that points to the internal ip address of your RD Connection Broker server.

    After making the above change please test again and reply back here with your results, whether positive or negative.

    Thanks.

    -TP


    Wednesday, December 18, 2013 11:29 AM
  • Hi nphsmith,

    In RD Gateway Manager, properties of RD RAP, Network Resources tab, please make sure you have Allow users to connect to any network resource selected.  Later, after you have everything working properly you can set it to a more secure setting.

    Please note that you need a DNS A record for desktop.yourdomain.com on your internal network that points to the internal ip address of your RD Connection Broker server.

    After making the above change please test again and reply back here with your results, whether positive or negative.

    Thanks.

    -TP



    Thankyou, that now works! The critical change was "Allow computers to connect to any network resource". Setting it back to the default (domain\domain computers) breaks it again. Can you clarify the security risk and/or recommend what a sensible more secure setting might be?  (I've tried setting to just our session hosts, same error with that).
    Wednesday, December 18, 2013 12:33 PM
  • Hi nphsmith,

    I do not see it [Allow users to connect to any network resource] as a significant security risk for most environments, but whether or not that is true depends on your specific needs/policies/firewall configuration.  What the setting says is essentially that a user that is a member of one of the groups on the User Groups tab may use the RD Gateway to connect to any ip address that is reachable via the RD Gateway.

    For example, depending on your firewall configuration, one of your users could connect from outside of your network and use your RD Gateway to connect to any of your internal servers or workstations (provided they have permission on the target host), or even connect to a server that is located outside of your network, say, on the Internet.

    If the above setting is a problem you could create a RD Gateway managed group and put all of the servers that users will connect to, but that can be tedious if you have a large number and there is not an easy way to edit a group once created.  Another option is to configure Windows Firewall with Advanced Security (wf.msc) so that outgoing TCP and UDP 3389 are only allowed to certain ips or ip ranges, which would accomplish the same goal.  Obviously there are many different ways to deal with it if it is a security concern for you.

    -TP

    Wednesday, December 18, 2013 1:18 PM
  • I’ve followed through this thread in detail.  We still cannot open published remoteapps.  At one point early on, we were able to – that was when we were using a self-signed certificate with only the internal server name.  Now we are trying to take it public and having troubles.

    Starting the app fails when we get a new authentication dialog after clicking Connect on the rdp launcher. For example:


    Notice that the remote computer (green oval) used to have our internal server name but this was fixed with the Set-RDPublishedName cmdlet.

    But this still gets followed by:


    Notice (red ellipse) that it’s trying to authenticate against the server’s internal name.  When I browse directly to the internal server from inside the network it’s presenting the public certificate.  This certificate is issued by a publically trusted authority, so it’s likely failing because of the name mismatch.  I cannot get past this dialog box by any means and so we do not have access.

    The way I read this thread, I would have thought the Set-RDPublishedName cmdlet would have taken care of this, but it didn’t fully.  When I look at Deployment Properties -> RD Web Access, the URL for the web access server is still showing the internal URL.  This is where I think it’s going bad.

    I’m wondering if I missed something.  I’ve seen the HA mode suggestions, but feel that is an egregious non-reversible work-around and would rather not go that route until 1. I’ve exhausted all the options and 2. Am sure that this would resolve our final roadblock.

    Our deployment is Server 2012 Standard R2, and we used the simple deployment option, so everything is on a single server.  The certificate is a single name certificate for the public name and works fine when authenticating against the public name.  Please help. We are a non-profit and don’t have access to high end support resources.

    Thanks,

    Karim

    Thursday, June 26, 2014 9:31 PM