OPEN CALL: Patching Windows XP with only ZENworks
Novell Cool Solutions: Tip
Digg This -
Updated: 17 Apr 2006
OPEN CALL: Andrew P. wrote: I was wondering if you could do an Open Call on how to patch Windows XP clients using ZENworks works? I need something that requires the least amount of work to patch 1000 machines over 30 sites. Products like PatchLink and SUS/WUS are not able to meet these requirements as there are no Windows servers on these sites (required so patches are not pulled over the WAN) - only NetWare 6.5 boxes.
Anyone have suggestions for Andrew? Fire away.
- Patrick Farrell
- Brian Mantler
- Jeff Crawford
- Hans Hegeman
- Adam Kearsey
- Stephen Smalley
- David Lange
- Gregg Heimer
- Lisa Deger
- Eric Ho
- James Koerner
- Matt Woolery
- Scott Russell
- Rodney Stuurman
- Richard Lewis
- Thomas McDonough
- Jennifer Sundberg
- Christopher Farkas
- Oliver Ringsdorf
- Kevin Gates NEW
We use ZENworks works to patch XP right now. It's a manual process of downloading the patches and making them into ZENworks applications, but it works just fine. Every patch I have seen writes a registry key. We simply set up a ZENworks application running the patch with its appropriate command line switches, associate it with all users or workstations, and set it to force run. In the condition section of the ZENworks app, we test against the OS version and the non-existence of the registry key that is created by the patch.
For example: KB903235 will create a registry key
Don't let the SP3 throw you; any post SP2 updates usually show up under there.
This is where VMware earns its weight in gold. Snapshot a Windows XP session, apply the patch manually, then check the registry to see what key it created. Build your ZENworks application, revert the snapshot to before the patch, and test it.
Microsoft has a utility named qfecheck which reports on the status of installed hotfixes. There is also a utility named qchain which lets you install more than one hotfix per reboot.
First, you need to install qfecheck on your machines.
After this has been installed on your workstations you need to create a ZENworks application that runs qfecheck and installs any hotfixes you may want.
I create a batch file and push it down to the workstations to run in unsecure mode. I also distribute the hotfixes to the local machines. I put all of these files in %systemroot%\system32\updates. My batch file for Windows 2k something looks like this:
@echo off qfecheck > %systemroot%\system32\updates\qfecheck.txt rem I like to date/time stamp my logs, note that I always append to the log echo "Start Updates -- %date%--%time%">> %systemroot%\system32\updates\updates.log rem win2k sp4 find "Current Service Pack Level: Service Pack 4" %systemroot%\system32\updates\qfecheck.txt >nul if errorlevel 1 ( echo "%date%--%time% W2KSP4_EN">>%systemroot%\system32\updates\updates.log %systemroot%\system32\updates\W2KSP4_EN.EXE /Z /M ) else ( echo "%date%--%time% did not run W2KSP4_EN (already installed)">>%systemroot%\system32\updates\updates.log ) rem post sp4 rollup 1 find "Update Rollup 1: Current on system." %systemroot%\system32\updates\qfecheck.txt >nul if errorlevel 1 ( echo "%date%--%time% KB891861">>%systemroot%\system32\updates\updates.log %systemroot%\system32\updates\Windows2000-KB891861-x86-ENU.EXE /Z /M ) else ( echo "%date%--%time% did not run KB891861 (already installed)">>%systemroot%\system32\updates\updates.log ) rem zotob find "KB899588: Current on system." %systemroot%\system32\updates\qfecheck.txt >nul if errorlevel 1 ( echo "%date%--%time% KB899588">>%systemroot%\system32\updates\updates.log %systemroot%\system32\updates\Windows2000-KB899588-x86-ENU.EXE /Z /M ) else ( echo "%date%--%time% did not run KB899588">>%systemroot%\system32\updates\updates.log ) . . . .
You can add as many hotfixes as you like.
After all hotfixes have been run, you need to run qchain, so add these lines to the bottom of your batch file:
%systemroot%\system32\updates\qchain.exe echo "Stop Updates -- %date%--%time%">> %systemroot%\system32\updates\updates.log
I set my app object to only run once, then when I have new updates, I modify my batch file, add the hotfix to the files distributed, and increment the version number on the application. Conversely, you could set the job to always run, but only run qchain if a hotfix was installed.
One other thing, be sure to read Hotfix Installer by Doug Glenn found on Cool Solutions. I have never tried it, but it looks like it is even better than my solution noted here.
Good ol' fashioned qchain.exe.
I used qchain.exe for a long time before moving into a dedicated Patch Management solution.
You can run it from within a login script or use a ZENworks Application object to push it out (just use a distribution script).More information on qchain.exe can be found in KB Article 269861.
Do not forget to run MSBSA or qfecheck when you are done.
Use the Cool tool Hotfix Installer
I use the tool to patch about 600 Windows 2000 PCs with one NAL-object. To patch Windows XP PCs, it can be done in combination with the Zwxpdrive tool if you are using mapped drives. (XP doesn't recognize drive mappings with the Unsecure/Secure System User option).
I've used the following method to patch my Win2000 and XP clients. We're running ZfD 4.
For larger Windows service packs I'll create a specific ZEN app to run the update silently at login. Haven't tried it with Windows XP SP2 though.
We do this firstly by downloading the MS patch and saving to a location everyone that is logged in has access to. In the MS downloads area for the patch in particular, they have a list of files and their version number as per the fix. I specify that the OS needs to be Windows 2000/XP and at least version 5.1.2600, and one of the files fixed version numbers needs to be less than that of the file being updated. Under the run options parameters I have
(use whatever parameters you like here).
Finally I choose who or what groups I wish to distribute by.
On a final note I also select force run and determine force run order. I do this by numbering the patches based on the month of release.
We don't have quite as many users as what you are after, we only have about 60 in the office and 40 in our remote locations, however it saves me a heap of time. There are lots of other options to refine this process, but hopefully this points you in the right direction.
I'm glad someone asked this question. I've done it so many times that I feel I could write a book on the subject. Perhaps I'll do that while I relax on the Hawaii cruise I'm earning with all my points!
David provided such a long and well-detailed response, we thought it would be easier to consume in a separate article. Check it out.
Well, of course you can use snAppShot to create any type of patching with windows updates, but that is only, of course, if you pretty much have the same image amongst your entire site. I even use snAppShot to open software Firewall Ports through Windows XP SP2 for specific applications - works great. Then again, don't forget about Novell's Patch Management software, that is, if you have a spare Windows server box and some $$$.
We are using WSUS to patch our Windows XP, but as I rolled out Windows XP - SP2 we decided to use ZENworks so that we could control the deployment. Also, after we applied SP2 we needed six additional patches so I added them to the end of the script then forced a reboot.
Here is a sample copy of my script:
Install-SP2.CMD @echo off Start \\bandit\u1\install\winxpsp2\Pre-SP2-Install.cmd #DOS window that is displayed so that the user knows that SP2 is being installed NET STOP "Network Associates McShield" #Stops McAfee - speeds up SP2 by 20 minutes \\Bandit\U1\Install\WinXPSP2\i386\update\update.exe /U /Z /Q #Actual silent install of SP2 copy \\bandit\u1\install\winxpsp2\i386\fecc_dt.bmp c:\windows\fecc_dt.bmp #New wallpaper so that we know who has been updated set computername >> e:\public\patches\SP2-Install.txt #log to a file the PC NAME for reference @echo "Applying Post Install Patches" #Applying 6 patches with qchain.exe prior to reboot \\bandit\u1\install\windows_security\sp2-post\WindowsXP-KB886185-x86-enu.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\WindowsXP-KB887742-x86-ENU.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\WindowsXP-KB887472-x86-enu.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\WindowsXP-KB894391-x86-ENU.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\WindowsXP-KB896727-x86-ENU.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\WindowsInstaller-KB893803-v2-x86.exe /quiet /norestart \\bandit\u1\install\windows_security\sp2-post\qchain.exe NET START "Network Associates McShield" #Restart McAfee Start \\bandit\u1\install\winxpsp2\Post-SP2-Install.cmd #Post Install Script that forces a reboot after 3 hours
The ZEN Application Details:
Run Options: Path to file: cmd.exe Parameters: /c %SOURCE_PATH%\Install-sp2.cmd Environment Tab: Run: Hidden (this will run the SP2 in the background so users can work while upgrading) The Pre-SP2-Install and Post-SP2-Install do not run hidden. Availability: OS Greater than/equal to 5.1.0 File Version: C:\WINDOWS\system32\svchost.exe is less than 5.1.2600.2180
You can use this same format for any patch. For the availability you just need to pick a file that will get upgraded after the patches are applied. This will be different for each patch.
I used this same format when we were still running NT workstations that did not support SUS. Really works great!
Sample Pre-SP20-Install Script
@echo off echo ******************************************************************************* echo * echo Your PC is being updated with Windows XP Service Pack 2 in the Background echo * echo It is possible to continue to work during the upgrade but you will see a slight echo performance decrease during the installation echo * echo This installation will take up to 50 minutes echo * echo You will be prompted to reboot when the installation is done echo * echo * echo ******************************************************************************* e:\update\dotsleep 1200 "Press any key to close this screen" if errorlevel 1 goto end exit :end Exit
Sample Post-SP20-Install Script
@echo off echo ******************************************************************************* echo * echo Your PC has completed the Windows XP Service Pack 2 install. echo * echo Your PC will automatically REBOOT in 3 hours echo * echo Save all data and Press any key to reboot now. echo * echo ******************************************************************************* echo * echo * echo * \\bandit\u1\install\winxpsp2\dotsleep 10800 "Press any key to shutdown NOW or q to CANCEL" (this is a sleep program that allows you to break out)" if errorlevel 1 goto end e:\update\shutdown.exe /L /R /C /Y /T:60 "You have 60 Seconds to SAVE Data!" :end Exit
I use Dotsleep for lots of scripts for displaying instructions for uses. This is a program that was written by one of our C-Programers 15 years ago. I also used this on my Novell File Servers before the Server command in the Autoexec.bat so that I could break out of the server start up. Saved a lot of F5/F8 commands.
DOTSLEEP <Seconds> "Message" If errorlevel 1 goto end command you want to run goto end :end exit
While DOTSLEEP is processing - any key will process the next line. Entering "q" will produce an errorlevel = 1 and goto end.
From time to time we deploy MS patches to our workstations. We are managing 530 plus workstations from three sites. All sites are connected with Fiber.
- Download all patches from MS website, and put them in \\server\vol\folder
- Create a batch file. Patches.bat
\\server\vol\folder\Windowsxp-kb111111-x86-enu /quiet /norestart
\\server\vol\folder\Windowsxp-kb222222-x86-enu /quiet /norestart
and so on.........
- Create a workstation package, and associate with all workstations.
- Under Windows XP tag, add policy "Patches"
- Under Action tag, add Action; Name:\\server\vol\folder\patches.bat; Working Directory: C:\Windows\system32
- Under Policy schedule, define the policy schedule type. We usually select On System Startup because it even works well with WOL service.
- Click Advanced Setting, Completion: check Disable the action after completion; Fault: Disable the action; Impersonation:system; Priority: Normal; Save all settings and the package is ready to go.
Because the schedule of package and policy is defined as System Startup, we usually turn on our workstations at night with the WOL service.
Check out Running Multiple EXEs from one App Object for some ideas.
I use the naming convention mentioned in the above article for the files. I put each patch in a application object and use the -u -n -z -q switches to get a silent install. Set to run once. I attached some AXT files as an example what I did for the MS05-038 patch for Win2000/XPSP1 and XPSP2.
We have some machines that are still at SP1 due to application issues. So for XP patches that have different patch files for SP1 and SP2 I make 2 application objects. I then make a system requirement on each to check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion to see if the value is/isn't "Service Pack 2". You can see this in the attached examples.
There are tools such as Shavlik and Ecora that allow distributed repositories - in the UNC format so the patches themselves can be copied to your remote Novell servers. The administration would be done on a workstation in the main office.
You can do this with ZfD but it is a lot of work. Before we implemented PatchLink, we setup this up with ZfD.
Step 1: Download all the patches to local servers.
Step 2: Setup a ZfD app that copies the patches to the local workstation. (Patches will not execute from a network correctly all the time.)
Step 3. Setup ZfD apps to execute each patch. You have to setup the correct switches in the parameters to make the patch execute correctly. You have to create a separate app for each patch, put them in the correct installation order. If you do this, use macro names where possible. Then you only have to change the Macro field value and you can just copy the patch app when setting up a new app.
If your users have admin rights, you can setup a batch file for each a group of patches and just execute the batch file instead of each patch as a separate app.
Step 4: delete the patches when you are done.
This is a lot of work because you have to manually download the patches, put them on the local servers and setup the ZEN apps. It can be done but very, very time consuming. I would recommend using PatchLink. You only need one Windows Server at your primary location. Then set up Distribution Servers at each location. The Distribution Servers can be a simple Windows xp/2000 workstation. It does not need to be a server. Just a basic XP box will easily handle the load. PatchLink already does all the work for setting up the switches for the Patches. This includes software like Macromedia Flash, Winzip, Novell Client, and Acrobat Reader! We are doing this and it has saved me so much time. I am able to push out patches within minutes if it is critical, instead of taking hours.
I call a batch file that looks for the existence of current patches. The backups of patches are stored in the Windows directory as folders labelled $NtUninstallKBxxxxxx$ (where xxxxxx is the patch number) I use the following format:
IF EXIST "C:\WINDOWS\$NtUninstallKBxxxxxx$\spuninst\spuninst.exe" GOTO 1 \\<server>\<volume>\xppatches\KBxxxxxx.exe -u -z :1
When a new patch comes out I add another couple of lines to the batch file. You just need to check what the switches are prior to installing (using /?) as they often change. Set it to not reboot the computer as with the amount of XP patches that come out the users will be booting twice a couple of times a week. Create an application object in ConsoleOne and associate to the everyone group. Set it to run in ZENworks at login and to run as system user. Ensure you have given workstations rights to the area on the server. Alternatively, copy the files to each workstation prior to running the patch.
My 2 Cents: Using WSUS with Windows Terminal Server Web Edition means you only need one MS license and desktops can access the WSUS services via the central IIS-based web server. May be OK if WAN bandwidth is available and cheaper (but not as good as) PatchLink.
As I have seen someone else comment, before we rolled out Patchlink we created an app object for each patch - which was an administrative nightmare. I found the Hotfix Installer utility on Cool Solutions. This utility works great; you basically setup one app object and keep your source files on the server. You setup the app object as a Force Run/Distribute Always. The utility has an ini file that controls which patches are to be installed. The utility checks to see if they are installed - if no new patches, it just stops. If new patches are added to the "patches.ini" file, then the utility begins to install. You can control the reboot from the patch, the utility, or a post command. The Hotfix Installer utility also creates a cumulative log file for each workstation and gives a status for each patch in the ini file.
So you create one app object, and just update the patches.ini file and put the source files on the server when you are ready to deploy a new patch (following testing of course!). If you have local desktop restrictions in your environment, elevate rights in the app object via "Unsecure System User."
Also, the author of the utility is very responsive and actually sent me some newly complied code when I was having a bit of trouble.
I'm actually from PatchLink, since ZENworks Patch Management is powered by PatchLink, I was reading this.
Andrew needs to know that ZPM's Patch Distribution Point software can be installed on any Windows machine, including a workstation, for local caching and distribution of patches. This is the easy to install PDP which can be launched from the management server and installed on any Windows machine with a ZPM agent already installed.
Also, the PDP is based on Squid, so you can do the same thing by installing Squid on any Linux machine, it is just manual instead of being launched from the ZPM server. Finally, if an organization has an existing web caching solution in place, regardless of what it is running on, they should be able to tie ZPM patch distribution into the existing solution.
Here is what we do with delivering and applying the patches to our XP workstations where the users don't have admin rights.
I have one NAL application that I just append all the patches to that I want to send out. This way, one application does it all and when we reimage a PC, just one application has to run and I don't worry about chaining them together.
After I have the NAL application push the patch files (and a txt and a bat file) local, I can run them as a system user with admin rights. My application runs the pushed BAT file that then looks to see if a "marker" file is on the PC for that exact patch (ie, already been installed). If it isn't there, it installs the patch with the /passive /norestart then the next line pipes out a text file with the name of the patch ending with .txt (my marker file). Below is what's in the batch file for ONE patch.
REM ---------> This Patch is MS06-002 if EXIST "C:\Program Files\Novell\MSPatch\Windowsxp-kb908519-x86-enu.exe.txt" goto 908519 "C:\Program Files\Novell\MSPatch\Windowsxp-kb908519-x86-enu.exe" /passive /norestart dir *.exe > "C:\Program Files\Novell\MSPatch\Windowsxp-kb908519-x86-enu.exe.txt" :908519
At the end of the batch file, I use the WinXP "shutdown" command to reboot the PC.
- Download Windows Updates to a Folder
- Create a batch file with /norestart - option
- Use the last update the /forceappclose /forcerestart - option
- Make a Snapshot - only Files and Folders - to copy files to client under NAL Application Environment set "Hidden" and "Unsecure System"
We have an environment where we don't have a lot of control over what end users do with/to their computers ... and therefore needed to come up with a solution using only ZENworks Desktop Management that would minimize the chances of something that the end user is doing (or has done) interfering with proper patch installation.
To this end, we've created an app object that
- Copies a set of distribution patches down from the server to a directory on the local PC.
- Copies a premade vbscript down to the %*winsysdir%\repl\import\scripts directory.
- Using the NET command in a post distribtion script, create a user account on the local PC, set the password for that account, add that new account part of the administrators group, and set the login script for that account to be the name of the vbscript that we just copies onto the system.
- Store information about the system's current default logon workgroup in a safe spot in the registry
- Set the autologon registry keys to use the new account we just created, to log into the local system (rather than whatever oddball domain the end user may have misconfigured), and to not log into Novell.
- We also set the RunLogonScriptSync system policy registry key to ensure that the logon script is completely run before windows loads the user desktop.
- Once these tasks are done, the system reboots using the poweroff.exe utility.
We set a number of system requirements for the app object including checking that XP service pack 2 is installed, that Windows Installer 3.1 is installed, and that the end user hasn't filled up their hard drive completely.
The vbscript file has to be hand coded to run the patch files that were downloaded to the PC and this code has to be updated each month when MS comes out with their patch list. This is where programs like Patchlink and ZPM would be nice ... but not everyone can afford those things. At the end of the vbscript you add code to undo the autologin registry keys, allow users to log into Novell again, randomize the password for that account you created, and reboot the system.
A few nice things about this method are:
- when the app object distributes there is something visible on the screen, so the end user knows something is happening. The system is then rebooted before any patch runs.
- When the system reboots, it automatically logs into the new account and starts running the patches. Because the login script runs before the desktop loads, you don't have any of the end user's apps loading/running at the same time.
- Additionally, no user desktop = no users trying to run office when you're trying to install office patches (for example).
Of course, end users may not like the reboots or being without their system for the 5 minutes or so it takes to do the install, but it's the price they pay for the freedom they enjoy in our computing environment.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com