[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Outlook clients on LAN getting a Certificate error after installing 3rd party SSL cert

Posted on 2012-08-22
14
Medium Priority
?
2,272 Views
Last Modified: 2012-10-24
New, single server, Exchange 2010 install. This client has numerous users accessing OWA outside the network, so we purchased a cert from a well know provider, and its working, no issues. The problem is that LAN users are now getting a pop-up stating the Certificate is invalid b/c the name doesnt match. It lists the Exchange server's local FQDN (example.mydomain.local), and provides the new SSL cert with the public FQDN (mail.mydomain.com). Users are the LAN are automatically being configured with Outlook Anywhere (which i need enabled for some remote users), and when i attempt to turn this off, it automatically re-enables itself. Im not sure if forcing users on the LAN to NOT use Outlook Anywhere would fix this or not, but i find it odd that it's automatically re-enabling itself.
How do i keep the purchased SSL cert in place for OWA and Outlook Anywhere, and stop the certificate mismatch error in Outlook for users on the LAN?
Thanks.
0
Comment
Question by:mhdcommunications
  • 6
  • 4
  • 3
  • +1
14 Comments
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38322311
there are two solutions to this issue.

1) Create a DNS Forward lookup Zone called mydomain.com and have a A record for
mail and SRV Record for _autodiscover._tcp.domain.com to point to your CAS Server.
2) Disable Autodiscover for all LAN users using registry (via GPO)
Ref: http://support.microsoft.com/kb/956955

Regards,
Exchange_Geek
0
 
LVL 1

Author Comment

by:mhdcommunications
ID: 38322444
1) Create a DNS Forward lookup Zone called mydomain.com and have a A record for
mail and SRV Record for _autodiscover._tcp.domain.com to point to your CAS Server.

I already have the Forward Lookup Zone for mydomain.com, as well as the A record. For the SRV record, do i point it to mail.mydomain.com? Port would be 443, or left blank? Weight and Priority left at 0?
Once this is done, will anything need to be done on Outlook Clients that are already configured?
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38322488
SRV should point to CAS Server locally. Port 443 needs to be provided

Here is what it should look like.

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.mydomain.com

Also, create A record for mail.mydomain.com to point to CAS.mydomain.com

Regards,
Exchange_Geek
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
LVL 1

Author Comment

by:mhdcommunications
ID: 38323314
Creating the forward lookup zone, A record (both of which were already created), and the SRV record has had no effect. Even re-creating the Outlook profile still pops up with the certificate error. The link for disabling Outlook Anywhere is broken. Do you know what the changes were that needed to be made?
0
 
LVL 41

Expert Comment

by:footech
ID: 38325958
The A record for mail.mydomain.com should point to an internal IP (of the CAS).  Is this what you have?
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38326585
You either need A or SRV not both.

Here is what the article states

Modify the registry on each client computer. To do this, follow these steps:
Click Start, click Run, type regedit, and then press ENTER.
In the navigation pane, locate and then click the following registry subkey:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
Set the following registry values:
Value name: PreferLocalXML
Value type: DWORD
Value data: 1

Value name: ExcludeHttpRedirect
Value type: DWORD
Value data: 0

Value name: ExcludeHttpsAutodiscoverDomain
Value type: DWORD
Value data: 1

Value name: ExcludeHttpsRootDomain
Value type: DWORD
Value data: 1

Value name: ExcludeScpLookup
Value type: DWORD
Value data: 1

Value name: ExcludeSrvRecord
Value type: DWORD
Value data: 1
Note To set the registry value, right-click the registry Value name, click Modify, type the Value data in the Value data box, and then click OK.
Exit Registry Editor.

Regards,
Exchange_Geek
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38327687
Not really sure why there are internal SRV DNS changes are being made.
This SSL error will almost certainly be coming from autodiscover. If you purchased a standard SSL certificate rather than a UC certificate then the URLs will be mismatched.

You need to do two things.
1. If you haven't already, setup a split DNS system to ensure that the host name on the certificate resolves internally to the internal IP address of the server.
http://exchange.sembee.info/network/split-dns.asp
Single host replacement will be fine.

2. Reconfigure the internal URL that Exchange publishes for autodiscover to use the name on the SSL certificate:

set-clientaccessserver -identity SERVERNAME -AutodiscoverInternalServiceUri https://host.example.com/Autodiscover/Autodiscover.xml

where SERVERNAME is the name of your Exchange server.

Once set, run iisreset for the change to take effect.

You will need to use SRV records for external autodiscover lookups to work correctly.
http://support.microsoft.com/kb/940881

If your external DNS provider doesn't support SRV records, then switching the SSL certificate to a UC type will be the easiest way out of this problem.

Simon.
0
 
LVL 1

Author Comment

by:mhdcommunications
ID: 38337343
@ Simon

I had done all of that prior to posting. The error is coming from Outlook Anywhere since LAN users are being forced to use RPC/HTTP instead of connecting to Exchange using TCP/IP. I need to disable this for LAN users. I turned off Outlook Anywhere, and this has stopped the error, but we want to be able to use this feature at some point.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38337384
You are trying to deal with the symptoms rather than the cause.
The problem isn't that the users are connecting via Outlook Anywhere, the problem is that for some reason the clients are failing to make a MAPI connection over TCP and connect instead on HTTPS.

The behaviour you are seeing with regards to autodiscover is completely correct and expected. When you enable Outlook Anywhere in Exchange, all Outlook clients will get the settings. However on the LAN they shouldn't use the Outlook Anywhere configuration because the configuration that is pushed out means Outlook only uses it in the event of a failure to connect on TCP/IP.

However, I still have to doubt if you have done everything that I have listed above, because if you had, you wouldn't get the error.
Furthermore, are you sure that it is Outlook Anywhere that is the cause? Outlook and Exchange is built on web services, even internally connections are made to the server using web services - free/busy information, autodiscover both use web services. If you haven't deployed a certificate with the internal name then you have to use a split DNS and ensure that you have adjusted every URL parameter involved in Exchange to use the external name. If you are getting the internal name then you have missed one.

Simon.
0
 
LVL 1

Author Comment

by:mhdcommunications
ID: 38374797
Update:
With Outlook Anywhere Disabled, Outlook clients that were automatically configured while it was enabled, are STILL connecting via Outlook Anywhere instead of creating a MAPI connecting VIA TCP. Re-creating the Outlook Profile removes the settings for Outlook Anywhere when the accounts are setup from Autodiscover, but if I were to manually add them back in, the services are still functioning. I removed the RPC and RPCwithCert virtual directories from IIS, and users are still able to use Outlook Anywhere, both internally, and externally.

However, I still have to doubt if you have done everything that I have listed above, because if you had, you wouldn't get the error.
I had already done everything you listed PRIOR to posting. I have involved half a dozen other technicians outside my organization, including an MCM for Exchange 2010.

Since Outlook Anywhere is not my issue, how do i figure out why they are being forced (i use the word forced because MAPI connections via TCP DO work) to use Outlook Anywhere while it's enabled (and even when it's not).
0
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 1500 total points
ID: 38378348
If you have removed the RPC virtual directory and run IISRESET, then Outlook cannot connect to Exchange via Outlook Anywhere, unless it is connecting via another server?
I presume that you are verifying this via the Connection Status tool in Outlook (hold CTRL, right click on Outlook icon in the system tray).

If Outlook Anywhere is disabled, and is being reported as disabled by the event log entry on the Exchange server, then Autodiscover should provide that information to the clients on their next update and the setting removed.

It is begining to look like you may have an issue around IIS, possibly a corrupt METABASE.

Simon.
0
 
LVL 1

Assisted Solution

by:mhdcommunications
mhdcommunications earned 0 total points
ID: 38443426
Purchasing a UC Certificat to resolve this issue.
Side note, would the dual- website's each containing the proper cert not work since this is Exchange 2010 Enterprise? All the literature from MS i could find about this workaround refer's to Small Business deployments (not specifically Exchange 2010 SBS, just 'Small Business' term's were used in this literature which i ofcourse, forgot to save a link). Is this feature possibly not available for Enterprise?
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38443981
The version of Exchange is completely immaterial. Doesn't matter whether it is SBS, standard on full product or Enterprise edition. They all work in the same way.

You have probably seen small business references because people not wanting to spend $60 on a suitable SSL certificate are usually small businesses. They want to spend as little as possible in many cases.

Simon.
0
 
LVL 1

Author Closing Comment

by:mhdcommunications
ID: 38529290
UCC Certificate is the fastest and easiest way to resolve the issue, granted it costs $$
0

Featured Post

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.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

As much as Microsoft wants to kill off PST file support, just as they tried to do with public folders, there are still times when it is useful or downright necessary to export Exchange mailboxes to PST files. Thankfully, it is still possible to e…
Stellar Exchange Toolkit: this 5 in 1 toolkit comes loaded with mega-software tool. Here’s an introduction to tools’ usage and advantages:
In this video we show how to create a mailbox database in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Servers >> Data…
To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…
Suggested Courses

825 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question