More often than not, we tend to use scripts for small, repetitive jobs. If we have time, we sometimes put these scripts or portions of them in subprocedures and functions within libraries for wider use. However, we can also use scripts to build a large solution. Many of the authors who write for this newsletter construct such solutions. Before you tackle such a project, you need to understand how to build a workable and maintainable system for the future, rather than a mass of spaghetti-type code that will be difficult to understand in 6 months.

This article begins a series in which I'll show you how to design and build a large, complex enterprise solution entirely by using scripts. I'll provide many useful scripts and techniques and draw on scripts from previous articles to maximize code reuse. To begin, let's look at the project requirements and design so that you can follow the entire solution and understand my approach.

Project Requirements
Imagine that your company wants to streamline updates to client computers. If you're already using a computer management-and-distribution application such as Microsoft Systems Management Server (SMS) or third-party software such as Hewlett-Packard's HP OpenView or IBM's Tivoli Software, then you already have a deployment mechanism. However, if you don't have such a workhorse at your disposal, Microsoft Software Update Services (SUS— is a free solution that can help you apply crucial fixes and security patches to Windows 2000 Service Pack 2 (SP2) and later clients and servers. Unfortunately, SUS doesn't help you update products such as Microsoft Exchange Server or Microsoft SQL Server or the variety of user files, application files, Task Scheduler jobs, and log files that you must install and maintain over the course of a computer's lifetime.

In addition to SUS, you need a smart solution that lets you create an update once and specify which computers will get the update. For example, the solution should let you install a finance update on finance systems, a marketing update on marketing systems, a Europe update on European systems, and a global update on all systems. The solution should also be flexible enough to deploy scripts and execute them on any client just moments after you finish writing the script. New or rebuilt computers that join the domain should automatically bring themselves up-to-date by applying patches and running the correct scripts in the correct order. To meet these requirements, you can build a centrally managed corporate update system.

Corporate Update System
I wrote a corporate update system many years ago that has evolved over time through use in a variety of organizations. It consists of a central script repository that contains scripts that clients (i.e., workstations, servers) can execute across the enterprise. Active Directory (AD) groups let you target certain scripts at all clients, certain groups of clients, or individual clients.

The administrator incrementally assigns each script a number and at the same time chooses whether to create a corresponding configuration text file that specifies which clients should execute the script. Clients keep track of the number of the last script they executed, and a scheduled task checks with the central script repository at 5-minute intervals to see whether a new script is available. If so, the clients execute the script to bring themselves up-to-date. The great advantage of this centralized management is that if you make a mistake in a script or update-installation routine, you can use the same update mechanism to quickly release a fix.

To kick things off, you need to create the scheduled task that checks for new scripts every 5 minutes and deploy that task to every PC in your enterprise so that each client can ensure it's up-to-date. Although you can add this scheduled task to your existing client OS build procedure for new PCs, this approach doesn't help you apply the scheduled task to existing PCs.

To ensure consistent deployment across the enterprise, I've created a series of scripts as part of the corporate update system known as the client targetter scripts. Each client that's processed successfully is automatically added to a special AD group, indicating that the client is now centrally managed. The client targetter scripts run at regular intervals to check for all PCs in the enterprise that aren't part of this AD group, attempt to install the necessary files onto these nonmember clients, and if successful, add these clients to the AD group. The client targetter scripts will continue to attempt to install the necessary files on any client that fails to receive the files and record multiple failures for manual administrative intervention.

As I mentioned earlier, this automation is made easier by placing previously created scripts in subprocedures and functions within libraries. However, the corporate update system requires a large number of constants and therefore also stores the constants in the libraries for ease of management. Web Table 1 (, InstantDoc ID 26360) provides a summary of the four parts of the corporate update system: client installation scripts; central script repository and update scripts; subprocedure, function, and constant libraries; and client files.

Central Script Repository
The central script repository should have a simple and effective structure that you can easily manage. You place the incrementally numbered script updates in the root central script repository folder (Web Table 2 provides a description of some of the folder path locations that I've used for the corporate update system). You should also assign each update a number starting with 1 (however, this requirement isn't always necessary; I'll discuss when to make these assignments in detail in an upcoming article about tips and tricks for the corporate update system). For my simple example, I created two updates named 1.wsf and 2.wsf. Although I used Windows Script Host (WSH) and VBScript to create all my corporate-update-system scripts, you can use other languages, such as JScript or Perl.

You can create a text file that corresponds with the update script and insert in the text file the name of every client you want to target with your script. However, if you have thousands of clients, you could spend hours creating and managing such a text file, and you'd probably end up writing scripts just to keep the text file up-to-date. A better approach is to create a corresponding text file (e.g., 1.txt, 2.txt) that stores AD groups containing the computer objects representing the clients that the update needs to target. When no text file exists, the update applies itself to all computers in the enterprise.

I advocate placing user objects and computer objects into AD groups so that you can easily target selected sets of users or computers. For example, if you want to target the finance department's computers, you can create a Finance Clients group and add all of finance's PCs to that group. The same principle can apply to any group you have. You can even target AutoCAD clients to send updates to PCs with AutoCAD installed. Establishing these groups takes time initially, but your efforts will pay off later when you can target updates to the groups that need them. You can add groups as you need them for your scripts—you don't need to create all the groups at the start—although planning for future groups is always a good idea.

In addition to the script and its text file, you might want to create a folder (e.g., numbered 1, 2, 3) to hold the files the script needs (e.g., patches to apply, files to copy). Now that you understand the overall project and the organization of the central script repository, let's look at our first script example.

Script Template and Sample Scripts
Listing 1 provides a template for all corporate-update-system scripts. The template uses standard Windows Script (.wsf) file format and the WSH XML

Sponsored Introduction Continue on to (or wait seconds) ×