ConfigMgr – Why you need to implement DNS Scavenging

Interestingly, the topic of DNS scavenging came up on the MVP alias. Since it appears many client environments still have not yet enabled DNS scavenging, this article is dedicated to why you NEED to enable DNS scavenging. Before it is too late. (dramatic enough? 😉

First, a short story. While employed at a large financial services company as one of their Windows Engineers and lead SCCM architect, we started encountering some strange issues with SCCM remote control. Attempt to remote control a Windows client by NETBIOS name and *another* Windows client would be brought up in the remote control session.

After troubleshooting this issue, we came to the conclusion that there were multiple DNS records for the same NETBIOS name, each with a different IP address! So, it was rather random whether you’d actually remote control to the intended client. Turns out, in 5 years or so that Active Directory was in use, DNS scavenging had NOT been enabled, leading to 1,000’s of invalid, old entries. Implementing DNS Scavenging solved this issue.

What are some of the side effects of DNS with no scavenging? Here are just a few of the possible side effects:

– Remote control fails to reach the intended client

– Client Installation Push method fails to connect to the correct client

– OSD installations – software installations fail

– Client Inventory reporting

– Active Directory discovery issues

How to properly implement? There are a few things you need to know about DNS Scavenging; the first is implementing DNS Scavenging within DNS, then enabling at each DNS zone and the impact of DHCP lease duration.

Some general advice; I’ll usually enable and leave DNS scavenging set to the default 7 days per DNS zone. Since DHCP lease renewals happen approximately half way through the lease period, even a 7 day DHCP lease will typically be OK.

Scavenging should only remove those records that were dynamically registered, not the manually entered A records.

The recommendation would be to take a backup of your DNS environment prior to implementing. And, for the first implementation, starting on an evening or weekend is probably a good idea.

For those clients that get removed from DNS because they are on vacation for 2 weeks, they re-register when they re-connect, and will likely send a new ConfigMgr hw delta at the same time.


Script to locate duplicate DNS entries (thanks Russ):

This entry was posted in ConfigMgr. Bookmark the permalink.

10 Responses to ConfigMgr – Why you need to implement DNS Scavenging

  1. amagsmb says:

    Does the new SCCM HW delta will create a duplicate computer account in the SCCM database?

  2. deploymentMonkey says:

    Never understood why these big financial instutions still underestimates this issue.. solution is easy and well explained .. but at each client site I face the same issue still..even after years…

  3. Really interesting post!
    When we retire or re-purpose a PC, we always delete it from an automated script. It delete the AD object, the DNS entry and the ConfigMgr object too. So if we re-image the PC right now, it creates a new DNS entry which is associated with the right SID of the new AD object.

    As a side note, the DNS entry is not only affected by the setting on the zone but also by the server settings and non-refresh interval. Here’s a good reference (especially the image at the end) :

    • configmgrmvp says:

      Thanks for the feedback… I have the same link in my post! 😉

      If you’d be interested in sharing your script, I could make it available here.

  4. JohnUbuntu says:

    DNS Scavenging is a poor man’s approach to an even poorer DNS/DHCP configuration implementation.

    DNS Scavenging only alleviates issues, it does not solve them and it’s important to understand that it’s not something that will just simply magically make everything work once it’s implemented. It won’t. The exact same issues you were seeing before will still occur, only far less often.

    The registration should be handled dynamically by the DHCP server, not the client. By doing this, the DHCP server will both register the A and PTR records for the client and delete them when the lease expires, removing the need for scavenging.

    DHCP dynamic registration was (properly) introduced with Windows 2008 and that’s what should be used nowadays. No one is using Windows XP anymore so all Windows clients respect it. As for non-Windows devices, it works even better.

  5. HoppyZ06 says:

    Regarding DHCP and PTR records. Does SCCM 2012 require PTR records for managing the SCCM client? I’m getting conflicting information from this. We were told by our network architects (since we are now migrated to a global network with the parent company and uses Linux for DHCP/DNS) that this is not necessary. From my understanding, SCCM requires both A and PTR records to validate that the client they are managing is correct. Our previous network (Windows 2008 R2) using DHCP worked just fine. If this is true, does anyone have any Microsoft links they can point me to so I can prove someone wrong? Thanks!!

    • Steve T says:

      CM 2012 needs to be able to resolve the host names. If you can install and manage your clients, then their DNS /DHCP implementation is probably OK.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.