Server 2012 RDS Certificate Mismatch through RDWeb

I have a 2012 RDS environment with 4 servers.
Server1: RDWeb, Gateway, Broker
Server2/3/4: Session hosts
I have everything configured properly, and a godaddy SSL cert installed for all roles in the RDS deployment properties.
I am having a certificate Name Mismatch when connecting to RDS desktop through RDWeb. The external web url is and the internal domain is domain.corp. I have used the script created by TP here:
to change the published name but still having the cert prompts pop up. I also tried running this script:
on the 3 session hosts and gateway server, but I am still getting the certificate prompt shown in screenshot.

This prompt comes up after I log in to RDWeb and click on the RDP icon. I can click yes and the session is opened. I would like to get rid of these prompts. Please note, I do not get the prompts when using RDP client, only through RDweb.
My settings in rdp client are to use the gateway server of and computer name of rds. I have round robin for rds pointing to the three session host servers.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
Round robin isn't how 2012 works and breaks the functionality of RDCB. That's why you are getting certificate errors as well.
CCtechAuthor Commented:
I have used round robin in several 2012 RDS deployments. Some thin clients require RDP, and cannot utilize RDWeb. Round Robin DNS is the only way around this that I have found.
I read others having this same issue an followed their steps. Basically, to resolve this the solution (workaround) was:

- remove certs from personal store on session hosts
- remove session host roles
- start RDS deployment over, adding session hosts and roles
- roles are re installed
- create collection again with same name
- all is working properly now, users are not getting certificate mismatch prompts through RDWeb or RDP client
Cliff GaliherCommented:
I have no interest in arguing with you. I'll let my credentials with Microsoft and my stats hear speak for themselves. Yes RDS will technically connect with round robin, but you are breaking the topology and it isn't working correctly. If you insist in following that path, my advice is moot and i need not reply further.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

CCtechAuthor Commented:
Cliff, I'm sorry if you think my reasoning of using round robin was an argument? Very strange, but I would love to find a way around this, I just haven't been able to find any working solution yet.
Cliff GaliherCommented:
It wasn't the reasoning.  It was just the matter-of-fact statement "I have used round robin in several 2012 RDS deployments. "

I gather you've worked I.T. for awhile. You know the routine.  Users and even other I.T. folks will say "I've done X and didn't see a problem" even though X was a terrible idea.  "I've typed in my password on a non-SSL site on a public WiFi network plenty of times. My password has never been compromised."  Yeah, it *happened* to work, but that doesn't make it right, or safe.

My point is justifying any position on personal experience alone is a bad idea. Personal experience is just too limited in exposure, and even when things "appear" to work (typing in a password in clear text networks), you may not know what is happening behind the scenes.

Round robin was a way to distribute connections. But a major change from 2008 to 2012 is that the RDCB does that now. There is no *need* to distribute connections via round robin. As for the rest, the RDCB in 2008 R2 already used redirection to maintain session affinity, and that hasn't changed in 2012.  Any thin client that doesn't support RDP redirection (such as XP thin clients) is now so old that they shouldn't be used anyways. There are plenty of *other* problems with RDPv6 and v6 that not working without round robin is the *least* of your worries.  Even microsoft's "Thin PC" win7 build for repurposing old PCs works well with it.  A thin client older than that has more than paid for itself and should be retired.  This isn't brand new RDP technology with 2012.  2012 just changes how it is used for better efficiency.

And therein lies one of the problems. Because the RDCB is also responsible for session affinity, using round robin DNS actually breaks that functionality.  The RDCB will *attempt* to maintain affinity, but round robin DNS will still throw the connection to the next available RDS server, affinity is broken, and the connection broker can't even properly track how many connections are on each host (because round robin DNS rebalanced them differently) and you can end up with heavily weighted servers and others vastly underutilized.  You basically kill RDCB with such an architecture.

I stand by my previous statement. You shouldn't be doing it. And yes, because round robin misdirects connections, certificates also throw errors. Your workaround masked the issue by re-issuing generic certificate names for the round robin DNS connections, but doesn't actually fix it as the RDCB now has no ability to distinguish machines for load balancing.  It actually makes *that* problem worse.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
CCtechAuthor Commented:
this was the actual solution to my problem. The steps I provided solved my issue.
Sorry to kick a dead horse ..... but I am experiencing this same issue where connecting from External gives me a cert mismatch but internal is fine.
On a 2012 deployment what should I be changing - I was following but have Web Access, Connection Broker and Gateway on a single server.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.