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:

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?

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.

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

• Edited by TP []MVP, Moderator Monday, November 12, 2012 2:55 PM
• Proposed as answer by TP []MVP, Moderator Tuesday, November 13, 2012 6:19 AM
• Marked as answer by Clarence ZhangModerator Wednesday, November 14, 2012 2:19 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.

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

• Edited by TP []MVP, Moderator Monday, November 12, 2012 2:55 PM
• Proposed as answer by TP []MVP, Moderator Tuesday, November 13, 2012 6:19 AM
• Marked as answer by Clarence ZhangModerator Wednesday, November 14, 2012 2:19 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.

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.

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).

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?

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.

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.

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

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.

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

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

Thanks again TP, this works!

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

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:

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

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

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>

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.

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

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

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,

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

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

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.

• Edited by Carl M Farrington Friday, May 03, 2013 3:50 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.

• Edited by Carl M Farrington Friday, May 03, 2013 3:50 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. 

But this doesn't fix the web access problem that we are experiencing currently. How are we supposed to get around this?

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???

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.....

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

This is a much simpler workaround:

http://jaredheinrichs.com/rdweb-the-computer-cant-verify-the-identity-of-the-rd-gateway-its-not-safe-to-connect-to-servers-that-cant-be-identified.html

that is exactly what this thread tries to avoid at all costs.

You can install ADCS in a DC. Not a CA and then a ADDS.Just to clarify future readers.

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

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

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

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

• Marked as answer by TP []MVP, Moderator Friday, December 06, 2013 4:17 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

• Marked as answer by TP []MVP, Moderator Friday, December 06, 2013 4:17 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

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

• Edited by TP []MVP, Moderator Wednesday, December 18, 2013 11:30 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
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

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

• Edited by TP []MVP, Moderator Wednesday, December 18, 2013 11:30 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).

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

Ive 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 its trying to authenticate against the servers internal name.  When I browse directly to the internal server from inside the network its presenting the public certificate.  This certificate is issued by a publically trusted authority, so its 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 didnt 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 its going bad.

Im wondering if I missed something.  Ive seen the HA mode suggestions, but feel that is an egregious non-reversible work-around and would rather not go that route until 1. Ive 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 dont have access to high end support resources.

Thanks,

Karim

Hi Karim

I have the same problem. Have you found a solution to this?

-=Grubler=-

There seems to be some strange issue where it doesnt like the FQDN because its not in AD, fix/workaround is below

From server manager open tools > terminal services > RD Gateway manager

Expand "Server name" > policies > resource authorization policies

Double click the default policy > select the network resource tab > select the "Allow users to connect to any network resource" radio button and hit apply.

Hi, I am having the exact issue right now. Were you able to resolve the issue???

Can you give me some info on this... 

Ive 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 its trying to authenticate against the servers internal name.  When I browse directly to the internal server from inside the network its presenting the public certificate.  This certificate is issued by a publically trusted authority, so its 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 didnt 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 its going bad.

Im wondering if I missed something.  Ive seen the HA mode suggestions, but feel that is an egregious non-reversible work-around and would rather not go that route until 1. Ive 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 dont have access to high end support resources.

Thanks,

Karim

Hi I am having the same exact issue your having. I am about to call Microsoft on this and I however if you resolved it. I would appreaciate it if you let me know the solution. 

Thanka

Hi Jgiraldo1988,

Please create a new thread with precise details about your environment (servers, clients, etc.), symptoms of the problem, exact error message(s) you are seeing, what tests you have done, etc.

Thanks.

-TP

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

This does not work for me. Am I missing something? The script runs successfully and says the new RD Web URL is what I want it to be, but in the RDS of Server Manager, it still shows the old address. I can access RDWeb internally and all the apps launch, but externally, the page loads and the apps fail to launch. Thinking it has to be the published URL, but I can't seem to change it.

This does not work for me. Am I missing something? The script runs successfully and says the new RD Web URL is what I want it to be, but in the RDS of Server Manager, it still shows the old address. I can access RDWeb internally and all the apps launch, but externally, the page loads and the apps fail to launch. Thinking it has to be the published URL, but I can't seem to change it.

Mako-Wish,

Please create a new question and provide details of your current configuration, for example, servers and the RDS Role Services installed on each, ports open on the firewall and which server they are forwarded to, FQDNs displayed on the prompt when launching, DNS entries, etc.

The URL for RDWeb shown in Server Manager does not matter, and is unrelated to the published FQDN that the cmdlet changes.

Thanks.

-TP

• Edited by TP []MVP, Moderator Tuesday, April 14, 2015 2:08 PM

This does not work for me. Am I missing something? The script runs successfully and says the new RD Web URL is what I want it to be, but in the RDS of Server Manager, it still shows the old address. I can access RDWeb internally and all the apps launch, but externally, the page loads and the apps fail to launch. Thinking it has to be the published URL, but I can't seem to change it.

Mako-Wish,

Please create a new question and provide details of your current configuration, for example, servers and the RDS Role Services installed on each, ports open on the firewall and which server they are forwarded to, FQDNs displayed on the prompt when launching, DNS entries, etc.

The URL for RDWeb shown in Server Manager does not matter, and is unrelated to the published FQDN that the cmdlet changes.

Thanks.

-TP

• Edited by TP []MVP, Moderator Tuesday, April 14, 2015 2:08 PM

This does not work for me. Am I missing something? The script runs successfully and says the new RD Web URL is what I want it to be, but in the RDS of Server Manager, it still shows the old address. I can access RDWeb internally and all the apps launch, but externally, the page loads and the apps fail to launch. Thinking it has to be the published URL, but I can't seem to change it.

Mako-Wish,

Please create a new question and provide details of your current configuration, for example, servers and the RDS Role Services installed on each, ports open on the firewall and which server they are forwarded to, FQDNs displayed on the prompt when launching, DNS entries, etc.

The URL for RDWeb shown in Server Manager does not matter, and is unrelated to the published FQDN that the cmdlet changes.

Thanks.

-TP

Please point me to the new thread then, because i have dealt with this exact issue with 2 customers now.. There doesnt seem to be a Work around, unless your public and internal domain is the same..??

I"m in the same boat, I'm afraid. 

I've seen a lot of discussions about this in this forum, but I'm not able to get this to work. 

I've got a single server with all of the RD roles installed on it with valid licenses. It's behind a router with a single static IP address assigned to the WAN interface with ports 3391-UDP and 443-TCP forwarded to my internal local static IP on my Windows Server 2012 R2 machine. It is part of local domain, let's call it, "server1.domain.local."

Connections from within my local network to https://server1.domain.local/RDWeb allow a published application to run properly. 

When I look at the Deployment Properties of RD Web Access Server it points to an non-editable entry called, https://server1.domain.local/RDWeb, not my external FQDN

I used the, "Change published FQDN for Server 2012 or 2012 R2 RDS Deployment" https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80 to see if that helps, but it doesn't seem to work. The local value still shows up in the Deployment Properties of RD Web Access Server.

I am likely to be unable to set up a public network interface with the external FQDN on it, namely remote1.domain.com as an example. I need to keep the server behind the firewall and continue using port forwarding with NAT.

When I connect to https://remote1.domain.com/RDWeb I can see the published apps. I've had various failures from this point on. Right now I'm getting, RemoteApp Disconnected" User account not authorized, or computer not authorized, or incompatible method.  

I have a public Cert that works fine. The same cert was used for all 4 required roles. I created a .pfx exported from IIS for this purpose with a third party certificate authority. 

I also tried setting up an mstsc connection with the public external FQDN used as a gateway. This fails, too. 

I used the Add Roles and Features, RDS installation, Quick, Session-based to set this all up. 

I thought maybe my Gateway just wasn't working properly. I uninstalled it, rebooted, and re-installed it. No joy. 

Domain Users can access RDS via mstsc locally. 

I can't figure out where to look next. 

I thought this would be instructive:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/67dfab70-7e10-4e0b-a3c8-63ce776f2355/how-do-i-change-the-url-to-the-remote-web-access-server-in-windows-server-2012?forum=winserverTS

However I'm still getting nowhere. 

If you have any suggestions, please be specific and clear. I expect I'm missing something. For example someone posted this at the previously mentioned page, "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."

Obviously, if I could do that I might not have a problem, but how does one do that in my circumstance? 

Help.

Thanks,

Steven

SOLVED!

I managed to get it to work. Because the MMC kept crashing, I couldn't modify the policies, especially the RD RAP. That policy had to be changed to allow RD access to a Domain Controller computer. I assumed that a single server solution, as the Quick installation of RDS is designed for, would create a policy that would allow RD users to access the server itself, even it is a domain controller. 

I had to get some help to change the policy via Power Shell. 

The actual commands were:

PS RDS:\GatewayServer\RAP\RDG_AllDomainComputers> Set-Item -Path RDS:\GatewayServer\RAP\RDG_AllDomainComputers\ComputerG
roup "Domain Controllers@'my local netBIOS domain name'"

The item above, "my local netBIOS domain name" would need to be replaced with your actual netBIOS domain name. 

I'll bet most folks can modify this policy via the MMC, so this CMDlet won't be needed. 

I would have though that, that would be the default policy. When the wizard discovers it's being run on a domain controller, it obviously should set that policy, or the whole thing fails. I expect this is the main problem most people are having to get this whole thing not work. 

Previously someone posted this: In RD Gateway Manager, properties of RD RAP, Network Resources tab, please make sure you haveAllow users to connect to any network resource selected. That would have a similar effect, if your MMC doesn't crash along the way. 

The first part of the wizard should also say that incoming firewall ports need to be forwarded to port TCP443 and UDP3391 from a router with an external address. That could save most folks a lot of bother.