Scripting vs Manual Effort
As may be apparent from previous posts, I'm keen on using automation, coding and scripting to make my life easier. I've sometimes been asked why put effort into coding a solution when it may not save much time versus manually fixing an issue? The answer, as is often the case, is 'it depends.' It can depend on the scale of the problem, the amount of time it would take to write a script versus the amount of time it would take to carry out the fix manually and the number of times it could be applied.
Let's look at a couple of examples.
If say, I decided to write a script that would calculate the approximate volume of a Kakapo (a flightless parrot indigenous to New Zealand) nest based on it's height and width, then this might not be a useful exercise. If I only ever wanted to know this information once or twice in my lifetime, then the effort in coding would most likely be best spent elsewhere. If however, I was a researcher investigating nesting habits of the Kakapo (or had written said script for a researcher investigating said nesting habits) then this would probably be worthwhile in investing the time.
In another recent case close to home, I was assisting someone in identifying the process for removing some software. The software was not in the Programs and Features applet (it was not installed via it's normal installer) and had been added as part of a build process when another product was installed. As the software had to be removed, I identified that this could be achieved by removing 4 DLL files as well as deleting 24 separate entries within the Windows registry. 12 of the entries had 32 digit identifiers for the class ID's which could be easily mistaken for another.
Based on my own experience I estimated it would take me approximately 15 minutes per system to manually clean up the registry entries. I was, however, not the one who would be carrying out the remediation work, this would be falling to an offshore team who were not comfortable with working with the registry. Their estimates were anywhere up to an hour for fixing up the registry settings.
As there were 9 servers in the original target group, there was a question about cost saving via scripting vs the time taken to develop a bulletproof script. With the other work in the changes being planned to remediate the software installation, it was estimated that with backout preparation that the change could take 2 hours or more per server. They did not want an outage of that duration for what was a relatively simple set of changes.
In this case, it was worthwhile scripting the activity especially as the scope increased to a few hundred systems needing potential remediation.
Leveraging code I had written previously for other activities and put together into a general utility library, it didn't take as much effort to write a script to carry out the activities required.
My script recorded it's start date/time, who ran the script, the host name as well as the time it completed execution and calculated the total time taken so that I could validate the time saved. The script logged to both the screen and a log file so that the user would know what was happening and we could review output after it was complete. I included the ProgIDs and GUIDs in variables and loaded these into arrays through which I then looped through to search for each registry entry. If the entry was found, I had the script call the registry editor (reg.exe) to export the key, confirm the backup .reg file was present and then delete the key. The DLL's were also processed in a similar manner - path loaded into an array, looped through the array and then backed up by moving from the source folder to a backup folder. This meant that backing out of the change was relatively simple, the DLL files could be copied back to their original location (which was documented in the log file) and the backup .reg files could be manually run to restore the registry entries.
The script took me approximately 2 hours to write - most of it was validating individual commands/sequences before integrating into the script. The resulting script took on average, 5-8 seconds to run from start to completion versus the 15 - 30 minutes per host manual remediation may have taken. Now my original target group of servers was only 9 hosts and if we assume that the remediation time was 20 minutes if performed manually, this translates to 3 hours of actual remediation.
When you compare this to a script requiring up to 10 seconds per host to complete the same work, there are definite benefits in using scripting vs manual remediation. The script produces consistent results each time (no human error from incorrect registry selection etc), performs checks before taking action, logs what actions it took and reduces the amount of effort of the person who has to carry out the remediation.