We help IT Professionals succeed at work.

window workgoup enviroment change to use domain controller

I would like to implement domain controller in our site ,but i not to sure what we need to consider like domain name ,last time i implement for my another customer is using "abc.local" but now window is recommend to using the FQDN like abc.com ,what is the consideration if i using abc.com as my domain controller name ?What is the process to use abc.com in my domain controller ?we need to register in domain hosting ?
Watch Question

You do not need to register anything at a domain hosting site as the internal 'domain name' does not need to tie into a public domain name. The Domain Controller needs to have a local Domain Name in order to function so ABC.local is in fact a legitimate domain name. I use xxx.local for all of my internal domain names in all environments, regardless of client Public Domain Names.

Using ABC.COM is fine as well, and MS recommends using a FQDN so that when issuing Certificates for email etc you can use the FQDN with less configuration on the backend later. However, it does not matter and if you do not want to register a public Domain Name, you don't need to.

The process to use something like ABC.COM is to input that name when the DC setup is occurring- the same as if you were to use Domain.Local. I would strongly suggest you make sure no one else is using that name publicly but the DC setup of a domain name does not interact with any public servers in any way and is independent of Public Domain Names.
systechSenior Technical Lead

You don't need a external hosting for creating an internal domain. You can name it either abc.com or abc.local or abc.internal etc. The reason why people don't suggest to keep your internal and external domain name same is that you won't be able to access the external website from inside the network unless you create some DNS entries. I.e - your company website is abc.com and if you are creating the active directory domain as abc.com then you will be not able access the external website from the internal domain. Other than that there won't be any issues.

Hope this clarify your query.


So is mean that if i want set-up exchange server in my environment if have the FQDN will make my life easier during deployment ?

If you own the xxx.com address publicly it could make it a bit easier in some aspects, but not enough to make it change anything you are doing. Even if you were to implement Exchange having a different internal Domain Name than a Public name isn't that big a deal as all Public access to your Exchange server will be handled based on a public name you choose with a registrar and how the associated MX records are configured.

This is entirely a personal preference, and my preference has always been to use a xxx.local Domain Name for my DCs.
Senior Solution Architect
Most Valuable Expert 2015
Top Expert 2015
As some of the experts already indicated that you do not have to use the same internal active directory domain as the FQDN you use externally. This is correct.

The reason why it is recommended to not use X.local is because 3rd party SSL authorities will no longer allow you to add SAN (Subject Alternate Names) with internal domains which are .local.

IMO the best method would be to have your "external.com" (public) and create an arbitrary name for your internal domain like gotodmian.com (example). You then can register your internal domain on the internet (does not have to be used). You obviously need to make sure that no one has your internal domain name registered publicly.

Then if you ever have a need to have an internal certificate you can go to a 3rd party SSL authority and request a cert for your internal domain. This mitigates creating an internal PKI (CA) in your domain which is a lot of work/management.

Having the same internal and external domain name is going to be a lot of work from a  DNS management perspective. It is also easy enough to create a separate External DNS
Zone on your internal network.

You will rarely come across a scenario where you need to add your internal domain name to a public SSL cert, but I would still plan for it using a FQDn that is available on the internet so if there is ever a need you have the option.