<div>
Get -WebServicesVirtualDirecto<wbr />ry |fl indentity, internalurl, externalurl <br />
<a href="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410751/cert-error2.PNG" target="_blank" title="cert error (29 KB)"><img alt="cert error" class="file-block lazyload" style="max-width: 800px;" data-src="https://filedb.experts-exchange.com/incoming/2019/01_w05/800_1410751/cert-error2.PNG" /></a>Is the External Url only used from internal access to external? For example Outlook using it on a client computer on the LAN. While external traffic only uses the 3rd party cert the DNS where AutoDiscovery is configured points to? Trying to understand how this works with the External Url blank. <br />
<br />
My understanding is both directories should be set to <a href="https://remote.clientsdomain.com" rel="ugc">https://remote.clientsdomain.com</a>&nbsp;<br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
Run this and restart IIS?
</div>


cert-error2.PNG

<div>
The external address is the address that is resolved. &nbsp;So with no external address assigned you will not be able to resolve to it.<br />
Make sure that the address that is resolved matches what is in the Cert. Normally you want to purchase a trusted third party SAN cert to address multiple domain names. &nbsp;Your server has an internal address that is pointed to exchange.domainname.local and your Cert does not have this address in the Cert.<br />
<br />
If you click on the View Certificate you will see the chain and it probably is Exchange.domainame.com<br />
<br />
If you change the internal URL address to Exchange.domainame.com and make sure you can resolve this address internally you will most likely be fine. &nbsp;You may have to create a DNS zone for domainname.com and add a A-Record of a CNAME for this address.
</div>


<div>
What version of exchange is this? you can get a publicly signed SSL certificate for ales that ten dollars these days?<br />
<a href="https://www.petenetlive.com/KB/Article/0000036" rel="ugc">Outlook Error “The name of the security certificate is invalid or does not match the name of the site.”</a><br />
<br />
<br />
Pete
</div>


Managed IT Services, Cyber Security, Backup

WORKS2011

<div>
<blockquote>
If you click on the View Certificate you will see the chain and it probably is Exchange.domainame.com
</blockquote>
 it's failing exchange.clientdomain.loca<wbr />l not .com (note - image in original post)<br />
<br />

<blockquote>
Normally you want to purchase a trusted third party SAN cert to address multiple domain names. &nbsp;Your server has an internal address that is pointed to exchange.domainname.local and your Cert does not have this address in the Cert.
</blockquote>
<br />
A UCC\SAN cert was purchased and installed which allows up to 5 names and only three are used. If I rekey the cert and add exchange.clientdomain.loca<wbr />l and/or exchange.clientdomain.com will it disconnect mobile devices that are already connected and these users get a failed cert error? Is it the best resolution? If so there are not that many mobile users. <br />
<br />
My understanding is exchange.clientdomain.loca<wbr />l wasn't necessary for LAN devices to resolve since it's internal to the LAN. <br />
<br />
I don't mind rekeying the cert if it's not going to disconnect or give a cert error to current mobile users. Will make the change if its the best option and needs to be done. <br />
<br />
Is there a way to create a self-signed cert since this is .local and/or use DNS on the server? You mentioned create a CNAME and Host A record.
</div>


<div>
its very unlikely you can add your internal domain to the SSL cert as this practice was ceased several years ago. Very few CAs will allow you to do this and insist all domains on the SSL cert are backed up by public DNS records.<br />
<br />
Just amend your internal addresses as advised and it works as designed.
</div>


<div>
Pete may just rekey the current cert, was hoping not to break current mobile devices. If they don't disconnect or give a cert error then will do this now. Since the failing cert name is exchange.clientdomain.loca<wbr />l do I add this or exchange.clientdomain.com or both. This part is throwing me, the .local I wasn't aware needed to be added to the cert. I've installed certs on other servers and not added the .local and they worked.
</div>


<div>
Steve, setting up the internal DNS now. Is the 2010 article ok for a 2016 Exchange server? I'm assuming so because all the powershell commands work so far for the following. <br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
I tested the get- commands for the internal DNS configuration and assuming set- will work if get- is pulling up information. There's been several warnings in powershell for years some of the commands are changing. Cert errors become a nightmare when they get halfway installed / configured and trying to avoid this. I'm probably too cautious when it comes to certs.
</div>


<div>
Didn't answer this prior, exchange 2016.
</div>


<div>
Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceIntern<wbr />alUri <a href="https://remote.clientdomain.com/autodiscover/autodiscover.xml" rel="ugc">https://remote.clientdomain.com/autodiscover/autodiscover.xml</a>&nbsp;is not working. The get- command remains empty. Any ideas? <br />
<a href="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410764/Screen-Shot-2019-01-29-at-5.51.59-AM.png" target="_blank" title="get command (57 KB)"><img alt="get command" class="file-block lazyload" style="max-width: 800px;" data-src="https://filedb.experts-exchange.com/incoming/2019/01_w05/800_1410764/Screen-Shot-2019-01-29-at-5.51.59-AM.png" /></a>
</div>


Screen-Shot-2019-01-29-at-5.51.59-AM.png

<div>
No indication why the above commands are not working. Tested for the sake of it and the external cert from go daddy with invalid name or name does not match error looking for exchange.clientdomain.loca<wbr />l.<br />
<a href="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410765/Screen-Shot-2019-01-29-at-5.27.39-AM.png" target="_blank" title="cert error (30 KB)"><img alt="cert error" class="file-block lazyload" style="max-width: 406px;" data-src="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410765/Screen-Shot-2019-01-29-at-5.27.39-AM.png" /></a>
</div>


Screen-Shot-2019-01-29-at-5.27.39-AM.png

<div>
<blockquote>
Just amend your internal addresses as advised and it works as designed.
</blockquote>
 Steve any ideas?
</div>


<div>
.local is no longer allowed &nbsp;to be added to SAN certs. <br />
Your best course of action is to change both the internal and external address to be exchange.domain.com and use your public cert that you have for the server.
</div>


<div>
I did this already. <br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
Set-WebServicesVirtualDire<wbr />ctory -Identity “EXCHANGE\EWS (Default Web Site)” -ExternalUrl <a href="https://remote.clientdomain.com/EWS/Exchange.asmx" rel="ugc">https://remote.clientdomain.com/EWS/Exchange.asmx</a>&nbsp;-BasicAuthentication:$true<wbr /><br />
<br />
The DNS settings I configured above are now routing logons to exchange outside and Outlook won't launch new profiles. Assuming this is due to the DNS changes made and the Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceIntern<wbr />alUri <a href="https://remote.clientdomain.com/autodiscover/autodiscover.xml" rel="ugc">https://remote.clientdomain.com/autodiscover/autodiscover.xml</a>&nbsp;not working.<br />
<br />
Good news current Outlook users just get the annoying cert error. Bad news no new profiles can be added to Outlook. I'm assuming deleting the remote.clientdomain.com forward lookup zone will resolve this. <br />
<br />
Am I correct thinking if Set-ClientAccessServer -Identity EXCHANGE -AutoDiscoverServiceIntern<wbr />alUri <a href="https://remote.clientdomain.com/autodiscover/autodiscover.xml" rel="ugc">https://remote.clientdomain.com/autodiscover/autodiscover.xml</a>&nbsp;changes then this should all be resolved? Or should I not focus on this step failing and back out of the DNS configuration route.
</div>


<div>
<blockquote>
You may have to create a DNS zone for domainname.com and add a A-Record of a CNAME for this address.
</blockquote>
yo_bee do you mind clarifying. I configured the zone but haven't made any records, only the default records were created.
</div>


<div>
First thing is that your Active Directory domain relies heavily on DNS and when you create your first Domain Controller it will also create your DNS zone for domain.local if that is what you call the domain. &nbsp;When you join computers to your domain they will register with the DNS server under the domain.local. &nbsp;Now you want to have some control of what IP's are registered with other domains (i.e. exchange.domain.com) so you need to create a new zone that has domain.com. &nbsp;Once this is created you can added a new A-Record for exchange.domain.com and put the internal IP-Address of that server in to the record. &nbsp;Once this is done you should ping it from command prompt and see if it resolves that correct internal IP. &nbsp;You should already have a public DNS record for this same A-Record that points to your public IP issued by your ISP.<br />
<br />
<a href="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410768/DNS.jpg" target="_blank" title="DNS.jpg (80 KB)"><img alt="DNS.jpg" class="file-block lazyload" style="max-width: 756px;" data-src="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410768/DNS.jpg" /></a>
</div>


DNS.jpg

<div>
Going back up a few responses, the reason your set-clientaccessserver seemed not to work is you checked it with a completely wrong attribute. There is no such attribute as autodiscoveryserviceurl. It is autodiscoverserviceinterna<wbr />luri. The correct command to see what is set for your SCP is get-clientaccessserver &lt;servername&gt; | select autodiscoverserviceinterna<wbr />luri. You will need to run this command for each of your servers running CAS. It should be the same result for all servers running CAS<br />
&nbsp; the scp listed is what outlook used internally. You need to be sure your internal clients can resolve the address returned to either your exchange server or the Exchange VIP on your load balancer.<br />
&nbsp; Lastly, you need to make sure this FQDN is listed on your certificate as a SAN name. If you are using a Wildcard cert, it may work. I had no luck with them in the past and use UC certs for exchange exclusively.
</div>


<div>
Outlook anywhere or Outlook client show Security Alert or certificate error , you need to read this article before:<br />
<br />
<a href="http://www.shudnow.net/2013/07/26/outlook-certificate-error-and-autodiscover-domain-com-not-working/?fbclid=IwAR2sKW9nZSABZvbHdpyy2emDVdtJPGKmz2yoPqFWvOjMPcQJ9UBAWshcIU0" rel="ugc">http://www.shudnow.net/2013/07/26/outlook-certificate-error-and-autodiscover-domain-com-not-working/?fbclid=IwAR2sKW9nZSABZvbHdpyy2emDVdtJPGKmz2yoPqFWvOjMPcQJ9UBAWshcIU0</a><br />
<br />
<br />
<br />
Use the <b>Set-ClientAccessService c</b>mdlet to modify settings that are associated with the Client Access server role.<br />
<br />
<a href="https://docs.microsoft.com/en-us/powershell/module/exchange/client-access-servers/set-clientaccessservice?view=exchange-ps" rel="ugc">https://docs.microsoft.com/en-us/powershell/module/exchange/client-access-servers/set-clientaccessservice?view=exchange-ps</a>
</div>


<div>
Sorry for not responding, caught up on other stuff.<br />
<br />

<blockquote>
Is the 2010 article ok for a 2016 Exchange server?
</blockquote>
 yes but bets to use the right one now we know which Exch version you're on:<br />
<a href="http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2016/" rel="ugc">http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2016/</a><br />
<br />
Basically, you should set the internal &amp;&nbsp;external URls to use the external domain so they work with your SSL cert.<br />
E.G <br />
<b>Old:</b><br />
&nbsp; &nbsp;External: mail.company.com/&lt;various Exchange URLs&gt;<br />
&nbsp; &nbsp;Internal: server.internalDomain.loca<wbr />l/&lt;various<wbr /> Exchange URLs&gt;<br />
<b>Becomes</b><br />
&nbsp; &nbsp;External: mail.company.com/&lt;various Exchange URLs&gt;<br />
&nbsp; &nbsp;internal: mail.company.com/&lt;various Exchange URLs&gt;<br />
<br />
to prevent unnecessary traffic going out over your routers, you should also create an internal DNS entry (or zone, depending on your setup) to direct mail.company.com to your Exchanges internal IP.
</div>


<div>
I did everything the thread requested and for whatever reason continued to have issues. I was pressed for time so I opened a live session here and the problem was resolved. I would like to mention the tech that helped me during the live session but can't find this setting in EE, would someone please point it to me. <br />
<br />
Thank you.
</div>


<div>
No the problem was resolved after I paid an EE for live support and for the life of me I can't remember who it was. I also can't find the transaction in EE and why I'm asking how to go about finding this information.
</div>


<div>
Thank you for everyone that helped on this. Was a combination of reading older information and somehow combined with missing information on the Exchange server. Maybe going to fast and simply overlooking details. We found an internal URL incorrectly configured and had to make an additional DNS entry. As mentioned I also had an EE tech take a look and this is the work that was performed. Sorry for the delay it's been a busy month. Thanks again for all the help.
</div>


<div>
<div class="content wysiwyg-content">
Cert error opening Outlook internal (LAN) all Outlook clients. External auto-discovery works fine. <br />
<a href="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410750/cert-error.PNG" target="_blank" title="cert error (15 KB)"><img alt="cert error" class="file-block lazyload" style="max-width: 377px;" data-src="https://filedb.experts-exchange.com/incoming/2019/01_w05/1410750/cert-error.PNG" /></a>
</div>
</div>


cert-error.PNG

Cert error opening Outlook internal (LAN) all Outlook clients. External auto-discovery works fine. 


The name on the security certificate is invalid or does not match the name on the site

Exchange is the server side of a collaborative application product that is part of the Microsoft Server infrastructure. Exchange's major features include email, calendaring, contacts and tasks, support for mobile and web-based access to information, and support for data storage.

Exchange

Microsoft Outlook is a personal information manager from Microsoft, available as a part of the Microsoft Office suite. Although often used mainly as an email application, it also includes a calendar, task manager, contact manager, note-taker, journal, and web browser.

Outlook

Within Internet message handling services (MHS), a message transfer agent or mail transfer agent (MTA) or mail relay is software that transfers electronic mail messages from one computer to another using a client–server application architecture. A MTA implements both the client (sending) and server (receiving) portions of the Simple Mail Transfer Protocol (SMTP). The terms mail server, mail exchanger, and MX host may also refer to a computer performing the MTA function. The Domain Name System (DNS) associates a mail server to a domain with mail exchanger (MX) resource records containing the domain name of a host providing MTA services.