none
Autodiscover fails after mailbox move

    Question

  • Hello,

    Environment: existing exchange 2010 org, with new Exchange 2013 introduced. Clients are Outlook 2013. Clients can connect to all mailbox on the 2010 Server, also can connect to new mailboxes on the 2013 Server. But if I move an existing mailbox from the 2010 Server to the 2013 server Outlook cannot connect anymore, because autodiscover fails. Both servers use the same autodiscover settings, SCP contains the same URL.

    TIA

    Update: I've just installed an Outlook 2010 for testing purposes and it is working! From this point it may be rather a client side problem than a server side...

    Monday, August 18, 2014 7:17 PM

Answers

  • Hey there,

    I actually installed 2013 using the CU5 install files. So you are right, CU5 does not matter from a first look, but it does matter overall for this issue. Keep reading.

    Tangent: This appears to be unrelated but I will mention it anyways. I noticed, after the mailbox was migrated that when I am on the internal network, autodiscover fails the same way it does for you. However, when I bring the client off the corporate network and have it connect via the public Internet, autodiscover suceeds. When testing with EXRCA autodiscover also succeeds. Please do note that external access to Exchange is handled by Microsoft's Web Application Proxy.  This proxy performs "pass-through" authentication of autodiscover so that may have something to do with it.

    Back to the main issue of Outlook staying disconnected after the migration.  I wasn't going anywhere with this so I opened a case with Microsoft. I was able to replicate the problem with the support tech and they were also able to replicate this in their lab. This was the conclusion:

    This is a known issue. It happens because when a mailbox is moved to 2013, the mailbox itself still has a cache entry that points the client back to the 2010 server. From what Microsoft said, this cache expires in an "undetermined" time interval for Exchange 2013 SP1 up to CU4 and every "2 to 2.5 hours" in Exchange 2013 CU5. They could not reference a KB article with this info.

    Microsoft mentioned that the cache is also cleared when recycling the IIS Application Pool that runs RPC on the 2013 CAS server which is also caused by an IISreset. However, I have not been able to verify the application pool recycle method in my tests. From what I can see, IISreset is the only way to clear the cache. I have sent a follow-up to Microsoft asking which App Pools specifically need to be recycled to avoid having to perform a full IISreset. I will test and report back here.

    In any case, here is my strategy moving forward which was blessed by the Microsoft team:

    1. Create a migration batch for a number of users (in my case I will make it 5 to 10 users at a time)
    2. Select to "Manually Complete the batch" in the "New Local Mailbox Move" window. This process will migrate 95% of the mailbox and then stop. 
    3. Once the migration has gone through 95% and it stops syncing, the batch shows as "synced" on the migration window. Until this point in the process, users are able to use Outlook without any interruption and the move is invisible to them.
    4. When I am ready to finish the migration, I will select to "Complete This Migration Batch" on the ECP Migration screen. At this time, users that have Outlook open will receive a prompt to restart it. When Outlook re-opens it will show as "Disconnected" until the next step is performed.
    5. Once the batch shows as "completed" I will perform an IISreset on the 2013 CAS server (or recycle the appropriate app pools once Microsoft provides them to me.) At this time, Outlook will show as "Connected to Microsoft Exchange" and users will receive a second prompt to restart Outlook. After the second restart you'll be good to go!

    I will try to time my migration so they complete after hours, when most people are less likely to have Outlook open.  Don't forget, that the cache entry that causes all these issues is cleared after about 2 to 2.5 hours if you are on 2013 CU5. In any case, I think it's better if you have control over when the migration finishes by opting to complete it manually.

    Hope this helps.

    Fable

    EDIT: Microsoft has confirmed that recycling the following Application Pools makes Outlook connect to Exchange 2013:

    Exchange 2013 CAS Server:

    • MSExchangeAutodiscoverAppPool
    • MSExchangeRpcProxyFrontEndAppPool

    Exchange 2013 Mailbox Server:

    • MSExchangeAutodiscoverAppPool
    • MSExchangeRpcProxyAppPool

    If you decide to not do an iisreset and opt for recycling the App Pools instead, be advised that after the AppPools are recycled, Outlook connects to Exchange and asks to be restarted. If you close Outlook and immediately open it again, you will be prompted with a username and password pop-up (At least I was in all my tests of this method.) This issue is resolved if, after you close Outlook, wait 5 to 10 minutes before you re-open it. You will not be prompted for a user/pass at this point.

    • Edited by tFable Thursday, August 21, 2014 1:43 AM added info on how to resolve by recycling apppools
    • Marked as answer by Temesvári Gábor Thursday, August 21, 2014 8:11 AM
    Thursday, August 21, 2014 12:09 AM

All replies

  • Did you point autodiscover.domain.com to exchange2013 server? If not please change it now. 
    Did you configure the URLs in exchange2013? If not please configure the same URL of exchnage2010 in exchange2013. Please check this and this


    MAS

    Monday, August 18, 2014 7:56 PM
  • Autodiscover points on both server to mail.domain.com. There is no autodiscover. prefix in use on the internal net. And as I mentioned, autodiscover is working for all mailboxes except the one that has been moved to the 2013 server.

    Tuesday, August 19, 2014 6:04 AM
  • Autodiscover should be pointing to exchange 2010 only if you don't have a load balancer in place. Please check this

    Your outlook should be outlook 2007 SP3 (with this update) or higher

    I strongly suggest
    --Enable outlook Anywhere on all the clinets/mailboxes as in exchange2013 outlook use RPC/HTTP even for intranet connections.  
    --Configure split DNS for resolving external URLs. Reference here


    MAS

    Tuesday, August 19, 2014 6:54 AM
  • Hi,

    Please check whether the moved mailbox can be accessed from OWA 2013. Since the moved mailbox can work well in an new installed Outlook 2010, please create a new Outlook profile for the moved mailbox to have a try. 

    For Exchange 2013 mailbox, all Outlook connectivity takes place over Outlook Anywhere(RPC/HTTP). Thus, your old Outlook profile for Exchange 2010 connection is not enabled Outlook Anywhere in Outlook. After creating a new profile, the new account information can be retrieved and Outlook services can be connected to the new server.

    Regards,


    Winnie Liang
    TechNet Community Support


    Tuesday, August 19, 2014 10:58 AM
    Moderator
  • Split DNS is in place, but it only resolves mail.domain.com. Outlook Anyhere is enabled on both servers.

    There is no load balancer, only one 2010 and one 2013 server. Mail.domain.com points to the 2013 server.

    Now we have similar to this (except the load balancer):

    And again, Outlook 2010 clients can connect using Outlook Anywhere.

    Tuesday, August 19, 2014 11:36 AM
  • The moved mailbox can be accessed via OWA, and Activesync as well. Outlook Anywhere is enabled on both servers. I cannot create a new Outlook profile, it fails because it cannot connect to the server. If I run the Thes e-mail autoconfig from Outlook, it fails to. If I move back the mailbox to the 2010 server, Outlook 2013 connects fine.
    Tuesday, August 19, 2014 11:42 AM
  • And again, Outlook 2010 clients can connect using Outlook Anywhere.

    Is that user a Exch2013 user or Exch2010 user?

    Did you try to move a user who is using outlook 2013 ?
    Did you try configuring a new profile for the moved mailbox? If not please try that.

    It seems outlook anywhere not enable on outlook



    MAS

    Tuesday, August 19, 2014 11:45 AM
  • After I move the mailbox from 2010 server to 2013 server, Outlook 2010 can connect to the mailbox, but Outlook 2013 can not.

    New profile cannot be configured as it does not find the mailbox.

    Outlook 2013 settings are the following (automatically configured, not manually):


    Tuesday, August 19, 2014 12:02 PM
  • I've just tested this way:

    1. I created a new account+mailbox on the 2010 server
    2. Connected to the new mailbox using Outlook 2013, this was okay
    3. Moved the mailbox to the 2013 server
    4. Outlook asked to be restarted, after restart it remained disconnected, autodiscover failed
    5. Uninstalled Outlook 2013, installed Outlook 2010 which connected fine
    6. Uninstalled 2010, installed 2013, but it was disconnected again

    I'm confused...

    Tuesday, August 19, 2014 2:19 PM
  • Did you install the certificate on Exchange2013?
    Outlook will only connect with Outlook Anywhere and for that to work, you need to have a certificate installed that your clients trusts.

    Did you configure autodiscover URLs and other URLs as per the link provided?


    MAS


    • Edited by MAS- Tuesday, August 19, 2014 2:28 PM
    Tuesday, August 19, 2014 2:21 PM
  • Verify the results of Get-ClientAccessServer | FL AutoDiscoverServiceInternalUri
    This should point to the New Exchange 2013 Server.


    Syed MM Messaging SME - IBM || MCTS || MCSE || MCSA || VCP5 || VCA ||

    Tuesday, August 19, 2014 2:40 PM
  • Certificate is installed on the 2013 server, OWA is working fine on this server for all mailboxes.

    Certificates are domain wide trusted as the Root CA is trused. I don't see any cert errors.

    URLs are configured to point to mail.domain.com, DNS is configured to point this address to the 2013 server.

    Tuesday, August 19, 2014 2:41 PM
  • The strange thing is marked with yellow

    Tuesday, August 19, 2014 2:56 PM
  • Please test autodiscover using this as well https://www.testexchangeconnectivity.com/

    Is it showing the same error


    MAS

    Tuesday, August 19, 2014 4:12 PM
  • I decided to restart the 2013 server, just for fun. After the reboot autodiscover started working for the migrated user to. Now I'm going to try to reproduce this behaviour.
    Tuesday, August 19, 2014 10:28 PM
  • Hello,

    I was having this issue yesterday while testing but with some differences. My environment:

    - Existing Exchange 2010 Environment. All 2010 servers on SP3 CU 3. Exchange 2013 Servers on SP1 CU 5

    - Clients include Outlook 2010 SP1 and Outlook 2013 SP1

    Test was as follows:

    - Create new mailbox using Exchange 2010, drop on 2010 mailbox DB

    - Create Outlook profiles in both Outlook 2010 and Outlook 2013. All works fine. Mail flows.

    - Move clients to the public Internet so Outlook Anywhere kicks in. All good here

    - From Exchange 2013, initiate a new migration for the test mailbox. 

    - When the migration finishes Outlook throws a pop-up and asks to be restarted

    - After restart, Outlook 2010 and 2013 stay disconnected. Looking at the Outlook "Connect Status" screen the client tries to connect to the Exchange 2013 server but the connection fails and it drops back to the 2010 server. When I tested this yesterday, autodiscover failed for me as well. However, today, autodiscover works fine when tested from outlook even when it is in the disconnected state.  Not sure why this is

    - On the 2013 CAS perform "iisreset"

    - Both Outlook clients ask to be restarted again.

    - After restart, Outlook 2013 works like a charm. Outlook 2010 prompts for username and password.

    I am not sure why autodiscover was failing yesterday but works fine today. 

    In fact, when I tested Autodiscover with exrca the test timed out when performed from the website and the when performed from the local client it caused the exrca client to crash after about 15 minutes of trying.

    Every single time, though, iisreset on the Exchange 20130 CAS was the solution.

    I am obviously not adding anything to the solution here here but I wanted to let you know that I am seeing a very similar issue. I actually came to the boards today to post my own experience with this problem. Since my issue is a bit different than yours I probably still will.

    fable


    • Edited by tFable Tuesday, August 19, 2014 10:59 PM typo
    Tuesday, August 19, 2014 10:56 PM
  • After restart did you try moving one more mailbox to exchange2013?

    MAS

    Wednesday, August 20, 2014 3:10 AM
  • Fable, thanks for sharing!

    MAS, after iisreset, created another new test mailbox, repeated the test the same way and the result was the same: autodiscover failed. After another iisreset the problem was solved. I can reproduce this any time.

    Now I'm going to CU5 the 2013 server.


    Wednesday, August 20, 2014 12:02 PM
  • Your exchange should be fully patched better.

    Meanwhile please make sure Autodiscover authentication and SSL settings are correct

    http://technet.microsoft.com/en-us/library/gg247612(v=exchg.150).aspx


    Thanks,
    MAS
    Please mark as helpful if you find my comment helpful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, August 20, 2014 12:11 PM
  • CU5 had not effect on this issue. IIS settings are correct.
    Wednesday, August 20, 2014 7:40 PM
  • Hey there,

    I actually installed 2013 using the CU5 install files. So you are right, CU5 does not matter from a first look, but it does matter overall for this issue. Keep reading.

    Tangent: This appears to be unrelated but I will mention it anyways. I noticed, after the mailbox was migrated that when I am on the internal network, autodiscover fails the same way it does for you. However, when I bring the client off the corporate network and have it connect via the public Internet, autodiscover suceeds. When testing with EXRCA autodiscover also succeeds. Please do note that external access to Exchange is handled by Microsoft's Web Application Proxy.  This proxy performs "pass-through" authentication of autodiscover so that may have something to do with it.

    Back to the main issue of Outlook staying disconnected after the migration.  I wasn't going anywhere with this so I opened a case with Microsoft. I was able to replicate the problem with the support tech and they were also able to replicate this in their lab. This was the conclusion:

    This is a known issue. It happens because when a mailbox is moved to 2013, the mailbox itself still has a cache entry that points the client back to the 2010 server. From what Microsoft said, this cache expires in an "undetermined" time interval for Exchange 2013 SP1 up to CU4 and every "2 to 2.5 hours" in Exchange 2013 CU5. They could not reference a KB article with this info.

    Microsoft mentioned that the cache is also cleared when recycling the IIS Application Pool that runs RPC on the 2013 CAS server which is also caused by an IISreset. However, I have not been able to verify the application pool recycle method in my tests. From what I can see, IISreset is the only way to clear the cache. I have sent a follow-up to Microsoft asking which App Pools specifically need to be recycled to avoid having to perform a full IISreset. I will test and report back here.

    In any case, here is my strategy moving forward which was blessed by the Microsoft team:

    1. Create a migration batch for a number of users (in my case I will make it 5 to 10 users at a time)
    2. Select to "Manually Complete the batch" in the "New Local Mailbox Move" window. This process will migrate 95% of the mailbox and then stop. 
    3. Once the migration has gone through 95% and it stops syncing, the batch shows as "synced" on the migration window. Until this point in the process, users are able to use Outlook without any interruption and the move is invisible to them.
    4. When I am ready to finish the migration, I will select to "Complete This Migration Batch" on the ECP Migration screen. At this time, users that have Outlook open will receive a prompt to restart it. When Outlook re-opens it will show as "Disconnected" until the next step is performed.
    5. Once the batch shows as "completed" I will perform an IISreset on the 2013 CAS server (or recycle the appropriate app pools once Microsoft provides them to me.) At this time, Outlook will show as "Connected to Microsoft Exchange" and users will receive a second prompt to restart Outlook. After the second restart you'll be good to go!

    I will try to time my migration so they complete after hours, when most people are less likely to have Outlook open.  Don't forget, that the cache entry that causes all these issues is cleared after about 2 to 2.5 hours if you are on 2013 CU5. In any case, I think it's better if you have control over when the migration finishes by opting to complete it manually.

    Hope this helps.

    Fable

    EDIT: Microsoft has confirmed that recycling the following Application Pools makes Outlook connect to Exchange 2013:

    Exchange 2013 CAS Server:

    • MSExchangeAutodiscoverAppPool
    • MSExchangeRpcProxyFrontEndAppPool

    Exchange 2013 Mailbox Server:

    • MSExchangeAutodiscoverAppPool
    • MSExchangeRpcProxyAppPool

    If you decide to not do an iisreset and opt for recycling the App Pools instead, be advised that after the AppPools are recycled, Outlook connects to Exchange and asks to be restarted. If you close Outlook and immediately open it again, you will be prompted with a username and password pop-up (At least I was in all my tests of this method.) This issue is resolved if, after you close Outlook, wait 5 to 10 minutes before you re-open it. You will not be prompted for a user/pass at this point.

    • Edited by tFable Thursday, August 21, 2014 1:43 AM added info on how to resolve by recycling apppools
    • Marked as answer by Temesvári Gábor Thursday, August 21, 2014 8:11 AM
    Thursday, August 21, 2014 12:09 AM
  • Fable, than you very much for the detailed info, I'll mark this as answer.

    In my tests if Outlook was open during the mailbox move, simply closing and re-opening it after iisreset did not solved the problem: autodiscover started to work, but Outlook stayed disconnected until a profile repair and another re-open. This is unacceptable in a simple mailbox move operation.

    It's okay that there is a cache that works like this, but I really don't understand why is this not documented or at least mentioned anywhere? What would be the suggested moving method to avoid interruption in the mail flow of the affected users? What if I move mailboxes between 2013 servers?

    This iisreset or app pool recyc is rather a workaround, than a solution.

    Thursday, August 21, 2014 8:11 AM
  • Hey Temesvári,

    Thanks for marking my post as an answer. From all of my tests, after IISreset is performed it will take Outlook a short period (usually under 2 minutes) of time to try to reconnect and then it will show the pop-up saying it needs to be restarted. After that restart, Outlook connects with no additional issues.

    I have found that the method I described, starting the batch and manually completing it, ensures minimal interruption for the end user. This way the admin can choose when the Outlook disconnects will occur and have enough time to perform the IISreset.  While the migration batch is sitting in "synced" mode and before you manually select to complete it, there is no interruption in mail flow, none. I have tested this extensively.

    I agree that there should be better documentation of this issue, this is why I tried to make my post as descriptive as possible. Hopefully search engine queries will redirect other desperate users here.

    You are correct saying that this is just that, a workaround.  Hopefully it will be addressed in one of the future updates.

    Thursday, August 21, 2014 3:34 PM
  • We have the same problem. Exchange 2013 CU7 and Exchange 2013 CU8.
    Friday, March 27, 2015 12:09 PM
  • Seeing the same issue with Exchange 2013 CU8 as well.

    @Alex, were you able to resolve this other than using the methods above?
    Thursday, May 28, 2015 5:22 PM
  • same problem here with Ex2013CU8 in coexistence with Ex2010. 

    any news about this Issue? Reset IIS on EX2013 oder Recycle Application Pools seems not to be a real solution... 

    Thanks. Best, 

    Martin

    Wednesday, June 10, 2015 11:23 AM
  • same Problem here with Ex2013CU10 in coexistence with Ex2010 SP3 UR5 and Office 2010 SP2 Client.

    Recycling App Pools works!

    Wednesday, November 11, 2015 3:05 PM
  • Hello

    Not sure if anyone is monitoring this still or not.  We are having the same issue but but we are on CU 10 which i would think this issue had been resolved this far down the road.  After every mailbox move we have to recycle the autodiscover app pool.   It looks like Tfable hit the nail right on the head second post not sure where all those other posts were coming from.

    Did you guys ever figure out what the fix is?   Or even why this behavior exists.

    Thursday, January 07, 2016 11:10 PM
  • Hi,i just want to mention that this behaviour exists in Ex2016 too.

    ATM i migrate our users from Ex2010 to Ex2016 and about 5% of the users can't connect their (fully patched) Outlook 2010 to the newServer.

    Is therestill no real solution?


    Thursday, February 25, 2016 3:44 PM
  • Same issue here with Exchange 2016 RTM and exchange 2010 SP3 RU11. This is in forums from 2014, how is this still an issue?
    Friday, May 06, 2016 1:06 AM
  • Just found this:
    https://support.microsoft.com/en-us/kb/3097392

    It's been documented by Microsoft in November of 2015 but it's not marked as a bug and only has the workaround to restart the AutoD App pool.  I have a case open with Microsoft and I'm trying to get a better, more permanent resolution.

    Monday, May 09, 2016 7:42 PM
  • Did you have any luck with this. I'm in the same boat. Exchange 2010 SP3 CU12. I was asked to try https://support.microsoft.com/en-us/kb/3073002 as well which seemed to make sense with trying to ignore the cached reference in the Outlook profile but it didn't help. The only thing that did was the Autodiscover application pool recycle on the Exchange 2016 servers.
    Monday, June 27, 2016 5:47 PM
  • Hello

    I am the one who originally started this question and seems to have taken on a life of it's own.   So far I have not seen anything that works.  We ended up changing the app recycle schedule to ever 30 minutes.  Has not impacted our performance at all.   However we do not use the automatic option during working ours.  We use manual option of moves during regular hours.   With manual you have to create the job, go back in start job then complete job which I believe part of that process under the hood is app pool recycle.

    This issue has been around for a long time and am really surprised that it still exists in EX2016.   I guess they will tell you that it works fine in the cloud.  

    Monday, June 27, 2016 6:32 PM
  • Thanks for taking the time to response to such an old issue. It is amazing that this is still an issue. When you select the "Manual Complete the batch..." option for a migration you're saying you don't have to recycle the Autodiscover appPool or do you wait long enough that 1/2 hour Autodiscover recycle is most likely correcting the issue before you proceed with finishing the migration?
    Monday, June 27, 2016 6:44 PM
  • When you do this using Manual batch I believe it has does its own app recycle or has some other way communicating the changes.  So no it has nothing to do with the 30 minute app pool recycle.

    What I find unacceptable about this approach is you need start the batch manually and then when complete you need complete batch which means you have to be watching the move and complete it right when it is done.

    I personally have not done this but others on my team say that it works.

    Monday, June 27, 2016 6:51 PM
  • I agree this is not a acceptable solution. I guess a workaround is better than nothing. Thanks for sharing.
    Monday, June 27, 2016 6:57 PM
  • are you kidding Microsoft ????

    Same problem here with a migration from Exchange 2010 CU15 and 2016 last CU (3 or 4 not remember)

    What the fuck it is ! If it's a caching problem, add a parameter to set a small caching time we can use during migration, like 10min. And after the migration complete we can go back to default if it can be a performance problem.

    But how I can migrate hundreds of mailbox if I have to do a IISReset each time ? We are never closed, 7/7 24/24 so ...

    It's unbelievable that such bugs are not corrected

    Friday, November 25, 2016 1:07 PM
  • This is definitely the same issue I have in my environment. We set our autodiscover app pool to recycle every 15 minutes and migrated almost a 100 users with no issues. Then last week after no changes in our environment we did a batch of 180 users. The following morning, we had around 25 users suffering from the disconnection issue. Even manually recycling the autodiscover app pool did nothing. For these particular clients we had to click repair on their outlook profile and this forced the connect after outlook restarted.
    Tuesday, November 29, 2016 3:02 PM
  • Yeah it's pretty absurd that it hasn't been fixed. I did get through migrating about 3000 users using the following method:

    1. Set the migration batches to be manually completed.
    2. Once I got the email telling me that the initial sync was done I would reset the Autodiscover AppPool and the Exchange Web Services AppPool on all Exchange 2016 servers (see at bottom).
    3. Once the AppPools were recycled I would complete the migration batch.

    It's a workaround but it's better than waiting for MS to fix it. Judging from the age of this post I'd say it's not changing anytime soon.

    Notes:

    • I had to recycle the EWS because people were not getting calendar availability for migrated users.
    • I had no reports that the Autodiscover recycle caused any disruption to the end users.
    • I only had one person report a "disconnection" between Outlook and Exchange when recycling EWS. It could have happened to other but they might not have noticed it because it would connect back pretty quick.
    • The IIS recycle process stands up an new AppPool process to service all new request for the application and closes down the old AppPool process once all of its requests have finished. If the old AppPool process does not have all of its requests finished within 90 seconds (by default) it will force the old process closed. In my environment the old Autodiscover AppPool process always gracefully closed but the old EWS AppPool process always timed out and was forcibly closed.

    I used PSExec to remotely recycle all of the AppPools at once. PSExec is a Sysinternal utility available from Microsoft. You can launch PowerShell as a users with Exchange server admin rights and change to the directory that you have PSExec.exe stored in then copy and paste the following commands all at once so you get the carriage returns:

      

    psexec \\ExchangeServer1 C:\Windows\System32\inetsrv\appcmd recycle appPool MSExchangeAutodiscoverAppPool

    psexec \\ExchangeServer2 C:\Windows\System32\inetsrv\appcmd recycle appPool MSExchangeAutodiscoverAppPool

    psexec \\ExchangeServer1 C:\Windows\System32\inetsrv\appcmd recycle appPool MSExchangeServicesAppPool

    psexec \\ExchangeServer2 C:\Windows\System32\inetsrv\appcmd recycle appPool MSExchangeServicesAppPool
    Start-Sleep -s 95

    You may not need to recycle the MSExchangeServices (EWS) if you don't have problems with calendar availability information with migrated users. I have the sleep command at the end to wait passed the 90 second time out for the EWS to force the old AppPool closed before I complete the batch.  

    Good luck and thanks again to JDFAdmin for his follow ups in the post.

    Tuesday, November 29, 2016 4:45 PM
  • There was a patch for Outlook to address the issue where you have to manually repair the Outlook profile but it looked like it had mixed reviews:

    https://blogs.technet.microsoft.com/exchange/2014/02/21/outlook-2013-profile-might-not-update-after-mailbox-is-moved-to-exchange-2013/

    Probably doesn't help you if you already migrated.

    Tuesday, November 29, 2016 4:55 PM
  • Hi

    Autodiscover is not working if the UPN/Userlogin name and Mail login is not the same on the domain account

    UPN = pet@contoso.com

    mailadress:

    pet@contoso.com

    This is the same white Active sync on mobile deviceswhen you set up youre mobile devices.

    See Link:

    http://blogs.perficient.com/microsoft/2015/07/office-365-why-your-upn-should-match-your-primary-smtp-address/

    Best regard Anders



    Monday, December 05, 2016 2:39 PM