DNS log import cmdlet

New blogpost, Yeah! Sorry about the delay guys, hopefully this blogpost will make you forgive me for having too wait.

It took me a while to determine the subject of my new blogpost but finally I found a topic for it. In my day to day work I have been busy upgrading Domain Controllers away from Server 2003 to 2008 (yeah I know, still legacy but hey some things you can control and some things you cannot).

Any way, part of the procedure was to decommission some DC’s with the DNS Service they were running with it. One of the businessneeds being to have the least amount of servers experience failing DNS requests due to unavailbalility of these servers. Time to enable DNS logging. The settings I used for logging can be seen in the screenshot below.

Log Settings

Sidenote, I did a similar script a few years back, it’s kinda fun and scary at the same time to see your scripting abilities evolve. Anyways, back then I used substring to define the separate objects in the script, apparently DNS on 64 bit servers assigns a larger number to the internal packet identifier property. It had 8 zeroes in front of it now, rendering my previous script useless. Well not completely useless but it became clear to me it needed an upgrade. So when examining the DNS log file itself, I noticed I could use the spaces in there to split the entries. I have no idea why I didn’t notice that the first time.

Another thing I had to work around was the fact a DNS log file looks like this.
Dnslogfile header

There’s a header in the logfile which spans multiple lines. As I did not want or needed to have this in my custom object, I had to find a way to work around this. Take a look at the first bit of code.

Import the dnslogfile

As you can see, I chose to discard the first 30 lines in the logfile. I’m still looking for a better way to do this as I don’t really like the fact the entire logfile is being read first (and some of them become quite large). If anybody knows a better way, please let me know. Als please note, I am aware some things in the script are not best practices, but the script was working exactly as I intended. Let’s look at the second part of the script.

Count dnshostnames

As you can see, this function uses the $data variable in the previous function (no best practice but as I mentioned, it worked exactly as I wanted). Basically the function takes the output from the previous function and groups them so we can simply count the number of occurences a certain IP address has in the logfile. This because I wanted to resolve the hostname that comes with it but I only wanted to have to do that once. To achieve this I used the Get-DNSHostName cmdlet. The passthru parameter is used to be able to forward the objects to a next function.

Now comes the real dirty part (remember, it works exactly as I intended).
Process the data

Like I said, it’s dirty but it works. In the end I scheduled the script to run each night and it gave me the exact output I needed, being the number of requests that were still being done, the servernames that did the queries and the hostname of the DNS server that the log file originated from.

With this script I was able to contact the departments responsible for those servers so they could change their DNS settings. I Am in the process of rewriting the script, I already did the first part, it’s shown below.

Improved function

As you can see there are quite a lot of changes in this function. The code is now re-usable. Next part is to rewrite the other two parts. I welcome suggestions, so if you have some, please let me know.

Also, as I mentioned the script is far from perfect, but doing exactly as I intended. Which brings me to the next part. I basically hate writing scripts that have flaws or are dirty like this. However, time is still money and why rewrite something if it’s working as intended. From a business perspective there is no reason to do this, however from a learning perspective I find it really interesting to improve existing scripts. As some sort of Guideline I started reading the Powershell toolmaking in a month of lunches book. Boy did I wish I picked up this book three years ago (was it even available back then?). Be sure to check it out.

Also you may ask, why blog about something when you know it isn’t perfect? The question itself is actually the main reason. I love Powershell, I however also realise I still make mistakes. So basically this post is meant to be of help to those that are looking for something like this but also an invitation to have you guys provide feedback. My experience with the powershell community is that all people involved are really good at helping each other. I try to assist others and thought this would be a great way get some feedback myself.

I hope you liked this post, I had a great time writing it.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s