?
Solved

Exchange 2010 CAS array without internal/external DNS

Posted on 2012-09-13
21
Medium Priority
?
1,252 Views
Last Modified: 2012-11-25
Hi y'all, this has been driving me crazy for days and I can't find good information on it anywhere.

How do I configure it so that my CAS array FQDN cannot be resolved externally while still allowing clients to resolve it internally?  We have no hardware load balancer, we have no split DNS, we have no internal domain name, we have no ISA server.  Basically, there is no "external" vs. "internal" aside from not being able to talk to domain controllers unless you're on one of our subnets.

Ultimately, what we need is something like the following

HUBCAS1 and HUBCAS2 configured in a NLB cluster
MBX1 and MBX2 configured in a DAG
OWA, Outlook Anywhere, Autodiscover, Activesync, etc. work no matter what network the client is on.

It works simply and straightforwardly in 2007, but this requirement to not have the CAS Array's FQDN resolvable externally is throwing me for a loop.  If I don't put an entry in DNS, then clients on our subnets will not be able to find the CAS Array.  If I put an entry in DNS, then clients not on our subnets will resolve the FQDN of the CAS Array and try to do a MAPI RPC connection.  It's a catch-22.

Please, somebody set me straight!  It can't be that complicated.  Thanks in advance!
0
Comment
Question by:McCombsExchange
  • 11
  • 8
  • 2
21 Comments
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38397148
Understand CAS Array was brought into the picture ONLY AND ONLY for load balancing. So, if you are facing such a big issue where you have no LB no Firewall no ISA. Are you suggesting that your Exchange box is facing the internet?

What you are supposed to do in this case.

Have External URL populated in your AutoDiscover / OAB / OOO / EWS etc ONLY.

Internally, clients are least bothered about your external links. Let your internal links for all these be set to default, this means that internally if your OL clients are going to connect - they would use DNS route to discover SCP Points (which is your CAS boxes) and work peacefully.

Externally, OL clients will try to connect to you're URL that would be something sort of https://owamail.domain.com/autodiscover/autodiscover.xml - owamail would point to your firewall IP which would NAT to internal IP of your CAS.

Your internal clients are least bothered to understand what owamail is all about since they connect to https://CAS Server Name/autodiscover/autodiscover.xml

Regards,
Exchange_Geek
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38397234
I'm sorry, but I don't think that addresses our situation.  I think I may not have described the situation adequately.  No firewall.  No NAT.  No internal IP/external IP.  The IP address is just *the* IP address, no matter where you are.

HUB/CAS servers are configured in a NLB cluster for load-balancing and fault tolerance.
Suppose the servers' FQDNs are HUBCAS1.company.com and HUBCAS2.company.com.  Suppose the FQDN of the shared IP is owa.company.com.

We also have dozens of subdomains for people's primary SMTP addresses.  Suppose I have users like user1@sub1.company.com, user2@sub2.company.com, etc.

Currently, each of our subdomains has an SRV record that points autodiscover to owa.company.com as the Exchange server name, and from there they get the name of the Exchange virtual server used by the mailbox CCR cluster.

We don't want the clients to use HUBCAS1.company.com or HUBCAS2.company.com.  They need to just use owa.company.com as the server name, and let the NLB cluster figure out which server to send the client to.

What am I missing here?
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 1600 total points
ID: 38397240
I suggest that you setup an internal only DNS. You must have DNS on AD domain controllers for Exchange to work correctly - domain.local or something like that.
Then configure the CAS array to use that host name.

Use your existing external name on the internet for everything else - web services etc. That should allow everything to work correctly.

You cannot use the same name for the Exchange server CAS/Array as for everything else, you are just going to confuse Exchange and the clients.
If the name of the CAS array resolves, then clients are going to try and connect to it over TCP/IP which will fail because they will also need to directly access the domain controller, which will require port 135, a port that most ISPs block and shouldn't be exposed to the internet.

Simon.
0
Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

 
LVL 5

Author Comment

by:McCombsExchange
ID: 38397254
Hi Simon!  Long time, no see.

Yes, I know you can't use the same name for the CAS Array as for everything else, and I understand about trying to connect over TCP/IP and the timeout due to port 135 being blocked plus not being able to reach any DCs.  Believe it or not, I have over a dozen years of Exchange admin experience and three previous major migrations under my belt.  I just work in an environment where there really isn't internal vs. external so I can't figure out how to make this work!

I was planning on something like outlook.company.com for the CAS Array instead of owa.company.com which would be used for everything else.

How do we set up an internal only DNS for just one host name?  We don't have domain.local or anything like that.  It's just company.com.
0
 
LVL 33

Assisted Solution

by:Exchange_Geek
Exchange_Geek earned 400 total points
ID: 38397266
It is pretty simple, you provide facts to us and we'll provide you solutions by our experience - you keep facts hidden, you'll get solutions that'll never match your scenario.

You just mentioned

HUB/CAS servers are configured in a NLB cluster for load-balancing and fault tolerance. Suppose the servers' FQDNs are HUBCAS1.company.com and HUBCAS2.company.com.  Suppose the FQDN of the shared IP is owa.company.com.

AND you mentioned earlier

We have no hardware load balancer, we have no split DNS, we have no internal domain name, we have no ISA server

As i said earlier, CAS Array is just an AD Object - nothing else - if you do not provide a LB, OL clients will individually be pointed to your respective CAS Servers.

Now, if i understand your new example - you've got a LB that has CAS as its members. LB hostname is name as owa.domain.com - so this host name would be required to be placed as internal URL for your Exchange features.

Now, for internal clients - understand they connect using SCP points, if SCP fails then they fail over to autodiscover. DNS as you mentioned is being shared between internal and external users using same FQDN. Well, in this case you're stuck - if you're internal users fail to connect to your hostname (LB) only then the OL would point to autodiscover.

OL connects internally using the following process
=> Search for SCP Connectiong (that is your CAS or CAS Array)
=> If above fails connect to autodiscover SRV using https
=> If above fails connect to autodiscover SRV using http.
=> If all above fail, Availability service fails.

Regards,
Exchange_Geek
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38397287
I haven't changed my story.  I specifically said I have an NLB cluster and no HARDWARE load-balancer.

Assuming I understand you correctly, I think I configure the internal URLs exactly the same way I have now, pointing to owa.company.com.

Where would I enter outlook.company.com (CAS Array FQDN) into the configuration if I'm not putting it on any of the virtual directories' URLs?

So, how does Outlook know when it is "internal" vs. "external"?  That is, how does it know to skip the search for SCP connection and go straight to connecting to autodiscover SRV using https?
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 1600 total points
ID: 38397311
You must be using AD DNS servers for Active Directory to work. You cannot rely on external DNS server.
Furthermore you shouldn't be using those AD DNS servers for DNS on the internet either as that will be a security risk.

Exchange is dependant and designed to work in a seperate environment, where you have internal and external resources. Your environment is unusual so you have got to fake it a bit. You need a host name that doesn't resolve externally so that the clients don't get confused. So create the zone on your internal DNS servers.

There is always a possibilit that the platform is going to have to be redesigned to accomodate how Exchange works because you aren't using it how it should work. The implemenation you have is not something I would have done. Even if I had the public addresses, the entire thing would be behind NAT. It woudl ahve split DNS, it would ahve internal and external DNS servers. Simply because that is how things are designed to work and it will make life easier.
That is how hosted Exchange platforms are designed - I have never seen an Exchange implemenation using the same IP addresses internally and externally.

Outlook knows because it cannot connect to the domain. When the connection to the domain controller fails it reverts to DNS entries. Hopefully your domain controllers do not resolve on the internet.

There is a heavy dependance within Exchange and the client for simply failing to connect/resolve in order to work correctly. If things resolve or connect then Outlook will presume it is on a LAN, and that will fail.

While the CAS array is used for load balancing, it is not the only reason to have it. As far as I am concerned every implementation of Exchange 2010 should use an RPC CAS Array, whether one server or fifty.

Simon.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38398622
I quite agree with you, Simon, but this is the environment I have to work with and they're not going to completely overhaul the entire networking infrastructure of thousands of users just to make sure one host name doesn't resolve externally but does resolve internally.

We do of course have AD-integrated DNS, but we also zone transfer to caching DNS servers, and that is what is accessible externally and what our clients are configured to use.  Would it be as simple as to create a zone for outlook.company.com in AD DNS and not transfer that zone to the caching servers?  Would that allow domain-joined clients on the local network to resolve outlook.company.com even though they are configured to use the caching DNS servers as their DNS servers?

That is what I was proposing to my boss yesterday, but he remained unconvinced that it would work.

I also agree that the CAS Array is necessary even when not used for load-balancing, which is why I've been chasing my tail trying to figure this out.  I really appreciate the input from you both, Simon and Exchange_Geek.
0
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 1600 total points
ID: 38398863
If you have control over the internal DNS, then do what I suggested above and create a zone for a domain that doesn't resolve externally. Use something completely different - companyname.local for example, and then setup outlook.companyname.local and use that for the RPC CAS Array. It will never resolve on the internet and that should clear most of the issues you will have over connecting.

However if you are using the same DNS servers internally and externally I don't think this is going to work. That isn't how networks are setup these days and the site is going against the grain. I don't know what else to suggest, because Exchange is designed to work in a certain way. I am surprised it hasn't caused you more problems with Active Directory working in that way as well.

Simon.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38406502
So is it possible then to not have a DNS record for the CAS Array FQDN at all?  What is the downside to that?

Would it not be the case then, that all clients will simply do the DNS lookup for a CAS array FQDN, find that it does not resolve, and connect via Outlook Anywhere RPC/HTTPS and never have the timeout issue?
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38406895
You need an FQDN for the CAS array internally. You cannot be without one.
Outlook Anywhere is just a proxy, the clients will still connect to the CAS Array address.

Simon.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38407029
How does that work?  Right now, Outlook Anywhere clients connect to mail.company.com and that lets them connect to the NLB IP address for our HUB/CAS cluster.  Why would that suddenly not work?

I have Microsoft engaged on this right now, but I am having trouble communicating to them about why the clients will not connect first via HTTPS if the CAS array FQDN is resolvable externally.  I was hoping they could go more in depth than we can here in this medium, but it seems probably not.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38414581
If the host resolves externally then Outlook will attempt to connect on TCP/IP. You then have to wait for that to time out before it fails over to HTTPS.
I have seen on more than one occassion though that failover simply doesn't happen if the server name (CAS Array) can be communicated with in any manner. It simply confuses Outlook.

Do get your call escalated if they struggle to understand, but as I have already said - this is a very unusual configuration and be prepared for Microsoft to turn round and simple say it is an unsupported and/or untested configuration.

Simon.
0
 
LVL 5

Assisted Solution

by:McCombsExchange
McCombsExchange earned 0 total points
ID: 38447600
We are getting creative with our DNS delegation, conditional forwarding and zone transfers. That plus changing the DNS servers handed out by DHCP should take care of the issue.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38479961
Hi Sembee,

Just trying to understand what you said here:
Outlook Anywhere is just a proxy, the clients will still connect to the CAS Array address.
Why does it need to be the CAS Array?  In 2007 Outlook Anywhere will happily let us connect to the NLB cluster IP address of our CAS servers.

How does a client know that it is "internal"?
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38483920
It knows it is internal because it is able to connect to the server using TCP/IP. As I wrote above, Outlook Anywhere depends on failing to connect to the Exchange server host name to start using HTTPS.

I don't know how you have been using an IP address, but your entire configuration is not any like a regular configuration. If you were to enter an IP address, if everything is working correctly that should be corrected to the server name, or if you are using Exchange 2010 with an RPC CAS Array, the CAS array address.

Simon.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38526066
Hi Simon,

That seems a bit circular to me.  The clients connect via TCP/IP when they are internal.  Well, how do they know they're internal?  They know they're internal when they connect via TCP/IP.  I'm more confused now.

When I said in 2007 OA will connect to the NLB cluster IP address, I didn't mean people put in the IP address.  I mean they put in the FQDN of the NLB cluster and then Outlook's able to connect to the cluster via the cluster's IP.

My boss wants to understand exactly why the 2007 way won't work anymore.  In 2007, if I have a notebook and I'm offsite, my Outlook client will know not to try to connect via TCP/IP and will go straight to Outlook Anywhere.  How?  Magically at some point, as soon as I step onsite, the Outlook client will know to try to connect via TCP/IP.  How?
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38535986
I thought I had already explained this.
It knows it is internal because it can connect on TCP. Outside the office that fails to work.

If you start Outlook from the command line with the rcpdiag switch :

outlook.exe /rpcdiag

you should see it attempt to connect on TCP, then connect on HTTPS.

Simon.
0
 
LVL 5

Author Comment

by:McCombsExchange
ID: 38592176
The disconnect here must be happening because "inside the office" and "outside the office" are terms that don't have real meaning for us.

So all Outlook clients always try to connect on TCP first by default?  And they won't switch to using Outlook Anywhere/RPC over HTTPS unless/until that fails?  There's never a case where Outlook knows to just jump in with RPC/HTTPS?
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 1600 total points
ID: 38595632
That is correct.

The configuration as delivered by Autodiscover has the clients attempting to connect via TCP first, then failing back. This allows Outlook Anywhere to be enabled on the server and pushed out to all clients, but only used when the clients are off network.

You can manually configure the clients to always use HTTPS connections, but of course that will be corrected by autodiscover automatically.

As I said further up the page, the way that you are operating is not the regular way and not how Exchange 2010 was designed to work.

However, Exchange 2013 on the other hand could work for you.
All connections on Exchange 2013 are over HTTPS, the TCP/MAPI method no longer exists. That means you can have a single URL for both internal and external traffic, which will always connect over HTTPS.

Simon.
0
 
LVL 5

Author Closing Comment

by:McCombsExchange
ID: 38629798
Simon was incredibly long-suffering while talking me through the minutia of the consequences of our non-standard environment.

Ultimately, we had to fake internal/external DNS using some servers that hosted a zone for just the CAS array FQDN and that zone can be resolved "internally" but is not transferred to the public DNS servers, so the CAS array FQDN is not resolvable "externally".

If you're here because you are similarly situated and trying to figure out what to do, put your deployment on hold.  Go and tell your boss that 1998 called and it wants its network topology back, and that you'll be able to go forward with the migration when they give you a big-girl AD to work with.
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to effectively resolve the number one email related issue received by helpdesks.
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
A short tutorial showing how to set up an email signature in Outlook on the Web (previously known as OWA). For free email signatures designs, visit https://www.mail-signatures.com/articles/signature-templates/?sts=6651 If you want to manage em…
Suggested Courses

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question