Deployment Solution

When scripting the installation of Windows XP, it's pretty important to install all the latest patches. We've had various mechanisms for doing this over the years, from actually going to Windows update, to slipstreaming, and even to running an in-house VB application. No matter what approach we tried, we found that a lot of time had to be dedicated to maintaining the patches - it all seemed a bit complex for something which should be so simple.

The approach we finally settled on was to implement a DOS Batch script. Despite what some of the .NET maestro's out there are now thinking, maintaining the patch level with this method is shockingly simple. Just dump the new patches into a patch folder, and the patch script would automatically detect the patch and install at run-time. Its not as clever as some slipstreaming products out there, but it is trivial to maintain.

Getting Patch-Batch into DS

This script caters for two types of patch types, the first type I call Level 1 patches, and these are based on the update.exe engine. The second type appears to be based on something called Wextract, and I refer to these as Level 2 patches.

The way the Patch-Batch works is by scanning a folder called L1, creating a list of Level 1 patches. These entries it then turns into a script (InstallL1.bat) which silently installs the L1 patches. Patch-Batch then proceeds to the L2 folder, and repeats the same process creating another patch installation batch file (InstallL2.bat).

To get Patch-Batch working do the following,

1. In your DS Applications folder, create a folder called PatchBatch
2. In the PatchBatch folder, create the two folders L1 & L2.
3. Populate the L1 folder with all the patches based in the update.exe engine
4. Populate the L2 folder with the patches based on Wextract
5. Download QChain, and place in the root of the PatchBatch folder.
6. Create the file Patch-Batch.bat in the root of the PatchBatch folder. The contents are as follows.

   REM Batch Patcher, by Ian Atkin, Oxford University.
   REM Level 1 patches are defined as those which take the longform switches, "/passive" etc..
   REM Level 2 patches are those which take the  short form switches "/Q" etc..
    
   REM Ensure the Install scripts for Level 1 & Level 2 patches are empty
   echo. > InstallL1.bat
   echo. > InstallL2.bat
   
   
   REM Export list of Level 1 patches in the L1 folder to L1.txt
   dir /b .\L1> L1.txt
   
   REM Export list of Level 1 patches in the L2 folder to L2.txt
   dir /b .\L2> L2.txt
   
   
   REM Scan through L1.txt, and create for each patch an install entry in InstallL1.bat
   REM QChain is used zealously to ensure multiple patches can be installed without reboot
   for /F %%a in (L1.txt) do (
     for /f "tokens=2,3 delims=-" %%i in ("%%a") do (echo %%i,%%j)
     echo .\L1\%%a /quiet /passive /norestart >> InstallL1.bat
     echo qchain.exe >> InstallL1.bat
   )
   
   
   REM Scan through L2.txt, and create for each patch an install entry in InstallL2.bat
   REM QChain is used zealously to ensure multiple patches can be installed without reboot
   REM Watchpoint: Its possible that some L2 Patches might require /Z switch to prevent reboot.  
   for /F %%a in (L2.txt)  do (
     for /f "tokens=2,3 delims=-" %%i in ("%%a") do (echo %%i,%%j)
     echo .\L2\%%a /Q >> InstallL2.bat
     echo qchain.exe >> InstallL2.bat
   )
   
   

7. Create an Deployment Solution Job to copy the PatchBatch folder to C:\PatchBatch on the client machine, and thereafter run the following embedded script,

   REM Install XP Updates
   cd c:\Patchbatch
   call patch-batch.bat
   call InstallL1.bat
   call InstallL2.bat
   
   

8. Add an embedded script to delete the folder c:\PatchBatch from the client machine,

   REM Delete PatchBatch Folder
   del /s /q c:\PatchBatch
   
   

9. Add a reboot power control task

The picture opposite illustrates the layout you should have in the PatchBatch folder. Notice the L1 folder has many updates (there are nearly 90 updates for XPSP2 at the time of writing), whereas the L2 folder has just one at the moment. This reflects Microsoft's move from the old Wextract mechanism which was popular in the Windows 2000 heyday to the update.exe engine which is dominant today. The L2 folder is as a result really only there for legacy reasons, but be aware that Microsoft might release some L2 patches which require the /Z switch to suppress a reboot. A watchpoint for the future.

And this is how the job looks on Deployment Solution.

Setting this job is tedious I have to admit -getting all the patches together initially takes an afternoon. But, once its done, that's it. And maintenance is sooo easy....

Adding Patches to PatchBatch

This is where it gets so easy, you can task anyone in the team to add patches. All you have to do is checkout the new patches on "Patch Tuesday" and download as you see fit to either the L1 or L2 folders (right-click the patch to view the file details. If the description says "Update Package" it is destined for L1, if it reads "Win32 Cabinet Self-Extractor" its destined for L2).

And that is it. The script takes care of it all from then on.

And as for maintaining the patch-level afterward, WSUS or Altiris Patch Management can do the business for you in slow-time.

Getting Clever

I've not implemented the following, but if I get some free time I just might tackle it. Most patches are now well behaved and enter themselves in add-remove programs list. This makes them readily inventoriable with a reg query command from DOS,

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall | find /i "KB" > PatchDump.txt

It should be possible therefore to enhance the above script so that the L1Install.bat and L2Install.bat scripts only install patches that are not already present. This would make this a handy item to carry around on a USB pen drive as another tool in the Desktop admin arsenal?

Hope you find this as helpful as we did.

Kind Regards,
Ian./