Skip to main content

DHCP on DNS, Scavenging and the DnsProxyUpdate Group:



            The entity that registers it owns the record. The nice thing about DHCP
owning the record is it will update it if DHCP gives the machine a new IP.
Otherwise you'll see multiples of the same in DNS whether scavenging is
enabled or not. I would force DHCP to own the record as well as enable
scavenging to keep it clean. To force DHCP to own the record, you will need
to do the following:


1. Add the DHCP server to the DnsUpdateProxy Group.
2. Force DHCP to register all records, Forward and PTR, (whether a client
machine can do it or not) in the Option 081 tab (DHCP properties, DNS tab).
3. Set Option 015 to the AD domain name (such as example.com).
4. Set Option 006 to only the internal DNS servers.
5. If the zone is set for Secure Updates Only, then DHCP cannot update
non-Microsoft clients and Microsoft clients that are not joined to the
domain. In this case, you will need to create and configure a user account
for use as credentials for DHCP to register such clients.

If your DHCP servers are Windows 2003 or WIndows 2008, Configure a
dedicated the user account you created as credentials in DHCP by going into
DHCP COnsole, DHCP server properties, and on the Advanced tab of the DHCP
Server Properties sheet click the Credentials button, and provide this account
info.

The user account does not need any elevated rights, a normal user account
is fine, however I recommend using a Strong non-expiring password on the
account.


Once you implement scavenging, you will need to wait at least a week for it
to take effect. You can quicken it up by manually deleting the incorrect
records to get started.

But more importantly, if DHCP is on a DC, it will not overwrite the
original host record for a machine getting a new lease with an IP
formerly belonging to another. To overcome this, add the DHCP server
(the DC) to the DnsProxyUpdate group. This will force DHCP to own
all records it will create moving forward and will update an IP with
a new name in DNS.


If you set this, but when a record shows up in the DHCP Lease list with a
pen (which means that a write is pending), it m ay mean it is trying to register
into a zone that does not exist on the DNS servers. This happens in cases
where the client machine is not joined to the domain and has a missing or
different suffix than the zone in DNS. It can only register into a zone that exists on
DNS and that zone updates have been configured to allow updates.

If this is the case, go into the client machine's IP properties, and
on the DNS tab in TCP/IP properties, clear the "Register this connection's
addresses in DNS" as well as the "Use this connection's DNS suffix in DNS
registration" check boxes, the DHCP Server will fill these in for you and register using
the domain name in Option 015.

Popular posts from this blog

Fixing Tanzu Kubernetes Pod to External Services Connectivity Issues with NSX-T

Fixing Tanzu Kubernetes Pod to External Services Connectivity Issues with NSX-T Last month I got a call from a customer who was pulling their hair out over a networking issue. They had just deployed VMware Tanzu Kubernetes Grid on their vSphere with Tanzu environment, everything looked good in the dashboards, all pods were running, but their applications inside the pods could not reach external databases running on traditional VMs in the same datacenter. The frustrating part was that some pods could reach external services perfectly fine, while others would just timeout. There was no clear pattern. Let me tell you how we figured this out and fixed it. The Initial Problem Here is what the customer setup looked like: vSphere 8.0 with Tanzu enabled NSX-T 4.1.2 for networking Three Tanzu Kubernetes clusters running different microservices applications External PostgreSQL database running on traditional VMs (non-Kubernetes) External API services running on another se...

Troubleshooting vSAN Storage Policy Migration Failures in VMware Cloud Foundation 9.0

Recently I had a customer who migrated their VMware infrastructure from vSphere 7.0 to VMware Cloud Foundation 9.0. After the migration, they wanted to update their vSAN storage policies to take advantage of the new vSAN ESA (Express Storage Architecture) features. However, when they tried to change the storage policy for their production VMs, the operation kept failing with a cryptic error message. The error they were getting was: "Cannot complete operation due to insufficient resources to satisfy current storage policy." This was strange because they had plenty of disk space available. The vSAN cluster was only at 45% capacity, and all the hosts were healthy. Let me walk through how we troubleshooted and fixed this issue. Understanding the Problem First, let's understand what was happening in their environment: They had a 6-node vSAN cluster running VCF 9.0 vSAN was configured with the new ESA architecture They were trying to migrate VMs fro...

Unlocking VMware Cloud Foundation 9.0: A Strategic Blueprint for Enterprise Transformation

The evolution of VMware under Broadcom represents not disruption, but clarification—a focused vision toward unified private cloud excellence. As organizations navigate this transformation, the opportunity has never been greater to build truly modern, efficient, and powerful infrastructure with VMware Cloud Foundation. After architecting VMware solutions across diverse enterprise environments, I've observed a pattern: organizations that embrace VMware Cloud Foundation (VCF) strategically—rather than viewing the transition as a burden—emerge with significantly more capable, cost-effective, and future-ready infrastructure. This post shares a practical framework for successfully modernizing your VMware environment, maximizing your investment, and positioning your organization for the AI-driven, cloud-native future. Understanding the VMware Cloud Foundation Vision Let's start with clarity about what Broadcom and VMware are building: VMware Cloud Foundati...