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...

• Edited by Temesvári Gábor Monday, August 18, 2014 7:36 PM

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

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.

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

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,

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.

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.

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

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):

• Edited by Temesvári Gábor Tuesday, August 19, 2014 1:15 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...

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 pro

Verify the results of Get-ClientAccessServer | FL AutoDiscoverServiceInternalUri
This should point to the New Exchange 2013 Server.

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.

The strange thing is marked with yellow

Please test autodiscover using this as well https://www.testexchangeconnectivity.com/

Is it showing the same error

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.

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

After restart did you try moving one more mailbox to exchange2013?

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.

• Edited by Temesvári Gábor Wednesday, August 20, 2014 12:08 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

CU5 had not effect on this issue. IIS settings are correct.

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

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.

Hey Temesvri,

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.

We have the same problem. Exchange 2013 CU7 and Exchange 2013 CU8.

Seeing the same issue with Exchange 2013 CU8 as well.

@Alex, were you able to resolve this other than using the methods above?

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