Exchange 2013/07 migration certificate issues
[Setup]
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: mail.domainname.com
External URL: mail.domainname.com
Exchange 2013
Machine name: EX2013.domain.local
Internal URL: EX2013.domainname.com
External URL: EX2013.domainname.com (Once I move everyone over I will change the ext URL to mail.domainname.com and switch the NAT rule in the firewall)
With netsol I have mail.domainname.com and EX2013.domainname.com(temp
I created EX2013.domainname.com 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 EX2013.domainname.com once the transition is done.
I also have on internal DNS zone for domainname.com. It has Mail and autodiscover currently pointed to EX07 and a record EX2013.domainname.com pointed to EX2013's private IP.
I have a public CA cert with mail.domainname.com and autodiscover and EX2013.domainname.com 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.
[Problems]
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 EX2013.domainname.com. 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 "djk38hf-4ne9f924-dkj@doma
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.
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: mail.domainname.com
External URL: mail.domainname.com
Exchange 2013
Machine name: EX2013.domain.local
Internal URL: EX2013.domainname.com
External URL: EX2013.domainname.com (Once I move everyone over I will change the ext URL to mail.domainname.com and switch the NAT rule in the firewall)
With netsol I have mail.domainname.com and EX2013.domainname.com(temp
I created EX2013.domainname.com 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 EX2013.domainname.com once the transition is done.
I also have on internal DNS zone for domainname.com. It has Mail and autodiscover currently pointed to EX07 and a record EX2013.domainname.com pointed to EX2013's private IP.
I have a public CA cert with mail.domainname.com and autodiscover and EX2013.domainname.com 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.
[Problems]
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 EX2013.domainname.com. 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 "djk38hf-4ne9f924-dkj@doma
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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 mail.domainname.com 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.
The Exch2013 I went to a different CA and purchased your standard UCC cert for this server.
ASKER
Simon,
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
$URLName="Exch2013.domainn
#Change this value to match the real name of the server
$ComputerName="Exch2013"
Get-WebServicesVirtualDire
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 mail.domainname.com. Since we use split DNS mail.DN.com 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 Exch2013.dn.com. But I get 2(sometimes 3) login prompts every time I open Outlook.
Any thoughts on what be causing this one? Thank you.
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
$URLName="Exch2013.domainn
#Change this value to match the real name of the server
$ComputerName="Exch2013"
Get-WebServicesVirtualDire
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 mail.domainname.com. Since we use split DNS mail.DN.com 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 Exch2013.dn.com. But I get 2(sometimes 3) login prompts every time I open Outlook.
Any thoughts on what be causing this one? Thank you.
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.
Simon.
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.
Simon.
ASKER
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 mail.domainname.com instead of Exch2013.domainname.com. Once I ran your code, complete with the externalurl as Exch2013.domainname.com the cert error went away.
I believe that was because of internal split DNS. It would look for mail.domainname.com 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?
Thanks,
Mike
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 mail.domainname.com instead of Exch2013.domainname.com. Once I ran your code, complete with the externalurl as Exch2013.domainname.com the cert error went away.
I believe that was because of internal split DNS. It would look for mail.domainname.com 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?
Thanks,
Mike
ASKER
Simon provided a wonderful site and script to help ease the migration to an Exchange 2013 platform.
ASKER
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.
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.
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.
Simon.
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.
Simon.
ASKER
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.
Regards,
Mike
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.
Regards,
Mike
ASKER
I ran your script and changed everything internal and external to EX2013.domainname.com. 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.