SSL .Local Domain Removal Exchange

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

http://www.wsit.ca/how-tos/exchange-server-2/configure-split-dns-and-exchange-2013-virtual-directories/

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.

Will.

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 @ https://support.microsoft.com/en-us/kb/940726

...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:
https://ServerName.contoso.com/ews/exchange.asmx

• 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 "mail.contoso.com."

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.

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.

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 (mail.domain.com) and the AD DNS is setup like this:
forward lookup zone - domain.com (was already there)
A record - mail - points to Exchange server on premise
MX record - points to Exchange server on premise
CNAME - autodiscover - value mail.domain.com

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

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 http://exchangeserverpro.com/outlook-2007-clients-display-certificate-mismatch-error-after-mailbox-migration/ OR http://kb.stonegroup.co.uk/index.php?View=entry&EntryID=208

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:

127.0.0.1 autodiscover.yourdomainnamehere.com - 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 (https://www.testexchangeconnectivity.com) to test Outlook Autodiscover, all the External URL (items below the <Type>EXPR</Type> lines) normally should not be missing. http://blogs.technet.com/b/exchange/archive/2008/09/26/3406344.aspx

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.

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 mail.domain.com.  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.

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.
https://acbrownit.wordpress.com/2012/12/20/internal-dns-and-exchange-autodiscover/

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

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://mail.domain.com/...   (... 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 - autodiscover.domain.com, domain.com and mail.domain.com.

Again, what the heck am I missing.

I very much appreciate your attention to this.

Thank you

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 https://domain.com/Autodiscover/autodiscover.xml for external addresses. Change domain.com with domain.local for what Exchange looks for on Internal clients.
2. If the autodiscover record is not found at domain.com/domain.local, the server will attempt to connect to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml (replace domain.com 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 DC1.contoso.com. However, Outlook tries to connect to https://contoso.com/autodiscover/autodiscover.xml.

https://support.microsoft.com/en-us/kb/2783881
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

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.

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.

Thought this is a guide for autodiscover troubleshooting (for info) with screen flow http://blogs.technet.com/b/exchdxb/archive/2012/05/10/troublshooting-autodiscover-exchange-2007-2010.aspx

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 https://company.com/autodiscover/autodiscover.xml, which in my lab environment resolved to my Domain Controller, which was also serving DNS, as well as a Certificate Authority. Ash15.com 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 ash15.com in the Subject or Subject Alternative Name then it gave the certificate error we see above.

Resolution:

The error is easy enough to get through & it only occurred on initial profile creation but this can definitely prove painful for some customers.

https://exchangemaster.wordpress.com/tag/autodiscover/

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 mail.mdomain.com -InternalHostname mail.domain.com -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.

Thanks

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.