Administration and Client Host Update Script
In my "other life" I run an IT team, which among other things supports some 300 workstations
in a networked environment. To support this equipment we currently use Microsoft's "Remote
Installation Service" (RIS)to build or rebuild workstations together with "Windows System
Update Server" (WSUS)to keep them patched up to date. Between these two systems we are able
to support standardised images on workstations that are maintained with the most up to date
security patches in a very cost effective manner.
There is however a third element of support that can cost us all a lot of time and that is
customisation and implementation of services that are not included in the original RIS images
or supported by the WSUS update system. Scheduling maintenance tasks to run at regular intervals
and the copying in of and/or installation of files and shortcuts for new or updated applications
can be a labour intensive exercise if these have to be manually accomplished. In theory it is
possible to do some of these things via Group Policy but there are often in our experience,
"fish hooks" in using group policy for this purpose, so we have settled on a scripted process
which is run on a server targeting every workstation we are responsible for.
Originally I used a command script to do this but as those who have experience of command scripts
will agree, some syntax structures for things like iteration and uploading of variables from
files using tokens can drive you a little bit nuts! I have recently implemented a new client
update script system, which is written using the Microsoft Powershell language.
Features
Operational Overview
The new "UpdateHost" script is called with two arguments which specify two directories:
The first directory contains a data file [.dat] of the machine names or IP numbers of the
machines which are to be targeted together with a bunch of subscripts that are to be run.
These subscripts can written in Powershell [.ps1] or in Command [.cmd] script. The names
of these subscripts are of no great importance as the control script will attempt to run any
.cmd or .ps1 scripts present in the directory. The subscripts contain the actions that are to
be performed on the range of workstations specified in the data file. Each subscript is called
with three arguments - The IP Number (if known); the Machine Name; and the file path of the base
location or repository that contains the files that maybe needed by the subscripts. These three
arguments can then be used by the subscripts to accomplish the tasks required.
The second directory is the base location or repository that contains the files that will be needed
by the subscripts to do the intended updates. These files maybe scripts to be scheduled to run on the
target clients and/or customised files that are needed on the target client for them to be operated
effectively.
In this way it is possible to quickly and accurately target and update discrete ranges of computers,
applying customisations that are consistent between each machine. Each individual subscript can be
focused on implementing one change, reducing complexity when maintaining or changing the process
concerned. It also means that staff time is not directed into attempting to remember what to do to
complete the installation of workstations that are used for different purposes in our organisation.
It is also possible to implement silent installs of MSI files or other applications by copying the file
to a local directory and scheduling the silent install to run at a convenient time when the workstation
is not in use. We recently used this mechanism to complete the unattended installation of the Microsoft
Office File Convertor and the installation of Adobe Reader 8 on all our machines.
Installation
I have made available a limited but fully functional version of this
process in a zip file. The zip file will need to be downloaded and the directory called ClientUpdate
extracted to C:\ on the machine you intend to run it from. If you chose to run this from another location
you will need to edit the scripts accordingly. The ClientUpdate Directory contains 2 scripts and 2
directories:
The script "Control .cmd" just calls the Powershell application and gets it to run the second script
"UpdateHost.ps1" with the appropriate arguments (described above).
The "Archive" directory is the repository base location (described above). It contains a hidden
directory called "Install" which will be copied to a target computer at C:\Install
The "Live" directory is the location of the data file and subscripts that are to be run. For this to
work in your environment you will need to insert valid IP numbers and/or machine names into this file
replacing my ones.
Activation
By running the "Control .cmd" you will call the "UpdateHost.ps1" which will locate the data file in the
"Live" directory and load the potential target machines. It will then locate all of the .ps1 files and
all the .cmd files (in this case there is one of each) and run them.
The Powershell file uses XCOPY to copy the Install directory in the "Archive" repository to C:\Install
on the target(s). The command file then schedules the "Action.cmd" on the targets local C:\Install
directory to run at 15:20 (If you want this to happen at a different time you will need to edit this
file in the Archive).
When the scheduled "Action.cmd" runs it will change the ACL permissions on the local directory
"C:\Install" and then defragment the local computer.
This all sounds complicated but is in fact straightforward and the scripts supplied can be copied and
adapted to accomplish many other useful routine tasks. Our version of this process runs 10 times per
day allowing us to update and customise our workstations in a structured manner that is efficient on
consultant time. One range of target hosts in our environment currently has a total of 25 subscripts
that are customising various things! Some of the customisations involve our implementations of other
scripts and applications I have shared on this site like the TimeKeeper,
the Get Inventory Script and the Clicker.
Prerequisites
To be able to run the Administration and Client Host Update Script, you will need to have loaded
Windows Powershell... which was released late 2006, on any workstation on which you want to
run this script. You will also need to set the Powershell script execution policy to:
"set-executionpolicy remotesigned". The prerequisites for Powershell on XP are Service Pack 2 and the
Microsoft .NET Framework version 2.0
|
