Recently the computers at our organization moved to a new AD domain, due to a merger. We are having problems getting the clients to dynamically register their DNS records in our AD-integrated DNS.
When a registration is triggered manually on the client (ipconfig /registerdns), everything works fine. You can see the registration process happening in wireshark as described here: https://technet.microsoft.com/en-us/library/cc771255.aspx
Only about 50% of the clients seem to be doing this by themselves however. On the other half, this process does not seem to trigger. Even though the events mentioned in the above article (e.g. on startup) should cause the client to register their A-record with the DNS server.
I have tcpdump constantly capturing traffic from a group of desktops which are exhibiting this problem. In these dumps, I can't find any registration attempts for the affected computers.
Some things to note about our environment
- The clients are getting their DHCP addresses from two DHCP servers in the old domain.
- The DNS servers the clients are told to use (option 006), are also the old domain controllers. But DNS requests for the new domain, are forwarded to the new DC's using conditional forwarding.
- For the new domain, updates are allowed. (Secure Only)
- The connection suffix provided by the DHCP (option 015) is still the old domain. But we have a list of suffixes deployed through a GPO, with the new domain suffix first in the list.
- The new AD domain has three domain controllers, two of which are also DNS servers.
Something we tried
For one of the DHCP scopes we set the connection suffix to the new domain and the DNS servers to the new domain controllers. This does not seem to make a difference.
This seems to be an interesting post about the subject: http://blogs.msmvps.com/acefekay/2012/11/19/ad-dynamic-dns-updates-registration-rules-of-engagement/ But most of the things mentioned there are in order. Except for the fact that IPv6 is disabled on the new domain controllers.
More info in response to Craig620's answer
- The DNS servers are running Windows server 2012 R2, the clients are all Windows 7, the DHCP servers are running server 2008 R2.
- All clients are joined to the same domain (new domain since merger), the problems occur only in this domain.
- There are no clients with static IP-addresses.
- We are not in the process of moving clients from the old to the new domain. We did this with some clients, but the computers which are having problems have not moved. They have been deployed using SCCM in the new domain.
- I can't find significant differences between the 50% that are having the problems and other systems. For example: Some computers in the same classroom are having problems, others are not. They are generally running the same software, updates, etc. And are connected to the same part of the network. Same hardware also. The difference that I can think of is that they are trying to contact another domain controller, but I can't see any attempts to do this.
- The problem has been going on for weeks so computers should have had plenty of time to register themselves.
- The clients don't seem to query for the zone SOA. The zone names for the old and new domain are not similar. (e.g. green.local for the old domain and int.blue.com for the new)
- I have a GPO in place for the DNS suffix search list. This is a list containing the new AD-domain in first place, followed by the legacy domains of the different merger organizations. This is the only DNS related GPO. But I will check this more thoroughly.