This article is not part of the Building Microsoft System Center Cloud series but we need these DCs for our Hyper-V cluster that we are using in our Cloud series.
Naming domain
Naming domain is very important step. It is not a problem to use local TLD in the testing environment but I will rather use the correct approach.
Best practices
- Always use existing domain that you own. But never use domain where you have or you could have your website and therefore the public DNS records exist or might exist in the future.
- That means if you have domain contoso.com then register new domain (for example contosoad.com) or use third level (for example corp.contoso.com).
- Do not use TLDs like local or int. Even when they never exist or there is a very small chance that they would exist.
- There are a lot of reasons to never use domains that do not exist. For example there is still a small chance that the listed TLDs will exist in the future. Also it is possible that somebody name own domain by the same name with local TLD. In this case you will never be able to establish a trust relationship with such organization.
- But the main reason to use domain that you own is clear and this is for security purposes. Nobody will own this domain because this is your domain name.
My recomendations
- Never change the NetBIOS because it is confusing (in the case you domain is corp.mycompany.com use CORP NetBIOS and do not change it for example to DOMAIN).
My choice for the testing environment: ad.contoso.com
Configuring Active Directory Domain Services
New forest – ADDS Configuration Wizard on Windows Server 2012 R2 – new “dcpromo”
- My choice: ad.contoso.com
- My recommendation for you is to never change the NetBIOS because it is confusing when DNS and NetBIOS are different.
- As I wrote in the article, where I configured the hardware, it is a best practice to put NTDS DB, DB logs and SYSVOL on separate physical disks (RAID arrays). In the virtual world we would like to for example put VHDX with NTDS on Tier 1 SAN, the SYSVOL on Tier 2 SAN and DB Logs for example also on Tier 2 SAN. Of course in our environment it does not matter because all VHDs will be in the same directory on the same volume on the same local disk and we will never separate them. But I want to show you the correct way.
Adding second Domain Controller
First domain controller has been deployed and the forest has been created. Now we can promote another DC.
- Set DNS to point to the first DC
- And continue as usually…
- At the end we should change DNS servers of the first DC. Because currently it contains only ::1 (localhost) so the DNS is pointing only to the local DNS.
- In the past I set preferred DNS to the local DNS but I figured out that is always better to point DCs to each other because you can do the name resolution immediately after restart before the local DNS service is running. Of course this apply to the environment where you have multiple DCs on the fast network (local network or direct optical lines between datacenters).
- Do not forget to change IPv4 if you use it and do not forgot that in your environment you probably do not have IPv6 gateway.
Group Policy configuration settings
Now I will configure the settings in Group Policy suitable for the tests that make our testing environment pleasant for the admins (and me).
Disable User Account Control (UAC) in GPO
- Disable User Account Control (UAC) and automatically elevate everything for the administrators. When you set this setting then every user in Domain Admins security group would feel on every server that is targeted by this GPO (in our case all servers) like he is working as default Administrator.
-
- Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options
- User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode: Elevate without prompting
- User Account Control: Detect application installations and prompt for elevation: Disabled
- User Account Control: Run all administrators in Admin Approval Mode: Disabled
- User Account Control: Only elevate UIAccess applications that are installed in secure locations: Disabled (optional)
- Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options
-