Which Windows command shell scripting books are useful?
The gold standard text for command shell scriptwriters is Timothy Hill's Windows NT Shell Scripting. Although the book is somewhat dated, it's still an excellent resource. Hill was the first author to introduce many administrators to the power of command shell scripting. Several recently published texts also provide information about command shell scripting. William R. Stanek's Microsoft Windows Command-Line Administrator's Pocket Consultant is one of the best. Stanek arranges the chapters by task, so you can quickly and easily determine which tool and code to use to accomplish a task.
I want to set up one machine on which to develop and test scripts and set up another machine in my production environment to run the scripts. What hardware and software are necessary?
I use a XP PC for script development and testing. I schedule production scripts to run on a Windows 2003 machine. This production server is a multiprocessor on a 1 GB network, which gives me enough power and network speed to run scripts simultaneously. At one time, I had about 2000 script instances running each day on my production server. If you're just getting started, you probably don't need that much computing horsepower. You can probably run scripts on your development machine. Another approach is to use a file server to do double duty as your production script server.
I use a matching folder structure for scripts on my development and production
machines. I store each script and its input and output files in a folder labeled
with a descriptive name. The Windows Server 2003 Resource Kit Tools are installed
on both the development and production machines in a matching folder location.
I store third-party tools in folders according to their source. For example,
I store all the tools from Sysinternals in one folder and all the tools from
Joeware.net in another folder. The matching folder structure lets me easily
copy a script from the development PC to the production server—I don't
have to change any tool, input-file, or output-file path in the script.
I use a script to replicate the folder structure from the production server to a second server so that I can run scripts from the backup server if the primary server fails. This backup step proved necessary after a disk controller failed on the production server and I quickly experienced fallout from other administrators and end users who use the output from the scripts that I run. The old adage held true that you don't know how much you miss something until it's gone.
If you're in a configuration-controlled environment, you might not be able
to install resource kit tools or third-party tools locally on the production
machine. To accommodate this type of situation, you can create a shared folder
on your network that contains the tools, then grant the Authenticated Users
group read-only access to that folder. You can then simply point to the tools'
shared folder in your scripts. As long as your production machine has network
connectivity, the scripts can access the shared folder.
Do I need to obtain or purchase a script editor to edit my scripts?
No. I use an editor for my Perl scripts but haven't found a benefit to using it for my command shell scripts. Notepad works fine for editing shell scripts and never inserts additional characters. I especially like Notepad because it's available on every machine I work on. Therefore, I'm not dependent on an editor application if I need to quickly write a short script on another machine. Microsoft Word doesn't work well for writing and editing scripts. Unlike Notepad, Word sometimes inserts unrecognized characters into saved script files.
I have several Windows OSs in my environment. How can I easily test my newly developed scripts across all the OSs?
Consider using a virtual machine (VM) solution such as VMware or Microsoft Virtual PC. I use VMware to host several OSs for script testing. I can use just one physical machine to test scripts on several OSs, which saves money because I don't need a lab full of test machines. In addition, I can recreate OSs quickly or easily add new OSs if necessary.
To prevent your VMs from exposing your network to vulnerability or infection, be sure to update them with the proper hotfixes and anti-virus definitions. Performing this vital step is easy to forget because you might boot into the VMs only periodically.
Scripts are usually backward compatible. That is, scripts that you write for
Windows 2003 and XP typically work on earlier OSs such as Windows 2000 and NT.
However, always test your scripts to ensure backward compatibility.