Furthermore that should point to the new server and be a name that is on the trusted SSL certificate. Next, all servers in the same AD site should have the same information for the internal Autodiscover URL. That is normal and you shouldn't change those. The Autodiscover virtual directories should be blank. 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. 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. Outlook just isn't working after migrating to 2016 without re-creating the profile and running a new autodiscover. All traffic are passing through the 2016 server for now (afaik), and proxies OK to the 2010 server. Re-configuring a users outlook makes the outlook work again (fresh data from autodiscover). The Autodiscover-tests complete without problem and have done so since the beginning. I checked the InternalURI for clientaccessserver on all three servers, and they are identical. I also checked the servers by running: Get-ClientAccessServer -Identity SERVER | flĪll of them got the AutoDiscoverServiceInternalUri set to " ".įQDN for all of them is set as their local hostnames ().Įdit number three as a reply to thanks for your reply. I'm not experienced enough to tell if this is correct or not.įor some reason, it seems like the servers are internally announcing their local names instead of the correct "". InternalURL and ExternalURL for all three are blank. Out of curiosity I checked the servers by running: Get-AutodiscoverVirtualDirectory | fl My own mailbox is "established" but doesn't update. Outlook is still not operational and is in a "disconnected" state. I allowed and accepted the certificate warning (as it said it was using the local name again - which doesn't match the SSL cert). Now it gives me the same message "allow this website to configure server settings?" but with the local name of the NEW exchange server in an URL format like " ". Then I moved the client from the external network, and put it in our internal network instead. I restarted outlook and the same thing happened. The connection was proxied through and to.
The mailbox stayed in a disconnected state and the connection status had one connection which had the status "established". It asked me the question if I wanted to allow to edit my settings. I just migrated a test-user from 2010 with outlook closed and tried connecting from an external network. When opening my outlook client I get the certificate warning message with the name of my old servers internal name (like: ), and the certificate in use is for our FQDN as. It happened on two of my computers connected to the same mailbox and same user (home and office computer). 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.
I migrated my own user, and I had my outlook open. This would cause a problem if I manually have to re-create profiles for all the users in our company. I then see MAPI traffic and it hits the new server as expected. If I delete the old profile, and re-create it using autodiscover, it works fine.
When I open outlook, it still uses RPC/HTTP towards the old server. My problem is that when the users are migrated, outlook 2016 is having issues connecting to the new server. SMTP traffic and HTTPS is proxied from the new Exchange 2016 installation - and works fine for the 2010 users behind. I've setup a co-exist environment with Exchange 2010 and Exchange 2016.Īt the moment mail-flow seems to work with no problems what so ever, and I have migrated two test-users from 2010 to 2016.