When creating a new forest in Active Directory on my domain controller running Windows Server 2012 R2, I was prompted to specify a root domain name. Must the domain name be registered and owned by me? What would happen if I enter a domain registered and owned by other people like microsoft.com? Later on when I try to add a Windows computer to this domain, will it go out onto the internet and search for microsoft.com or would it search only in it's subnet (my domain controller)? Would it be safe/preferable to just enter a domain that is owned like microsoft.com?
Domain – Must the root domain name be registered when creating a new forest in Active Directory
active-directorydomaindomain-controllerwindows-server-2012windows-server-2012-r2
Related Solutions
If the clients are resolving the hostname properly then you've got another problem. DNS is out of the picture once the hostname is resolved by the client.
Some things to think about:
Are clients using any kind of HTTP proxy to access the Internet? Does the proxy have the correct DNS information available?
What's the DNS cache look like on the client after a failed access attempt? Are you seeing the right IP address cached for the hostname?
What's actually happening on the client? Are you seeing a connection stuck in SYN_SENT state to the correct server IP address, TCP port 80?
Are there any firewall rules that might relate to blocking access to the website's address?
This smells like a firewall / proxy / cache / filter problem, not a DNS problem.
Unfortunately, there's nothing really compelling I can say about getting rid of the badly-named Active Directory domain. It's unfortunate that they chose to do that route, but technically this can work. (I hate this kind of bad naming practice, too... "vile", I believe, is how I've referred to it in the past... Wish I had some good advice to forward a domain-rename argument to you...)
Looks like I'm running into (a variant of?) this issue: the promotion completes successfully if I use "long" logon credentials, i.e. A0.lab\AdmA0 instead of A0\AdmA0.
However, based on the article, this issue should only happen if NetBIOS over TCP/IP is disabled, but it's actually enabled, and this can be verified in the ipconfig output. I also tried configuring the VMs with static network settings instead of using DHCP (which is required by Azure), and forcing NetBIOS over TCP/IP to "Enabled", but the error always happens; the only way for the promotion process to work is by using "long" credentials.
However, this definitely seems to be an Azure-specific quirk: I have created an identical test environment on a local Hyper-V server, and everything works as it should.
Looks like either Azure is doing something strange at the network level which block NetBIOS, or the Azure Windows Server 2012 R2 VM templates have some strange NetBIOS-related behavior which makes DC promotion fail in this peculiar way.
Update:
Culprit found: https://msdn.microsoft.com/en-us/library/azure/dn133803.aspx.
Does Virtual Network support multicast or broadcast?
No. We do not support multicast or broadcast.
Azure virtual networks don't support broadcast; thus, even if NetBIOS is enabled, it just doesn't work. And it looks like Windows Server 2012 R2 really needs it for a DC promotion to work.
Workaround: use "long" logon credentials during DC promotion (full.domain.fqdn\username instead of NetBIOSDomain\username).
As for why Azure virtual networks don't support broadcast, and how can they manage to do that while still relying so heavily on DHCP... that's beyond my ability to understand. And I'm not quite sure I really want to understand; Azure networking is well known to be rather peculiar.
Best Answer
The name of an Active Directory domain is only for internal usage, thus you could name it anything you want; however, in an Active Directory environment, the domain name also acts as the DNS suffix for all computers in the domain, and the domain controllers act as internal DNS servers which are (or at least behave as they were) authoritative for that DNS domain.
What this means is, if the AD domain name conflicts with an actual domain name that exists on the Internet, all DNS queries for that domain would be answered by your DCs, and not by the actual Internet DNS servers which manage it. In your case, if you name your domain "microsoft.com", then you would have all sorts of problems when trying to connect to Microsoft sites or services, because you wouldn't be able to query the public DNS servers for that domain (as your internal DNS servers would believe they rightfully own it).
Incidentally, the same is true if you use your real public DNS domain as your Active Directory domain: things are of course a lot simpler because you actually own them both, but this still requires you to mantain two distinct DNS setups for the same domain, one for the Internet and one for your internal network.
As a best practice, you should use a subdomain of your public DNS domain as your AD domain name; if f.e. your public domain is "domain.com", you could use "internal.domain.com" or "ad.domain.com" or whatever, as long as it's a valid subdomain; this wil ensure no conflicts and a lot less headaches.
You should, anyway, not use any domain name you don't actually own, even if it's not currently active (because it still could be registered later by someone else than you, and headaches would ensue).