Link to home
Start Free TrialLog in
Avatar of get-ADuser -F ($_.Name -eq "Todd")
get-ADuser -F ($_.Name -eq "Todd")Flag for United States of America

asked on

Exchange 2013 CAS HA doesn't work with second Exchange 2013 server

I have 2 Exchange servers.  Servers are oxexsrv1 and oxexsrv2.  Both with CAS and mailbox roles.  I also have a DAG in place.  I have a split dns in my internal dns of mail.company.com and autodiscover.company.com.  Both have Round Robin Host A records pointing to each I.P. Address of both Exchange servers.  I performed a Test-OutlookWebService  for my mailbox in both servers, and was successful.  I also made sure that my AutoDiscoverServiceInternalUri matches the Autodiscover.xml file and they do.  

My problem is, that if I shut down oxexsrv1, my Outlook client will not connect to oxexsrv2.  The DAG moves the datastores from passive to active no problem.  But my client will not connect, nor will OWA work.  I tried ipconfig\flushdns.  I have pinged the mail.company.com and it points to oxexsrv2 when 1 is shut off.  But it just wont connect.

I don't know what to do.  I think I tried everything but I obviously am missing something.  Another thing to note is that while oxexsrv1 is on, I can  perform a server switchover to oxexsrv2 and it works fine there too for the datastores.  But if oxexsrv1 is off, it is if oxexsrv2 CAS role just wont work.  (There are no firewalls on blocking 443)

Fairly new to Exchange.  I have had a consultant help, but he seems to be stumped too.  This is really driving me crazy, and any suggestions would be most welcome.  Powershell is still a little new to me, so I apologize in advance if I have questions to your suggestions on how to perform the cmdlet.
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

With Exchange 2013, Outlook Anywhere  (OA, formerly RPC over HTTP) is always used for connections. And by default, OA URLs still refer to individual FQDNs.  So you'll want to change the hostname for OA to the round-robin DNS record.

You can use get-outlookanywhere to view your existing settings and set-outlookanywhere to set them.  Autodiscover is only half the battle. It'll still pass on specific references if that is how OA is configured, which is the default.
Avatar of get-ADuser -F ($_.Name -eq "Todd")

ASKER

I did the Get-outlookanywhere, and it give me a whole lot of listings of information.  It looks like it is referencing both servers with the cmdlet and also looks like everything matches.  What property or name and its value am I specifically looking for?
Internalhostname for both servers show mail.company.com.
That should be working then as long as mail.company.com has records for both CAS servers.  I'd probably try a network capture on the client when you shut down the server. See what it is doing and follow the contact path. You aren't seeing a certificate error (you mentioned 443, not 80) and you have properly configured certificates for both CAS servers using the mail.company.com hostname in the certificate?
Yes exactly.  No certificate error and both EX CAS have same certificate installed using the CN mail.company.com.  Not even using SAN at all.  That is why I am so frustrated.  It should work.  How do I do a network capture?
All I do is watch the Outlook connection status fail.
Netmon is a program that can grab a capture. As can wireshark.  Netmon files can even be viewed in Wireshark (which is the method I most prefer.  No extra drivers for netmon, but wireshark has better formatting and filtering in my opinion.
Ok cliff, today I am going to put Wireshark on a laptop that has outlook on it.  I won't be able to turn off EX2 until Monday, because of end of month.  (Everyone needs their email).  Not being familiar with Wireshark, what would you suggest that I look for. (What do I capture?). The EX1 is on 10.1.1.14 and EX2 is on 10.1.1.230.  Not sure if that is relevant, but still learning.
Nothing worked.  Netmon showed me that Outlook.exe was going to .230.  But still wouldn't connect.  DAG passive and active mount switches over like a charm but doesn't help me when no client can connect to it.
Then this probably isn't a failover issue at all. If it were, outlook would still be trying to connect to .14, not .230.  This sounds more basic and would probably be a problem even without HA in the mix.  Make sure your CAS services are started.  Check the event log for CAS related errors. Run the Exchange BPA.  Check and make sure firewall rules aren't blocking traffic that the CAS uses.  Treat this like you would troubleshooting a single CAS server that isn't allowing client connections.
I will try the BPA.  Didn't look for Event log errors at the time, but will look and see next time I test this SOB.  I like the idea of treating like a single CAS server.  You may be right.  I just need a win on this thing.  Just once!
BPA would not work because it failed to install .Net Framework 3.5 SP1.  I looked to see what was installed and I have .net 4.0  Not sure I want to mess with installing 3.5 for fear it will screw up what is installed.  Unless you think otherwise.
Also CAS services?  Lot of services in there.  Anything specific?
I recommend regular BPA scans of manor services, so a.net 3.5 is no big deal. It is obviously introducing change, so make a backup.
Well, not sure if I am doing this right.  I went to Exchange under tools in the ECP and tried to install from there.  It failed with the above posted message.  Are you saying to install 3.5?  Then try it again?   Makes me nervous.
Correct.  .Net 3.5 is used by a ton of apps and is an option (but often installed) feature in new OSes.  It isn't even a download but is included with the OS media because it is so prevalent. Just use the add roles and features wizard under server manager and you'll see .Net 3.5 in the features section.
ASKER CERTIFIED SOLUTION
Avatar of get-ADuser -F ($_.Name -eq "Todd")
get-ADuser -F ($_.Name -eq "Todd")
Flag of United States of America image

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
As above mentioned, it was the "sharedwebconfig.config" not being present on EX2 that caused all the problems.  An Exchange Incident ticket was created and the support team found this through reading event logs, that I could not understand.
This was resolved after purchasing an Incident Help Desk Ticket through Microsoft Support.