Hi

I have what I can only describe as a strange issue.

Over the last weekend I switched our E2010 CAS role over to E2013 CAS role in readiness to migrate over to E2013. The users mailboxes remained on E2010 server.

We have a split DNS, With outlook Anywhere enabled internally with a separate DNS entry/ address for the CaseArray role from the Outlook Anywhere role.

E2013 is running the latest patched version, E2010 on rollup 7.

While all the testing and connection at the time worked with the test pool of users, and the email enable application worked, I started to user calls with various connection issues.

These were as follows.

1.       When logging on to their mailbox via WebApp, they received the message :

 something went wrong

Sorry, we can't get that information right now. Please try again later. If the problem continues, contact your helpdesk.

X-ClientId: KBPU - 9ERN - EWGB - ILGLMXKG

X-FEServer: EXCMGGBMC002

But they were able to connect using outlook.

1.       Outlook prompting constantly for user authentication, at first I thought this was only the users that were still on outlook 2010,but it also effect users on outlook 2013 to. Both versions of outlook are fully patched and up to date.

The strange thing about both were that one was not related to the other and whatever mailbox / client combination I tried to test on several clients I could not replicate the issue.

With the outlook version it got even stranger. While testing on my account my outlook correctly connected to my mailbox using RCP/TCP protocol. But the users that were having issues the connection status was still trying on RPC/HTTP.  To add to the strange situation, if I replaced there users details on the login prompt with a service account that has access to their mailbox, outlook connected to their mailbox. They were able to work, and access any shared mailboxes they have and work as normal.

But Outlook was connecting via rpc/http and not TCP.

Which reading all documentation should not be possible when Outlook Anywhere is pointing to E2013 with a mailbox on E2010.

This has had me stumped, so any help would be extremely grateful from you guys & girls.

Hi Kev-P,

You must have already done this, but never hurts rechecking.

1.  Hope you have updated the SCP object for all servers 2013\2010.

Get-ClientAccessServer | fl Name, AutoDiscoverServiceInternalUri

Set-ClientAccessServer -Identity "CAS-01" -AutoDiscoverServiceInternalUri "https://cas01.contoso.com/autodiscover/autodiscover

2. Autodiscover and other DNS entries points to EXCH2013 ofcourse

3. Have you removed ex2010 all references on DNS for the common namespaces like mail.domain.com

4. Set OWA ExternalURL $null for Ex2010 servers, if you don't have any specific reason to keep them. OWA proxying will be affected if you have some value here.

5. Ex2010 InternalURLs are pointing to unique Ex2010 server FQDNs

6.  Permission Inheritance is blocked on the user object.

Solution: Re-enable permissions inheritance for the user object who has problem when access OWA or ECP. To do this, follow these steps:

1. Start ADSI Edit by clicking Start, click Run, type adsiedit.msc, and then click OK.
2. Locate the user object in question, right-click the object, and then click Properties.
3. On the Security tab, click Advanced.
4. Click Allow inheritable permissions from the parent to propagate to this object and all child objects to re-enable permissions inheritance.
5. Click OK two times to apply the change.
6. Wait for Active Directory replication to propagate the changes, or force Active Directory replication if it is necessary.

Look for any errors on CAS2013 side for connectivity.

The default Exchange 2013 internal Outlook Anywhere settings dont require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

Refernces:

http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

http://vanhybrid.com/2012/10/09/exchange-2013-interoperability-with-legacy-exchange-versions/

Hi Satyajit.

Thank you for you reply, in answer to your point below.

1) SCP is correct on all servers pointing to the correct entry in DNS for our mail URL

2) Yes DNS points to a NLB for both autodiscover and email URL, the NLB settings was changed to point to Ex2013 CAS instead of Ex2010 CAS.

3) We are using the same name space / URL so there should be no references point back to E2010 for them once the above was done.

4) Did not know about settings the Ex2010 ExternalURL to Null on the Ex2010 CAS that is one thing that I did not do.

5) all internalURL's point to the Ex2010 server they are configured on.

6)inheritance for the one of the users with the issue of connecting to there mailbox via WebApp  is correct and is on. 

I will check for error's in Ex2013 side, but as I had to roll back the change at the weekend I have no way of checking live on that at present.

Out of all the suggestions above the only think that was not removed was the externalURL settings on Ex2010 servers, would this cause the intermittent connection issues?

The part I don't fully understand though is that if I authenticated on any of the outlook clients with the issue, with the service account not connected to there mailbox the client connected. but would not do so with the account the mailbox belongs to.

If there was a connection issue with the settings, that should not have worked either.

Hi Satyajit.

Thank you for you reply, in answer to your point below.

1) SCP is correct on all servers pointing to the correct entry in DNS for our mail URL

2) Yes DNS points to a NLB for both autodiscover and email URL, the NLB settings was changed to point to Ex2013 CAS instead of Ex2010 CAS.

3) We are using the same name space / URL so there should be no references point back to E2010 for them once the above was done.

4) Did not know about settings the Ex2010 ExternalURL to Null on the Ex2010 CAS that is one thing that I did not do.

5) all internalURL's point to the Ex2010 server they are configured on.

6)inheritance for the one of the users with the issue of connecting to there mailbox via WebApp  is correct and is on. 

I will check for error's in Ex2013 side, but as I had to roll back the change at the weekend I have no way of checking live on that at present.

Out of all the suggestions above the only think that was not removed was the externalURL settings on Ex2010 servers, would this cause the intermittent connection issues?

The part I don't fully understand though is that if I authenticated on any of the outlook clients with the issue, with the service account not connected to there mailbox the client connected. but would not do so with the account the mailbox belongs to.

If there was a connection issue with the settings, that should not have worked either.

No need to remove the externalURL on the 2010 CAS for OWA. It will proxy fine within the same AD site. Typically you put the 2013 CAS ExternalURL here  as well, but not 100% necessary. Autodiscovery is version specific. Why it didnt work? Check the IIS logs and HTTP proxy logs on the 2013 server to see what IIS error was thrown.

Is Outlook Anywhere enabled on the 2010 CAS? It should be. 

What is set for the 2013 Outlook Anywhere setting?

get-outlookanywhere |FL

Hi

yes outlook AnyWhere is enabled on both environments, and works.

As I said the issue appears to be random. 

I carried the switch over at the weekend internally (external via TMG still pointing to Ex2010) and all worked ok with a majority of users who were in the office over that period (help desk, support staff). 

the problem appeared with a random set of users over time, were they were constantly prompted to enter there login details by outlook.  Other users didn't have any issues with outlook connecting ok to there mailboxes. Once the problem arose nothing appeared to let them past that stage unless i entered the service account instead of there account details and then outlook connected.

That is the part that is confusing me, if it is a proxy issue outlook would never have connected, if it was a authentication issue, then the service account should also have failed to authenticate. 

Hi

yes outlook AnyWhere is enabled on both environments, and works.

As I said the issue appears to be random. 

I carried the switch over at the weekend internally (external via TMG still pointing to Ex2010) and all worked ok with a majority of users who were in the office over that period (help desk, support staff). 

the problem appeared with a random set of users over time, were they were constantly prompted to enter there login details by outlook.  Other users didn't have any issues with outlook connecting ok to there mailboxes. Once the problem arose nothing appeared to let them past that stage unless i entered the service account instead of there account details and then outlook connected.

That is the part that is confusing me, if it is a proxy issue outlook would never have connected, if it was a authentication issue, then the service account should also have failed to authenticate. 

For the users that didnt work, did you try creating a new Outlook profile? Do they have Lync running? If so, kill it and then create a new Outlook profile and see if that works.

Yes, we went though all the normal remove ost, new profile, repair etc

still the same.

all users have Lync /or skype for business which is being rolled out. 

Even changing to a completely different PC / terminal server they had the same issue. Which makes it even more strange. thought they could login via WebApp (the group i was working with, when were not all on the same location)

Hi

yes outlook default setting is RPC/HTTP with both fast and slow networks boxes ticked. As per the guide.

http://blogs.technet.com/b/exchange/archive/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations.aspx

I didn't try it again by turning of this on the clients that don't work at the time, but even if I did and the rcp connection worked next time they start outlook it would again reset back to the above settings by the settings received from exchange.

The settings from the above command are as follows.

ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic, Ntlm}
ExternalHostname           : email.******.com
SSLOffloading              : False 

Hi

yes outlook default setting is RPC/HTTP with both fast and slow networks boxes ticked. As per the guide.

http://blogs.technet.com/b/exchange/archive/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations.aspx

I didn't try it again by turning of this on the clients that don't work at the time, but even if I did and the rcp connection worked next time they start outlook it would again reset back to the above settings by the settings received from exchange.

The settings from the above command are as follows.

ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic, Ntlm}
ExternalHostname           : email.******.com
SSLOffloading              : False 

Hi,

I noticed that the external server via TMG is still pointing to Ex2010. Please confirm the ExternalHostname for email.******.com is your Exchange 2010 or Exhcnage 2013.

In the problematic client when the issue occurs, please check the Connection Status (press CTRL key - right click on the Outlook icon from right bottom corner taskbar) to collect the following information:

Server Name, Status, Protocol, Authn, Encrypt, Type

Also confirm if there is any event logs in server side.

Regards,

email.*****.com is a the same on both sides of our network (split DNS) so while I had changed the internal network to point to E2013 the internet face via TMG was still pointing to Ex2010. Users connecting via that had no problem connecting.

The clients that were having issues, were stuck asking for login credentials, which kept prompting when they were using there own login. BUT when I changed the login details on the prompt to a service account, outlook connected and they were able to connect to there there mailbox. The connection type via connection status within outlook was stating outlook connected using rpc/http.

The clients that worked with no issues all connected using rpc/tcp.

both set's of clients were on the internal network. when there was a issue, it was not version related to outlook (2010 & 2013) or location user with issue were spread over UK, Hungary. Belgium and Malaysia.

Also if the user had the issue pop up, connection to a different system and using a separate client/ PC they still could not connect. which makes me thing it's not client set-up related.

[edit] The above example on the same client if a user worked and logged on via the same outlook client that didn't work with a user that did, outlook would connect ok.

It's not also exchange store related as the users were spread over multi stores.

The store were mounted on the same server.

• Edited by Kev-P 20 hours 36 minutes ago

Yes, we went though all the normal remove ost, new profile, repair etc

still the same.

all users have Lync /or skype for business which is being rolled out. 

Even changing to a completely different PC / terminal server they had the same issue. Which makes it even more strange. thought they could login via WebApp (the group i was working with, when were not all on the same location)

Hi,

Do you mean the WebApp access issue has been resolved and only the client side authentication issue occurs randomly for some users?

If all the mailboxes are still located in Exchange 2010, the Outlook should still connect to CAS 2010 for internal connection with RCP/TCP protocol. Please check the following settings in the problematic users and normal users Outlook clients respectively:

1. Click File > Account Settings, click Account Settings.
2. Click the E-mail tab, click the Exchange account, and then click Change.
3. Click More Settings, and then click the Connection tab.
4. Check whether Connect to Microsoft Exchange using HTTP is checked, then click Exchange Proxy Settings.
5. Confirm if the checkbox for fast network and slow network are checked or not.

Please uncheck Connect to Microsoft Exchange using HTTP to use RCP/TCP protocol and check whether the issue persists. If the issue only happens when using RPC over HTTP (Outlook Anywhere), please check your Outlook Anywhere settings in server side:

Get-OutlookAnywhere | fl Identity,*auth*,*HostName*,*SSL*

Regards,