SSL .Local Domain Removal Exchange

Removal of .local domain in SSL for any version of Exchange.  Need confirmation of changes for SSL cert itself and local DNS changes.

When generating the CER, are only two names now needed, external domain of Exchange services URL ( and ?

After performing the internal virtual directory URL changes matching the external...changes to split the DNS are the following?

create a zone for the external domain name (
create an A record, name of domain in SSL certificate (, point to Exchange server
create a MX record and point to Exchange server
create a CNAME record for and point to SSL URL (
Use are SRV record - _autodiscover _tcp - 443 and point to SSL URL (

Of course, other records like www and anything else needed for the external domain.
I don't have a test setup to test this with so my first will be a production network.

Thanks for any input.
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.

Will SzymkowskiSenior Solution ArchitectCommented:
That is correct. You only need to configure your MX record if you are using DNS to route mail externally. If you are using a smart host then you do not need this record.

Take a look at my HowTo for configuring Split DNS and Exchange virtual directories. The Exchange virtual directories outlines for Exchange 2013 specifically but all of the steps will work for Exchange 2007/2010. Just disregard the set-mapivirtualdirectory cmdlet (last step).

You also need to make sure that you Enable the Exchange cert with the correct services on all of your CAS severs as well. I have also got a HowTo on my site for this as well.

btanExec ConsultantCommented:
Just to share, specific to autodiscover , you need the “autodiscover.smtpdomainname” name in the Exchange 2010 SSL certificate the and that really depends if you need to include autodiscover names for all of your SMTP domain names. That is, you only need an autodiscover name for each SMTP domain that a user is likely to enter as their email address. Most just goes for domain names used as primary email addresses for mailboxes. Any additional domains that may be legacy names (from previous company name/merger) are left out of the certificate most of the time.

for the removal of .local and with its cert replacement , potential scope of impacts is mostly mismatched in fqdn of the URL that is stored in the following objects, if these are not changed accordingly too:
• The Service Connection Point object for the Autodiscover service
• The InternalUrl attribute of Exchange Web Service (EWS)
• The InternalUrl attribute of the Offline Address Book Web service
• The InternalUrl attribute of the Exchange unified messaging (UM) Web service
Do see the (resolution) checks and PS command @

...and also some may typically forget this check for their existing split dns
These steps assume that a host record exists in the DNS to map the FQDN that you specify to the IP address of the CAS server. For example, consider the following scenario:• The original internal URLs for the Exchange components point to the internal FQDN of the server. For example, one of these URLs points to the following:

• The FQDN that is specified on the certificate points to the externally accessed host name of the server. For example, the certificate specifies an FQDN, such as ""

In this scenario, you must add a host record for the mail host name that is mapped to the internally accessed IP address of the CAS server to let internal clients access the server.
RFloyd30Author Commented:
Both nice comments and some items I did not prepare for fully.  I've read the articles before I posted this question but thank  you and all are in my plan.  I will performing the task for a large network this week.  I will leave this here for a few days and update after the implementation.  I may have more questions.
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.

RFloyd30Author Commented:
Follow up - Just got a chance to do this on a large network, about 200 users.  all seemed to go well but getting the dreaded SSL name mismatch error on the Outlook clients.  Also had to fix the OWA HTTP redirection - that is fixed.

On the name mismatch, I cannot find the problem.  All virtual directories match the SSL ( and the AD DNS is setup like this:
forward lookup zone - (was already there)
A record - mail - points to Exchange server on premise
MX record - points to Exchange server on premise
CNAME - autodiscover - value

When I look at Outlook anywhere via the powershell's Get-Outlookanywhere I see one parameter that is blank - xropurl.  Not sure what that is and a few searches did not reveal anything.
Also, saw some articles preferring the Outlook Anywhere authentication be NTLM, not basic.  Other than the security of this, would this cause the mismatch.

On a PC that has the mismatch message, I can hold CTRL down and right click the Outlook icon on the systray and perform the test connection.  When I review all there, I see no .LOCAL any place to clue me in what is happening.

Can you guys think of what I'm missing here?

Thank you for any input!!!
btanExec ConsultantCommented:
I believe "XropUrl" from MS stated it is applicable only for multi-tenant Exchange deployment where the system has been configured to host multiple and discrete organizations or business units (the tenants) that ordinarily don’t share e-mail, data, users, global address lists (GALs), or any other commonly used Exchange objects.  It isn't available for on-premises deployments hence should not matter in your case.

For mismatch, we can check this OR

We typically need at least 2 certificates. One for OWA/Outlook Anywhere, one for Autodiscover service.  However, that is not always as wanted easily, so some stopped the message coming up by adding an entry to the hosts file like this: - Apparently this tells Outlook to look on the local machine and this way send Outlook to search right back to the client computer hence no more error.

Also good to use Remote Connectivity Analyzer ( to test Outlook Autodiscover, all the External URL (items below the <Type>EXPR</Type> lines) normally should not be missing.

For authentication, ClientAuthenticationMethod as {Basic, NTLM} and IISAuthenticationMethods as {Basic, NTLM}. I do not recall ClientAuthenticationMethod must be both, but IISAuthenticationMethods should be both. This is so to make sure NTLM works for internal connections w/o prompting for a password when accessing from within the domain.
RFloyd30Author Commented:
Thanks for the post - i will check all these with a fine tooth comb tonight.

Just a thought.  When the SSL mismatch error pops up, it has the name of the Exchange server on the pop up windows - exchange.domain.local.

So i thought i would add a CNAME record in the .local zone for this and reference  This failed and the dns would not take the input.  It gave me an error of cannot add this record...  sorry i don't have the exact message.

So it may seem to me that since the Outlook clients have in their outlook profile for the exchange server - exchange.domain.local - that is where the mismatch is.  

What would this be?

Thank you for any help.
btanExec ConsultantCommented:
this post has some clarity in this area as well for the mismatch and autodiscover. This esp for domain publicly useable on your Exchange AD environment, you will run into certificate errors when mail clients use Autodiscover). The solution suggested using SRV to be added into your internal DNS zone is a good check on your setup. Point to note also is that Subject Alternate Names (SAN) in SSL cert may be unrecognised as many 3rd party CA that provide SSL certificates are beginning to deny requests for that aren’t publicly available. Hence you won’t be able to get a valid SSL certificate that allows domain.local as a SAN.

In short, you'll want to enter a SRV record in your domain.local DNS Forward Lookup Zone to point Autodiscover on that domain to Autodiscover uses the local domain DNS too attempt connections to Autodiscover. So you need to ensure that your internal domain is capable of handling it.
RFloyd30Author Commented:
No luck.

I put in the SRV record and it still did not solve my issue.  Wow, I've got to be missing something but I cannot figure it out.  Maybe a call to Microsoft MSP.  

I would assume that Autodiscover is working as its not getting to the SRV record?  I don't really know at this point.  I've checked everything and all URLs and URI is pointing to :
Https://   (... is relative to the cmd that I'm checking)

Maybe my DNS is the issue?  
Even when I do all the NSlookups and the test Exchange connectivity, there is no place that it is looking for a .local.
My SSL cert has 3 names -, and

Again, what the heck am I missing.

I very much appreciate your attention to this.

Thank you
btanExec ConsultantCommented:
Maybe a quick check of below as if all done then it must be other area for the issue
1. The first place autodiscover looks is for external addresses. Change with domain.local for what Exchange looks for on Internal clients.
2. If the autodiscover record is not found at, the server will attempt to connect to (replace with domain.local for internal).
3. If autodiscover information cannot be found in either of the first two steps, Exchange will attempt to use a Service Locator record in DNS to determine the appropriate location of the configuration files. Make sure there are no A records for autodiscover.domain.local in the zone.

Also pls see through this work around -
The SSL certificate subject is However, Outlook tries to connect to
Method 1: Reissue a certificate that includes the domain name as the Subject Alternative Name
Method 2: Do not install the IIS service and DNS on the same server
Method 3: Do not install or bind an SSL certificate on the DNS server running IIS
Method 4: Configure Outlook to allow the connection to the mismatched domain name
RFloyd30Author Commented:
Thank you for the reply.

Not sure I totally understand options 1 and 2.

I've read the KB article and bypassed it for now.  I'd really like to have it working as designed rather than making changes to the registry to bypass it but will do if all else fails.

Observation is that once a client gets the message and answers Yes (sometimes twice) it goes away forever???  Will know more later about that as the days progress.  My testing was with a terminal server.  I could choose a particular users profile (as administrator) and once you try to compose a new message, the alert would pop up.  Answer yes to it and then close outlook.  Reboot terminal server and then use the same user again in Outlook and no message.

The onsite administrator did not get it this morning either although he was getting it on Friday before all the checks and balance changes over the weekend.

Not sure what all that means but I will keep a close look.

My 2 cents is this - the problem is with local outlook profiles that have the server name of the local Exchange server, server.domain.local.  This is the name on the pop up security mismatch error.  Somewhere RPC is still looking for the local name and its not resolving to the correct URLs which match the SSL cert.  I know its RPC as I use RPCdiag on launch and see the connection.  Another reason I feel autodiscover is good is that I created a new user with a new outlook profile and walking thru the setup wizard for Outlook was all successful automatically, with no SSL mismatch.  It did populate the server field automatically with the local server name - server.domain.local.  Of course this matches the A record for itself in the DNS.  And again, using the connectivity analyzer built into Outlook (CTRL and right click the Outlook icon in systray) shows no .local in any setting.

Thanks again for the input.  Very valuable and appreciate your time.
btanExec ConsultantCommented:
Thanks I believe we are aligned in understanding and just the troubleshooting for this intermittent is tough going and I can understand that. Agree with you that definitely the mismatch is something to do with the .local records since it is supposed to be working well for autodiscover, DNS records in a proper, SSL cert has the FQDN rightly created for.

 As of now, unless we can make it permanently appearing, the doubts still exist. I did though of re-setup in staging and a one separate client to one DNS server/CA/Exchange setup instead - it is effort though. Really how depends how involved we can get but having to review the event viewer on error log encountered for MS tech support to advice accordingly may be an alternative.
btanExec ConsultantCommented:
Thought this is a guide for autodiscover troubleshooting (for info) with screen flow autodiscoverflow.JPG

Separately, I am reading this article and it may also be inherent to Outlook 2013 client new concurrent polling ut may not necessarily be for our case, just sharing it out in case, it hits some "sparks"
When Outlook 2013 does it’s simultaneous DNS AutoDiscover query the first URL it tries is, which in my lab environment resolved to my Domain Controller, which was also serving DNS, as well as a Certificate Authority. resolved to this server because it’s my internal Active Directory domain name & the name server entry resolves to my DC (just ping internaldomainname.local in your AD lab environment & you’ll see the same thing).

Now because I have web enrollment enabled & am listening on 443 in IIS the server responded. Also, because I did not have a cert installed on the server with in the Subject or Subject Alternative Name then it gave the certificate error we see above.


The error is easy enough to get through & it only occurred on initial profile creation but this can definitely prove painful for some customers.
RFloyd30Author Commented:
Thank you again!

I think I'm on to something and having an issue.

When the client gets the SSL mismatch, I look at the connection and its RPC.  I went down that road and find the when using powershell to look at the INTERNAL hosthame, it does not exist.
So trying to set it with the command below:

Set-OutlookAnywhere 'EXServer\Rpc (Default Web Site)' -ExternalHostname -InternalHostname -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -ExternalClientAuthenticationMethod Basic -InternalClientAuthenticationMethod Basic

But it looks like the parameter "InternalHostname" is no longer valid.  TechNet does not show this as valid...  If that is the case, how do I set this?

Looking now myself.

btanExec ConsultantCommented:
Noted that the option is not available in (Exch2010SP3UR2) but the Outlook Client should looks up the AD for an Connectionpoint first before doing lookups on (eg) and As discussed before, the sequence is something as below, so if the xml has the InternalHostname stated, then it should be fine..
1. Access autodiscover via SCP in AD.
2. If SCP access fails, it will try:
3. Then
4. Local XML file
5. SRV record

In fact I see this article's worth in using DigiCert tool.
Separately I see DigiCert post stating also use of InternalHostname
Some suggested using AutoDiscoverSiteAffinity but I rather not do so...

In a nutshell, it contains the script (I suspect it is not using internalHostname though I did not manage to see the script...) to modify the internal URLs to something that resembles a publically routable URL. In other words, it will set the internal URLs and AutodiscoverServiceInternalUri to something similar to the external OWA URL (e.g. Maybe the script can be handy but I do see the use of InternalHostname is still valid in Exchange 2013 as tested in the article

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
RFloyd30Author Commented:
I'm going to close this for now.  Thank you very much for all the input.  Anyone using this for help read the entire post as it all helped.

It appears the problem has been solved.  It took maybe a time or two for a client to get the SSL mismatch message and answer Yes and the prompt went away.  

Also our terminal server users kept getting the prompt and the solution there was to recreate the profile.   I know, we have a lot of TS users so this is a pain.   And we did have another PC on the network get message but again, a new profile seems to have solved.

Thank you again for the assistance.
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

From novice to tech pro — start learning today.