Forum Discussion
Troy Davis
Aug 14, 2019Copper Contributor
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 CompNa...
- Sep 04, 2019
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.
Troy Davis
Aug 14, 2019Copper Contributor
Thanks for the reply btw...what more information would you need to determine if it is the correct reverse zone?
Dave Patrick
Aug 14, 2019MVP
Some examples here for classful and classless subnets.
- Troy DavisAug 14, 2019Copper Contributor
I guess I don't understand what you are trying to say. I was asking what you wanted me to show you or tell you to determine if it was correct? Sorry if I'm being dense today.
Everything migrated over from the old 2012R2 DC w/out issue. Same reverse zone and everything that was on the old PDC/SDC. Is there some sort of permissions that NETWORK SERVICE should have to update DNS or is that all handled by the DHCP User credentials that is set up. Because as you can see from the screenshot, the reverse record is being updated (the migration took place on 08/10/2019). So I'm at a loss as to why they are being updated, yet I'm getting those events.
Reverse Lookup Zones container have the following:
0.in-addr.arpa
127.in-addr.arpa
255.in-addr.arpa
xx.xx.xx.in-addr.arpa
- Dave PatrickAug 14, 2019MVP
I guess I don't understand what you are trying to say.
You asked what information? So I was just providing some insight. Might also check this one.
- Troy DavisAug 14, 2019Copper Contributor
You made the comment [quote]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.[/quote]
That's what I was responding to, wondering what information you required to tell if it was correct for the network/mask...
As far as your link...I already have that set up
Everything was working prior to the cut over. Migration went well, no issues with promo and data sync. Set the DNS dynamic update credentials and everything works as my users aren't having any issues, I can ping/connect to computers. I'm not seeing these errors on my SDC, but I'm assuming that's because it is only in Hot Spare...which...that is the only difference...prior I had my DCs in load balancing for DHCP, I switched it over to Hot Spare this time. Other than that, that's all I can see that I've changed.
So you don't think there is a permission anywhere for NETWORK SERVICE? I just restored my old PDC to my test lab and I'm not seeing anything different...
...again, thank you for your replies.