We have a 2012 server with RDWeb, RDGateway, and RDCB roles installed:  gw.domain.LOCAL

We then have another 2012 server that is a RDSH: rd1.domain.LOCAL

The gateway server has a wildcard cert installed for *.domain.COM and I have installed RDCB HA and set the HA name to rd.domain.COM which is the same hostname being externally used by clients to connect to RDweb/RDGateway.

So now if I log in from a Windows 8 machine, or from my Surface RT, it is seamless and opens without issue...

But if I log in from a Windows 7 machine, after clicking Connect I get prompted to authenticate again (despite having already authenticated via RDWeb) and then I get a warning popup letting me know that there is a certificate mismatch and the computer name is rd1.domain.LOCAL...  Why is the name of the actual RDSH server getting shown to the client at all, shouldn't that be hidden?

Going to test from an XP machine and a Mac now, but any ideas on why the Win7 box can't seamlessly connect would be great...

Thanks!

Wes

• Edited by pesospesos Monday, July 01, 2013 2:56 AM

I followed the steps here to assign my wildcard cert to the RDSH server: http://blog.skadefro.dk/2012/08/windows-server-2012-server-8-remote.html

Now win7 clients (although still getting prompted to auth a 2nd time) can get in without the cert squawk... but win8 clients get the 0x607 error again.  Ugh.  Can't win.

What is the name in the certificate you deployed for Single Sign On?  What about for Publishing?

If you're going to use Windows 7, you should have the RDP 8 update installed and enabled.  For non-Windows clients, I do not know why they would not work, you would need to follow-up with the ISV. 

All certs are the same - our wildcard which is rd.domain.com

should the cert be different?

Maybe I am misunderstanding SSO.  I don't think SSO matters too much for us since our users use this for remote access from home, so this will rarely if ever be domain-joined machines.  However, I do expect that once I authenticate to the RDWEB site, that my credentials don't have to be entered again.

Getting win7 users to load the update is fine, but what about vista/xp users?

There is no RDP 8 update for Windows Vista or XP.  I can't say if there ever will be one (I don't make those decisions).  If I had to guess, I would say it is unlikely. 

The following is a post that talks more about how SSO changed in 2012 and how to get it working in each scenario.

http://blogs.msdn.com/b/rds/archive/2012/06/25/remote-desktop-web-access-single-sign-on-now-easier-to-enable-in-windows-server-2012.aspx

Thanks Don - having RDP 8 fancy features for xp/vista clients is not a big deal and it's understandable that new performance features etc. wouldn't be backported to those very old OSes.

What we do need (especially for Vista, which is still going to be around for quite some time) is a way for users to seamlessly connect in without getting all kinds of security warnings etc.  This should be doable with a public cert, just like it is with the Citrix solution.

Maybe I'm misunderstanding, so let me ask clearly:

Is it possible, given an internal domain.local AD domain, to set up a rdcb/rdweb/rdgateway configuration with multiple RDSH servers and have RDP 6/7/8 clients be able to connect to it via RDWEB authentication and click on the Collection name and be brought into the remote desktop environment without any extra popups for certificate mismatches or re-authentication?

If so, are there clear instructions on how to do so available, or is Microsoft's solution really aimed only towards domain-joined workstations?

Thanks!

Wes

The blog post goes into that....if you're using clients that don't support RDP 8 you need to use the old method of Web Single Sign On.

For the new web SSO to work, the RD Connection Broker server and the RD Session Host servers in the deployment must run Windows Server 2012, and all virtual desktops must run Windows 8. The accessing clients must support RDP 8.0. In mixed environments, youll have to configure web SSO the old way. As before, web SSO with smart cards is not supported.

Thank you Don.  I took a brief look at "the old way" article and it is of course for 2008 r2...  We can use the same configuration on 2012 to provide web SSO for XP/Vista/W7/W8 clients, even though our RDSH and RDweb/RDGateway servers are all 2012?

• Edited by pesospesos Sunday, December 23, 2012 7:56 PM

Hi Don, I've tried to follow the article but it's written for 2008 r2 and the groups and management tools don't line up with 2012.  Is there any guidance on setting up 2012 server "the old way" so that we can create a consistent SSO experience for non-domain joined clients running xp/vista/7/8 (rdc 7/8)?

Thanks!

Hi,

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.

Regards,

Clarence

TechNet Subscriber Support

If you are TechNet Subscription user and have any feedback on our support quality, please send your feedbackhere.

HI,

Please take a look at following articles.

http://technet.microsoft.com/en-us/library/cc732329.aspx

http://technet.microsoft.com/en-us/magazine/ff458357.aspx

Thanks you Clarence - looking forward to it.

Jason, not sure if your post was intended for me, but I already have a certificate.

Have you considered setting up your own Certificate Server?

Yes, we have an enterprise CA.  That works great for securing internal resources, however it doesn't really help us in this scenario, which is remote access for personal computers that are not domain-joined or under our administrative control...

If the clients connecting can't use Windows 7 and RDP 8, you might consider giving them a certificate that they can then import into their trusted root so that they trust the certificates coming from your internal CA. 

If that is not an option, you will have to change the server names to match the external domain so that users can use your public certificate.

So I would change the servernames of the RDSH servers to match *.externaldomain.com ?  How do I do that and still have them be domain members of internaldomain.local ?

Trying to have these users go through importing a cert would be an exercise in futility :-)

Thanks Don,

Wes

This is one of the problems with using a .local domain on the internet.  I realize that several people do it and that it worked in 2008 R2, but with Server 2012 it's not going to be easy due to changes in the RDS architecture.  If you must continue to use .local, I would suggest you continue to use 2008 R2 Session Host servers until such time as you can migrate to a public domain name. 

For years Microsoft encouraged the use of .local

I would be happy to engineer a change to an external domain name, but the process is extremely complicated with a lot of room for issues with exchange etc.

To be clear, are you saying that .local will be an issue even in a pure 2012/win8 environment?

thanks Don.

No it's not an issue in Windows Server 2012/Windows 8 environment because the RDP 8 client understands how to deal with this configuration.  The issue is with older clients that don't understand how to connect to the collection name instead of to a farm name/hostname.  These older clients will still be able to connect but they can't do SSO if the host is Windows Server 2012. 

Windows Server 2008 R2 and Windows 7 will be supported for many years to come, it is Windows XP that will be the issue.  Support for that is ending soon. 

Gotcha.  OK I am going to run some tests on Win7 with RDP 8 client.  I guess Vista users are out of luck?  Well I guess Vista users are in the minority anyway ;-)

Hi,

I experienced the same issues before i applied the RDP 8.0 hotfixes to the Windows 7 SP1 clients.

Please see the forum http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/f089964d-758f-4982-889b-fc536ddb3c05.

• Download and install KB2574819 and restart the windows 7 client.
• Download and install KB2592687 and restart the Windows 7 client.
• Reset the internet explorer settings to the default configuration by navigating to advanced internet options settings.
• Load the Remote Desktop website from internet explorer using a version 9 browser.
• You should then be prompted with a popup stating the webpage wants to run the following add-on: Microsoft Remote Desktop Services Web Access Con.. from Microsoft Corporation.
• Allow this.
• You can check whether the add-on is enabled by navigating to manage add-ons within the options menu. Look for the MsRdpClientShell Class ActiveX Control version 6.2.9200.16398.

Best Regards,

Ryan

• Proposed as answer by Jason Mei Tuesday, January 08, 2013 3:08 AM
• Marked as answer by Clarence ZhangModerator Wednesday, January 16, 2013 9:50 AM
• Unmarked as answer by pesospesos Sunday, June 23, 2013 6:54 AM

Hi,

Any update? please drop me an update on this issue. lood forward to hearing from you.

We have the same issue. Any updates?

Finally coming up for air after a number of other projects and need to revisit this so we can replace our Citrix farm soon.

The earlier response regarding securing .local domain names on the internet does not apply here.  Just like Citrix Secure Gateway, the connection looks like this:

client machine --> gateway server --> remote desktop session hosts

In the Citrix world, a certificate only has to secure the connection between the client machine and the gateway.  This makes sense as part of the point of the gateway is to hide the internal resources from the outside world!  For some strange reason, Microsoft seems to have decided that it's a good thing to expose the internal AD FQDN of the gateway server to the outside world.  For the life of my I cannot understand this decision.  It makes zero sense and only complicates things.

At this point I have yet to perform the steps I did last time to set up HA for the RDCB role so that I can assign a .com name to it.  Will do that again shortly and revisit the topic, although I am not hopeful that we are going to get anywhere with this as it appears Microsoft has engineered this flaw into the design.

Hi,

The internal AD FQDNs are only exposed to users who have valid credentials and are logged in. 

Have you tried creating a SAN Certificate, or have you considered setting up a split brain DNS. The only downside with a split brain DNS is double handling records.

Best Regards,

Hi ryan, there is still no reason to expose internal names, even to authed users. This type of access is often used for external partners and parties. No benefit to staff either. Regarding your suggestion as you know you can no longer purchase certs with .local in them that are valid beyond 2015 so not really a long term fix unfortunately...

Hi,

The only two address's shown are the remote gateway/web address external FQDN and the internal standalone RD connection broker or HA address.

The only internal FQDN exposed would be the Remote connection broker, if you have a HA configuration then the Farm Name would be the only FQDN exposed. This should not be a concern but i do agree that Microsoft should consider hiding FQDNs etc, and create a option for admins to view such details for troubleshooting.  I am Interested to know whats changed with Server 2012 R2.

Best Regards,

Me too.

However, I do not think you are 100% right when it comes to what is and isn't exposed...  My experience was that unless you had RDP 8.0 the internal name would still cause multiple auth prompts and cert squawks even after changing the RDCB to an external cert-matched name via the HA workaround...

HI,

Have you ran the RDP 8 and DTLS Update. I found that if you reset the client internet explorer after the updates, you would be prompted with the option to install the RDP active x control. 

When connecting to a Session server or a VDI pool you should see the following:

The only two FQDNs shown are the Remote computer and the Gateway server. 

Certificate miss matches are common with Session servers as the certificates are forgotten about. I assume this has been done from reading the previous posts.

This is because the configuration data for RDSH is stored in the WMI, Win32_TSGeneralSetting class in WMI in the rootcimv2TerminalServices namespace. 

Is it possible to provide a screen shot of the errors you are seeing ?

The only time i have seen a internal FQDN shown is when a certificate is not trusted or if there is a miss match, which causes the server in question to present the following:

Best Regards,

• Edited by Ryan Mangan Sunday, June 23, 2013 9:25 PM Sentence correction

Hi Ryan, it says right in my post above "unless you have RDP 8" - so I am referring to machines that don't (or can't in the case of Vista for example) have RDP 8...  This includes the ancient RDP for Mac client which doesn't work with RDGateway at all!  The iTap client that you have to pay for on Mac connects, but gets the same squawks.

Apologies, I was going off the first post.

You can override the "squawks" in ITAP.  

Best Regards,

Thanks Ryan.  Hopefully it will be less of an issue as time goes by, but as you can imagine it's the folks with XP and Vista that are the most challenged and likely to be stymied by little things like this, especially after years of relatively smooth (but expensive) sailing with Xenapp...

Hi Ryan and Don,

I have rebuilt my servers:

gw.domain.local (rdweb, rdcb, rdgateway)

rdsh1.domain.local (rdsh)

I have assigned my certificate *.domain.com to the web, gateway, and both rdcb roles under Edit Deployment.  When I try to connect via rdweb from my Surface RT, I get a squawk when the connection initiates, mentioning gw.domain.local, and then I get another squawk after I allow the connection which is the typical remote desktop connection squawk, referencing a mismatch between gw.domain.local and *.domain.com

Shouldn't Surface RT have the RDP 8 components, and not squawk?

I believe I got around this last time by configuring HA on the connection broker so that I could alter the connection name to be rd.domain.com and avoid using the .local name altogether from the client perspective.

Unfortunately adding in a SQL server simply for this naming change creates another single point of failure, not to mention wasting server resources.  I figured the simplest route was to install SQL on the same server as RDCB, but no matter what I do I cannot get the HA configuration to accept the local server's SQL instance.

Is it impossible to do so?

Thanks,

Wes

Anyone know if it's possible to get HA configured on the RDCB using a SQL instance on the RDCB server itself?  That would seem to be the simplest single server solution to reducing the number of squawks here.  Really don't understand how it is that Microsoft wasn't able to do with 2012 what Citrix has been doing since the 90s with secure gateway - frustrating.

Hi Wes,

You may change the published FQDN (even without HA) using this cmdlet:

Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

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

Please note that you need to run this in an admin powershell prompt and if you are not running it on the broker you need to specify the -ConnectionBroker parameter.  I recommend running it directly on the broker.

Thanks.

-TP

• Proposed as answer by TP []MVP, Moderator Thursday, December 12, 2013 7:59 PM
• Marked as answer by TP []MVP, Moderator Thursday, December 19, 2013 9:29 PM

It's an old thread but I would like to add a solution.

I recently deployed an RDS 2012 R2 environment and was struggling with these certificate warnings as well. Then I realized that I had these same problems with RDS 2008 R2.

The solution is to open the RD Gateway management console, go to the policies, right click on Resource Authorization Policies (left pane) and select Manage Local Computer Groups.

Create a group, give it a name and then add the external FQDN of your server.

Now open the properties of your RD RAP, go to the Network Resource tab and the select 'Select an existing RD Gateway-Managed computer group'. Select the group you just created and your done.

Grtz

Filip

I know this is a very old post but the answer here at the bottom (Filip) helped me out.  I used the solution posted at the top but once I changed it to my External FQDN, the session was unable to find the remote computer".  That solution in combination with Filips solved my problem.

Thanks!

Thank you to everyone who contributed to this thread.  I know it's an old tread but the problem .. or lack of clear instructions .. is still around.  This thread helped in understanding where all the bodies are buried.  I'm going to try the many suggestions here and ..hopefully.. no more certificate squawks/popups.

Thanks again!