Forum Discussion
Migrated DCs to 2019 getting numerous 20319 Events
Just migrated DCs over to 2019 and I'm seeing a large number of Event 20319 Name Registration with the user NETWORK SERVICE.
"Forward record registration for IPv4 address [[x.x.x.x]] and FQDN CompName.domain.local failed with error 9005 (DNS operation refused."
This almost seems like NETWORK SERVICE needs to have some sort of permissions somewhere that I'm not finding in my google searches.
When I migrated, I deleted all DHCP leases to force them all to get new, and I can see them all in DNS (even reverse lookup zone they are listed). - Should I have deleted them out of the reverse zone as well? Maybe that's the problem?
PDC - DHCP, DNS, all FSMO
SDC - DHCP (hot spare), DNS, GC
Option 006 I have both DCs listed, I have DHCP credentials set up (nothing has changed from the previous DC and the account isn't locked)
Actually think I just figured it out. Seems I forgot to update the DnsUpdateProxy Security Group with the new DCs.
One thing I also noticed was that the computers that kept showing up in the 20319 events all had their computer account instead of the DHCP Update account having permissions on its DNS entry. Deleted the computer and added DHCP Update with the same rights as all the other computers that did have DHCP Update...released/renewed and all seems to be well.
So, I'm going to mark the solution as the following: make sure all is set up according to https://blogs.msmvps.com/acefekay/2016/08/13/dynamic-dns-updates-how-to-get-it-to-work-with-dhcp-sca...
This is where I noticed that I forgot to update the DnsUpdateProxy SG with the new DCs. Then, on the problematic computer's DNS entry, I had to manually delete the computer account permissions and add the DHCP Update credential permissions. When I released/renewed, I no longer had the 20319 events.
I'd check if the reverse zone for this network subnet even exists.
Please see the above screenshot showing the reverse zone exists as well as the tag that is referenced in the one event is listed in the reverse zone...
I see that but we cannot tell from what you posted that it is correct for the network and mask so might try recreating the zone.
