Scripts are Super-Lists

Techs do lots of tasks repeatedly. Some lists get very long, like ones for building a computer and all the settings you want to change from the defaults. It's a good idea, when there are tons of things to remember, to make a checklist. This way you guarantee that every computer is built the same.

In the beginning, building a computer in my company (they didn't use Group Policy, nor Roaming profiles) took me a few days (end-users were spoiled and could download and install anything from the Internet, and I was required to migrate all their "toys" and settings).
My job was absolutely overwhelming. Everyone who had my job before me quit - all of them. Too many rude, over-demanding end-users, and my boss backed them, not me.
I soon started scripting. I had scripts for this task, scripts for that task, etc. There were so many scripts for so many things. My build-times got down to a day-and-a-half. This is still a long time, in tech-speak, but I was getting things under control.

Most companies don't allow end-users to play on their computers, and they use Group Policy and Roaming profiles. Building a computer consists of dumping an image to the hard drive and delivering. It's all cookie-cutter - no headaches for techs. If end-users want to play, they should bring a deck of cards.

I got very efficient, I thought. The stress subsided to where it was almost tolerable. My boss saw this, and then dumped an additional department of end-users onto my plate. Back to the impossible hi-stress mode. People with emergencies had to wait up to three days, if I had multiple emergencies going on simultaneously.

That's when it dawned on me that my scripting needed to go to the next level. My collection of scripts needed to be streamlined. To do this, my scripts had to use checks. If "this", then do "this", else do "that". Three scripts became one here, two other scripts became one, etc, but I kept thinking up new tasks that could be scripted. There was one that I ran more often, though. It was my "main" script.

Today, that script is nearly 1200 lines (including blank lines and comments) and is so comprehensive that it will check Adobe versions, Flash, Sun Java, IE version, Office service pack level, check for hard drive errors, etc, etc, etc. And it will even ask if I want to install or upgrade and will call that task. If a computer is new without updates, it will take over an hour to run this script, depending on the installs needed. If a computer is fully up-to-date, this script takes seconds to run, skipping sections that don't apply.
This script allows me to do several hours worth of work in a very short time. And because scripts don't forget, like my busy and aging mind does, nothing gets neglected.
Now it can take me as little as 30 minutes to build a computer and migrate all the user's stuff from the old PC to the new one, right down to the Desktop icon positions on the screen. Other than the end-user's unique data and settings, eveyr computer in my area ends up the same.

Another thing my super-script does is, when I find a problem - or potential problem - I can add certain tweaks to this script. This is proactive and keeps machines healthy.

My stress levels have dropped significantly because I can do an impossible workload using scripts. The workload is no longer impossible.

My company is slowly locking-down what end-users are allowed to do, they've started using Group Policy, Windows Updates are automatic, and they're discussing Roaming profiles. That will help, but I've learned under stress how to get every tiny detail "just right", so my maintenance-and-update script will never be obsolete. It just gets more refined as the years go by.

Eventually, I would like this script to end up being programmed in Visual Basic as an interface tool, calling xml files where options are stored, and allowed any tech to customize what happens, including calling scripts of their own.