Let me preface this by saying that I'm by no means a trained sysadmin but rather, shall we say, learning on the go. Apologies if the answer to my questions is obvious but I couldn't find it by Google/Superuser search.

So I'm in-charge of manage about 200 windows computers where I work and I recently learned about this thing active directory to easily effect changes on all computers which is just great. So I set up the domain controller and found a .vbs script to join computers to the domain. Perfect.

Except the GPOs I set are not being pushed down to the computers. I tried running "gpupdate /force" on a computer and it shows the following error

The processing of Group Policy failed. Windows attempted to retrieve new Group Policy settings for this user or computer. Look in the details tab for error code and description. Windows will automatically retry this operation at the next refresh cycle. Computers joined to the domain must have proper name resolution and network connectivity to a domain controller for discovery of new Group Policy objects and settings. An event will be logged when Group Policy is successful.

User Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

I looked around some more and it seems when I point the DNS of the clients to domain controller, the updates go through (Running nsloookup {domain.com} returns a non-authoritative answer). Now, it could be that pointing the DNS to DC is mandatory in AD. But I never saw this mentioned in any of the tutorials I found which is really weird. So is it really required? If it is, is there any way I can update the DNS of all the computers in the domain without physically going to each computer?

This also raises another issue. What if I, for some reason have to change the current IP of the DC. Do I then need to update the DNS again on every computer?

Thanks for your time and looking forward to your advice.


pointing the DNS to DC is mandatory in AD


The only real DNS requirement1 is that your AD domain (with subdomains) must be resolvable by clients – but there is nothing specified about the exact path it takes. ("Non-authoritative answer" is completely normal.)

For example, if the following commands return successful results (SOA with zone information, SRV with service details) then the DNS configuration should be good.

nslookup -q=soa YOURDOMAIN
nslookup -q=srv _ldap._tcp.YOURDOMAIN
nslookup -q=srv _ldap._tcp.dc._msdcs.YOURDOMAIN

(SOA is not strictly required, but I included it for dynamic DNS updates. There are other required records, e.g. _kerberos._tcp, but there's probably no need to test every single one of them.)

  • So if the AD domain was chosen from the global namespace, e.g. ad.example.com or corp.example.com, and if it was properly delegated (i.e. the parent example.com domain has correct NS records), and if your regular DNS servers can forward the DNS queries to the AD DC (i.e. port 53 isn't firewalled off), that's enough.

    (The DNS port on DCs doesn't need to be accessible to the entire world, only to the joined PCs. Correction: it needs to be accessible to the DNS resolvers; i.e. to the DNS servers that your PCs use.)

  • If the AD domain can't be delegated for some reason (e.g. if you chose a made-up TLD like example.corp), but the PCs still use some other internally-managed DNS servers, then it's still enough to just set up a "forward zone" or "stub zone" on those DNS servers.

  • If you can't do delegation and don't control the DNS servers being used... then you have a problem. You could still do tricks like NAT'ing all DNS requests so that they go to an internal DNS server; it works but it's rather ugly in principle.

  • (In all three cases above, there's really just one place to reconfigure in case you add or move DCs – be it NS/glue records or the "stub zone" configuration or whatever.)

Pointing the DNS directly to DCs is only useful in rare situations, e.g. when setting up a "test" domain with 2-3 PCs, or when the DCs do in fact double as the organization's main DNS resolvers (which, I believe, was against all recommendations before Server 2016).

1 Of course there are other non-DNS-related requirements as well. At minimum, the PCs must be able to reach Kerberos on the DC for authentication; LDAP (regular and Global Catalog) for looking up GPO information; and SMB (i.e. file sharing) for downloading the GPOs themselves.

For troubleshooting, I'd install Wireshark on a workstation, start the packet monitoring, and watch what happens when gpupdate /force is run. There also are various Windows knobs to activate verbose logging of GPO processing.

  • Thank you for the detailed response. You're awesome. I tried the nslookup queries you posted. Two of them worked fine but _ldap._tcp.YOURDOMAIN returned "Non-existent domain". Earlier I was trying to set the all the NS records manually on godaddy which was a mistake. Now I've set it point to custom nameservers NS1.DOMAIN and NS2.DOMAIN (both's IP pointing to the only DC for now.). Waiting for the changes to propagate. Will update with hopefully good news in a couple of hours. :) – Manoj Jain Nov 6 '17 at 12:43
  • @ManojJain Based on your comment, are you indicating that you used, for your Active Directory domain name, an existing public domain you owned? This does go against best practice, but is not terrible. However, you shouldn't be updating public DNS records to make your active directory work. Instead, you do what is called Split-DNS, where you still point your computers to your internal AD DNS, but you duplicate the necessary public records internally. Never use your internal AD DNS servers for public name resolution or open them to the public internet. – Appleoddity Nov 6 '17 at 14:39

Not to detract from the otherwise detailed answer provided, but I’m not sure it fully addressed your question.

Here are some short answers to how this works.

1) Yes, your computers are supposed to use the DCs as their sole DNS servers. It’s true you could use alternative DNS servers and either forward requests or duplicate/replicate records, but this would be rare in a smaller organization and require more administrative work. And, no matter where the records come from, it is required to be able to resolve all the records that are stored on the DC. Typically, you will use your internal AD DNS servers for your internal systems, and configure your internal DNS servers to forward all other requests to your ISP's DNS servers - this is done under the "Forwarders" configuration.

2) DHCP is what hands out the IP address info to systems dynamically. In a typical Active Directory organization, you will disable DHCP on any routers / gateways and enable the DHCP role on one of your servers - typically a DC. This is because DHCP can work together with your DNS server to keep records up to date. Within your DHCP configuration, you will specify what DNS servers are to be used for your internal systems. An organization of 200 systems would not, or should not, be using static IP addressing - so the DNS settings are not something you need to change on each system. You manage it centrally by modifying your DHCP configuration. You need to have a properly configured DHCP server on all subnets within your organization.

3) if you change the IP address of the DC/DNS servers you just update DHCP to reflect those changes for your systems. However, you should plan ahead and not create a situation where you need to change an IP address of a DC because there are other implications apart from DNS settings if you do so.

  • Re "Yes, your computers are supposed to use the DCs as their sole DNS servers. It’s true you could host DNS records elsewhere, but this would be rare and require more administrative work." You are describing different functions (recursive resolver for everything, and authoritative server for a domain) which really have nothing to do with each other. Just like you don't need to directly use Google's DNS servers in order to resolve google.com (instead your resolver finds it indirectly), you also don't need to directly use the DC in order to resolve the AD domain it hosts. – grawity Nov 6 '17 at 13:10
  • (Or in other words, using a different server as the DNS resolver in no way implies hosting DNS records elsewhere. The setup you describe is common, but in no way required.) – grawity Nov 6 '17 at 13:15
  • @grawity My answer was not an attempt to suggest otherwise. I've updated it to hopefully be more clear. – Appleoddity Nov 6 '17 at 14:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.