Home / server / Questions / 761827
Accepted
xstnc
Asked: 2016-03-06 09:26:29 +0800 CST

Exchange 2010 - Exchange 2016 co-existence and migration

  • 772

I've setup a co-exist environment with Exchange 2010 and Exchange 2016.

At the moment mail-flow seems to work with no problems what so ever, and I have migrated two test-users from 2010 to 2016.

SMTP traffic and HTTPS is proxied from the new Exchange 2016 installation - and works fine for the 2010 users behind.

My problem is that when the users are migrated, outlook 2016 is having issues connecting to the new server.

When I open outlook, it still uses RPC/HTTP towards the old server.

If I delete the old profile, and re-create it using autodiscover, it works fine.

I then see MAPI traffic and it hits the new server as expected.

This would cause a problem if I manually have to re-create profiles for all the users in our company..

Does anyone have any pointers?

Edited with more information:

I migrated my own user, and I had my outlook open. I got the message that my box was migrated and that I needed to restart outlook; and so I did! My mobile-phone and OWA works like intended, and it's just my outlook clients acting up. It happened on two of my computers connected to the same mailbox and same user (home and office computer).

When opening my outlook client I get the certificate warning message with the name of my old servers internal name (like: Exch2010.domain.local), and the certificate in use is for our FQDN as mail.company.com.

Second Edit:

I just migrated a test-user from 2010 with outlook closed and tried connecting from an external network. It asked me the question if I wanted to allow https://mail.company.com/autodiscover/autodiscover.xml to edit my settings. I clicked "allow", and nothing happened. The mailbox stayed in a disconnected state and the connection status had one connection which had the status "established". The connection was proxied through mail.company.com and to Exch2010.company.local. I restarted outlook and the same thing happened.

Then I moved the client from the external network, and put it in our internal network instead. Now it gives me the same message "allow this website to configure [email protected] server settings?" but with the local name of the NEW exchange server in an URL format like "https://exch2016.company.local/autodiscover/autodiscover.xml". I allowed and accepted the certificate warning (as it said it was using the local name again - exch216.company.local; which doesn't match the SSL cert).

Outlook is still not operational and is in a "disconnected" state. My own mailbox is "established" but doesn't update.

Out of curiosity I checked the servers by running:

Get-AutodiscoverVirtualDirectory | fl

InternalURL and ExternalURL for all three are blank. I'm not experienced enough to tell if this is correct or not.

For some reason, it seems like the servers are internally announcing their local names instead of the correct "mail.company.com".

I also checked the servers by running:

Get-ClientAccessServer -Identity SERVER | fl

All of them got the AutoDiscoverServiceInternalUri set to "https://mail.company.com/autodiscover/autodiscover.xml".

FQDN for all of them is set as their local hostnames (servername.company.local).

I have no idea what to try next..

Edit number three; as a reply to @Sembee: Hello @Sembee; thanks for your reply. I left them blank and did no changes. I checked the InternalURI for clientaccessserver on all three servers, and they are identical. The Autodiscover-tests complete without problem and have done so since the beginning. Re-configuring a users outlook makes the outlook work again (fresh data from autodiscover). All traffic are passing through the 2016 server for now (afaik), and proxies OK to the 2010 server. None have mentioned any problems. Outlook just isn't working after migrating to 2016 without re-creating the profile and running a new autodiscover.

Fourth edit: When I came in to work today, my own laptop (did not work yesterday/sunday) AND the laptop (did not work on saturday) I use for testing both worked fine. It could be some sort of delayed sync doing this to me? I'm currently setting up another test, to see if it behaves in the same way - and if its possible to time it somehow. Any pointers would be much appreciated.

exchange

5 Answers

  1. Lets start with the easy bit. The Autodiscover virtual directories should be blank. That is normal and you shouldn't change those.

    Next, all servers in the same AD site should have the same information for the internal Autodiscover URL. Furthermore that should point to the new server and be a name that is on the trusted SSL certificate. Thus:

    get-clientaccessserver | set-clientaccessserver -AutodiscoverServiceInternalURI https://mail.example.com/Autodiscover/Autodiscover.xml

    When you have done that, run an Autodiscover test in Outlook. Hold down CTRL while right clicking on the icon in the system tray. Choose test email auto configuration. Deselect the second and third options. Run the tests - see what is being returned to the client.

    Next, check the configuration of Outlook Anywhere. Again that should be identical across all servers because it can proxy it across. Check both the internal and external URL.

    Mailboxes should redirect automatically - failing to do so can be an indication of poor domain replication. However it also depends on how quickly you tried to use the mailbox after moving it to the new server. Again you do have to wait a little while for the domain to replicate the change for Outlook to pick it up.

    • 0
  2. Best Answer

    After trying for hours, with help from a colleague; we managed to get this working as intended.

    I started with a reinstall of Exchange 2016 on both new servers, and set them up from scratch. A few of the things we did the second time around got this to work.

    We started out with checking all the information in:

    Get-OutlookAnywhere | fl

    Setting -InternalClientsRequireSsl to false; as we decided it's not needed internally due to the design of the network and the fact that our cert doesn't contain the internal name of our server.

    We also set the auth to use NTLM for external and internal auth for all servers. We also changed the priority of Windows authentication (putting NTLM) on top for RPC in IIS. After running an IIS reset; everything seems to work as intended. I'm unsure if we missed an IIS reset or reboot in our first attempt, but atleast it's working now!

    • 0

  3. I think you have to consider as two part. First look your MAPI configuration for internal outlook either 2010 or 2013

    Verify your server setting mapi authentication should select windows authentication ntlm and windows authentication negotiate.

    As per Microsoft documents some of client still can connect as Rpc/http and it will works

    • 0

  4. We had the same issue. After migration outlook clients don't connect. found the mapi virtual directory keeps removing the authentication. Once that is put back it connects. If you change the urls then it clears the authentications.

    • 0

  5. I think this is a known issue from Microsoft, for me simply recycle the MSExchangeAutodicoverAppPool from IIS console or use the following command 

    Restart-WebAppPool MSExchangeAutodiscoverAppPool

    while waiting for an update, you can configure auto-recycle of this AppPool in IIS you can read from this link

    https://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange-2013-or-exchange-2016

    • 0