Here's what I think I need to do: assign a CA certificate to services related to ActiveSync while continuing to use the self-signed certificate for internal use. How can I do this? Scenario: Exchange 2010 on Windows 2008, no Edge Server. Internal Windows domain name is myinternaldomain.com (a mistake choosing that years ago apparently). The internal Windows domain name used to be the external domain name, too, but was intetioinally allowed to expire and is now registered elsewhere. Internet (external) domain name of externaldomain.com Cannot get a UCC with the internal Windows domain name since the same name is registered as an Internet domain name to another entity. Have a UCC for externaldomain.com and secondexternaldomain.com. Upon installing the CA certificate, internal Outlook users get the Certificate error message saying "the name on the security certificate is invalid or does not match the name of the site." If I unassign the CA certificate so it no longer is applid to IIS and assign it to the self-signed certificate, the Outlook users don't get that error message. I presume, however, that will cause a problem with ActiveSync, OWA, etc. All of this seems to make sense. But is there a way I can configure Exchange to use the CA cert for external purposes (ActiveSync, OWA, etc) while telling Exchange to use the self-signed certificate for the internal connections? I havent' found any answers that seem to address this issue but much of this is new to me so I'm may just not be recognizing the answer. Thanks. UCC CA certificate

The only way to do that would be to have a separate IIS web site for external access than you use for internal access. It's best to try to use the same certificate for both internal and external access. You've discovered one of the problems with having different internal and external DNS domains. You might consider implementing a split-brain DNS. It makes these kinds of things much easier.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

That's typical that happens when users just get a single name cert and not a ucc cert. But in this case you can't get a ucc cert per se because someone already owns that domain. You need to set all the Exchange services; autodiscover, oab, webservices etc to use the external name on the cert instead of the default internal client cert. Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site" http://support.microsoft.com/kb/940726James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Thank you jamestechman, that was my Plan C. However, I'm still getting the certificate warning in Outlook on the internal computers, so I'm afraid I still don't have something set right. Here's what I did. Set the AutoDiscoverServiceInternalUri to mail.externaldomain.com Recycled the autodiscover pool in the IIS manager And assigned all services to the UCC cert. It appers Outlook is still finding the server name servername.myinternalname.com, that's what is at the top of the cerfificate warning box in Outlook. Any ideas, anyone? Thanks.

Start Outlook. Hold the Ctrl key and click on the Outlook icon in the system tray. Select Test E-mail Autoconfiguration. Enter your e-mail address and domain password, clear the Guessmart checkboxes and then click Test. Post the results here.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

What I do in these situations is order a SAN certificate with shortnames. So you can get a SAN cert with mail.externaldomain.com, and SAN name "autodiscover", and/or "mail". The cert provider should be able to give you a cert with a shortname, because it is not publicly routable, and is only for internal use. Then you can point the Autodiscoverinternaluri to "https://autodiscover. Since the cert has that name on there, you will no longer get certificate errors. You could do the same for internal OWA. Your internal clients will resolve the shortname. This is easily testable as well. Just type your OWA address in your address bar. https://mail/owa. If your dns is setup to allow this (which it most likely is), it will resolve, which means you can acquire a certificate that just has "mail" as a SAN name. If your internal Autodiscover is pointed to your exchange server you can also test by going to https://autodiscover/owa. http://jaworskiblog.com

To be clear, once you have the SAN cert with shortnames "mail" or "autodiscover", you would run Set-ClientAccessServer -Identity CASServerName -AutoDiscoverServiceInternalUri https://mail/Autodiscover/Autodiscover.xml Set-WebServicesVirtualDirectory -Identity “CASServerName\EWS (Default Web Site)” -InternalURL https://mail/EWS/Exchange.asmx -BasicAuthentication:$true http://jaworskiblog.com

That's a reasonable thing to do when you can issue an internal certificate and it's free. But you don't need to spend thousands of dollars on a public certificate with hundreds of SANs. I wouldn't try to use the self-signed certificate for anything other than internal Exchange SMTP traffic that wants to use it. I encourage my customers to build an internal CA and use it for internal certificates and use public certificates for internet-facing purposes when necessary.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Ed, Here is the result of the Test E-mail Autoconfiguration. Interestingly, it references the the Windows (internal domain) name: myinternaldomain.com and a second external domain name (externaldomain2.com) but other than with the userid the first external domain name, which really is the primary Internet domain name and the subject of the UCC cert, doesn't appear. Obviously I've changed the actual URLs to self-defining generic names, although it's too easy to misread myINTERNALdomain.com as myINTERNETdomain.com, which it isn't. <?xml version="1.0" encoding="utf-8" ?> - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> - <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> - <User> <DisplayName>MYUSERID</DisplayName> <LegacyDN>/o=MYORGANIZATION/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=USERID</LegacyDN> <AutoDiscoverSMTPAddress>USERID@EXTERNALDOMAIN.COM</AutoDiscoverSMTPAddress> <DeploymentId>66fb2fae-4dd8-4b47-9b59-3a81b4d15219</DeploymentId> </User> - <Account> <AccountType>email</AccountType> <Action>settings</Action> - <Protocol> <Type>EXCH</Type> <Server>MYSERVERNAME.MYINTERNALDOMAIN.COM</Server> <ServerDN>/o=MYORGANIZATION/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MYSERVERNAME</ServerDN> <ServerVersion>738180DA</ServerVersion> <MdbDN>/o=MYORGANIZATION/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MYSERVERNAME/cn=Microsoft Private MDB</MdbDN> <AD>MYSERVERNAME.MYINTERNALDOMAIN.COM</AD> <ASUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/EWS/Exchange.asmx</EwsUrl> <EcpUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/ecp/</EcpUrl> <EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um> <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr> <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt> <EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret> <EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms> <OOFUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/EWS/Exchange.asmx</OOFUrl> <UMUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/EWS/UM2007Legacy.asmx</UMUrl> <OABUrl>http://MYSERVERNAME.MYINTERNALDOMAIN.COM/OAB/103f2403-3a27-45a9-8802-83027a0457aa/</OABUrl> </Protocol> - <Protocol> <Type>WEB</Type> - <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://MYSERVERNAME.MYINTERNALDOMAIN.COM/owa/</OWAUrl> - <Protocol> <Type>EXCH</Type> <ASUrl>https://MYSERVERNAME.MYINTERNALDOMAIN.COM/EWS/Exchange.asmx</ASUrl> </Protocol> </Internal> - <External> <OWAUrl AuthenticationMethod="Fba">https://mail.EXTERNALDOMAIN2.COM/owa/</OWAUrl> - <Protocol> <Type>EXPR</Type> <ASUrl>https://mail.EXTERNALDOMAIN2.COM/ews/exchange.asmx</ASUrl> </Protocol> </External> </Protocol> </Account> </Response> </Autodiscover>

Thanks Scott, We do have a UCC with the following contents but no shortnames: Subject name CN = EXTERNALDOMAIN.COM OU = Domain Control Validated O = EXTERNALDOMAIN.COM SAN contents: DNS Name=EXTERNALDOMAIN.COM DNS Name=www.EXTERNALDOMAIN.COM DNS Name=mail.EXTERNALDOMAIN.COM DNS Name=autodiscover.EXTERNALDOMAIN.COM With the internalautodiscoveruri set to the externaldomain.com and all services assigned to the UCC, the htts://mail/owa does not resolve but https://mail.externaldomain.com/owa does relsolve. Thanks.

Thank everybody, I think I have discovered my mistake. What is the old saying, RTFM (and I might add, do what it says, since I read it but didn't do everything it said). Looks like I failed t o modify the internalUrL attribute of the EWS. Now having done that so that it also references the externaldoman.com it appears the outlook certificate warning does not come up anymore. Hopefully I haven't caused trouble down the road with this change. Again, folks, thank you very much for your efforts. Sorry to have been too obstinate/distracted/dumb not to have followed the KB article and done this in the first place, or at least the second, without bothering you folks. Ken