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—http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp) 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. . . .
Register
