New Server DHCP/DNS issues

Hi all.

I was wondering if anyone can give me some solid advice how to fix a major issue. We just bought brand spankin new servers and installed Windows Server 2019 Standard on it. We joined it to our Domain (2 Server 2008R2 and 1 Server 2016 Standard servers). One of the 2008R2 servers was the “primary” server. The DHCP information was backed up from the 2008R2 server and imported into DHCP server on the new 2019 servers once the 2008’s were demoted and taken off the domain.

Right off the bat we had dns issues. Figured out there was no forwards set so I set them to 8.8.8.8

Worked great, but the next day we had computers getting booted off the network,

What we figured that once a client requested a DHCP lease renewal, that would work, but something in the DNS was not update. So the computer basically got booted form the internet and could not access domain resources. I think we “fixed” the issue by clearing out the records in the DHCP, and that seemed to solve the problem. A week later weird stuff started happening again.

Our Kyocera copier can no longer send faxes and scans to shared folders on the server (SMB)

Can’t Ping the first server but can remote into it

Can Ping the second server but can’t remote into it

Hyper V machine on first server can not access shared folders on first server but can on second. (This used to work)

Here are some Event log errors.

Event Id 20320 Source DHCP Server

PTR record registration for IPv4 address [[192.168.2.245]] and FQDN StrattonPC.pennview.local failed with error SERV_FAIL. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.

Event Id 20317 Source DHCP Server

Forward record registration for IPv4 address [[192.168.2.102]] and FQDN Galaxy-S9 failed with error SERV_FAIL. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.

A bunch before 5pm today

Event Id 30322 Source DHCP Server

PTR record registration for IPv4 address [[192.168.1.34]] and FQDN Frank.pennview.local failed with error 9005 (DNS operation refused.

).

Now I can’t log into the second server either by name or by ip address so I cant show logs on the first server.

The server 2016 server is off site and does not show these types of errors.

If anyone can point me in the right direction how to fix this issue that would be great.

Thanks

Doug

Without looking directly at your configs, it sounds like you’ve got quite a few errors in your DNS & DHCP configurations.

Step 1. Confirm AD Replication is healthy and repair if needed.
Step 2. Confirm DNS is working on all AD Domain Controllers and repair if needed.
Step 3. Confirm DHCP is configured appropriately (depends on your environment what that means) and that DNS is pointed at AD bound DNS Servers. Ensure that dynamic DNS registration is working.
Step 4. ipconfig /renew /registerdns from all machines

Be sure that your server does not point to an outside DNS server as primary or secondary. Be sure that’s the same in your DHCP settings as well. I am assuming that you have a site to site VPS set up so the two AD server can see each other. Your AD server should point to the other DNS server as primary and then itself. Let the forwarders do their thing if you need to get outside. Also…double check Windows firewall. It can interfere with a lot of things.

I’m afraid that you’re going to have to approach this from the client end. Changing the timeouts is only going to help clients the next time they check in, which is usually after half the existing lease time, or sometimes during boot. You can approach this by manually forcing the clients to check in. You might be able to do this by tweaking some group policy settings, or by running a script to bulk “ipconfig /registerdns” on a bunch of clients.

If you insist on doing this from the server end of things, it should be possible to write a custom program to read the entries from a DHCP lease export, and register the addresses, but be sure to run it as the same account that DHCP uses for registrations, or else it may have trouble updating the entries in the future.