Posted by: Richard Siddaway
In the context of Windows administration – what is automation?
Ask any number of admins and you will get at least that number of replies – usually more. These answers can range from using command line tools, using batch processing\bulk editing tools, through scripting to fully automated automatic response systems.
From a dictionary view point the latter definition is the one closest to the truth. However, when we are talking about administartion of computer systems how many of us trust fully automated systems? Do we really trust a computer to manage our computers? Think on it.
My take is that automation, especially in the administartion field, is any activity that we get the compuer to perform for us rather than performing the task manually at a GUI console. For example if I have to create 100 users in Active Directory it is a boring task using the GUI that will take me a good chunk of time – as an aside if we had an AD Olympics we could have the 100, 200, 400 etc user races. Sorry I go and lie down in a dark room for a while.
Creating the users manually there is a good chance some errors will creep in. If we create these users using a script and we feed the information (names etc) from a file the task is accomplished much quicker and the chances of errors is reduced. If the data is wrong the chance of errors between the two approaches is equal.
The benefit of automation is that the time I would have spent pointing and clicking at the GUI is now spent on something more interesting.
So in my world automation is using computer techniques to perform tasks at a much quicker rate. As another example compare logging onto a dozen file servers to discover the share information against inputting the dozen compter names into the WMI command we saw last time.
In my last post I said that you didn’t need to be a .NET programmer to use PowerShell. I would expand that to say that you don’t need to be a programmer to write scripts.
One thing I find people obsess about is the performance of their scripts. To be honest if it runs in a sensible time frame I don’t care. Assume I have a weekly job that takes me 1 hour and I spend 4 hours developing a script to perform that task. If the script takes 5 minutes to run I only have to run the script 5 times to have recovered my development time. After that I am in profit every time I run it.
Now if I decide I want the script to run in 2.5 minutes I might easily spend another 4 hours (probably more) making the script run faster. Is it worth it when i could be solving other problems which will speed other processes.
The 80:20 rule suggests we will get 80% of the payback for 20% of the effort. This is the spot to hit when scripting. Solve the problem and move on. When you need to revise the script or discover some really clever technique that will have a dramatic impact on processing time – thats the time to make changes.
This can be summed up in Richard’s First Law of Scripting – if it gives the correct result and finishes in a time frame that is accepatble then it is a good script.