Print
Discuss
Send to friend
RSS feedsAs promised, this month we're going to discuss another use of Windows scripting and the Windows Scripting Host (WSH), which are topics we introduced in last month's Windows New Technology. However, that's not all we'll be covering, as the example we've chosen - the rollout of new or updated Windows desktops - will also allow us to look at the use of a number of other technologies.
Among these are disk imaging and Windows 2000's Sysprep tool, which can be extremely useful in such an exercise. Desktop deployment is always a big issue, so the more desktops you have to roll out, the bigger your problems become - unless your computer supplier is prepared to deliver systems ready configured to your exact requirements. Many companies will also be starting to upgrade to Windows 2000 (or XP), which can be a lengthy and problematic process, with several different ways of tacking the huge amount of work that can be involved.
One approach is to simply pop the appropriate Windows CD-ROM into each new PC and run the install or upgrade setup program from scratch. To speed things up on a large network, however, the software can be copied to a server share and the setup procedure run from there. It's also possible to automate a network-based installation by preparing one or more answer files in advance.
Disk Cloning
These can provide virtually all of the information requested by the setup program (computer name, workgroup, domain settings and so on), rather than having to sit around waiting for the appropriate prompts to appear. However, even with an answer file, the installation or upgrade can still take a while, which is why disk cloning is a preferred alternative. With disk cloning, a typical or 'model' system is configured, then a copy, or image, of its hard disk is taken using special disk imaging software.
That image can then be replicated to other systems as required, the final cloning process typically taking just a few minutes compared to the 20 to 30 minutes per PC often needed for a conventional install. The bad news is that Windows itself doesn't come with disk cloning or imaging utilities, although there are third-party tools available, such as Symantec's Ghost (www.symantec.com) and the software we used for this feature, PowerQuest's Drive Image 5.0 (www.powerquest.com, see Figure 1).
There are also others, but they all work in basically the same way, enabling the contents of a hard disk partition to be cloned at the block level, regardless of operating system concerned, with the resultant image being stored in a single compressed file.
This file can usually be written to a network share, local disk or most types of removable disk media (including CD-RW with Drive Image 5.0), with disk spanning available where large amounts of data are involved. A disk image can then be uncompressed and written back onto one or more other hard disks using the same cloning software. A special boot disk, which typically starts the PC using DOS with a minimal set of drivers for the disk devices and network interfaces being used, is needed for this. All of this sounds very straightforward and it can, indeed, be both quick and simple. However, there are a couple of caveats to bear in mind.
Cloning issues
The first thing you have to consider is the need to standardise the PC hardware involved. It's no good, for instance, taking an image of a PC's hard disk with a video controller or network card from one manufacturer and cloning it onto others with a different mix of adapters. The end result will be an unusable system, although there are ways around such problems, such as using the Sysprep tool, which we'll discuss shortly.
Even then, standardisation helps to keep things simple, which is what you want when rolling out multiple desktops and should be practised as much as possible. Another concern is the unique Security ID (SID) assigned to each new Windows system during the original setup process, which can cause more than a few headaches.
For instance, if you clone disk contents 'as is', each clone will have the same SID and won't be seen as unique when attached to a network - no matter what IP address, system or user name are later applied. Fortunately, there's a way of overcoming the SID and other disk cloning issues by using a special utility called Sysprep from Microsoft. More properly referred to as the System Preparation Tool, the software that makes up Sysprep can be found on the Windows 2000 Professional CD-ROM in a CAB file (DEPLOY.CAB) in the /support/tools folder.
It's also in the Windows 2000 Resource Kit, while the latest 1.1 release can be downloaded, together with documentation, from Microsoft's Web site (www.microsoft.com/ windows2000/downloads/tools/sysprep/default.asp). The principal Sysprep utility is a command line program called SYSPREP.EXE, which is used to prepare the source disk for cloning. As part of this process, it configures a miniature version of the Windows setup wizard, which is then ready for automatic execution when the cloned disk is first used to boot a new system.
It also arranges for the automatic execution of a tool called SETUPCL.EXE to generate a new unique SID on the target drive. In addition, the execution of the mini setup wizard can be automated using an answer file called SYSPREP.INF, which is much like the one that can be used to automate the full Windows setup procedure. This is very useful, as we'll see shortly.
A cloning example
As with most jobs, preparation is key. The first thing to do is to carefully configure the 'model' system, which needs to be done from scratch - preferably with a newly formatted hard disk. The Sysprep documentation advises that you make sure the same Windows 2000 HAL (Hardware Abstraction Layer) will work on both the 'model' system and cloned targets, and that they have the same ACPI (Advanced Configuration and Power Interface) capabilities. However, mass storage and other interfaces don't have to be identical, because the Sysprep mini setup software can detect changes and install drivers. As we've already mentioned, if you want a smooth installation, it's best to keep the number of such variables to an absolute minimum.
For our walkthrough, we used a desktop PC designed for use on a typical small company network and assumed an identical setup for the clones. We started with an installation of Windows 2000 from a CD-ROM, followed by the latest drivers needed for the video and network adapters we were using. The latest Service Pack updates were then applied, after which we made sure the network properties were set to use DHCP so that we could obtain an IP address and other networking information automatically.
We also installed some optional components, including the company's chosen anti-virus software and a full installation of Microsoft's Office. These were configured to run from a network server rather than the local hard disk, which enabled us to keep our image file as small as possible. Next, we configured Internet Explorer to use the LAN for its connection and to start with a blank page. However, we didn't set up an email account, as this requires user-specific parameters. We didn't create a local user account at this stage either (we can do this manually) and the default Administrator account was left without a password for reasons we'll explain in a minute. In addition, we didn't join the model PC to a workgroup or NT domain on the host LAN.
Rather, we opted to do this using Sysprep's mini setup wizard, which let us use the same image to set up PCs for different departments in the same organisation. Finally, any temporary files/folders created were deleted and the Windows Recycle Bin was emptied. We also deleted the contents of the various event logs, then checked the hard disk for errors before our test run with the disk imaging software.
Building an image
Exactly how you go about creating a disk image depends on the software involved and media used. In our case, Drive Image 5.0 needs to be run from DOS and the image file stored on a network share, a fixed hard disk or removeable disk medium such as floppy, Zip or writeable CD-ROM. To use a network share, a boot disk with suitable LAN drivers was needed. This can take a while to build, however, so we opted to use a second partition on the hard disk while testing, finally switching to CD-RW for the final image, as this is quick and easy and doesn't require a LAN connection.
Another plus was that this approach doesn't have any impact on network bandwidth. Moreover, with Drive Image 5.0, the CD-RW you end up with can be used to boot the target system and run the imaging software, which does away with the need for special boot floppy disks and makes life easier still. With compression enabled, we managed to fit our disk image into a file that would fit onto a single CD-RW, which we tested to make sure it worked.
Inevitably, some tuning was required, but once we were happy with the results, we proceeded to apply the Sysprep software to deal with the SID and further streamline the deployment process. The two executables that make up Sysprep (SYSPREP.EXE and SETUPCL.EXE) must be copied to a directory beneath the root on the hard disk of the model PC (c:/sysprep).
This directory can also hold the answer file SYSPREP.INF. Details of the various parameters that can be specified in this file are in the documentation included in the Sysprep package. In addition, the Sysprep software also comes with a useful Setup Manager Wizard, which can be used to create answer files without having to get your hands dirty with actual code (see Figure 2). This can be used both with Sysprep to generate an answer file that duplicates the configuration of the current PC, while for ordinary unattended installations, there's also the option of creating a new answer file from scratch and further modifying an existing answer file, which is all done using prompted menu displays.
With most cloned images, though, very few commands are required in the Sysprep answer file - just the bare minimum were used to create our example, which is shown in Listing 1. In the first section (Unattended), the first line (OemPreinstall = no) tells the wizard we're going to use a disk image. OemSkipEULA = yes tells it to skip the display of the End User Licence Agreement (EULA). The next parameter, KeepPageFile = 0, forces Windows to recreate the paging file to suit the host PC memory configuration. ExtendOemPartition = 1 extends the system partition to fill the whole of the hard disk, although it only works on NTFS-formatted volumes.
In the (GuiUnattended) section, we first skip the welcome screen (OemSkipWelcome = 1), then set the admin password. Note that if the Administrator password is already set, this step will fail, which is why we deliberately left it blank when configuring the model system. We also opted to set the time zone here (0900 for GMT), although this could have been done in advance on the PC used to create the image.
Next, we set up the local user in the (UserData) section. Here, we left the FullName= parameter blank to force the mini setup wizard to ask for a name, followed by Orgname = "Our Company" to set the organisation to the name of the company involved. Finally, ComputerName = * causes the wizard to generate a random computer name based on the name supplied. In (networking), the command InstallDefaultComponents = no makes sure the existing networking settings are left alone, while in (Identification), the target system is made a member of the domain called PCMAG, using the account name and password specified, which has domain administrator privileges.
Finally, in (GuiRunOnce) we tell the wizard to run the script we're going to cover next to make some final checks and adjustments on the target system. It does this by adding the command specified to the RunOnce subkey in the Windows Registry on the target system - HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnce. The script is executed just once - the first time a user logs on following the execution of the mini setup wizard.
Our setup script
There are many things you can do with a script to further automate the process of desktop deployment. In our example (see Listing 2), we've used a script as a kind of automated checklist to make sure we've covered the main bases during the cloning process. First, we make sure we're logged on as the local administrator (using the Wscript.Network object) before reading the Windows Registry to make sure we've joined the PCMAG domain.
We use the Wscript.Shell object to look for a key that was created by the Sysprep mini setup wizard. We then add the global group pcmag_users to the local administrator group to allow us to gain access to the network shares and printers allotted to such users.
Next, we map a network share and copy over the latest anti-virus signatures using a simple batch file before removing the mapped drive letter and ending the script.Putting it all together You're now in a position to start the deployment process. The 'model' system needs to be prepared as already described, then the Sysprep software installed in the correct directory (c:/sysprep), together with the answer file for the mini-setup wizard (SYSPREP.INF). If you're going to call a script, that must also be present on the model system.
You should then run SYSPREP.EXE to prepare the disk for cloning, adding the /forceshutdown switch to the end of the command so that the PC will switch off as soon as Sysprep has completed its tasks. You can now boot the system using the disk imaging software and clone the hard disk contents of the model. The disk image can now be restored to other work-stations as required.
When these are subsequently rebooted, the Sysprep utility will run the mini setup wizard using the answer file copied onto the model PC, then create a new SID. TheVBS script will be run as soon as someone logs onto the cloned PC. By following this procedure, the rollout of an operating system upgrade becomes a relatively easy procedure.
The same approach can also be used to apply later security updates, provide access to new applications and so on. Some companies also use cloning and imaging to resolve support problems, setting a strict limit as to how long they will troubleshoot a dilemma before returning the affected PC to a known good state by applying the original disk image. Local data will be lost, but this can be handled with proper procedures, while the combination of disk imaging, Sysprep and Windows scripting is something well worth looking into more closely.
WSH and security
Because it can do so much, the Windows Scripting Host is often misused by virus writers to wreak havoc on unsuspecting PC users. Typically, you'll get an email attachment that, when double-clicked, doesn't open a spreadsheet or graphic as expected, but runs a script instead.
This script can then edit the Windows Registry, connect to network shares, call other programs and do all kinds of damage unless steps are taken to stop it happening. The sledgehammer approach is to disable WSH altogether, but this will also stop other legitimate uses of Windows scripting. A better approach is to install an up-to-date anti-virus solution and, if you're running Microsoft's Outlook, apply the various security patches we've covered previously in PC Magazine's Power User section.
If you find WSH has been removed from your Windows 2000 system, you can't just reload it using the Add/Remove Programs applet in the Control Panel - it must be reinstalled by downloading the latest software from Microsoft (http://msdn.microsoft.com/ scripting). You might even find that it's still loaded, but the connection between the source script files and WSH executable has broken.
See also:
All Software Applications
del.icio.us
Digg this
reddit!
