Contextual Guidance at the moment of need helps your employees adopt to new software or processes instantly. Boost knowledge retention and employee engagement step-by-step with one easy solution.
Course Of The Month
6 days, 14 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Active Directory Domain Name with On-Premisis Exchange Server: Split-Brain DNS (split DNS)
Posted on 2014-12-14
Searching the Web produces many articles offering Best Practices for naming the Active Directory Domain on a local LAN.
The prevailing sentiment seems to be to use a subdomain of the entity's primary FQDN. For example, the company widget.com might have an AD domain of ad.widget.com or corp.widget.com. The LAN AD would use a unique subdomain of the primary FQDN.
My question has to do with Exchange in the above setting. It seems that the recommended configuration for Exchange is to use Split-Brain DNS (split DNS). Unless I am misunderstanding this, that would suggest that I should name the local LAN widget.com (rather than ad.widget.com or corp.widget.com).
I would like to better understand the pro's and cons of choosing to configure my AD Domain as a subdomain (e.g. ad.widget.com), and the impact on deploying an on-premisis Exchange server in that environment.
Please advise.
Thank You.
The prevailing sentiment seems to be to use a subdomain of the entity's primary FQDN. For example, the company widget.com might have an AD domain of ad.widget.com or corp.widget.com. The LAN AD would use a unique subdomain of the primary FQDN.
My question has to do with Exchange in the above setting. It seems that the recommended configuration for Exchange is to use Split-Brain DNS (split DNS). Unless I am misunderstanding this, that would suggest that I should name the local LAN widget.com (rather than ad.widget.com or corp.widget.com).
I would like to better understand the pro's and cons of choosing to configure my AD Domain as a subdomain (e.g. ad.widget.com), and the impact on deploying an on-premisis Exchange server in that environment.
Please advise.
Thank You.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
3
2
10 Comments
Active 3 days ago
The name of the Windows domain doesn't really matter, as long as you get the DNS correct.
The main reason people say to use a sub domain, particularly with the increase in web services is that it becomes very clear what is internal and what is external. If you have mobile users then the end user doesn't have to wait for a name resolution attempt to timeout, or a wildcard to get in the way.
However within Exchange, there is one critical part that is affected, and that is Autodiscover.
Externally Autodiscover will want to connect to Autodiscover.example.com - where example.com is the part of the email address after the @ sign.
As such, most implementations of Exchange will use something along the lines of host.example.com for the public facing web services (both internal and external).
The best advice I can give you is to be very clear on the three roles a domain plays:
- The WINDOWS domain.
- The WEB SERVICES domain.
- The EMAIL address.
Having all three the same can work, but does mean particular care has to be taken over the DNS configuration both internally and externally.
Web services and email address domain are often the same, I think almost every deployment I have done which isn't a multi tenant type implementation has been configured like that.
The web services domain is configured within the internal DNS, but it is not the AD DNS zone.
What domain you use for the Windows domain doesn't really matter, as long as it is something that either you control, or does not resolve on the internet.
This last point can be important. With increasing frequency (as AD domains get older) questions are asked about renaming the domain, because it was called widget.com, but the company is now called super.com.
Perhaps because of a buy out, merger, loss of a legal case etc, or just marketing wanting to eliminate all traces of the old name. Therefore choosing something very generic (ad.local) means that it doesn't matter. I have three sites that I am involved with that use a very generic domain, on purpose. Makes no technical difference, other than ensuring there are no problems later on because of name change.
Simon.
The main reason people say to use a sub domain, particularly with the increase in web services is that it becomes very clear what is internal and what is external. If you have mobile users then the end user doesn't have to wait for a name resolution attempt to timeout, or a wildcard to get in the way.
However within Exchange, there is one critical part that is affected, and that is Autodiscover.
Externally Autodiscover will want to connect to Autodiscover.example.com - where example.com is the part of the email address after the @ sign.
As such, most implementations of Exchange will use something along the lines of host.example.com for the public facing web services (both internal and external).
The best advice I can give you is to be very clear on the three roles a domain plays:
- The WINDOWS domain.
- The WEB SERVICES domain.
- The EMAIL address.
Having all three the same can work, but does mean particular care has to be taken over the DNS configuration both internally and externally.
Web services and email address domain are often the same, I think almost every deployment I have done which isn't a multi tenant type implementation has been configured like that.
The web services domain is configured within the internal DNS, but it is not the AD DNS zone.
What domain you use for the Windows domain doesn't really matter, as long as it is something that either you control, or does not resolve on the internet.
This last point can be important. With increasing frequency (as AD domains get older) questions are asked about renaming the domain, because it was called widget.com, but the company is now called super.com.
Perhaps because of a buy out, merger, loss of a legal case etc, or just marketing wanting to eliminate all traces of the old name. Therefore choosing something very generic (ad.local) means that it doesn't matter. I have three sites that I am involved with that use a very generic domain, on purpose. Makes no technical difference, other than ensuring there are no problems later on because of name change.
Simon.
Active 3 days ago
Don't forget that if you want to use a UCC certificate (e.g. for activesync) then the naming will be important (e.g. .local is no longer supported)
Active 4 days ago
I though .local was being discouraged due to recent changes changes with SSL Certificates.?
Active 4 days ago
Simon,
Are suggesting that I could have an Exchange server name exg.widget.com both internal and external to the LAN, and that server can be joined to an AD that is ad.widget.com?
I though joining the exchange server to the above mentioned domain would automatically make it exg.ad.widget.com (rather than exg.widget.com). This would give it a different name internal to the LAN as compared to externally.
Am I overlooking something?
Are suggesting that I could have an Exchange server name exg.widget.com both internal and external to the LAN, and that server can be joined to an AD that is ad.widget.com?
I though joining the exchange server to the above mentioned domain would automatically make it exg.ad.widget.com (rather than exg.widget.com). This would give it a different name internal to the LAN as compared to externally.
Am I overlooking something?
Active 3 days ago
yes that's right, but also bear in mind the 5 names you will use - e.g. exchange.widget.com, autodiscover.widget.com, exchange, mail.widget.com, exchange.ad.widget.com etc
Active 4 days ago
So, if I were to use ad.widget.com as my AD Domain would the following be true?
Your help is much appreciated.
exchange.widget.com - this would be used external to the LAN
autodiscover.widget.com - would not work from within the LAN but would externally
exchange - I'm not sure what this one is for (just the server name)
mail.widget.com - for ?
exchange.ad.widget.com - for use inside the LAN
Your help is much appreciated.
Active 3 days ago
exchange.widget.com - this would be used external to the LAN - correct
autodiscover.widget.com - would not work from within the LAN but would externally - correct, you may want to consider autodiscover.ad.widget.com
exchange - I'm not sure what this one is for (just the server name) - sometimes inside the domain Outlook can try to connect to the server without a domain - not strictly necessary but useful
mail.widget.com - for - external access depending on your DNS setup - e.g. you may have clients trying to access https://mail.widget.com/owa
exchange.ad.widget.com - for use inside the LAN - correct
so exchange and mail.widget.com are not strictly necessary but you will need to consider your external DNS and exchange settings
You usually get 5 domain names when getting a UCC so in that case I would include the exchange name without a domain...
autodiscover.widget.com - would not work from within the LAN but would externally - correct, you may want to consider autodiscover.ad.widget.com
exchange - I'm not sure what this one is for (just the server name) - sometimes inside the domain Outlook can try to connect to the server without a domain - not strictly necessary but useful
mail.widget.com - for - external access depending on your DNS setup - e.g. you may have clients trying to access https://mail.widget.com/owa
exchange.ad.widget.com - for use inside the LAN - correct
so exchange and mail.widget.com are not strictly necessary but you will need to consider your external DNS and exchange settings
You usually get 5 domain names when getting a UCC so in that case I would include the exchange name without a domain...
Active 3 days ago
First - I would never use the server's real name on the internet.
So if your server is called "Exchange" then the internet name, name on the SL certificate etc would be something like mail.example.com. I always use generic names for services, never the server real name.
The main reason is when it comes to updating or replacing the server, or adding an additional one. It makes life very difficult to move services about.
The fact that you cannot have .local on an SSL certificate makes no difference with regards to the name of the domain. As it is just DNS entries it makes no difference.
With regards to the host names above, it looks like you are reading old information.
No longer do you include the server's real NETBIOS or FQDN on the SSL certificate. Two names only need to be included - its alias FQDN (mail.example.com) and Autodiscover (autodiscover.example.com)
On Exchange 2013 the clients connect to the FQDN set in Outlook Anywhere. They don't use or even know the name of the real server, because the database does not belong to a server, it is a domain object that is just hosted by the server.
Simon.
So if your server is called "Exchange" then the internet name, name on the SL certificate etc would be something like mail.example.com. I always use generic names for services, never the server real name.
The main reason is when it comes to updating or replacing the server, or adding an additional one. It makes life very difficult to move services about.
The fact that you cannot have .local on an SSL certificate makes no difference with regards to the name of the domain. As it is just DNS entries it makes no difference.
With regards to the host names above, it looks like you are reading old information.
No longer do you include the server's real NETBIOS or FQDN on the SSL certificate. Two names only need to be included - its alias FQDN (mail.example.com) and Autodiscover (autodiscover.example.com)
On Exchange 2013 the clients connect to the FQDN set in Outlook Anywhere. They don't use or even know the name of the real server, because the database does not belong to a server, it is a domain object that is just hosted by the server.
Simon.
Featured Post
Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
A company’s centralized system that manages user data, security, and distributed resources is often a focus of criminal attention. Active Directory (AD) is no exception. In truth, it’s even more likely to be targeted due to the number of companies …
Active Directory security has been a hot topic of late, and for good reason. With
90%
of the world’s organization using this system to manage access to all parts of their IT infrastructure, knowing how to protect against threats and keep vulnerabil…
The video tutorial explains the basics of the Exchange server Database Availability groups.
The components of this video include:
1. Automatic Failover
2. Failover Clustering
3. Active Manager
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Suggested Courses
Course of the Month6 days, 14 hours left to enroll
726 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.