The unforeseen benefits of scripting and automation
Scripts are great, right? PowerShell, with it’s hooks into the .NET Framework, allows us to automate just about any task we want to do. Whether it’s deleting some old files, monitoring Active Directory, provisioning new virtual machines and now even managing network switches, the only limitation we have is our time and knowledge. PowerShell can automate all kinds of stuff!
The complexity of the tasks we do in PowerShell vary widely. Some use the PowerShell console exclusively just to do simple tasks they used to do with cmd.exe. Shame! Others decide to write some simple scripts that delete files older than a specific date or perhaps do a WMI inventory of the PCs on their network.
Automation is More than Saving Time
The crazy, passionate PowerShell admin geeks, on the other hand, take it to another level altogether.
All this automation is great, right?
While you’re saving all this time do you ever stop to realize that writing a script forces you to learn that task inside and out? Even if you merely go through the motions of writing a script without even writing anything you’ll come out knowing a ton more about the actual task!
Have you ever decided to sit down and script some process that you think will take five minutes and end up taking five hours? It’s not because you wanted to add more bells and whistles to the script but you honestly didn’t understand the task well enough in the first place? Be honest!
I’m not talking about the one-liners like Get-Content sometextfile.txt where you're just viewing the contents. I'm talking about actual scripts; the scripts that you pour your heart and soul into sometimes off and on for days. I'm talking about 500-line scripts or PowerShell modules; the stuff that makes you think!
A Personal Story
I love examples and I seem to always have a bunch in my head at all times so here’s one from personal experience.
If you’re an avid reader of this blog, you might have seen the articles I’ve posted about Active Directory-integrated DNS records. I was having a hell of a time tracking down some issues of disappearing DNS records at a client site.
Throughout this process, I’ve had to learn a lot of how DNS integrates with Active Directory because I’ve scripted nearly everything I’ve done.
Let me give you an example of setting permissions on an AD-integrated DNS record. You may say you know how to do that, right? Just go into the DNS MMC console, right-click on a record, click on the Security tab and do whatever you need to do. Sure, that’s fine but do you know what your action is actually doing there?
You might not.
You’re not just “setting permissions” first of all. You’re actually setting a new ACE on an Active Directory object that’s in the objectClass dnsNode. Also, this dnsNode object can either be located in the Forest or DNS zones naming context depending on how you set the replication scope up.
Also, do you know that you can also find these DNS records via Get-WmiObject or Get-AdObject? The rabbit hole goes deep.
Do you understand where I’m going with this?
The next time you run into a problem you can’t figure out pretend like you’re going to write a PowerShell script to automate it. I guarantee you that just getting into that mindset will open up your mind on a different level and allow you to solve problems you never thought you could.
