Mailbag: Happy Birthday Ronald Reagan (Issue #7)
Mark and Tom here again with Mailbag Issue #7!
We’re light on overall questions, but in-depth on one of them this week. Let’s get to it!
Question
When I run nslookup contoso.com my RODCs don't show up in the list of DNS records! What gives?! Should I add them?
Answer
NO! Well, probably not. This is by design. RODCs, by default, don't register any of the generic DNS mnemonics. The reason for this that RODCs generally exist to serve branch locations where physical security is a concern. You probably wouldn't want apps that aren't DCLocator aware (It's 2015 and you don't support DCLocator ,Mr. Appdev?) to bind to your domain name to find a DC and discover an RODC in a remote branch. That could cause slew of issues ranging from WAN saturation and RODC performance problems to application compatibility issues between the app and the RODC.
This configuration is something we recommend even for RWDCs as part of the branch office deployment guide. Also make sure to check out the RODC BODG (SRSLY). In most cases, you should just leave the default behavior alone.
Question
OK. So what's a DNS mnemonic?
Answer
It's got nothing to do with the Yakuza, a data package, or Keanu Reeves. DNS mnemonics are all of the various "types" of DNS records that your domain controllers register to provide specific services to sites or the domain in general. The list is (from the BODG):
Mnemonic |
Type |
DNS Record |
Dc |
SRV |
_ldap._tcp.dc._msdcs.<DnsDomainName> |
DcAtSite |
SRV |
_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName> |
DcByGuid |
SRV |
_ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName> |
Pdc |
SRV |
_ldap._tcp.pdc._msdcs.<DnsDomainName> |
Gc |
SRV |
_ldap._tcp.gc._msdcs.<DnsForestName> |
GcAtSite |
SRV |
_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsForestName> |
GenericGc |
SRV |
_gc._tcp.<DnsForestName> |
GenericGcAtSite |
SRV |
_gc._tcp.<SiteName>._sites.<DnsForestName> |
GcIpAddress |
A |
_gc._msdcs.<DnsForestName> |
DsaCname |
CNAME |
<DsaGuid>._msdcs.<DnsForestName> |
Kdc |
SRV |
_kerberos._tcp.dc._msdcs.<DnsDomainName> |
KdcAtSite |
SRV |
_kerberos._tcp.dc._msdcs.<SiteName>._sites.<DnsDomainName> |
Ldap |
SRV |
_ldap._tcp.<DnsDomainName> |
LdapAtSite |
SRV |
_ldap._tcp.<SiteName>._sites.<DnsDomainName> |
LdapIpAddress |
A |
<DnsDomainName> |
Rfc1510Kdc |
SRV |
_kerberos._tcp.<DnsDomainName> |
Rfc1510KdcAtSite |
SRV |
_kerberos._tcp.<SiteName>._sites.<DnsDomainName> |
Rfc1510UdpKdc |
SRV |
_kerberos._udp.<DnsDomainName> |
Rfc1510Kpwd |
SRV |
_kpasswd._tcp.<DnsDomainName> |
Rfc1510UdpKpwd |
SRV |
_kpasswd._udp.<DnsDomainName> |
And if you enter any of those under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DNSAvoidRegisterRecords, delimited by newlines, your domain controller will no longer register that specific mnemonic. For example, if you don't want a specific DC to be globally available as a KDC, you'd set that key to contain Kdc. The domain controller will deregister its _kerberos._tcp.dc._msdcs.contoso.com SRV record and no longer be discoverable as a KDC forest-wide. Only client in the same site will find it. You can also set these in Group Policy as outlined, again, in the Branch Office Deployment Guide.
Question
I've seen links to guides to sizing hardware for AD, but I couldn't find any good design examples for AD. Could you possibly post examples of designs from real world deployments as a yardstick example or minimum recommended based on size or scale of implementation?
Answer
Since we're skipping the hardware sizing discussion, which you can learn all about here, let's talk about design. And let me start off with a big, fat it depends. Here are some questions you should probably ask when designing your site topology. We don't have a lot of real world examples to post, since our customers get a little weird about posting their site topologies on the blog (whatever that's all about), but we can talk about some discussions we would typically have while planning.
Do I need a separate AD site?
This TechNet reference says it a lot better than I will:
A site is defined as a set of IP subnets connected by fast, reliable connectivity. As a rule of thumb, networks with LAN speed or better are considered fast networks.
Have another location that isn't part of the LAN? Make it a site. Usually this will result in a hub-and-spoke topology where all of these remote branch sites connect back to a headquarters location. Multi-hub-and-spoke topologies are not uncommon, though.
Do I need a DC in each site?
This is a good place to start. Identify all of the sites in your organization that require a domain controller. Generally, these would be branch offices or sites that are physically separate from your datacenter site. A good example of this would be a headquarters in Detroit, where you've got a bunch of users and a local datacenter. The users next door to the datacenter quite likely don't need a domain controller in their building. However, those remote users and servers in the Las Vegas office would greatly benefit from having a local domain controller. Benefits of a local DC include the ability to withstand a WAN outage, as well as performance improvements due to lower latency. That said, I have some customers who put a DC in every single remote site, and those who pick and choose based on business requirements. That brings us to the next question…
How many DCs do I need in each site?
I'm just going to keep this on the clipboard now… but, it depends. You should always shoot for at least two just in case one goes down. If that's a hard sell to management, you need to decide if failing over to the next site over the WAN link is good enough. If you're connected with reliable, high speed, low latency links, that might be good enough.
The other half of this question depends on how many users you have in the site. A big campus with 25,000 users is going to need many more DCs than a branch office with 100 users. I can't tell you how many you'll need. You need to use performance monitor, measure performance, and add capacity if needed. Remember, if you have two servers at 50% capacity and one dies, you're going to have a real problem on your hands. Make sure to maintain enough available capacity so that if one, or even two nodes goes offline you have enough capacity to service all of your clients. Also keep in mind that developers and users aren't always nice to AD and like to do things like run super-generic LDAP queries against the entire directory. Nobody likes it when you query an OU with 500,000 objects with something like (samaccountname=hahahaha) as your LDAP filter. Stop it.
How many global catalogs do I need?
This is a subject for a different day, but in the vast majority of situations you should just make all of your domain controllers a global catalog and call it a day. In a future mailbag we'll talk about some non-GC scenarios. In four years at Microsoft and seeing dozens of customer environments, I've seen one situation where the customer had a legitimate reason to make every DC a GC (dougga knows who I'm talking about!). Just check the box. Or, rather, don't uncheck the box during DCPromo Install-ADDSDomainController
How about DNS?
Well, if you're running DNS on your DCs, you're in luck. You'll have nicely distributed, multi-master DNS. If you aren't running Microsoft DNS, and are running something third-party, you'll need a DNS server in every site where a DC exists. Active Directory depends on DNS. No DNS, nobody can find a DC, DCs can't find each other, and everybody is generally unhappy.
So back to your original question, it depends.
Stuff from the Interwebs
Last week, we unveiled HoloLens. If you haven't seen it, check it out. Someday, you'll be able to have virtual Mark and Tom standing next to you saying "Click there…no, no THERE."
Ford revealed the Focus RS this week. Check out the link and the reveal video with Ken Block.
Weird Al is going on tour. This is almost as exciting as seeing the Foos in DC on the 4th of July.
Tom "Detroit" Moser vs. Mark "Everybody" Morowczynski