After installing Exchange Server 2016 into your organization you may receive reports from your end users of a security alert containing certificate warning messages appearing in Outlook.
The two most common problems reported by the Outlook certificate warning message are:
- The name on the security certificate is invalid or does not match the name of the site
- The security certificate was issued by a company you have not chosen to trust
Why Does Outlook Display a Security Warning for a Certificate Problem?
When you install Exchange Server 2016 into your Active Directory environment the setup process registers a Service Connection Point (SCP) for the Autodiscover service. Autodiscover is used by client applications to discover information about Exchange mailboxes and services. For example, Outlook uses Autodiscover during the setup of a new Outlook profile to discover the server settings for the user, so that the profile can be automatically configured (instead of the old days of manually entering server names and other details into Outlook).
By default the Autodiscover SCP is registered using a URL that includes the Exchange server’s fully-qualified domain name. You can see the Autodiscover URL for an Exchange 2016 server by running the Get-ClientAccessService cmdlet in the Exchange Management Shell. For example:
[PS] C:\>Get-ClientAccessService -Identity EXSERVER | Select AutodiscoverServiceInternalUri AutoDiscoverServiceInternalUri ------------------------------ https://exserver.exchange2016demo.com/Autodiscover/Autodiscover.xml
Note: Previous versions of Exchange used the Get-ClientAccessServer cmdlet. With the changes in Exchange 2016 server roles architecture the new cmdlets for these management tasks are *-ClientAccessService. The old cmdlets are still available in Exchange 2016, but if you use them you will see a warning message that they are deprecated.
Autodiscover is accessible via an HTTPS (SSL) connection from clients. The Exchange server also has a number of other web services that are accessible using HTTPS connections from clients, such as Exchange Web Services (EWS), Outlook on the web (also known as OWA), ActiveSync (for mobile devices), and Outlook Anywhere (used by Outlook clients).
As the connection is over HTTPS the SSL certificate configured on the server must meet three criteria to be considered valid by the client:
- The certificate was issued by a trusted certificate authority (CA)
- The certificate has not expired
- The name on the certificate matches the server name (or URL) that the client is connecting to
How to Fix Outlook Security Warnings After Installing Exchange 2016
There are two parts to the solution:
- Configure the Autodiscover URL for the service
- Install a valid SSL certificate
Configuring the Autodiscover URL for Exchange 2016
It is not recommended to leave the Autodiscover URL configured with the server’s fully-qualified domain name. Instead, you should configure it to use a different DNS name or alias. This is part of your overall Client Access namespace planning for Exchange 2016.
In this example I will change the Autodiscover URL to use the DNS name of mail.exchange2016demo.com.
[PS] C:\>Set-ClientAccessService -Identity EXSERVER -AutoDiscoverServiceInternalUri https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml
You also need to add a DNS record for the namespace if one does not already exist. In this example I add an A record of “mail” to my internal DNS zone, and point it to the IP address of the Exchange 2016 server (because it is the only server in the organization). If you have multiple Exchange servers then either DNS round robin or a load balancer could be used instead.
Install a Valid SSL Certificate
With the namespaces correctly configured, and DNS records in place, you will then need to provision an SSL certificate for the Exchange 2016 server. If this is a new concept for you then I recommend some additional reading:
To provision an SSL certificate for your Exchange 2016 server the process is:
- Create a certificate signing request (CSR)
- Submit the CSR to a certificate authority such as Digicert
- Complete the pending certificate request on the Exchange server
- Enable the SSL certificate for Exchange services
Summary
The common causes of Outlook security alerts containing certificate warnings are misconfigured Exchange server namespaces, and invalid SSL certificates. Using the steps demonstrated above you can reconfigure your namespaces and/or install a valid SSL certificate. When your Exchange server’s configuration has been corrected the Outlook security alerts should stop appearing for your end users.
Great article Paul, thanks! I spent 2 days trying to fix this. Now I found your helpful suggestions I fixed it.
Richard.
Hi Paul,
Just a quick update on this. When I ran your script on exchange 2019 I got the following warning.
WARNING: The Set-ClientAccessServer cmdlet will be removed in a future version of Exchange. Use the Set-ClientAccessService cmdlet instead. If you have any scripts that use the Set-ClientAccessServer cmdlet, update them to use the Set-ClientAccessService cmdlet. For more information, see http://go.microsoft.com/fwlink/p/?LinkId=254711.
Hi Paul,
You adviced to use a SAN certificate instead of an wildcard.
I re-used the wildcard cert from the previous server. all namespaces are correct, also all dns records are present and resolvable.
but still internal Outlook users gets the certificate warning from the internal servername. when you check the connectionsettings it points to the correct namespace. (mail.domein.nl)
could the warning be displayed because of the wildcard certificate?
For legacy reasons, we are stuck with a .local internal DNS name. You said in a comment above to “Use split DNS to control where it resolves to for internal vs external clients”. We have Exchange 2019 up-and-running; how do I stop the certificate error coming up every time Outlook 2019 starts? Our external domain name has a valid GoDaddy certificate which I’ve imported into Exchange and the OWA works fine from an internet connected PC as do iPhones connecting to Exchange, but the domain PCs throw up an error every time because “The name on the security certificate is invalid or does not match the name of the site”.
Our internal Exchange server name is like this…
fbvexch.domain.local
Our external domain for OWA is like this…
remote.domain.co.uk
this resolves to the internet address of our SonicWALL firewall that routes the traffic through to the IP address of the Exchange server.
#desperatecryforhelp #willhavelotsofgrumpyusers
Hi Phil,
From my understanding, you cannot include any “.local” domain names in SSL certs anymore. Folks used to include them in the SAN field of the certificate (a security risk).
You could use DNS to control the resolution I believe if you setup a DNS forwarding zone (and it’s corresponding reverse lookup zone). Basically, the additional DNS forward zone will route DNS lookups of “.local” to whatever you specify. Basically, the DNS lookup for “.local” will go out your firewall and then back in, where it will routed appropriately, just like all other external users.
Just to add to and clarify this answer, you can add a forward lookup zone of external.com in your internal Windows DNS servers, and then add an A record for mail.external.com in the forward lookup zone, pointing at your internal server IP address. This way when clients locally lookup mail.external.com they are instead returned the INTERNAL IP of your mail server. Since they are requesting the DNS name mail.external.com, the certificate is valid. As long as your internal URL is the same as the external, the clients won’t be asking for the server.internal.local address, because the SCP specifies the external DNS name, and the Autodiscover will too.
The trick is to use the cert for your external namespace by using the external namespace internally, by adding that namespace as a new forward lookup zone in your on-premise DNS. Optionally if you use the router for DNS, add another conditional rule which points at the internal DNS server for your external domain name.
The problem you will have is when you change web server, you need to remember to update the www record in you internal DNS as well.
Thank you very much for all articles. You are the best!
Paul,
I think the most common mistake is that most of the people don’t change the Clietnaccess Server settings on the 2010 server to point to the New Exchange serverand that’s why they get the Certificate warning
i.e (As your settings)
set-clientaccessserver -identity EXHANGE2010 -AutoDiscoverServiceInternalUri https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml
Bingo. thanks!
Hello Paul,
Great article. I would like to know whether after installing Exchange 2016 in the existing Exchange 2013 setup, Can I use a two different DNS name space for autodiscover and outlook anywhere.
For e.g Exchange 2013 using DNS alias host.xyz.com and Exchange 2016 using host2.xyz.com.
In short can I have few users connecting to Exchange 2013 and other users connecting to Exchange 2016 in Coexistence setup.
Hi Paul,
My name is harvey email ID harvey_srivastava@oculusit.com I have a client where his whole infrastructure is setup on plnmail.pln.local he never had a third party cert nor a CA in his infrastructure. I purchased a SAN certificate that has 5 sites mail.paralosninos.org, autodiscover.paralosninos.org, webmail.paralosninos.org to connect to owa we use mail.paralosninos.org I amend this cert post which I was getting an invalid cert prompt in outlook I deleted the a record under pln local and used split domain mail.paralosninos.org and autodiscover.paralosninos.org and in the exchange # the host file for pln mail and plnmail.pln.local and created 2 new entries pointing to mail.paralosninos.org and autodiscover.paraloeninios.org post which on a terminal server I changed the clientaccessservice and the corresponding urls for oab,ecp,webservicesvirtualdirectory to mail.paralosninos.org wherein it works in the owa,handheld devices and outlook on the terminal server now there are 14 different sites where user machines are there outlook does not work on any of my sites there is no blockage at the firewall.
Now if I create a a record under pln.local pointing to my exchnage server it works on all the sites but I keep getting the invalid cert prompt from plnmail.pln.local
I did autodiacoverapplicationpool recycle created new outlook profile tested in different machines no luck.
Currently no help from anyone request you to please contact me on my email address
Paul, thx for your article.
Can you help me in configuring namespaces for our Exchange?
We have domainname kalina.ru, Windows Server AD with name b26.kalina.ru. Exchange Server with name forth.b26.kalina.ru.
InternalURLs configured to mail.kalina.ru and extrenalURLs to kalina.ru
mail.kalina.ru is CNAME forth.b26.kalina.ru and when users in office launch Outlook they got warning about certificate (name mismatch forth.b26.kalina.ru), which issued by Geotrust to *kalina.ru and kalina.ru.
When users connect via browser to https://mail.kalina.ru/owa – certificate shows as valid, with green lock.
DNS server has 2 zones: kalina.ru and b26.kalina.ru
For kalina.ru we use next data:
SOA: kalina.ru
A: external IP
MX: kalina.ru
autodiscover CNAME mail.kalina.ru
mail CNAME forth.b26.kalina.ru
mx: external IP
Can you explain how to properly configure the DNS records so that we do not receive a certificate warning?
Thank you.
That sounds to me like you have not configured all of the namespaces correctly. I recommend you read this article: https://www.practical365.com/exchange-server/avoiding-exchange-2013-server-names-ssl-certificates/
Thanks Paul, yes we will be installing a valid third party cert for migrations so makes sense to just go all the way through and get them setup seamlessly.
We will be installing 3 new 2016 Exchange servers that will only be used for the migration of mailboxes to Office 365 so we can achieve greater throughput. They will never be used in the production Exchange environment going forward. Is there a recommended best practice during install or config to avoid these servers ever being used for Autodiscover services and the certificate prompts? If all Exchange traffic hits a load balancer first which directs traffic to the production servers can we just change the internalURI and be done with it?
Depends what your existing environment looks like. But also keep in mind that if these servers are going to be migration endpoints for your EXO migration, they’ll need a valid third party cert installed anyway.
Personally I would set them up to work as seamlessly as possible in co-existence so that there’s less risk of unexpected issues.
I had an exchange server failure this past weekend. I have rebuilt the server. I was able to get the DAG reconfigured and the DB’s in the DAG. All is good there. Now I am getting a certificate error so I noticed the certificate is assigned to the server that existed already but it is missing from the newly formatted and installed server. I have tried to export and import the certificate from the original server but I keep getting this error.
A special Rpc error occurs on server XCH02: Cannot import certificate. A certificate with the thumbprint FCBF254E775FC90925ED5AD997DC90503C02234A already exists.
I am not sure where to go with this and was wondering if you could pleas offer me some assistance.
Anything is greatly appreciated.
Scott
Here I am always jumping the gun. I got it figured out. I had to remove the certificate from the certificate mmc console and then it let me add it. I am not sure how that got there but it is all fixed now.
This helped me fix my SMTP TLS Certificate Error thanks. However still having and issue I have a split dns name domain.work / domain.internal for our email addresses. The Server’s actual name is exchange1.domain.work and that’s not matching the wild card certificate used which causes an error. The Security Alerts pops up with exchange1.domain.work at the top and when I view the cert its using my wildcard domain.com one which is correct how do I fix this?
Great articles. But I did not find a solution to my issue.
After installing two servers, Server 2016/AD/DNS and Server 2016/Echange 2016 CU7, and configured and tested that I could send and receive email. I then made what I think now is the blunder. I renamed the Exchange server to follow a name standard, from SD-EX-01 to SD-EX-001.
After this I can’t log in with https://localhost/ecp or …/owa anymore (also not the host or fqdn).
When I look at the certificate when I get the warning, I see it has SD-EX-01 and not the new name in it. I seem stuck.
Any suggestions how to proceed or do I reinstall?
Thanks
It’s not supported to rename a server after installing Exchange, and that most certainly will break it. At this stage I recommend you treat it as a failed server and do a recovery install.
https://www.practical365.com/exchange-server/recovering-a-failed-exchange-server-2016-server/
I presented a new Ex2016 server and already changed the AutodiscoverServiceURI to https://company.com/Autodiscover/Autodiscover.xml and Outlook keep protesting for the certificate.
Strangely enough, the security alert “View Certificate” button shows the right * certificate but the error message shows the server FQDN.
X The name on the security cert is invalid or does not match…..
Am I missing something else?
Did you also configure the rest of the client access namespaces?
No, that was certainly the issue.
I was missing EWS, ActiveSync and the other websites.
Thanks Paul.
Hi Paul
Thanks for all the good content and info across your whole site.
Im in the middle of an upgrade from 2010 to 2016 and having teething issues. 2010 was not installed perfectly. The virtual directories and autodiscover are set to the server names along with a few other config’s I dont know are right or not. Anyway
I am getting the certificate issue for a user on the 2016 server. the cert is SSL form GoDaddy and has the mail domain name. I had to export this from the old 2010 server and import to the new. Per Microsoft instructions, the cert on the Exchange server when viewed has the certificate authorises in the chain as expected. However when you go view the cert from outlook error it does not contain the chain just the email domain. so it states it does not trust the provider.
It was installed correctly and added to all the services including mapi so a bit stuck.
Passed that outlook cant find the server. I put in a host file to point email.domain to the new exchange and autodiscover.domain.com to new exchange but no luck
Cheers for any advice
Sean
Do the clients have any issues with that cert when they connect to the Exchange 2010 server?
Hi Paul
Thanks for replying.
So yes clients connecting to the 2010 exchange get a cert error. Now i put this down to the fact that the virt directories were never configured to the name on the cert. They were left as the server name. My thinking was to leave that as is, I set the correct name on the virt directories on the new exchange and then could right away point the dns record at the new exchange.
Here is were I am.
Outlook 2010 clients connect to the new exchange with a proxy error code 10 but still work. Outlook 2013 clients cant find the server. So it must be security related, but in essence autodiscover is failing?
I have changed the virt directories back to the server name as if I use a machine with a host file pointing mail domain to the new exchange not even the 2010 clients can connect to it.
So as a general rule I fix any namespace issues with the existing environment before I proceed with install or migration to a new version. It makes the co-existence period seamless if you fix the existing problems first.
I fixed everything got everything smooth except the outlook connection. After a few hours of frustration I found it was the proxy settings intercepting the connection. Even though bypass local addresses was set and the mail domain was in the advanced exceptions list.
Thanks for the replies Paul
Hi Paul,
My reply gets deleted. Can you please tell me why.
Thanks,
Amjad
Hi Paul, I tried to put some comments but i believe bcz of ip address and other configuration they get removed. I am following guidance given under techgenix and a guy tried to explain everything but i am stuck at this point.
so this is what i will be doing. after installing exchange 2013 with 2007. i will be creating following namespaces :
Exchange 2007 has Ip address: x.x.x.3
for exchange 2007:A record for mail.domain.com x.x.x.3
for exchange 2007:A record for Autodiscovery.domian.com x.x.x.3
for exchange 2013:A record for legacy.domain.com x.x.x.3
new exchange 2013: x.x.x.93
for exchange 2013:A record for mail.domain.com x.x.x.93
for exchange 2013:A record for Autodiscovery. domian.com x.x.x.93
i read some of your guidance documents , not sure but do i have to remove first two A records for Exchange 2007 and leave all others on Domain Controller.
one more thing to mention. Autodiscover.mydomain.com name space was not configured on exchange 2007 previously. it was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS:
Get-ClientAccessServer -Identity SPC-EXCH1 | fl AutoDiscoverServiceInternalURI
output was: https://spc-exch1.stpeters.int/Autodiscover/Autodiscover.xml
so i believe it has not been configured properly . i plan to change it
Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007.
Hopefully this time my comments will go through. as i removed all ip address .
Thanks,
Amjad
I think you should engage a consultant for this work. Your Exchange 2007 environment is not set up correctly in the first place, so that needs to be fixed first before you can plan the upgrade. A consultant can review your environment and recommend a course of action to resolve the current issues and perform the upgrade.
There’s only so much advice I can give you based on bits of info in your comments.
one more thing to mention. Autodiscover.domain.sk.ca name space was not configured for exchange 2007 on Domian controller previously. it was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS:
Get-ClientAccessServer -Identity SPC-EXCH1 | fl AutoDiscoverServiceInternalURI
output was: https://spc-exch1.stpeters.int/Autodiscover/Au
todiscover.xml
so i believe it has not been configured properly . i plan to change it
Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI https://autodiscover.domain.sk.ca/Autodiscover/Autodiscover.xml
will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007.
Thanks,
Thanks a lot Paul, do i have to configure them on Exchange 2007 ? or 13.
Please let me know .
Thanks
Both. What guidance are you following for this migration? The steps are documented on the Exchange Deployment Assistant that is available on TechNet.
Thanks for replying.
I am following guidance given under this link
http://techgenix.com/planning-and-migrating-small-organization-exchange-2007-2013-part1/
so this is what i will be doing. after installing exchange 2013 with 2007. i will be creating following namespaces :
Exchange 2007 has Ip address: 172.16.90.3
for exchange 2007:A record for mail.domain.sk.ca 172.16.90.3
for exchange 2007:A record for Autodiscovery.domian.sk.ca 172.16.90.3
for exchange 2013:A record for legacy.domain.sk.ca 172.16.90.3
new exchange 2013: 172.16.90.93
for exchange 2013:A record for mail.domain.sk.ca 172.16.90.93
for exchange 2013:A record for Autodiscovery.domian.sk.ca 172.16.90.93
i read some of your guidance documents , not sure but do i have to remove first two A records for Exchange 2007 and leave all others on Domain Controller.
Thanks,
Amjad
one more thing to mention. Autodiscover.domain.sk.ca name space was not configured on exchange 2007 previously. it was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS:
Get-ClientAccessServer -Identity SPC-EXCH1 | fl AutoDiscoverServiceInternalURI
output was: https://spc-exch1.stpeters.int/Autodiscover/Au
todiscover.xml
so i believe it has not been configured properly . i plan to change it
Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI https://autodiscover.domain.sk.ca/Autodiscover/Autodiscover.xml
will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007.
Thanks,
just forgot to mention that i have not done any settings in Virtual directory (except one ) do i have to do those one first ? because i configured OWA internal url and external Url and after that OWA is appearing in Certificate menu with right domain name.
Thanks,
Amjad
Yes you need to set up your namespaces first.
Hi,
I have exchange 2007 and installed new exchange 2013. i am having Trouble in certificates assignment. when i am going to ECP on server 2013 it is showing me only local domain and no other domain. Any idea what should i do. previously we were using self assigned certificates and now i plan to use third party certificates. what thing i need to consider.
Thanks in advance for your help.
Amjad
A little more on the Cert warning that people often get.
We are receiving in Mac Outlook a cert warning for the DNS Domain Name. “exchange.DNSdomain.com” but this is listed only as an internal name. Exchange users “exchange.mailDomains.com” for auto discover in DNS and as configured on the exchange server.
Why would outlook keep hunting for a secure connection to the “exchange.DNSdomain.com” when it is not external used?
How is it even picking this up when the DNS Auto discover setings are correctly set and tested with the connectivity test website?
Sorry.. I messed up my post here. I intended to write not “exchange.DNSdomain.com” but “autodiscover.ADdomain.com” The issue is that outlook keeps hunting a secure connection to the Active Directory Domain name url. Not as posted above with “exchange.DNSdomain.com”
(sorry long day)
Outlook checks for Autodiscover in a number of different ways. One of them is by looking for the well known CNAME of “autodiscover”. If that resolves in DNS, it will try to connect.
You can suppress that lookup using Group Policy. Or you can remove the DNS record (but that might break other clients relying on it).
The other possibility is that your CAS Autodiscover Internal URI is set to that URL. That will not be tested by the connectivity analyzer, because it’s only testing externally and can’t see the Autodiscover SCP that is used inside your domain. So you should check that as well.
Update – Resolved the issue by following the article:
https://support.microsoft.com/en-in/help/3073002/after-migration-to-office-365,-outlook-doesn-t-connect-or-web-services-don-t-work
I had to apply both methods to resolve the issue. Just changing the registry did not do the trick. In Method 2, I didn’t have to use the new profile after creating it. Just adding it was enough.
The article’s title suggests the solution is for Office365 and it does not mention the Security Alert message. Though, in my case, we have Exchange 2016 and machines were getting invalid name security alert. So the solution works for in-house Exchange as well.
Excellent article! I have read it several times to match the settings on my Server 2016. Though, Outlook is still generating the error: serv2016.xyz2.local The name on the ……
Server is the domain controller + DNS +Exchange
My local domain name is xyz2.local but actual email domain name is xyz.com. Autodiscover and OWA work from outside. On the SSL, I have:
autodiscover.xyz.com
xyz.com
email.xyz.com
DNS on the server has:
email (Host A) (FQDN: email.xyz2.local) pointing to server’s private IP
Any suggestion will be much appreciated. Thanks.
Hi Paul,
I’m having issues with Outlook 2016 after upgrading from 2013. I had to add AutoDiscover (autodicover.domain.com) to our External DNS in order for 2016 to get the mail profile. The mail server used to be remote.domain.com. The DNS entry is still there but outlook is looking for remote.domain.com and the cert displays autodiscover.domain.com. I understand that they don’t match and I’m getting the “The name on the security certificate is invalid or does not match the name of the site” warning when launching outlook.
Do you know of a way I can remedy this? Installing the self-signed certificate is not working correctly.
Thanks in advance!
If these are internal Outlook clients, you should be configuring the AutodiscoverServiceInternalUri as demonstrated in the article. Whatever name you choose (autodiscover.domain.com is fine) then needs an entry in DNS pointing to your Exchange server (or load balancer if you’ve got multiple servers), and the SSL certificate must include that name.
Also just to add, if you’ve got Autodiscover configured correctly don’t forget that all the other namespaces on the server also need to be configured.
https://www.practical365.com/exchange-server-2016-client-access-namespace-configuration/
Having trouble getting my certificate warning to go away and outlook anywhere working properly. My local domain is internal we will say exchange.contoso.internal. I have a FQDN mail.contoso.com that is signed to that domain and also autodiscover.contoso.com. Local clients still get a certificate warning pointing to exchange.contoso.internal after running your powershell script on exchange 2016. In DNS I have authority setup for contoso.com and have an a record for mail.contoso.com pointing to my internal IP of exchange (also one for autodiscover.contoso.com). OWA works from outside and in, mail is flowing. Local outlook clients work fine except for the cert warning. After running the script some outlook clients have troubles connecting, they continually ask for a password even after providing the correct credentials.
Did you install a certificate?
Which versions of Exchange are running in the organization?
Hello Paul
First of all, thanks for a great article! As always you make things brilliantly easy to understand.
I have question which I hope you will find time to reply to.
I’m planning to install Exchange 2016 into an existing Exchange 2010 organization which consists of one server only. However, I don’t plan to configure anything else (routing, connectors, etc.) on Exchange 2016 for some months.
Question is – will just installing Exchange 2016 to leave it alone without configuration – affect the existing autodiscover/Outlook Anywhere functionality?
Thanks in advance. Have a nice day.
I would question why you’re installing it months before you need it. It’ll always be a thing sitting there that you need to maintain and think about any time there’s a troubleshooting scenario.
As long as you get the Autodiscover config set, yes.
outlook will not let me get in to my e-mail account-says over and over some security error just keeps popping up for last 36 hours – how do I read my e-mails — they are piling up ? why ami blocked?
Call your IT Help Desk, they can help you.
Hello,
I have a disk consumption issue. After installing Exchange Server 2016 and configuring all everything correctly, my HDD is being consumed at a very fast rate, like a partition of 320GB shrunk to 60GB the following morning but after doing some checks found in C:windowstemp some .tmp files being created at a very fast rate.
Please help because cant get to know whats causing all these files to be created at that very fast rate.
hi,
first of all thanks so much for great articles.
I’ve recently installed an Exchange 2016, with multi tenancy.
Assume I have 2 domain: DoaminA.com and DomainB.com. Now how am I supposed to configure autodiscover URI?
I have 2 accepted domain, so I created 2 SRV record instead of “autodiscover.DomainA.com” and “autodiscover.DomainB.com”.But I don’t have any valid SSL yet.
the problem is people can’t connect to exchange through outlook 🙁 it’s ok with IOS Mail application though!
any help would be really great
thanks in advanced
TechNet has documentation for this.
Paul,
I purchased your guide and have read this section over and over but I’m still confused. Here’s my scenario:
Single Exchange 2010 server with autodiscover as https://exchange2010server.domain.com/Autodiscover/Autodiscover.xml.
I want to make the new uri: https://autodiscover.domain.com/Autodiscover/Autodiscover.xml, as I don’t want to include that “exchange2010server” name in the new 2013 cert. The name autodiscover.domain.com is already a part of the existing cert as well.
Since the new 2013 servers are in the same data center, should I still follow your advice: “This means that using the same Autodiscover SCP URL for the new servers, so it matches the Autodiscover SCP URL of the existing servers, is the best approach.”
I’m considered changing the 2010 uri to match what we will be using for the new uri, but I’m not sure how Outlook clients will react to that.
Thanks in advance for your help.
Hi,
I have a very weird problem. I am running 2 x Win2012 servers with Exchange 2016 CU1, in DAG configuration with kemp loadbalancer in front. I have a valid SSL certificate from COMODO, which is installed on both servers and all services are assigned to it. Now, when I open from browser ECP – the connection is secured and I get green bar. However when I open the same URL but OWA, the bar is green only up to the login screen. Once done, when all mails are displayed, the connection becomes unsecured displaying a self signed certificate is used, which is not even installed or visible through the management center. The configuration:
[PS] C:Windowssystem32>Get-ExchangeCertificate -Server Exchange
Thumbprint Services Subject
———- ——– ——-
XXXXXXXXXXXXXXXXXXXXXXXXXXXX IP.WS.. CN=mail.domain.be, OU=PositiveSSL Multi-Domain, OU=Domain …
XXXXXXXXXXXXXXXXXXXXXXXXXX ……. CN=WMSvc-EXCHANGE
Does the self-signed certificate have one of the Exchange servers names on it, or the load balancers name? What happens if you bypass the load balancer?
Hi Paul. I am pulling at my hair at this one. I have a 2016 server that has been up and running for a while. All of the users are local to the Exchange server, although one of them has a laptop and she goes out of the office with it. So far all has been good. I now have a new user who’s laptop is not in the office and every time we try to set up a profile in Outlook 2010, we get the certificate warning “The name on the security certificate is invalid or does not match the name of the site”
Generally, the way I understand this, you would get this warning if the Exchange URLs were not set up correctly, or if the name on the certificate differed in some way. But that is not the case here, or at least I do not think it is.
Here is some information:
First off, I used your ConfigureExchangeURLs script to set up this server. I used “webmail.company.org” when I configured. Here is the output for GetExchangeURLs.ps1:
Outlook Anywhere
– Internal: webmail.company.org
– External: webmail.company.org
Outlook Web App
– Internal: https://webmail.company.org/owa
– External: https://webmail.company.org/exchange
Exchange Control Panel
– Internal: https://webmail.company.org/ecp
– External: https://webmail.company.org/ecp
Offline Address Book
– Internal: https://webmail.company.org/OAB
– External: https://webmail.company.org/OAB
Exchange Web Services
– Internal: https://webmail.company.org/EWS/Exchange.asmx
– External: https://webmail.company.org/EWS/Exchange.asmx
MAPI
– Internal: https://webmail.company.org/mapi
– External: https://webmail.company.org/mapi
ActiveSync
– Internal: https://webmail.company.org/Microsoft-Server-ActiveSync
– External: https://webmail.company.org/Microsoft-Server-ActiveSync
Autodiscover
– Internal SCP: https://webmail.company.org/Autodiscover/Autodiscover.xml
My certificate subject alternative name is webmail.company.org. Here is the results of CertificateReport.ps1 (in raw HTML):
BODY{font-family: Arial; font-size: 10pt;}
H1{font-size: 16px;}
H2{font-size: 14px;}
H3{font-size: 12px;}
TABLE{border: 1px solid black; border-collapse: collapse; font-size: 10pt;}
TH{border: 1px solid black; background: #dddddd; padding: 5px; color: #000000;}
TD{border: 1px solid black; padding: 5px; }
td.pass{background: #7FFF00;}
td.warn{background: #FFE600;}
td.fail{background: #FF0000; color: #ffffff;}
td.info{background: #85D4FF;}
Exchange Server 2010 Certificate ReportServer: Company01 (Mailbox, ClientAccess) SubjectStatusExpiresSelf SignedIssuerSMTPIISPOPIMAPUMThumbprintDomains Microsoft Exchange Server Auth CertificateValid12/1/2020YesMicrosoft Exchange Server Auth CertificateYesD2633048B7DF7186E041D3422149031084E09704 Company01Valid12/28/2020YesCompany01YesYesYesYesB3D92CD0890421FACE42E5A7D8D5AFC50B9ABAF6Company01, Company01.Company.LOCAL WMSvc-Company01Valid12/25/2025YesWMSvc-Company01A6F66D793846442B86B419055A8D054474990911WMSvc-Company01 webmail.company.orgValid8/1/2017NoGo Daddy Secure Certificate Authority – G2YesYesF754A761393996055EA145D838233E0CCDC342E0webmail.company.org, http://www.webmail.company.org
I cannot figure out why this person (and I have the same issue using Outlook 2016 from my home office) gets the certificate warning. Any help you can give me would be appreciated.
Phil Goldwasser
I am in the process of migrating from 2010 to 2016. I moved over a few mailboxes, and then I started receiving an error.
“There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the target site FQDN of my server.
Outlook is unable to connect to the proxy server. (Error Code 10)
The strange thing is that half of the users I have migrated work without any issues. In addition, any NEW users connect with no issues either.
I can just click ok to the error, and everything still works, but its annoying and I would like to resolve this prior to completing the migration. Any ideas?
What have you looked at so far?
Another important consideration when you run into this issue after installing a 2016 server in your environment is MAPI over HTTP. When you install the first 2016 server MAPI over HTTP is enabled and if the new 2016 server which is a CAS by default resides in the same site as your old CAS server it will proxy and server clients. When we encountered this issue after installing our first 2016 server we corrected the issue by fixing the MAPI VD internal and external URLS to use our DNS alias which resolved the issue for us.
Configuring the namespaces for all services (including MAPI) should be one of the first steps anyway.
Hi Paul
I do your article step by step but after installing Exchange 2016 and set valid certificate SSL warning appear and also repeatedly need user name and password
What does the certificate warning say? It will tell you the name that the Outlook client is trying to connect to, as well as the reason the certificate warning has appeared.
hi,
yes but in local name format mail.domain.local
I don’t understand your answer.
If you think the certificate warning shows that the client is trying to connect to the wrong server name, you should check all your Exchange namespaces to make sure you’ve configured the internal and external URLs correctly.
Hi, paul. I have the same problem with my Exchange 2016, the first of all I’d like to thank you for your greate arcticles about Exchange. So I’ve got a problem with autodiscover in internal network. I installed 2 mailbox servers and 2 Edge in DMZ. I created DAG and included 2 servers, it is assigned IP and FQDN for DAG. I use 2013 outlook and then i try to connect to exchange the connection is fail. Appears the window “The action can not be completed. The connection to Microsoft Exchange is Unavailable … ” I’m sad. I read your article and took decision to create in my internal DNS CNAME record “Mail” for target host of DAG. I created new certificate in my local certification authority and impoted him to both servers. The certificate has SAN. There are two records in SAN field such as autodiscover.domain.ru and mail.domain.ru. All virtual directory in both servers I change to https://mail.domain.ru/owa , ecp, and etc . I executed the command:
Get-ClientAccessServer | AutoDiscoverServiceInternalUri
the result of command is displayed for both servers:
AutoDiscoverServiceInternalUri https://mail.domain.ru/Autodiscover/Autodiscover.xml
For Outlookanywhere I assigned mail.domain.ru for both servers as well.
As I know in previous version of Exchange we have to change Cas server to FQDN CassArray Name or Alias in mailbox setings . I mean we should run command Set-MailboxDatabase -RpcClientAccessServer , but the commant as I know occur with error.
Paul, sorry for my long story. Do you have any ideas what I have to do?
May be I should create Cname records for FQDN the both servers and include them in certificate?
1. The Client Access namespaces should not resolve to the DAG IP. They should resolve to the Mailbox server IP address, or to the load balanced VIP. If you’re not using a load-balancer then you can use DNS round robin instead. It is demonstrated here:
https://www.practical365.com/exchange-2013-client-access-server-high-availability/ (the same applies to Exchange 2013 as 2016)
2. Hopefully your DAG’s FQDN is not mail.domain.ru.
3. Setting the RPCClientAccessServer on databases is not required in Exchange 2013 or 2016.
4. You might have missed a virtual directory in your configuration. Use my GetExchangeURLs.ps1 script here:
https://www.practical365.com/exchange-server-2016-client-access-namespace-configuration/
Hi, Paul. Sorry for long break. My DAG’s FQDN is not mail.domain.ru and I’ve used your script to change my Exchange’s virtual directory from FQDN to mail.domain.ru for both Servers. But when I try to connect to Exchnge occurs fail and appears a notice ” The connection to Microsoft Exchange is unavailable”. Certificate is a valid and not self-signed . I took desicion to use DNS Roun Robin. So, outlook try to connect not namespace mail.cpxdemo.ru and to one of FQDN. OWA, ECP and etc. are working perfect. Do I need to configurate anything more? By the way , I changed only internal URLs, external URLs have not used and no internet access.
Paul,
You know a lot from the exchange team – could you ask for this cmd-let 🙂 🙂 🙂
Set-ClientAccessService -server “myNewServer” -ActivateAutodiscover
it will do 2 things:
1. Register the servers Client point with your configured value.
2. Tell the other servers, that this server is now ready to announce virtual directories.
/anker
Hi Paul.
Is it possible to prevent exchange from “announcing” those virtual directories immediately?
Even if the SCP is changed to the “correct” DNS name as fast as possible, it seems that the virtual directories are distributed to outlook clients and somehow cached on the existing exchange servers. We have a lot of outlook online clients, and I could not prevent the certificate warning for almost an hour. Had to reset IIS on the existing exchange 2013 servers, which made a lot of noise also.
/anker
No. Well, sort of. This article explains one way to mitigate this situation.
http://blogs.technet.com/b/exchange/archive/2015/11/18/exchange-ad-deployment-site.aspx
But if you suspect a problem you can recycle the Autodiscover app pool in IIS without doing a full IIS reset.
ok thanks Paul.
that would be an option. with sites.
but, will prepare a script to recycle app pools across the ex servers I think.
/anker
Worse than I thougt. A lot of the outlook online clients got the 2016 exchange server name in their profile. and even that the correct names are now replicated, the outlook clients just promps for password and the profile points to the 2016 wrong name.
only solution is 2 delete the profile. THEN autodiscover works and set the right server name.
MS could have avoided this broken by design approach by making all new Exchange server installs put into a Deployed state, leaving them excluded from the AutoDiscover process until they’re properly configured, validated and put into a Production state. Scripting an AD Site /32 hack for the new server is the best workaround to avoid unnecessary helpdesk calls.
Not the Server’s FQDN, sorry if I was misunderstood. The server’s FQDN is xyzserver.xyz.local. The external URI is mail.xzy.com. The internal URI is also mail.xyz.com. The internal DNS server points mail.xyz.com to 192.168.1.3, while external DNS points it to some outside public ip. If they ping from their worksation mail.xyz.com they get 192.168.1.3. That is what I meant.
On the exchange server, I set all of the Virtual servers to use mail.xyz.com as the internal and external URI. So when configuring Outlook 2007 (again, I know it is not supported), I put mail.xyz.com as the server name and mail.xyz.com in the outlook anywhere proxy section.
On Outlook 2013, it does it all automatically, so I put in her email address (Janedoe@xyz.com) and her password and it auto configures nicely. I even tried doing it manually and typing in the servername, mail.xyz.com, but it ends up the same as if I had let it autoconfigure.
End result is that on Outlook 2013, she still gets the certificate warning.
What exactly does the certificate warning say? Which of the validation items is failing?
It says “The name on the security certificate is invalid or does not match the name of the site.”
The certificate is for mail.xyc.com.
Run the certificate report here:
https://www.practical365.com/powershell-script-ssl-certificate-report/
And also the GetExchangeUrls.ps1 here:
https://github.com/cunninghamp/ConfigureExchangeURLs.ps1
And then please email me the results of both to paul at this domain. I’m just having trouble visualizing your scenario.
Do I need to edit the scripts before I run them?
Did you ever a resolution on this? I am working with a customer that has a .local internal domain but the cert cant have the .local name. What did you do to get outlook clients to work without getting cert warnings? My only other option i am seeing is to create another OWA site with a new IP to assign the .local internal CA cert to.
Don’t use the .local domain for the Exchange namespaces. Use a valid domain that you can get a certificate for. Use split DNS to control where it resolves to for internal vs external clients.
Thanks for your amazing articles! I have followed all of your information about this certificate warning, but I have one pesky machine that is still throwing this warning. All of the other machines do not show the warning. They are all using Outlook 2007 (yes, I know it is not supported with Exchange 2016, but it is working). The one with the issue is the only Outlook 2013 install in the whole company.
I did a ctrl click on outlook icon in the system tray and chose to test auto configuration and in the results, all of the entries have the correct FQDN.
On the exchange server, I have set ALL of the virtual directories with the same FQDN for internal and external. I have an internal DNS entry for the server pointing to the internal address, and in our outside DNS, the entry points to the outside ip. Everything seems correct, yet this one machine still throws the error.
Any ideas?
Outlook can cache Autodiscover info for a while and cause the issue to remain. If you recreate the profile does it go away?
No it did not. I recreated the profile twice and it is still coming up!
Check for hosts file entries on that one computer, perhaps it is trying to connect to something else.
I’ll check, but I did ping the mail server by its FQDN and came up with the correct ip!
Your clients shouldn’t be attempting to connect to the server’s FQDN though.
Paul, I can always count on you when I’ve been banging my head on a wall. I am about to help a small business client switch to an external trusted cert and I was testing on my own two node dag. I created new (self-signed) cert with only the webmail.domainname.com and autodiscover.domainname.com. I modified ALL the Virtual Directories (multiple times because it still gave cert error). I would open Outlook and after 20-30 seconds I’d get the security cert error pop-up with the name of one of my exchange servers. Arrrrgh. Then I saw your comment about Outlook profiles hanging on to outdated information. I created a new profile about 30 minutes ago. Mailbox has finished sync’ing up and I still haven’t gotten the offending pop-up. Great call. I looked in the registry in my old profile and did not see the server name anywhere. Anyway to clean that up without creating a new profile. I can see this will be an issue with the small business that I’m about to switch certs. Oh well….they pay me by the hour.
assuming the mailbox your testing with is on 2016.
configure the rest of the url to match not just autodiscover(specifically outlook anywhere)
Paul,
I created with the FQDN to IP, added that IP in Exchange 2016 (only have one yet) in coexistence with Exchange 2010 and ran the command to change the InternalUri the Autodiscovery.
What I realized on the client outlook?
He communicated with the IP of the new FQDN, but looking at the status of the client connection outlook, it is still showing that you are connected to the FQDN of the server, which should be the new FQDN that changed in InternalUri.
I logged with another user and created from scratch profile and he did the same thing, it shows that the FQDN is connected with the server name instead of showing logging in FQDN that created again.
What could be wrong?
Thank you
If all you’ve changed is the Autodiscover URI for the new server that is just part of the solution. Read the article again, it references the other namespace configurations that are also needed for a newly deployed server.
hello Paul,
If we will have four exchange servers on that case which server we have to point like Exchange A , Exchange B , Exchange C and Exchange D . Which server name we will use for FQDN.
Set-ClientAccessService -Identity EXSERVER -AutoDiscoverServiceInternalUri https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xm
You don’t use a server name, you use a DNS alias.
More reading:
https://www.practical365.com/exchange-server-2016-client-access-namespace-configuration/
Exchange 2013 did this as well. Setting autodiscoverinternalserviceURI is the first thing I do. Great article.