AppNote: Roll Your Own -- Creating Custom Packages with ZENworks Patch Management
Novell Cool Solutions: AppNote
By Gary Childers
Digg This -
Posted: 29 Jun 2005
The Patch Challenge
In most IT environments, two of the leading headaches that LAN administrators must deal with on a daily basis are: Keeping Windows PCs up to date with all the myriads of OS patches that are constantly coming out to deal with newly discovered vulnerabilities, and Keeping spyware off of the PCs.
Today, most corporate networks are doing fairly well -- at least, much better than they used to -- in taming the constant threat of computer viruses. Most LAN administrators wouldn't dream of deploying workstations now without some type of antivirus software installed, and without a mechanism to continually update the antivirus definitions that the software uses to detect virus threats.
But the IT industry is still catching up in the area of deploying current OS patches, and by and large, still in a reactive mode when it comes to the area of spyware. Some organizations are still in the "dark ages" of sending out teams of technicians to every PC, to manually apply OS updates and other software (can you believe it?). Many organizations merely react to spyware infections when users complain about sluggish performance, or unusual behavior on their PCs, and then they send out a tech to manually run a spyware scanner.
Spyware is a little "off the radar" to most of the antivirus applications, because spyware programs are technically (for the most part) not "viral" in nature. Many of the current spyware applications spawned off from legitimate programs used by other Web-enabled applications. To make matters worse, there really is no hard and fast definition to date that outlines exactly what is and isn't defined as spyware.
For the moment, we kind of have to rely on the "Senate" definition of spyware, that is: "I know it when I see it." Some companies that produce alleged spyware are actually suing other companies in court, for labeling their software as "spyware". Apparently, it should be called "marketing application software". But in practical terms, most of us rely on the anti-spyware software vendors for that definition, just as we have long relied upon the antivirus software vendors for antivirus definitions.
All that aside, how can LAN administrators keep up with all the constant barrage of OS patch updates, application updates, and anti-virus and anti-spyware updates that perpetually need to be deployed to every single workstation? In large organizations, the "dark age" method of sending out armies of technicians to manually apply updates is clearly unacceptable.
There are network management applications that have stepped up to fill that need. Some of them have been around for years. For example, Novell's ZENworks for Desktops is all about workstation imaging, deployment and management, application deployment and management, inventory, and more. Many organizations are quite successfully using ZENworks to deploy, manage and update all their workstations.
But precisely because a product like ZENworks can do so much for you, there is by necessity a big learning curve that has to be achieved before you can reap all the benefits of the automation of desktop administration. The same can be said of all enterprise management products. For those already invested in the product (and the training), this may not be a problem. But how about for the rest of us?
ZENworks Patch Management to the rescue. Novell apparently saw the need to provide a patch management solution, not as robust as ZENworks for Desktops, but that is simple and effective. Rather than start from scratch, and write their own application, Novell found a best-of-breed solution from PatchLink, and partnered with them. ZENworks Patch Management is, after all, just a re-branding of PatchLink Update Server, with full technical support from Novell.
ZENworks Patch Management (PatchLink) really just does one thing, and does it well: it updates OS and application patches. It uses a completely Web-based application, built on Windows (surprising, coming from Novell) to detect, manage and deploy patches to client workstations. The server uses a subscription service to PatchLink's main site to keep current on available OS and application updates, and from a Web interface the administrator can select and deploy patches to registered workstations.
The workstations run a small PatchLink agent, that periodically checks with the PatchLink Update Server, to determine if there are any update packages assigned to it. If updates are assigned, they are downloaded and applied to the workstation, usually without any end user intervention or even awareness. It happens automatically. If the OS patch requires a reboot, the default action is to notify the user with a popup window that his workstation is updated, and needs to be rebooted.
One big "plus" for the ZENworks Patch Management solution is that the end user requires no administrative rights on the workstation. The PatchLink Update Agent service installed on each client performs the updates. Another "plus" is that it requires very little administrative training. The Web management interface is pretty intuitive, and once you have deployed your first couple of update packages, you're off and running.
Current users of ZENworks Patch Management or PatchLink at this point might be saying "Yeah, so tell me something new." Well, one interesting idea that I can offer is in the area of creating your own customized application update packages with PatchLink. You can "roll your own" updates.
For the most part, PatchLink is designed to deploy pre-defined update packages that are downloaded from the PatchLink main site. These are OS and application updates that have been fully tested and released by the software vendor (such as Microsoft), and then packaged and fully tested again by the PatchLink engineers. These include not only all the Microsoft OS patches (although those are by far the majority), but also patches from Adobe, Citrix, Macromedia, WinZip, and many other vendors.
For antivirus software updates, pre-defined packages are also provided from Computer Associates, Command, McAfee, Sophos, Symantec, and Trend Micro. But conspicuously missing in the lineup, currently, is any type of spyware detection and removal software.
It should be noted here, that using the PatchLink update service for antivirus or other application updates assumes that you actually own the software licenses for those particular products. End of legal disclaimer.
What I would like to demonstrate here is how to use PatchLink Update Server to deploy and update an application of your own selection. While the pre-defined packages from the PatchLink subscription service may provide 99% of what most people need, there will always be that other 1%. And when it's your job to provide that 1% solution, then that becomes an important 1%.
PatchLink Update Server allows you to create custom packages, in addition to all of the pre-defined ones. Those of us who are familiar with ZENworks for Desktops, or other management products, will find no difficulty with this. For those new to deploying automated application packages, I will walk you through it here.
Creating the Custom Package
For this demonstration we will create a custom package to install the Spybot – Search & Destroy anti-spyware application silently to client computers.
The first thing you must do is to acquire the installation files for the application (obviously). The next thing you need is to determine how to perform a "silent" install of the application (if possible), so that end users don't have to make any decisions on how the application is installed.
For the Spybot application, I downloaded the latest version (1.4) from the application vendor's Web site (http://www.safer-networking.org/en/download/index.html). Then I found the installation application's command-line switches for the silent install from the vendor's FAQ page (http://www.safer-networking.org/en/faq/30.html). Then I started creating my package.
Below is a portion of the Web interface of the ZENworks Patch Management server, on the "Packages" screen:
At the bottom of the screen, you can click on Add to begin to add your custom package:
This opens the Package Editor, to start you off in creating your new package. Click "Next" at the intro screen, and then enter the name and description for your package. In the next screen you can select the operating systems to which this package will apply, and then the next screen is where you really start building your custom package:
Right-click on the Target Computer, and select Add Directory, to specify a directory on the target computer where you want to copy the installation files for the package deployment.
Note: the Package Editor expects to browse to the specified directory on the local computer (the one from which you are running the Web interface and Package Editor). So the best way to specify this directory is to first create the directory on the local computer, with the desired installation files, and then browse to it with the Package Editor.
For this example I chose to create a C:\PATCH directory on my local computer, with the installation file SpybotSD14.exe in it, and then specified that directory in the Package Editor.
On the next screen of the Package Editor we create the script that executes the installation of the package. If you are really into scripting, you can get fancy and create a VBscript or Jscript, but to keep it simple, I just created a simple batch file to deploy my application.
Note: It is best to test out and validate the operation of your script before using to deploy your package. Test it locally on a single test computer, to ensure that it works exactly as you expect it to perform, so that it will execute properly when deployed as a package.
On the Scripting screen of the Package Editor, select Edit to input your script. If you have created and tested your script offline (as recommended), then all you need to do is cut and paste the script commands into the editor. My script commands for Spybot installation are:
c:\patch\spybotsd14.exe /verysilent /dir="c:\program files\SpybotSD" /group="Spybot" /noicons /components="main"
As you can see I went a little crazy with the command-line switches, just to demonstrate what level of control I might exercise on the installation. The /verysilent switch runs the installation with absolutely no indication to the user; the /dir= switch allows me to select the target installation directory. The /group= switch told it what program group to create on the Windows Start Menu, but that was really overridden by the /noicons switch, which told it not to create any shortcut icons on the desktop, Start Menu, or Quicklaunch tray. The /components= switch allowed me to select only the main program components for installation, with none of the extra skins or language files.
Once you have saved your script, click "Next" past the next couple of screens, and the Package Editor will upload and compress (if needed) the installation files you specified, and ready the package for distribution.
Silently Running the Application
But like many applications, once installed, Spybot is designed to run with user intervention. Normally a wizard pops up on first execution, and asks the user to update the spyware definitions, immunize the system, and run a scan of any spyware it can find currently hiding in the system.
However, many administrators would prefer not to have to rely on the end user to be responsible to run his own spyware checker, update it and immunize the system. Can't we automate that as well? It just so happens that we can.
For this, I just need to create another custom package, starting out with the same procedure as above. This time, I will name the package "Spybot Definition Update and System Scan" as here:
Again I selected the appropriate operating systems for this package, but skipped past the "Add files and directories" screen in the Package Editor. I only want to execute a series of commands for this deployment.
On the Scripting screen, again I will select "Command" as my type of script, and enter the script commands (or cut and paste them) in the editor:
@ECHO OFF IF NOT EXIST "C:\Program Files\SpybotSD\SpybotSD.exe" GOTO NOGO :SPYCHECK "C:\Program Files\SpybotSD\SpybotSD.exe" /taskbarhide /autoupdate /autocheck /autofix /onlyspyware /autoimmunize /autoclose ECHO Spybot update and scan completed on %date% %time% > c:\spycheck.txt GOTO FINISH :NOGO ECHO Spybot is not installed. Please install Spybot. > c:\spycheck.txt :FINISH
The heart and core of this script is just to run the SpybotSD application silently, automatically updating its definitions, automatically checking the system, and automatically immunizing. The /autoclose is necessary to exit the application, since it is running in the background, invisible to the user.
But you can see that this script first does a check to see whether the program is installed in the path that I specified in the installation package. If so, it silently runs the application, then writes a completion string to a specified text file. If Spybot is not installed, it just writes a different message to the text file, and then exits.
Deploying the Custom Packages
Deploying the newly created custom packages is a snap. Assuming that you have already installed the PatchLink agent on the target workstations, just go back into the "Packages" tab of the PatchLink Update Server Web management interface. To limit the view to your own custom packages, select "Locally Created Packages" in the Status field, and click Update View.
Deploying you custom packages is no different than deploying any other update package provided by PatchLink. Merely check the box beside the package name, and click Deploy on the toolbar at the bottom of the screen.
Go through the screens of the Deployment Wizard, selecting the computers to which you want to apply this package, and select any particular options you wish for the deployment. Hint: 99% of the time, the default choices work just fine, so you can click "Next" through virtually all the screens in the Deployment Wizard.
Of course, always test out any deployment on a test PC, before inflicting it upon your live users. We would prefer to catch all of our "OOPSes" before other people get to see them, right?
If you watch the target computer during the deployment, you will see disk activity, but no other indication that software is being deployed. That's what we want to see.
The Update and System Scan package we created is deployed in exactly the same way. You will see quite a bit of disk activity as it scans for spyware, and if you have Task Manager open, you can also see that SpybotSD.exe is running as an application. But there is no other sign that the application is running.
I have used Spybot – Search & Destroy as an example application which can be deployed as a custom package, but really the concept is precisely the same for any other application that you may wish to deploy in this manner. It only requires that the installation application can be run with command-line switches, or a configuration file, or some other type of scripting mechanism.
In terms of ease-of-use, it's hard to beat ZENworks Patch Management for the everyday updates of the operating system and standard applications. But if you have an application that is not included in the standard list, you might have to learn to "roll your own" deployment, which involves a little scripting, and learning the installation application's command-line switches or configuration file parameters.
Fortunately, it's not exactly rocket science, just a little bit of good old-fashioned work. Happy patching!
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com