More on Exchange 2007 and certificates - with real world scenario
Published Jul 02 2007 03:20 PM 43.7K Views

EDIT 10/4/2007: Since this post has been published, we have updated the Exchange 2007 Autodiscover Service whitepaper to include this information. Please consult the whitepaper for most up-to-date information.

In reviewing all of the certificate data out there, Jim and I noticed that the information is fragmented into smaller topics and widely distributed. We wanted to supplement previous blog posts on this topic (this one and this one) with an overview of how Exchange 2007 uses certificates and a walk-though of how a typical small company might think about this topic.

Exchange is now using certificates for more than just web, POP3, or IMAP. In addition to securing web services, Exchange 2007 has also incorporated Transport Layer Security (TLS) for session based authentication and encryption. TLS has been around for a while but the Exchange 2007 implementation is able to mutually authenticate with external transport servers, internal servers and Outlook 2007 clients. TLS as implemented in Exchange 2007 is an effective alternative to S/MIME and is much easier to administer. 'Domain Security in Exchange 2007' is an excellent whitepaper on Exchange 2007 and TLS so we aren't going to reproduce it in this post, but we wanted to give mention to this new change and point everyone in a direction to read more on this topic. You can download it here:

Since Exchange 2007 shipped, we in Support Services have been helping a lot of customers navigate the process of obtaining and installing certificates. The following scenario comprises the majority of our experiences:

Tom works for a company, Contoso Inc. Let's also say that Tom just put a default install of Exchange 2007 on a server called SERVER01 which makes its internal FQDN SERVER01.contoso.local since he also implemented split DNS. Tom wants to make sure he takes all of the correct steps in order for his External Outlook Anywhere 2007 clients to function correctly. He wants his users to be able to access OWA using He has also read enough Microsoft documentation to know that the Outlook 2007 Auto-discover feature will attempt to find my auto-discover service at the following locations (in order from top to bottom):

Service Connection Point (SCP) – client communicates directly to AD

Tom doesn't want his users to get "invalid certificate" errors nor does he want to affect his clients with redirection requests.

Tom has just one more decision to make and then its implementation time. Does he go with the recommended solution of a certificate with Subject Alternative Names (SAN) – also known as Unified Communications Certificates or with individual certificates?

SAN Cert (Microsoft recommended solution)

Pro – Simple to administer on the server

Con – If you are purchasing the cert from a 3rd party it can be expensive (up to 10x more than a classic SSL cert)

Con – If you generate this cert with your internal MS certificate server, external clients/devices must be configured to trust this internal CA which may involve configuring many devices (Outlook clients, mobile devices, etc).

Con – not all CA's support this type of certificate. See this article for a list of CA's that do:

929395 Description of the Exchange-specific Web sites that are provided by X.509 certification authorities;EN-US;929395

Classic 3rd party SSL cert

Pro – inexpensive

Pro – most clients will trust the CA by default

Con – can complicates deployment on the server or require the use of an unfamiliar alias

The decision on this is your's (Tom's) hands so we'll cover both here:

The SAN cert method

You will need to contact a 3rd party CA that supports these types of certs (see link to KB929395 above)

Next, you need to know all of the Subject Alternative Names that you need to register. Here is the list that applies in Tom's scenario (for the '-domainname' parameter):

Officially, the NetBIOS names of the server are not required. But many users and admins like to use OWA internally and this will prevent unnecessary warnings about the cert when they log on. There are no ill effects from adding internal names but they are not necessary.

This is the Exchange Management Shell (EMS) command Tom would enter to generate the cert request to be provided to the 3rd party CA in order to generate the actual certificate:

New-Exchangecertificate -domainname,, contoso.local,, server01.contoso.local, server01 -Friendlyname contosoinc -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true –subjectname "c=US o=contoso inc,"

We have found that the '–subjectname' option is the most confusing. The help contents in EMS are vague as well. The best description is found in the TLS whitepaper mentioned at the beginning of this post so we're not going to reproduce it here.

As we just stated, the above command will generate a certificate request file you can then submit to the CA of your choosing. Once they have processed your request and you have the cert, you need to install it onto your default web site. You don't install the certificate using the IIS Admin Console, you need to do it using the management shell.

First you have to import it:

Import-exchangecertificate –path <full path to cert file>

Then enable it:


When you run the above command you will be prompted to enter the name of the service you want to enable this certificate for. You can enable the cert for IIS, POP3, IMAP, SMTP, or UM depending on your circumstance. You can enable it for multiple services with the enable command by adding the following parameter:

-services IMAP, POP, UM, IIS, SMTP

After that it will prompt you for the thumbprint, so just copy and paste it from the results of the import procedure mentioned above.  If for some reason you don't have the thumbprint in the same window you can get it by typing the following monad command:


You can also specify the thumbprint when you execute the 'enable-exchangecertificate' command by adding this parameter:

-thumbprint D75305BEF8175570EB6E03BA6FF4372D05ACE39F4

Combined it would look like this:

Enable-exchangecertificate –services IIS, UM, SMTP –thumbprint D75305BEF8175570EB6E03BA6FF4372D05ACE39F4

Make sure you copy the correct thumbprint if you have more than one. You can tell by running the 'get-exchangecertificate' PowerShell command and match up the subject with the correct thumbprint.

Next you need external DNS records that point to the IP address of your CAS server for any external name mapped to this certificate.

The other method

Jim and I are also hearing "These 3rd party companies want to charge me a lot of money for this SAN cert thing, is there another method?"

Why yes there are a couple of alternatives and here they are:

Alternative 1

Get a normal SSL certificate for the autodiscover namespace ( in the scenario). If you plan on using TLS you'll need to make sure to follow the instructions above but for subjectname you only need to specify the one namespace. The steps are no different to import and install at that point.

For this first example users will enter the following url for Outlook Anywhere or ActiveSync:

They would use this url to get to OWA:

Alternative 2

This alternative addresses users that may not be as open to learning a new URL for OWA, activesync, or other web services they may already have configured. Get 2 certs, one for and one for cert goes on your default web site.

Next, create a new Web site from within IIS manager called AutoDiscover.

Right click, "Web Sites", choose "Web Site", make the description AutoDiscover, assign a new dedicated IP to this web site, use the default port of 80, don't enter a host header, for the Path, point to the same directory as your default web site


Also accept the default permissions.

Right click this web site, get properties, and go to Directory Security. Assign the cert here.

From the Exchange Command Shell, run the following command:

New-AutodiscoverVirtualDirectory –WebSiteName AutoDiscover –BasicAuthentication $true –WindowsAuthentication $true

Note that the web site name parameter is case sensitive.

Go back to IIS manager, confirm the creation of your new AutoDiscover Virtual Directory. You can delete the autodiscover virtual directory from the default web site but it's not necessary and there is no additional risk by leaving it there. Finally, make sure external DNS have A or CNAME records for the following: pointed to the external IP of Default Web Site pointed to the external IP of the AutoDiscover web site

Now that you have your cert installed, now what? Default certs issued by a MS certificate authority are valid for 2 years. The length of 3rd party certificate validity depends on your agreement with them. You can use the certificate manager addin for the local computer to renew these certs when the time comes or you can also repeat the steps above to get a new cert from another CA if you like. There are several ways to do this and the choice is yours to make as to how you accomplish the renewal.


If you choose to install and use your own CA, you will have to ensure that clients, servers, and devices that access any secured site trust your CA as a root. This is actually a minor procedure but depending on the technical ability of your users or in large deployments it can become quite complicated.

Also, if you plan to incorporate an SSL accelerator or ISA server located in a DMZ you need to make sure that you export the private key of the certificate (pfx file). You can do this from the IIS administrator program once the certificate has been installed following the previous procedure.

Here are some links on that process:

299875 How to implement SSL in IIS;EN-US;299875

915840 How to install root certificates on a Windows Mobile-based device;EN-US;915840

297681 Error Message: This Security Certificate Was Issued by a Company that You Have Not Chosen to Trust;EN-US;297681

332077 IIS 6.0: Computer must trust all certification authorities trusted by individual sites;EN-US;332077

Certificates for Windows Mobile 5.0 and Windows Mobile 6

- Christopher Gregson, Jim Westmoreland

Not applicable
Thank you VERY MUCH for posting this. It helps clarify many of the questions I hear in one concise post.
Not applicable
I would add that Windows 2003 CA support SAN, but it is not enabled by default. details how to enable it.
Not applicable
Great writeup, could have used it a month ago!  

The *only* thing I would love to see is a table of major cert providers (and cert "packaged" names) cert providers with:

Cert Authority/Product Name/ Root cert / intermediate cert / Price / SAN support / WM5 trusts? / WM6 trusts?

Now that I thought about it, I almost want to make that table  :o
Not applicable
Thanks for the post.  Makes things a lot clearer.

The reality is that most organisations have different internal and external namespaces and the doco so far has been very obscure.  You should get the ISA 2006 support teams to add their feedback too.  I have been told that when requesting a new certificate, you need to ensure that the first SAN listed in the certificate matches the internal site name to be published in the ISA rule.  This is a required workaround at the moment for ISA 2006 apparently.
Not applicable
Does Alternative 1 work for Entourage clients or just Outlook 2007?

Moving to Exchange 2007 has broken access for Entourage clients, and it looks like the certificate is the issue, although Entourage is giving nothing away...
Could you explain why ActiveSync and OWA seem to work as before (Exchange published by ISA to whilst Entourage breaks and OL2007 requires an acceptance of an invalid servername?
Not applicable
I setup the OWA as instructed but i am have 1013 failed with MSH
TEST-OUTLOOKWEBSERVICES. Outlook still cannot download OAB

I found one strange things is the certificate is RSA 2048 bit length SH1

all other is ok
another questions is on IIs, should I enable annoymous access?
Not applicable
For Alternative 1 you can ommit the name for autodiscover and use the -IncludeAutodiscover Parameter. This is especially usefull if you have multiple "accepted domains", as this parameter ensures that an autodiscover entry is created for each accepted domain.

@ UZIH: I worked with internal CA's but didn't enable SAN support. It worked out of the box...

Not applicable
good overview of a process that is very confusing. I am using SAN certs through Verisign. If you use Versign as your CA, you will need to contact them to enable a new set of features in the certificate enrollment UI they have. Once that is done, you will need to use the standard IIS cert request process and not the Exchange Powershell commands. Verisign's enrollment could not read the Powershell output. Once the IIS digest is uploaded, you manually add all the domain name you need and then Verisign combines the digest with the domainnames and out pops your cert.
You will be charged for every domain name as a single cert...which is different than others and more don't use NetBIOS.
Not applicable
Is the following true?  A previous EHLO post claims that https:// is hardcoded and not Http:// in outlook as you indicated:

Service Connection Point (SCP) – client communicates directly to AD

Not applicable

What we have here is correct... which post are you refering to? Might have to fix the typo there or make it clearer if it is not explicit enough...
Not applicable
Thanks everyone for the additional comments and questions.  Here are responses from Chris and me:


MS CA should support SAN's out of the box.

Chris Lehr,

This is always changing so rather than post it in here I chose to like to the best documentation we have about it.  That doc will be updated over time so we don't have to keep changing the blog post.;EN-US;929395


The problem with Entourage is that it's looking for an Exchange virtual directory.  This will only work if the mailboxes are on E2K3.  If the mailbox is on E2k7 then it is redirected to the OWA virtual directory.  That is documented here:

924625 When you use Outlook or Entourage with an Exchange 2007 mailbox, you cannot connect to Exchange 2007, and you receive an error message;EN-US;924625


No, don't turn on anon access.  I suggest you call in to our support center or use the help forums.  There isn't enough detail in your post and this isn't the place to troubleshoot specific problems.

Not applicable
How would we use an existing wildcard certificate?
Not applicable
Alternative 3:

Forget about spending >$200 for a SAN SSL cert
Forget about spending $ for a autodiscover SSL cert
Forget about creating creating multiple websites and dealing with that mess.

See my guide on setting up Outlook Anywhere, OWA, Activesync, etc using just 1 SSL Cert, 1 public IP and no need to create multiple website.

Not applicable
Also note that if ISA publishing is involved and you want to use a SAN certificate, in the ISA Publishing Rule you must forward the external client to an internal server whose DNS name is the exactly the first FQDN that you use in your certificate.

E.g. if the first FQDN of your certificate (assuming split DNS) is "" then you must forward the external request to "" instead of "" making sure that ISA can successfully resolve the URL from your internal DNS Server.
Not applicable
Thanks Jim - at present my CAS is on my Mailbox server, so no auto-redirection of /exchange to /owa - however, changing the url in Entourage to has fixed the problem. Now it's only RPC/HTTPS I have to fix using the info in this post ;) Thanks also Uzih for the enable SAN tip...

Not applicable
Question about the new-exchangecertificate command "Tom" used in the post....

The subjectname CN used was server01.contoso.COM, although the public url is and the internal FQDN is server01.contoso.LOCAL.  Should the CN have been ...local or mail...?  

I've been going nuts trying to get outlook anywhere (2k7 server, 2k3 clients) to work (owa is fine).  My current cert is Subject/CN = and Domain/SAN =, server.domain.internal, server,
Not applicable
Colin - Wildcard Certs

Currently Exchange ActiveSync will not work with wildcard certs.  If you don't plan to use EAS then everything else should work fine.

Yannis - ISA

Excellent points and accurate.  I'm hoping to get some follow up from our ISA team.

Dan - subjectname

in the example 'Tom' should use .com.  The domain used in the subject name should be the domain name that you legally own or have rights to.  Each vendor may want different fields in the CN but generall it's country code, company name, domain name.  The .local is not used because that is the internal namespace and is not valid externally.

Not applicable
Great post guys.  Here are a few other tips I recommend in helping with certificate issues:

- Install an Enterprise CA in your environment; all of your domain-joined clients will eventually trust the issue through AD replication.  This is a potential time-saver if the bulk of clients are connecting are joined to the domain.
- For non-domain clients (i.e., home PCs) consider the steps in KB297681 for an easy way to allow clients to get to the issuing CA.
- Don't forget about self-signed certificates; technically they work but they are troublesome because they are untrusted
- Finally, don't forget that Outlook for Outlook Anywhere only looks at the "issued to" name on the certificate, not the SANs!
Not applicable
I have a question regarding obtianing a SAN/UC certificate:
We have 1 domain and requested the cert with the following SANs:

Since we didn't include as one of our subject alternative names, will Outlook spit out an error when it can't contact and then successfully contact

I'm just worried that we'll get an error since we didn't the into the cert.  Any thoughts?
Not applicable
When you say "Officially, the NetBIOS names of the server are not required", are you referring to "Server01.contoso.local" as well or just to "Server01"?  I assume the former, and I am fairly certain that this information is incorrect.

Try using a cert without "Server01.contoso.local" in it, then use Outlook 2003 on a computer outside your network to create a profile (ie. use OA when you initially set the profile up).  I bet you it doesn't work.

This info might also help others with this problem.

Regards, John
Not applicable
Thanks for the info Terry :-)


no, OL will work fine as long as you have a trusted cert for one of the URL's that is requests.

John Fletcher,

You have it backwards.  The NetBIOS name is SERVER01 and is not required but I recomend that you included it.  Server01.contoloco.local and are valid fully qualified domain names (FQDN) and will be used from internet based hosts.
Not applicable
Do you support wildcard certs for POP/IMAP.  I am getting the following error in the event log on my cas server:

Event ID: 1102

The POP service failed to connect using SSL or TLS encryption.  A valid certificate is not configured to respond to SSL/TLS connections.  Check the configured hostname as well as which certificates are installed in the Personal Certificates store of the Computer.

The same wildcard cert works fine for OWA.
Not applicable

Not supporting wildcard certs is not the same as whether it will work or not.  To my knowledge there are no issues with wildcard certs and POP/IMAP.  I see that others have posted about this same issue in the support forums and there have been no responses.  I found no known issues documented or cases opened about it.  Make sure that you enabled the certificate for POP and IMAP.  If all seems well I would recomend that you use the support forums or open a case so we can investigate further and get to the bottom of it.

Not applicable

 I reviewed your post describing Alternative 3.  It seems that with your method External Outlook 2007 clients will always get the redirect when autoconfiging.  The methods we described will not result in a security alert or redirection warning.  Your method will work great as well if your users are ok with this redirect.  Of course if I have misread or you have found a way around this redirection issue, feel free to correct me.

Not applicable

I already posted in the newsgroup, but haven't gotten a reply as of yet.  The post is titled "POP/IMAP SSL Issue - Exchange 2007".  It's dated 6/27/07.  The description of the error lead me to believe that POP/IMAP didn't know what to do with a certificate with a *.<domain name> as the host name.  That's why I asked if wildcard certs were supported.
Not applicable
I really enjoyed TwoJ walkthrough.  I thought it had alot of good info even if you don't take all his SSL advice.  I'm new to Exchange 2007 and finding all of this to be a bit overwhelming.  

My employer wants to use ISA 2006 in a DMZ to protect OWA with web publishing rule.  My understanding is that I must export our existing VeriSign cert from Exchange 2003 so that it can be imported to the new Exchange 2007 server, or does it go to the ISA 2006 in the DMZ?    I feel blind sided by some of the information in this post.  It seems so much more complicated now.  

Does anyone know of any other good walk-throughs that may simplify this process?  
Not applicable
Jim W. - That's my question.  We have a pre-existing wildcard certificate for * (our server is  Our email addresses are all, however.  Can we use a wildcard SSL cert for OWA/SMTP/POP3/IMAP?
Not applicable
I am thinking of implementing Alternative 2 for Autodiscover.  It states in the help file "Do not use the Certificate Manager snap-in to import the certificates for any service on an Exchange server. Using the Certificate Manager snap-in to import certificates on Exchange servers will fail. Therefore, TLS or other Exchange certificate services will not work".  However, your article states: "Right click, "Web Sites", choose "Web Site", make the description AutoDiscover, assign a new dedicated IP to this web site, use the default port of 80, don't enter a host header, for the Path, point to the same directory as your default web site


Also accept the default permissions.

Right click this web site, get properties, and go to Directory Security. Assign the cert here.
Is there a downside to importing the Cert outside of the EMS?
Not applicable

Correct, you need to export the cert from your CAS server to install on the ISA server.  You need to export the private key with it so be careful to include that checkbox when you do it.


You can use your existing wildcard cert for OWA and SMTP but I'm not sure if there are issues with POP and IMAP.  I'm going to try to get a final answer on that today and post an update ASAP.


You want exchange to be 'aware' of the certificate.  Installing it using the shell allows you to easily enable the cert for multiple services.  If you have a single server and aren't planning on using anything other than OWA/EAS/RPC-HTTP then you'll be fine using the IIS UI.
Not applicable
Prelimnary testing is showing that POP and IMAP will NOT work with wildcard certs.  I'm trying to get this documented in a KB as well.
Not applicable
I created an article on my blog on how to publish the Autodiscover on ISA 2006.  Since this article is about the Autodiscover and you said you will be publishing using ISA 2006, I figure this blog entry might be of help to you.

Not applicable
I created an article on my blog on how to publish the Autodiscover on ISA 2006.  Since this article is about the Autodiscover and you said you will be publishing using ISA 2006, I figure this blog entry might be of help to you:
Not applicable

Not to beat a dead horse, but as my post above re: request for autodiscover in both http or https, if i do a ctrl-right click on the OL2007 tray icon and run the test, it only tests for HTTPS.  If as you say it should also poll http, is there a reason mine is not?  The link I am referring to that contradicts your claim about polling both http and https for autodiscover:

Not applicable

A lot of documentation leaves that little tidbit out.  My impression is that a lot of the documentation is describing ideal and best practice scenarios.  This is an easy conclusion to draw since the server loads with a self signed cert.  I'm not sure if Outlook

makes the http specific request visible in the UI but I've seen it plenty of times in debug and netmon traces.  If you look you can find references to it, here's a webcast by Joe Turick:;EN-US;935439

Check out slide 24:

Connect to AutoDiscover - hosteddomain

Outlook connects to autodiscover.[]/ autodiscover/ and []/ autodiscover by using HTTPS

This fails – HTTPS not configured

Outlook retries by using HTTP, but doesn’t authenticate

Outlook gets an HTTPS redirect to

Short of posting up source code I'm not sure how else I can convince you.  I suggest that you get a network trace of your connection attempt then filter the trace for HTTP traffic.  If the HTTPS request fails you should see it


Not applicable
Hello Adrian,

 Can you try the following?

Ctrl-Right click the tray, choose "Test E-mail Autoconfiguration"
In the e-mail address put in
click "test"
click on the "log" tab.
Review the entire log and you will see we do in fact try http://
You are likely not seeing this because you are succeeding well before we try this in your situation.

Not applicable
Before I go out and by another certificate I want to make sure that this is going to work.
I setup Exchange 2007 on my internal network. I setup a route though my firewall for OWA and Activesync, I created a FQDN of I bought a certificate for External access works well.
However, internal users connecting to the new server with Outlook 2007 get prompted twice because the certificate doesn't match the internal server which is ppgexg001.mydomain.local.
According to what I have read here, if I create a new host record for and buy a 2nd certificate for and apply it using the instructions here, the internal users will no longer be bothered with certificate errors?
Can you confirm this please.

Paul S
Not applicable
I think your EMS command has two typos:

New-Exchangecertificate -domainname,,contoso.local,,, server01 -Friendlyname contosoinc -generaterequest:$true -keysize 1024 -path c:certrequest.req -privatekeyexportable:$true –subjectname "c=US o=contoso inc,"

1. You need another space after the second domain name, ''.
2. In the list of domain names,  '' should be 'server01.contoso.local'

Can you please clarify?


Not applicable

It should work fine.  You can test prior to this with your own CA if you want.  Internal OL uses the SCP to get the URL, external clients will use the SMTP address of the user to 'guess' the URL so as long as your SMTP address is then it should

work fine.  The SCP address will probably fail or generate a prompt so you may want to change that value in AD for internal users.  You can see what it's set to by using this command in the shell:

get-clientaccessserver | fl autodiscoverserviceinternaluri

I imagine you'll get your .local namespace returned.  You can change it by doing this:

set-clientaccessserver <servername> -autodiscoverserviceinternaluri:

That way internal clients that are able to use the SCP and external clients will resolve to the same name that the cert was issued to.


Yes,thereisatypointhatthereshouldbeaspacewhereyouindicated.  And yes, I typoed the name in the command for .local and should have entered .com.  I think it still makes the point though.  I would blame Chris for that but he's not here to defend himself today




Not applicable
FYI, we updated the command in the original post to correct the typos pointed out by Loren.  It should be accurate now.
Not applicable

I think the EMS typos show that an obtuse CLI, which may be very helpful for large IT shops, is no substitute for a fully developed GUI. It took me an entire afternoon to cobble together the EMS cmdlets required to make Exch2007 function properly. This migration, compared to the 2000/2003 migration, is horrendously complicated.

I'm a consultant to small businesses. I've discussed this "it's in the EMS and not in the GUI" situation with other small biz consultants and intermal staff at small and medium sized shops. Several have indicated that they are going to *skip* Exch2007 due to the onerous admin learning curve (EMS) and/or because there is no in-place upgrade option. Truly, it shouldn't take three cmdlets, one of which was 349 characters, to do what took just a handful of mouse clicks in Exch2003 (prepare cert request, install cert). And if you guys (the poor dude running the demo at the Seattle launch event had an awful time, too) can't get the cmdlets correct, how in the heck can an already overwhelmed jack of all trades system admin?

*Please* help us out and finish the GUI!

Not applicable

Believe me I empathize with you.  I will personally forward your feedback to the product team.

Not applicable
I've followed the directions to the T in creating a certificate,
I'm going the self signed route, and when I go to import the
cert, I'm getting an error "PrivateKeyMissing".  Anyone run into
this error before?  If so, what can I do about it?
Not applicable
I think it's worth noting that, even though Comodo is listed as an approved SAN Cert provider in KB 929395, their root issuing cert is not among the trusted root certs that ship with Windows Mobile, so if you choose to use their SAN Cert you will be forced to install the CAB file they provide on every Windows-based ActiveSync device that will sync with the server with the Comodo cert. Comodo was at least nice enough to build the CAB file for us. You have to register as a user on their support forum and then you can DL the CAB (it's attached to a post they made in the support forum).

Not applicable
I am using my own internal CA - Please advise Template to use with the certreq command to submit a request for use with E2K7?
Not applicable

The support forums are a better place for your question but it sounds like you didn't check the box to enable the private key to be exportable.


Thanks again for the excellent point.


You don't have to specify a cert template when you request a cert in the shell.  If you are referring to the type of cert to choose on the certsrv website, pick advanced cert request then web server.  Hope that helps.

Not applicable
This just seems to complicated. Our company has set up Exchange 2007 as and have Outlook web access as We got a certificate from GoDaddy for Outlook web access works fine, however all Outlook 2007 clients on the internal network get the certificate error when Outlook is started. What is the simpliest least expensive way to resolve this problem?
Not applicable

Yes, this is complicated and hopefully this will help you.  The cheapest way is to install your own Enterprise CA and issue your own certs.  Send instructions to your users on how to install your CA root certificate in their trusted root store.  All domain joined clients will trust your CA automatically so only remote clients will have the problem.  Be sure when you generate the request file that you inlcude any possible name that a client will use to access your server and be sure to include the autodiscover address as well.  Take your time, follow the steps above and you should be good.  If you still need help use the support forums or open a case with MS Support.
Not applicable

 Jim and I discussed this this morning.  The reason I think this seems over complex is because as I read it you don't have any RPC/HTTP(s) clients.  If this is true and you never plan to have these types of clients your fix that you have in place now is pretty optimal.  All you have to do now is change your Internal URLs to point to  Most of these can be set directly in the Exchange Management Console.  There is one that needs to be set via the Shell directly.  If you have any issues just open a support ticket.  To be clear though, Jim's suggestion is more robust and allows for RPC/HTTP(S) in the future.
Not applicable
I have gone the route of the Alternative 2 posted above in this article.  When I run the test from Outlook 2007 on the domain, I get a success.  However, I get an Error 1013 that returns a 401 Unauthorized when I run test-outlookwebservices on the CAS box.  Is this normal?
Not applicable
Here is the lowdown o the ISA limitation with SAN certificates and the workarounds for ISA itself:
Version history
Last update:
‎Jul 01 2019 03:29 PM
Updated by: