Exchange 2013/07 migration certificate issues

I previously had a single server Exchange 07 environment.  Stood up an Exchange2013 sever successfully.  Mailflow is working, I have moved my own admin account over to EX2013 and am able to successfully send and receive mail with a few tweaks(on the outside need to use the temporary public a record).

Exchange 07
Machine name: Ex07.domain.local
Internal URL:
External URL:

Exchange 2013
Machine name: EX2013.domain.local
Internal URL:
External URL: (Once I move everyone over I will change the ext URL to and switch the NAT rule in the firewall)

With netsol I have and setup with different public IPs, firewall allows smtp traffic and NATs them through to their proper internal IPs.

I created so I could test everything out before moving everyone over to the new server , making the NAT changes and decommissioning the old Ex07 server.  I will get ride of the public A record once the transition is done.

I also have on internal DNS zone for  It has Mail and autodiscover currently pointed to EX07 and a record pointed to EX2013's private IP.

I have a public CA cert with and autodiscover and as SANs installed on the new server successfully.  The old server has a single cert through a different public CA, I just left that one alone.

Ultimately I want a seemless experience for my clients.  I don't want them to have to change anything in Outlook, their smartphones, there Outlook on their home machine, anything, if I can avoid it.

Currently on my internal machine with Outlook 2013 I get prompt to login 2-3 times when I open Outlook and I get a certificate error(name mismatch).  It claims it's looking for EX2013.domain.local.

I have been looking through site after site and have changed all the virtual directories internal URL to  I have run Set-ClientAccessServer and a few others to manually specify the internal URL.  Yet I still get a cert name mismatch.

If I continue on under Account Settings->Server Settings-Server: reads "".  I believe that is normal.

I'm looking for any advise or areas to check to clear up this certificate name mismatch and the 2-3 logins every time I open outlook.

Your help is appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Simon Butler (Sembee)ConsultantCommented:
Usually you would switch the URL over to the Exchange 2013 platform and the older version gets the new URL - the "legacy" URL. That is because Exchange can downgrade easily, either proxy or redirect the traffic as required.

The first thing you need to do is check all of the URLs are correct.

I would make the Autodiscover URL the same on both servers, pointing to the Exchange 2013 URL.

As for the prompts when connecting with Outlook, check the authentication methods. If you have configured basic then that can generate prompts. I would also look at what host name has been configured for Outlook Anywhere by Autodiscover.

Read the client access coexistence documentation on TechNet - that will cover what you should be doing, particularly around Outlook Anywhere and ActiveSync.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tw525Author Commented:
Simon, thank you for you post.  Very helpful information.  In fact I've bookmarked it as your page seems to have the accumulation of a lot of other sites I have read with a few good additions.  I believe my setup was correct before.  However I setup your script and ran it anyways.  I'm still getting the pop-up name mismatch.  The Service alert is clearly being passed the EX2013.domain.local somehow and not seeing this name in the cert.  I'm a bit perplexed what is providing this internal hostname.

I ran your script and changed everything internal and external to  Which should be routable on the inside and outside of our network.  I had already setup split DNS and it seems to be working.

Interestingly the login issue has stopped.  Not exactly sure what I did to resolve unfortunately.  But when I got in this morning no more pop-ups.
tw525Author Commented:
One other item to mention, not sure if it's relevant.  My Exchange 07 server is running a single named SSL cert, not a UCC.  I recall a Microsoft tech showing me a trick to utilize a single cert in Exch07.  I didn't take detailed enough notes on the process and subsequently forgot all the specific steps.  I recently had to renew a UCC cert(different client) and looked back into this process.  However it was far more hassle than it was worth, especially with UCC certs so cheap now-a-days.  With this client and the people still connected to the Exch07 server, they don't currently get any certificate errors.  If you go to the accounts-Server: it lists as Exch07.domain.local even though the server's cert is with no SANs.  Not sure how it doesn't get the pop-up.

The Exch2013 I went to a different CA and purchased your standard UCC cert for this server.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

tw525Author Commented:

I think I have located the name mismatch error.  So in playing with your script.  I found something missing.

#Change this value to match the name of the external certificate
#Change this value to match the real name of the server

Get-WebServicesVirtualDirectory -Server $ComputerName | Set-WebServicesVirtualDirectory -InternalUrl https://$URLNAME/ews/exchange.asmx -ExternalUrl https://$URLNAME/ews/exchange.asmx

In your original posting the -ExternalUrl portion was missing.  Prior to adding that we looked at the test Email Auto configuration and noticed OOF was still referencing  Since we use split DNS will look to the old Exch07 server.  We added the above -ExternalUrl, and no more cert mismatch error and when you look at Email Autoconfig it lists OOF as HWM-Mail1.

So that issue is resolved.  However I have found the login prompts return when cached exchange mode is enabled.  I've looked at the OAB in the autoconfig and it correct lists  But I get 2(sometimes 3) login prompts every time I open Outlook.

Any thoughts on what be causing this one?  Thank you.
Simon Butler (Sembee)ConsultantCommented:
How embarrassing. I have been using that script for years, and hadn't noticed the error. It was in the 2007 and 2010 versions as well, so I have corrected all three.

Prompts - is that with an Exchange 2013 or 2007 mailbox?
Prompts are usually an SSL mismatch or an authentication configuration issue - using basic for example will generate prompts.

tw525Author Commented:
Not at all Simon, a minor syntax error.  Your page is a great collection of info.  That same info I would find in pieces on other sites.  Nice to have a well written page that has the accumulation of info you need to do this install.  I passed your code along with your site to several other techs to help out engineers doing this install.  It will be helpful to all I think.

I will certainly award you points for your suggestions, as they definitely resolved my issue and help me find that OOF was the trigger.  The funny part is, if you initial code had the externalURL for webservices, I might not have discovered the specific issue that was triggering the cert error.

If there are those that like to find that smoking gun when trouble shooting.  I think the wise approach, if you were experiencing a similar issue, would be to run the Outlook email autoconfig report(mentioned on your site).  Grab a copy of the output.  Then run the script, but do just the web services fix.  Then kill and reopen outlook.  Still getting the cert pop-up, move onto the next service.

My biggest issue was since it was reporting Exch2013.domain.local in the security alert and saying it's a name mismatch in the cert, I was always looking for Exch2013.domain.local.  However this turned out not to be the issue.  When examining the before and after of the email autoconfig results OOF, which is altered by the webservices line in your code) was instead of  Once I ran your code, complete with the externalurl as the cert error went away.  

I believe that was because of internal split DNS.  It would look for which internally still pointed to the old Exchange 2007 server. So that fixed that problem.

I just wanted to leave this thread open a little longer to see if anyone had any input on the multiple logins when cached Exchange mode is enabled?  

tw525Author Commented:
Simon provided a wonderful site and script to help ease the migration to an Exchange 2013 platform.
tw525Author Commented:
Further detail:

I was also able to resolve the multiple login prompt issue.  Under your outlook account settings->Connection Tab->Outlook Anywhere->Exchange Proxy Button...  There is the "On fast networks, connect using http first, then connect using TCP/IP".  This was checked.  When we unchecked this option, the multiple login prompts went away.  They were able to connect with NTLM Authentication and no further prompts.  

We ended up making a GPO to push the settings out to all clients and this resolved the issue across the board.  Interesting notes on this.  They have a mix of Office 2013 and 2010.  In the office templates for 2013 come by default with the "RPC/HTTP connection flags" policy.  The Office 2010 templates do not.  I did find however that Microsoft released a custom template for office 2010 that includes this feature.  If you are interested look up KB 2426686 and from there you can download the 2426686_template.adm file and gain access to this settings for your Outlook 2010 clients.

Setup the GPO, released it into the wild, had the users logout and back in, problem solved.  

Another interesting note.  When I had migrated the users to the Exchange2013 server last night I RDP'd into the terminal server(Office 2010) and tested and got no login prompts at all.  it connected immediately.  It did have the "on fast networks..." option checked.  It was the only client that I noticed that did not get multiple login prompts.  All local machines had this.  A few users had a seemingly endless number of login prompts.  I had them enter their credentials the first few times and select remember password and then just hit cancel.  Outlook would say need password, while at the same time updating folders(never seen that before).  After it was done updating folder, need password would change to the normal healthy Connected to Microsoft Exchange.

Another thing that would have helped me to know, that is a little off topic, the domain admin account is not enabled for Activesync in exchange 2013.  I wasted a lot of time testing with the DA account, before finding that.  I tried a normal user account and everything had been working the whole time.  I have not researched if there is a way around the DA/no AS default rule, but thought it might help others avoid this time suck issue.

Thanks again Simon for your assistance on the certificate error.
Simon Butler (Sembee)ConsultantCommented:
You need to be careful with the setting that you have changed.
Exchange 2013 only uses Outlook Anywhere for connections, which is why you are seeing both boxes enabled. With older versions of Exchange only the slow connection would be enabled.
Therefore while the problem may well be resolved for Exchange 2007 users, it will cause some issues with Exchange 2013 users because Outlook will now have to timeout before using Outlook Anywhere to connect.

tw525Author Commented:
Simon, you may be right and I might reverse that setting.   After more digging I found the root of the issue.  This client never used Public folders, so they weren't high on our priority list to worry about.  However somewhere I read about using the Outlook connection status(hold cntrl and select the Outlook task bar icon) to verify what connection Outlook is using.  I found that all the connections to Exchange2013 were connecting via https.  However the one connection using TCP was the legacy connection to the public folders on the old Exchange server.  If I could have found instructions on setting PFs on Exch2013 anew, I probably could have saved myself some headache.  But I didn't want to throw in the towel on PFs incase the client ever found a need.  So I went through the migration process.  Once completed connection status showed all https.  I manually turned "on fast networks" back on and it showed no issues.

I also have another client with Exch2013 with fast and slow networks checked and no issues there either.  Thanks for the followup Simon.  Interestingly, with the other Ex2013 client I had to reset the internal URLs and used the script you created.  None of the command let's worked on that server like they did the one I built from scratch.  Almost like I wasn't in an exchange powershell or didn't have the permissions.  I went through the ECP and changed them manually.  Just an interesting side note.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.