Hi again,
This issue has came up too much, so I wanted to blog something short about this.
Prerequisites:
- Update (Added June 29th 2013) – If using Exchange 2013, check out Exchange 2013 Outlook Anywhere Considerations for some additional specific Exchange 2013 issues.
- Exchange 2007 or 2010
- Outlook 2003 / 2007 / 2010
- Windows XP / 7 / etc..
- Outlook Anywhere ( RPC over HTTP ) enabled – with Basic Authentication or NTLM Authentication
- Autodiscover – working correctly 😉
So, you’ve got it all configured, you enabled Outlook Anywhere, configured ISA 2006 / TMG / UAG to publish the Outlook Anywhere (or not), you published Autodiscover records an all is working great !
BUT ! you have this annoying user credentials pop ups, and users are going nuts ! and so do you !@ ( enough sarcasm ) it may work for a while, and then you are prompted again for user and password, or even worse – it might not work at all…
Here’s what can go wrong in bullets because we have a few different issues that might cause troubles..
- Outlook Anywhere is configured to use NTLM authentication:
- Solution 1 – Configure MSSTD or the Certificate Principle Name correctly (see below)
- Solution 2 – Configure your clients local security policy, in specific – LmCompatiblilityLevel to 2 or 3
- Solution 3 – If you try to pull NTLM with ISA / TMG / UAG, either configure “Kerberos Constrained Delegation” – check links below for the white-paper from Microsoft” or change the publishing rule to apply to “All Users” and in the Authentication Delegation tab choose the option “No delegation, but client may authenticate directly”
- SSL Certificates issues
- Outlook Anywhere was enabled for – mail.company.com (ExternalHostName), but you have a wildcard certificate or the certificate subject name does not match mail.company.com
- Solution – Configure MSSTD or the Certificate Principle Name correctly (see below)
- Outlook Anywhere continuously keep being configured automatically !%
- Solution – Lucky for you I have already blogged about this 🙂 Prevent Outlook Anywhere (aka RPC over HTTP) from being automatically configured in Exchange 2007 with autodiscover
- Update (Added June 29th 2013) – If you’re going to deploy Exchange 2013 anytime soon – work your way to adapt autodiscover and don’t go in this path..
So what’s that MSSTD or Certificate Principle Name ? well it’s a method Outlook can verify that the server you are connecting to indeed holds the correct SSL certificate subject name before sending credentials to.. well yeah it ain’t that secure.
This setting is actually being configured automatically since Exchange 2007 and continue to be with Exchange 2010.
So here’s what you can do with it – all examples follow the Set Outlook Provider cmdlet syntax:CertPrincipalName
- You have a wildcard certificate – Run this command:
Set-OutlookProvider EXPR -CertPrincipalName msstd:*.company.com
- You have a differnet subject name on your SSL certificate then the ExternalHostName you configured for Outlook anywhere on your CAS server
Set-OutlookProvider EXPR -CertPrincipalName msstd:correctsubject.company.com
- You don’t want that “only connect to proxy servers that have this principle name in their certificate” check box marked at all ! 🙂
Set-OutlookProvider EXPR -CertPrincipalName none
New feature with Exchange 2010 – The Set-OutlookProvider cmdlet now allows Outlook 2010 clients to connect exclusively through RPC over HTTP (Outlook Anywhere) before trying RPC over TCP connections when connecting over the Internet. !
This means you can control the check box “On fast network, connect using HTTP first, then connect using TCP/IP”, here’s the two options:
- Always connect using HTTP (mark “on fast networks”) :
Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
- User TCP/IP first then HTTP (default):
Set-OutlookProvider EXPR -OutlookProviderFlags:None
This should cover it, no more pop ups and hopefully Outlook Anywhere and you will be friends again !
ilantz
Credits (or links) :
When, if and how do you modify Outlook Providers?
Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG
Good!tks!
Gave this a try the other day.
First tried Set-OutlookProvider EXPR -CertPrincipalName msstd:correctsubject.company.com
Seemed to have worked for the first day, but everything fell over the day after. XP computers still prompting for username / passwords.
So then I Tried: Set-OutlookProvider EXPR -CertPrincipalName none
Seemes to have fixed the issues on most computers. However; some windows 7 computers complain about the name on the certificate not being the same as the name of the proxy server.
and some windows xp computers keep prompting for username and password.
LM Compatibility level is set to 3 for all computers. and all are set to negotiate authentication in outlook.
I have noticed though if i set the authentication type in outlook to NTLM and the back again to negotiate it works :S
Not sure if theres something wrong in my exchange autodiscover / outlook anywhere config?
Any tips / suggestions are much appreciated.
Hi Dominic,
Thanks for following my post.
– Do you have proxy enabled for your client computers ? if so make sure, that all the http/https traffic to the exchange CAS servers is totally excluded. you must bypass proxy to the CAS servers.
– In addition, please verify the parameter AutoDiscoverServiceInternalUri when running the Get-ClientAccessServer | FL , the value must match the certificate name.
Please update me with the outcome..
Holy crap ilantz, you saved my ass…. Many thanks!!!
You are very welcome Aaron !
stop by more often 🙂
We have been trying to months to resolve the Outlook prompting issue. We are using Basic Authentication. The advice you give about verifying the AutoDiscoverServiceInternalUri parameter, do you mean they must match exactly? Here is what we have:
AutoDiscoverServiceInternalUri:
https://webmail.compname.com/Autodiscover/Autodiscover.xml
SSL Certificate Subject Alternative Names (there are several, including the following):
webmail.compname.com
http://www.webmail.compname.com
autodiscover.compname.com
Outlook Anywhere Settings:
External Host Name: webmail.compname.com
“the value must match the certificate name” means that the URI value must match at least one SAN or the subject name of the certificate presented by the CAS server, in our case it seems it does.
Another good tip is to make sure you exclude traffic to the Exchange web services from clients using Proxy, make sure they all are connecting directly to the server.
ilantz
You mean Client IE proxy exclusion? using GPO?
Well the “proxy” servers mentioned in the post are RPC over HTTP proxy servers..
Thank for the tip to solve the issue getting Outlook Anywhere running with NTLM through an TMG server. By changing the Web publishing rule as in “Solution 3” did the trick 🙂
I’m glad you found this post useful Lars !
Drop by more often for some more 🙂
** I’ve noticed I didn’t include the link for the NTLM whitepaper, post is updated.
ilantz
Good to know if you have more than one AD site and subdomains:
http://blogs.technet.com/b/exchange/archive/2008/09/29/3406352.aspx
Yes, the first example in that article points out clearly that one should not modify the EXPR setting if more then a single CAS is published and the external URL’s are different. Thanks for the comment !
I have the following scenario:
Exchange 2007 servers hosting domainA.com and DomainB.com
Exchange 2010 servers hosting domainC.com, domainD, domainE.com and more to come.
Exchange 2007 OA goes thru ISA 2006
Exchange 2010 OA goes thru F5 (SSL offloading).
I just can have an MSSTD *.domain.com as far as I know.
How do I handle this?
Do I need to use an “umbrella” domain for all domains?
Should I have the same wildcard certificates in both ISA and F5 and let DNS do the rest?
The domains are under the same forest of course.
Any help is appreciated. Thank you.
Hi,
as long as you “must” modify the MSSTD setting, then my best advice is yes – use the same SSL certificate.
the actual domain names users have, or when exactly their proxy server is located will be handled automatically by exchange.
Using the same SSL certificate will simplify the solution IMHO.
best regards,
ilantz
Thank You sooo much, after too weeks UAG and Exchange troubleshooting – your post was the solution. Exchange Autodiscover with UAG Direct Access won’t function without the OutlookProviderFlags:ServerExclusiveConnect. Now all is right!!!!
Greetings from good all Germany
I’m happy to hear that! Drop by more often 🙂
Hello Ilanyz,
I am hoping you can help me out. We have a wildcard cert on our cas and all xp machines always prompt for a password as it seems xo can’t handle the wildcard * cert not being the exact server name. Win 7 machines are fine.
Is there any way of getting around this without running the set-outlook provider and to fix it from the xp side.
I am afraid to run the command as we have a multi domain with different certs in different geo regions and I am afraid I will lock out the other regions if I start using the set-outlook provider when I am not 100% sure on the cmdlet.
Thanks
Brian
Hi Brian,
If you are using different certificates in each region , you are forced to use the default “empty” mssd value on the provider. You can however switch the external outlook anywhere server name to match the certificate subject name and you’ll be set.
Hope this sorts your issue.
Ilantz
ilantz –
Thank you for this hugely valuable article. Could you speak to this situation? I have an existing exchange server hosting multiple email domains (using autodiscover w/HTTP redirect to service them all from one server). I’ve brought up a parallel Exchange server group (this time, multiple servers). I want to move clients from the old single server to the new server group. To do this, I’ve set up a new SSL cert and am modifying the HTTP redirect on a client-by-client basis. This works FANTASTIC…except for the Outlook Anywhere. Since I can only specify ONE certificate for the entire system, I’m stuck. Outlook Anywhere fails either for the old or new system.
Do you have any advise on how to handle this? Would a wildcard cert work in this case?
Hi Jeremy ,
Is the actual hostname for outlook anywhere changes?
How does active-sync for example works for you in this situation?
Ilantz
Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
Quick question, what is the impact to the user experience
What is the most failure scenario associated with performing this change
Well, quite straight forward – as it states, this flag will mark HTTP as the primary method (on fast,on slow). Everyone’s profile will be updated accordingly.
In addition, if your current Outlook Anywhere settings are to use Basic Authentication this will cause users to enter their credentials when opening Outlook (with the save option).
I have a problem that hopefully you can help me with. We have exchange 2010 with a mixture of 2007 and 2010 outlook clients. Most clients are windows XP, the IT department is really the only ones using Windows 7 or 8. We have 3 offices that are not on our domain that connect to our email server and 5 internal sites that also use it. (Exchange 2010) We originally had the issue of outlook anywhere automatically pushing out configuration settings to our internal clients, causing workstations on our internal lan to grab outlook anywhere configurations and would make the login prompt show up. I do not want my internal workstations to use any outlook anywhere settings at all. SO I followed your other articles suggestion and turned off the automatic setting push. THis worked great.. but now we are having the issue of the external offices losing their outlook anywhere settings. During testing I noticed that after I setup outlook anywhere manually and successfully connect, I would wait about 1 minute or so and go back into the profile settings.. all the settings were gone. Outlook would still function fine, but if a user rebooted their machine they would not be able to connect to our exchange server.
Is there a way to enable the automatic outlook anywhere settings but make sure internal workstations do not grab the settings? From what I read even if I created a GPO policy the internal clients will still grab the auto settings…
How can I make sure external clients do not lose their outlook settings and at the same time make sure internal clients do not use outlook anywhere?
Thanks for your help.
Also we are using basic authentication.
Hi Jimmy,
Here’s a method I hope will work out for you:
1) Re-enable Outlook Anywhere (bring back the provider)
2) Work with an AD group to have all your “External” users / users that use Outlook Anywhere
3) Disable RPC over HTTP for all users that are not within that group (Set-CASMailbox -MAPIBlockOutlookRpcHttp:$true)
Another way would be – remove the provider, disable SCPLookup,http etc and leave only the localxml option for remote clients and provide them with a static XML file for autodiscover settings.
Looking forward with Exchange 2013 I already updated my posts recommending to think this through and re-enable the provider back..
Hope this helps you out,
ilantz
This may be a dumb question but what is the full syntax to disable it for a group? Should I follow the below links instructions or is there a preferred method that uses the (Set-CASMailbox -MAPIBlockOutlookRpcHttp:$true) that doesn’t require importing and configuring templates.
Thanks for all your help really appreciate it
Link: http://www.christitus.com/blog/2011/03/23/disable-outlook-anywhere-in-group-policy-object-gpo/
CIO won’t go for it… I’ve never had this problem before.. I am really confused why my internal workstations are pulling outlook anywhere settings….I did not set up this environment however…
Shouldn’t internal clients pull the EXCH settings and not even use the EXPR settings? Is there a way to change both the EXCH and EXPR settings post installation? Perhaps they were not set correctly.
Sorry for all the questions I’ve been trying to figure this out for a few weeks now.. Its either massive amounts of internal users getting login prompts or people externally losing their settings.
Hi,
It’s simple – it’s by design.
When you enable Outlook Anywhere for the first time, the Autodiscover application on the CAS server is updated with the new situation and updates all clients with the values.
Either embrace it, or think it over 🙂
My real honest opinion is to embrace it, even better – move all internal/external to HTTP. That’s where Exchange 2013 went and will stay there..
As for the powershell command, try working with this example, and modify the commands accordingly.
http://social.technet.microsoft.com/Forums/exchange/en-US/621c25a3-81be-4cad-9268-3758e9200be7/exchange-management-shell-command-to-add-users-to-an-activesync-mailbox-policy-based-on-group
Hope this helps you out.
Ilantz
Hi, good post, I tryed test config msstd:*.demo.com in outlook proxy servers however In windows XP with outlook 2010 popup authentication:
I have a exchange server 2010 with autodiscovery configuration is:
CN=mail.demo.com
email.demo.com
autodiscovery.demo.com
Thanks for your help.
Hi Alefred,
Altering the MSSTD settings is required when your external hostname for Outlook Anywhere does not match the certificate subject name.
From what you’ve written, I understand the certificate subject name is “Mail.demo.com”.
So, work your way to match the the EXPR MSSTD setting to the correct subject name. having more then one subject alternative names on the certificate does not obligates you to change the value…
hope this solves your issue,
ilantz
Hi, i’m struggling also with the popup “Windows security outlook connect to emailaddress”. I have disabled outlookanywhere, still the windows security popup is coming up. I have a selfsigned certificate and added the proxy settings manually in outlook. Also not configuring outlook over internet in outlook doesn’t resolve the annoying popup. Do you have any suggestions?
Thanks in advance
Hi Marian,
Let’s try to brake this out..
1) You do not want to enable Outlook Anywhere ? is it disabled ?
2) If it’s disabled why did you enter the proxy settings manually ? That will configure Outlook to use Outlook Anywhere.
3) Is the client you are testing a Domain joined client ?
4) Do you have any HTTP proxy between the Exchange and the client ?
ilantz
1 it can be disabled . I tried both to find out if the popup disappears.
2 All to try out.
3 domain user
4 no proxy
status update:
i am able to connect to owa/autdiscover/rww
from within oulook i can set the out of office reply
i am not able to run the test email outlook configuration (holding donw CTRL and right click on outlook in system tray)
At that moment the popup appears. When I let it sit there user can work with outlook, when ik click cancel (OK button is grayed out) i have to click on Excange needs password. Then the connection with the exchange server is OK again.
Hi Marian,
You can see “out of office” this tells us that Autodiscover is providing the client with the information – which is good.
However you say that running the auto-configuration test fails ? what does the LOG tab says ?
In addition, can you please run the following:
Get-OabVirtualDirectory | FL BasicAuthentication, WindowsAuthentication, InternalURLVerify that WindowsAuthentication is enabled, and that the URL is correct for your internal server names.
ilantz
Hi Ilantz,
I was able to stop the windows authentication popup and not being able to run the auto emailconfiguration wizard. I send you my entire document. If this is too much you can shorten it. Thanks for your help and your suggestions
Hi Marian,
I didn’t realize you have SBS installed.. these has various “special needs”.
If you did perform all those steps you’ve pasted and the auto configuration is still not working, I would suggest asking for professional help with a Microsoft Partner or Microsoft support.
ilantz
Problem was solved by taking all those steps
Great! Thanks for sharing.
Perhaps you can link the source for others to use?
Hi ilantz,
Thanks for the great post, can you please explain a bit further about bypassing proxy? as our Outlook 2013 users were getting those popups every few mins (connecting to Exchange 2010), and Windows does not even remember the password keyed in even with “remember the password” checked. Please note the popup happens in internal network, so should use rpc/tcp to connect to Exchange 2010
Interesting thing is those popups seem to have stopped for now after we excluded fqdn of the exchange 2010 server in IE proxy, but why Outlook would contact proxy server specified in IE for authentication? I mean why it redirects authentication request to proxy server? It should just make direct contact with AD for it, shouldn’t it
Your help would be much appreciated
Merry Xmas to you
Cheers
Grand
Hi Grand,
Since Exchange 2007 and Outlook 2007 versions, services such as OAB,Free/Busy, OOF and Mail Tips are available thru web services.
This means that the client will contact the Exchange server via HTTP/s, where some proxy servers will not interfere, some will block the authentication between the client and the server which will turnout as popups….
Anyway, excluding the local URLs for the Exchange servers within the proxy and allowing direct connectivity to the server will be the best thing to do. (preferably configured during the deployment phase…)
hope this explains things better,
Happy new year !!
ilantz
Hi ilantz. I see you are an eminence on this subject. 🙂 Can I pick your brain for a (hopefully) quick answer? Why does the Outlook 2010 client (Exchange 2010) only accepts logging into it using the DOMAIN\username combination while going through HTTP Proxy (MSSTD)? And what can I change to allow logging in using the email address as well? Thank you in advanced!
Hi Ceezar, do you have a reverse proxy taking action in this situation ? Like TMG or ISA?
Keep in mind that email isn’t really a logon value…you should work your way to match your users UPN values with their emails. That way you can establish this, add a UPN suffix if your ad domain FQN is different from your email domain.
Hope this helps 🙂
Hello Ilantz!
I hope that you will let me pick your brain on an interesting issue. When Outlook 2007 opens and queries AutoDiscover (Exchange 2010) it keeps receiving Basic Authentication for the Proxy Authentication Settings under Exchange Proxy Settings. I have both IIS and CAS set to only use NTLM but I can’t figure out how to force NTLM Authentication on Outlook clients.
Greatly appreciate any help you could offer! 🙂
Hi, just to make sure. You did configured the clientauthenticationmethod to NTLM using set-outlookanywhere? You can restart the service host and protected service host services to make sure these setting takes place.
From there it will take some time to have those pushed to outlook clients. Does a new profile gets the correct value?
I’m having the credentials issue on one of our most simple setups. SBS 2011 (with Exchange 2010). All certificate names match, single domain, all 7 machines, Outlook 2013. Also have the issue of being unable to set out-of-office auto replies when outside the office using Outlook. Users currently have to use owa to set and remove.
It is driving me nuts. Any help would be VERRRRY appreciated as I may rip my hair out.
Thank you,
Tyler
Hey Tyler,
I just to want to verify the details.
Internally all works correctly? Any popups while connected to LAN?
Did you verify your setup using exrca.com? That might help…
Ilantz
I have tested it and all comes back happy. The workstation is located at a home office, not joined to the domain and has never been in the office.
Internal is happy. I am completely stumped.
Does the certificate being used was issued from a trusted source? Like verisign , thwate etc… ?
Turn on the outlook diagnostics log and check the olkdisc.log file, that helps alot.
I have a weird error. I followed your steps, and i searched and read so many other sites for the solution, but no success yet.
Im using single ex2013 server, which is working and configured with a wildcard ssl. i think my config is good.
And here is the weird thing: If im using https://testconnectivity.microsoft.com to test my OA , it can fully finish the test if im using the autodiscover option. But, if im adding the addresses manually, which is i think the same what autodiscover tells, the test stuck when it tries to ping my RPC Proxy.
I really tried everything, i watched my regedit port settings, i reenabled rpc, i rechecked my dns zone settings, and i found 0 errors.
The weird thing is if im trying to add my account via outlook 2013 from an external network, it wents fine and i can do anything. But when im trying to use another account, which is using another domain what is configured in my exchange too, its not works.
I think my problem is somewhere with the RPC proxy, im just gone mad cuz of the test when autodiscover can ping my rpc proxy and manual settings dont (it has the same address each way)
I would really apprecciate your answer, pls save me.
Thanks
Hi,
Autodiscover uses the primary SMTP Address suffix of a user, so you’ve said the 1st ( I guess the primary domain you have ) is working good.
All you need to do is add the autodiscover record for your other domain suffix.
As for your situation:
1) You’ve said you’re using a wildcard cert , lets call it *.domain.com
2) I guess you have an external URL for that domain (OWA,OA,ActiveSync etc..), lets call it owa.domain.com
3) I believe that your autodiscover record matches that and is autodiscover.domain.com
4) The other user is using another SMTP domain suffix for example user@domain2.net
So to allow the other domain you need to create an autodiscover record as well..
Use the SRV record method for domain2.net because your certificate is a wildcard which confirms to a single domain.
Here’s an example to use when you’ll create the DNS on domain2.net:
Service: autodiscover
Protocol: tcp
Port: 443
Priority: 1
Weight: 1
Host: autodiscover.domain.com
to test it use nslookup -q=srv _autodiscover._tcp.domain2.net.
you can compare it with a “real” one also : nslookup -q=srv _autodiscover._tcp.contosoo.com.
Good luck, and please report back…
ilantz
Hi,
First thank you for your fast answer.
When i read your and many articles on the net, i found that i should build an SRV record to my dns zone. I did it with all the two records. They are answering to the test code what you told me after i reconfigured my domain2’s SRV record when i forgot a . 🙂
My only problem is, now when i tries to manually with the connectivity test, then with autodiscover each domains are working, i can use my accounts but when i manually type my rpc and other addresses, the test fails at the RPC ping section and got 404.
So if you know pls tell me whats the difference between the autodiscover and manual setups?
Well… With exchange 2013 manually configuration is a little more difficult .. If you noticed, once auto configuration is complete, you will see a server name which is a GUID value..that’s the mailbox guid value of which you configured the profile.
I’ll recommend you to always use Autodiscover as it’s more easy. But if you do want to configure manually, just look up the mailbox guid value first, or use exrca.com to “tell” which one is it – look in the log to see.
Hope this clears out the issue 🙂
Ilantz
Hi ilantz,
I have the same authentication problem on Ex2007/Outlook 2007 without having Outlook anywhere activated.
I am not sure if it is a problem of proxy autoconfigure, we use a pac file on out Clients, for we got different proxies for different Websites. Mostly we use a squid 2.5.
I made an exception for our internal network, so Outlook should connect direktly to the mail server.
Got any idea what this could be?
Regards
Jens
I would first identify the proxy as the cause. If it is… Just make sure you are bypassing it. Check your log files on the proxy… After eliminating the proxy we can start investigating the exchange server side 🙂
Hi ilanz,
Checked Proxy for about 30th time 🙂 Found the problem. For anyone who uses a proxy.pac file you need two exceptions returning direct access:
shExpMatch(host, “mailserver.domain.local”)
shExpMatch(url, “autodiscover.domain.local”)
I had a shExpMatch for url in the first one (with the Mailserver).
Thanks, anyway nice blog, will be looking in here from time to time 🙂
Regards,
Jens
Happy you’ve found it 🙂 glad to have you here!
Ilantz
Thank you for the blog entry, very interesting article and comments.
We are having an issue implementing Exchange 2013 with NetScaler and AAA;
– Everything works well both internally/externally if the AD Domain and Public DNS / SSL Cert have matching names.
– Everything works well internally for Internal users (direct not via NetScaler) if Internal/Public Domain names differ
– However OA fails from a Public connection (via NetScaler using AAA) if Domain Names for Internal (AD Name)/External DNS are different
– If we disable AAA on the NetScaler all works OK
Could this be an Exchange configuration issue causing OA connectivity issues when using AAA with mismatching Domain Names and if so what are best places to start looking?
We are using a wildcard cert for SSL.
Hi Wayne,
sorry for the late response, is your issue still open ?
Hello,llantz!
I’ve tried to remove EXPR as your another blog article.
But I couldnt set “empty” msstd value back.
How do set it back ?
If I run command set-outlookprovider EXPR -certprincipalname “msstd:”??
Hi Rica,
To revert the EXPR back to default you should run the following:
Get-outlookprovider –identity EXPR | remove-outlookproviderNew-OutlookProvider -Name:EXPR
Hope this helps
ilantz
Good morning,
I have the following scenario.
A customer migrated, about 1 year ago, its Windows Server 2003 and linked Exchange to Windows Server 2012 and Exchange 2010.
At that time, everything went almost good, I mean that even if we still did not know for which reason Microsoft ActiveSync never started working, at least OWA and Outlook Anywhere were working both for internal and external clients.
We are using selfsigned certificates (not external ones, for a fee), the ones which were created during Exchange 2010 installation.
A week ago, the selfsigned certificates expired, so they where renewed from the proper wizard.
After this operation, we have the current situation:
– The internal clients, using Outlook, have the error “The name of the security certificate is invalid or does not match the name of the site” (but they still continue to work properly).
– The external clients, using Outlook Anyware or OWA through proxy access, from the date of expiring of previous certificate don’t work anymore, I mean that at the date of expiring of certificate they warned this issue, but importing the renewed certificate (even manually installed in Trusted Root Certification Authorities), they have the same error message of internal clients “The name of the security certificate is invalid or does not match the name of the site” and they cannot access to mail and work.
Obviously both internal and external clients received the renewed certificates.
I tried to take a deep search on KB and widely on the Web in order to find a workaround or a solution, but I am still without anything to do.
Could you please suggest me anything useful?
I put in the link below screenshots of some Shell “get” commands in order to show current settings of the Exchange Server.
Ask me further information if you need.
Regards,
nino
http://s21.postimg.org/6whcaalhz/exch.jpg
Hi Nino, I guess that if the message of mismatched subject name is showing up. Then that’s your issue… Make sure the subject name is equal to your external URL.
Just saw the outputs… The certificate subject name is server06, it should be imap.vistosi.it
So when you create it, make sure it’s the primary name, then add the rest..
Changing the LmCompatibilityLevel to 2 resolved the issue for me on the client machines
https://technet.microsoft.com/en-us/library/cc960646.aspx
Thanks for sharing your results Paul!