Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.
COURSE of the MONTH
11 days, 11 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 4 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)
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 4 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
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 4 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
Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Uncontrolled local administrators groups within any organization pose a huge security risk. Because these groups are locally managed it becomes difficult to audit and maintain them.
In the absence of a fully-fledged GPO Management product like AGPM, the script in this article will provide you with a simple way to watch the domain (or a select OU) for GPOs changes and automatically take backups when policies are added, removed o…
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment.
The video tutorial explains the basics of the Exchange server Database Availability grou…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses
Course of the Month11 days, 11 hours left to enroll
752 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.