How to validate client dns settings for a few thousand systems

Over the last year or so, I have been working on correcting and ensuring correct DNS settings on clients. Inconsistency of documentation between build and support teams, or mistyped entries can prove to be a large scale problem as well as outages waiting to happen. To create a centralized store of DNS client settings is always a challenge, especially when not everyone is in close communication, and you want automation involved. So being an Active Directory guy, I thought of ways to involve AD in this. There is always GPO settings, however these are not permanent, and GPO's can't differentiate between NIC cards that should and shouldn't be touched. So, to get around this problem, I wanted something that was location specific and smart enough to be able to tell what a valid internal IP address was. Having SCOM and SCCM as the tools to help implement this, I came up with a set of scripts for various OS's to parse reports, set client settings, and provide monitoring of client settings to track any deviation from the published standards. The trick to this was stashing DNS client setting information in AD. Since the settings were site specific, tying the information to the site object seemed like a natural choice. From here you can either extend the schema to include an attribute for this, or use one that is available but not in use. The best path seemed to be using one not in use, and what appears to be perfect is the location attribute. Since it is a text field, and is editable in the AD Sites MMC, it is easy to manage. Once that is in place, vbscript's are easy to produce to check the client machine's site, pull out domain specific information out of the location field, compare the approved settings against all "valid IP" NIC's for any problems. Different issues provide different results to the scripts for responsible teams to resolve. There are always some exceptions to the rule that are hard to code for, so not getting to overzealous in the configuration scripts, and providing an exception capability to monitoring scripts is a must.