Link to home
Start Free TrialLog in
Avatar of ITtelligent
ITtelligent

asked on

Exchange 2013 Outlook Anywhere

Hi Experts,

I have just recently migrated a server from Exchange 2007 to 2013. Apart from going a little slowly, it had no real troubles.

Now that we've got the mailboxes over and 2007 removed, Outlook clients cannot connect.  When they try, they get "The attempt to log on to Microsoft Exchange has failed.". I've read a heap of different notes about SSL, host names, authentication methods, RCP back end - but nothing seems to help.  I cannot connect internally or externally. I've tried with a variety of different Outlook versions, all with the same result.

I'm using a wild card cert, and I think I've got it correctly configured, i.e. autodiscover presents msstd:*.domain.com.

Extremely frustratingly the Microsoft Remote Connectivity Analyzer reports no problems at all.

Checking the HTTP/RPC logs, I can see that my attempts are getting are getting HTTP status codes of 401, but the Microsoft tool is getting 200s, and working fine, but other than reading the status codes, I can't make much sense of the logs.

Do you all have any suggestions on how I can track down the problem?
Avatar of giltjr
giltjr
Flag of United States of America image

What version of Outlook are you running?

What type of security is Outlook configured for when doing RPC over HTTP?

Is this on your LAN or over the Internet?
Avatar of John Christopher
John Christopher

Hi,

Try validating DNS entries
 did u find anything under application logs ????
Try outlook Logging
check if the certificate name matches the website, make sure certificates aren't expired and that they are trusted.
confirm if the firewall is set up correctly... ExRCA would help check firewall status.
Avatar of ITtelligent

ASKER

@giltjr  I've tested with Outlook 2007 and Outlook 2010. Both are at most current versions. Also I've tested the exact same clients against other Exchange 2013 servers without issue.  The current security is NTLM, with IIS security being NTLM and Basic.  If has the exact same behavior over both LAN and externally over the internet.

@John Christopher - the DNS all resolve to the right things.  I have had it split, i.e. internal URLs pointing to the internal DNS name and external URLs pointing to external, that didnt make any difference. It is currently set to the same URLs, that resolve properly internally/externally. The certificate is a brand new wild card cert. All DNS names I are using match that cert.
Also does any one know why the Exchange Remote Connectivity Analyzer reports OK, but Outlook refuses to work? It seems paradoxical.
Over the Internet unless you are allowing the ports required for NLTM through your firewall  the clients should be configured to use basic authentication.

What do you see in the event logs (not the HTTP logs)?
@glitjr, it was my understanding that all of this Outlook Anywhere traffic is all encapsulated in HTTPS traffic.  The only port that should be forwarded is HTTPS, irregardless of what authentication methods.

Is this not correct?
Well yet, but some firewalls mess with the packets in a way that NTLM does not work.  I know NTLM does not work at my company, however in addition to a firewall we also use F5 to load balance a pair of CAS servers.
@giltjr I can see your angle. However my problem is internal and external. And the Exchange Remove Connectivity Analyzer (which is external) reports A-OK.

So at the moment, I'd be completely happy with resolving internal Outlook Anywhere connectivity - which is all within the same local subnet, clients talking directly with Exchange.
Hi,

What build is your exchange and installed on what OS ??

 This can be a compatibility issue as well with exchange 2013..

as you know till last year we had many issues before exchange 2013 sp1 was released..
 exchange 2013 wasn't supported on windows 2012 r2 std... before exchange 2013 sp1 was released..
do u have the compatible environment...

Thanks & regards
John chris
Hi,

Also try this link, helped one of my clients to set up Outlook anywhere...

https://4sysops.com/archives/outlook-anywhere-for-exchange-2013/
i also doubt abt the wild card cert.... is it possible for you to get a SAN certificate and give it a go..
Are you forcing Outlook to use RPC over HTTP?  If so do you have any type of load balancer that is also used when the users are on the LAN?

We use the load balancer internally also and so even when on the LAN if we force RPC over HTTP we have to use basic authentication.

However, you said that NO authentication works, right?
Please make sure your DNS and MX records are pointing to the right server name/IP.

Internally you should have something like: mail.server.com --- >  192.168.1.10
Externally you should have something like mail.server.com --- >  70.256.13.251

If you are able to open you ECP screen on the 2013 exchange server, select servers from the left side menu and move to virtual directories on the right side.  Here make sure that all your virtual directories have the same name for internal and external access.  (https://mail.mydomain.com)

Restart your IIS
MX records should not come into play at all for Outlook Anywhere.

I found one thing, that you may have already found:

If you installed a wildcard certificate on your Exchange 2013 server – you must perform the following:

    Update your EXPR setting – Set-OutlookProvider EXPR -CertPrincipalName msstd:*.company.com
    Update your EXCH setting (yes!) – Set-OutlookProvider EXCH -CertPrincipalName msstd:*.company.com
@John Christopher Exchange 2013 SP1 CU7, on Server 2012 R2.  I've not tried a SAN cert, but I've tried a regular cart, with all of the hosts names referring it correctly (mail.domian.com) and I had the same unsuccessful result.  That's a nice article you linked and my settings reflect that. My setup passes step 4, the ERCA passes, but Outlook doesn't connect.

@giltjr. Yes, the HTTPS connection is forced. Valid settings are pushed out through autodiscover. No load balancer in place, as noted the clients connect directly to the Exchange server within the local network. Different authentication methods do work for ERCA. I can get it to work with basic or NTLM. It makes no difference to the Outlook clients, they still do not connect.

@hecgomrec Yes, DNS is valid. I've double, triple checked this.  If this was a problem surely ERCA wouldn't connect? Yes, all URLs of my virtual directory have the same base DNS name.
@giltjr Yes, nice tip on the EXCH one. I came across that late yesterday. It has been applied already - without success.
I'm banging my head against a wall as to why the Exchange Remove Connectivity Analyzer (ERCA) works but my Outlooks clients do not - surely they should either both work or both fail.

Reconfirming, I've tried the very same Outlook clients (2007 & 2010) on a different Exchange 2013 system successfully.
you indicate you have triple check.

What do you get when you run a CMD and ping for yourmail.domain.com.

Are you able to go on your browser for yourmail.domain.com
@hecgomrec I get the right IP when I ping, inside and out.

ActiveSync and OWA which use the same DNS name, are working completely fine, inside, outside and with ERCA - so think that solidly confirms my DNS are OK.
Also I can clearly see the communication getting HTTP 401 errors for (both internal and external) Outlook clients and HTTP 200 codes for ERCA in my HTTP RPC logs - I just can't understand why that would be the case.
Could this have something to do relating to public folders? They were migrated across. They operate fine within OWA. But perhaps Outlook is looking for some link I've not corrected since the migration?
I've located a possibly related error in my event logs.

Watson report about to be sent for process id: 6408, with parameters: E12IIS, c-RTL-AMD64, 15.00.1044.025, M.E.RpcClientAccess.Service, M.E.RpcClientAccess.Parser, M.E.R.ArraySegmentExtensions.SubSegment[T], System.ArgumentNullException, 5b8e, 15.00.1044.021.
ErrorReportingEnabled: True
What is the event ID?

Only hits I have found, and I assume you too, are against older versions of Exchange.  A couple seem to be bugs, and few seem to be related to CAS not be able to get to a mail box.
@giltjr 4999. Yes I can't match up the error in any searches either.
Microsoft have been debugging this for 3 days, without success.

We installed another Exchange server side by side and migrated the mailboxes over. As soon as the mailboxes were on the new server, they opened in Outlook.

Looks to be a corruption in the RPC systems.

Will update ticket with MS finish what they're investigating.
Ok this just bump me now...

After recent updates, I don't recall exactly what I reboot first or last, but I had to bring my exchange servers down together with my main DC.  Restarted main DC and only after it was up I brought up my exchange servers and problem solved.

I had the same issues described here... all tests passed from outside but there was no mail flow anywhere.

Looks like Exchange did not locate the main DC and authentication was not happening afterwards.

I'll keep more time between servers restart from now on... maybe I reboot them too fast to close to each other and the my DC takes a long time to boot up... is in a box (No VM).
@hecgomrec We've rebooted the troubled server many times over the troubleshooting period. I didn't seem to have any trouble authenticating. We've a primary and backup DC in this scenario.
ASKER CERTIFIED SOLUTION
Avatar of ITtelligent
ITtelligent

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
No experts offered a working solution. Self solved.