I am very new to PowerShell. So I am not claiming to be an expert or anything of the sort; and I’m sure that if an expert looked at my code he or she would immediately know that it was written by a novice. For now, though, it’s likely inefficient, but functional.
Most of the members on my engineering team, including me, are old-school GUI admins. We know scripting, mostly VB, to fill in the gaps and, after the degree to which we have consolidated our environment, it works, we get by. Recently, however, we’ve noticed inconsistencies in the configurations of our Windows DNS servers that are sprinkled throughout all of the various settings between the servers properties, on conditional forwarders; and on zone settings that include the notify and zone transfers options. There is no easy answer to this problem with VB.
Being the relatively new person on the team, I get the projects everyone runs from; and this project to clean up the DNS settings is one such project. I could do it manually, logon to each server, look at all the settings with the management GUI and correct those that are wrong. I would have that done by now, as daunting of a task as it would be with 32 servers and thousands of zones, forward and reverse, to look at individually and hope that I spot all the errant settings on the first pass. One problem would be though: how would I know if I missed something? But an overarching issue is that the settings inexplicably change, unbeknownst to us; and a requirement of the project is to monitor for changes so that we know when any one of a raft of settings that exist in any number of places has changed. Some settings are in the registry. Some are on the zone or in the directory partition, etc…
In tackling this problem, I’ve started with the low-hanging fruit with the DNS service parameters registry key that gets to what would be the equivalent of the settings that are on the server properties sheets in the MMC GUI.
I use the remote registry function of .NET in PowerShell to scrutinize the DNS service parameters registry key on each server. My script looks at all of the value names that exist in the key and uses the names to create a checksum. And all of the servers that are in the same functional group, e.g. all scavengers or all non-scavengers, should have the same value-name checksum. The beauty of doing it this way is that I do not have to have previous knowledge of or account for all of the possible value names that can exist in the parameters key in order to know that something has changed that adds a value because the checksum created from the value names will change. I also create a checksum of the values that I know should be there minus those that are unique, and an additional server checksum that includes unique values. So if a known value is changed, depending on where the change occurs, the corresponding checksum will change. Then, I store these checksums along with the value names checksum in a csv.
So, now what I am working on is, if I take a properly configured server for each functional group and run the script on it to establish baseline value-name checksums, and load the baseline value names, value and unique checksums for each server in that group in the csv file I use to load the server names for the script to check, I should be able to get the script to compare the current checksums to the baseline checksums, and send an email to the team’s distribution list if they are not the same, identifying the server that has experienced a change in its DNS parameters registry key. A nice handy tool for automating on a utility server as a scheduled task, perhaps once per day.
Simply put, if a DNS server has had its properties sheets changed between runs of the scheduled task, my team will get spammed. At least, that is the intended end result. I’ve been working on this for two days and have gotten as far as establishing the baseline checksums for each server. I still need to code the comparison. Then, move on to figuring out how to code checking conditional forwarders and zone properties.
I’ll keep you posted on my progress. If anyone is interested in my code, thinking it might be useful, leave me a comment. I’ll have to check with my boss to see if I can share it.