Novell Home

Automating your Patches on ZENworks 6.5 Desktop Management

Novell Cool Solutions: Feature
By Martin Irwin

Digg This - Slashdot This

Updated: 12 Jan 2006
 

Executive Summary
The ZENworks Desktop Management 6.5 Patch
Design rules and Environmental Considerations
Component Grouping
Requirements
Pre-installation Requirements
Services loading and unloading
Variables
Example of Windows Subscriber variable definition
Conclusion
Appendix A: Default features available for each Software Package
Appendix C: Credits and Legal Attribution
Author
Contributors and Reviewers

Executive Summary

In today's business environment, manually controlling ZENworks servers for periodic updates and tasks is impractical. It is a well-known fact that automating the patching process can significantly lower a system's total cost of ownership.

Typically, when administrators patch a given ZENworks Server, they need to Launch the Service Pack installer which identifies the servers needing to be patched, logs itself in, stops the services, and copies the files. All the while the administrator is monitoring the screen for its completion. The time involved can be anywhere between half an hour and two hours–and sometimes even more. Multiply that by hundreds of servers and many patches–the costs to your business can skyrocket.

From a physical-networking perspective, things become even more complex. Sending the same patch five times to five servers instead of once and then forwarding it on can cause slow response times for your users. On the other hand, when you don't fully utilize the same WAN bandwidth, it is wasted during off-peak hours.

This white paper addresses all of these concerns by showing how the award-winning Novell ZENworks software can tier, schedule and automate the distribution of their own ZENworks Desktops Management and Servers patches. My previous White Paper gave you the foundation for TED and Software Packages so I will not repeat that here.

In this white Paper I hope to show you the ready-made Compiled Packages (CPKs) Novell provides now for ZENworks Desktop Management 6.5. We discuss the patching methodologies of patching Backend and Middle Tier services for both the Windows and NetWare operating systems. We dive right into the design of each CPK and recommended Best Practice for using each one.

The ZENworks Desktop Management 6.5 Patch

With the release of Service Pack 2 for ZENworks Desktop Management 6.5, Novell introduced an array of CPKs that allow you to automatically patch your desktop environment with ZENworks . With this new feature you can choose to patch your Backend and Middle Tier Servers with either the traditional Setup Graphical User Interface (Setup GUI) or use ZENworks Server Management to automate the roll out. If your network of Backend servers is spread out over WAN lines or you have ten or more backend servers you will gain efficiencies by using the CPK.

Note: When we talk about backend services we mean Imaging, Wake On Lan, PREworks, Application Management, Automatic Workstation Import, and Inventory (including XML services). When we talk about Middle Tier we mean services offered to ZENworks on behalf of workstations that are outside the firewall or that only have the ZENworks Agent installed and not the Traditional Client.

The CPKs are divided up into two broad Categories – Middle Tier and Backend. On the NetWare CPKs we also carry Helper CPKs that stop services in advance and start them after the patch, but on Windows the services are stopped and started in each CPK.

Design rules and Environmental Considerations

With this CPK we have not used any custom created NLMs or DLLs. Whatever was available to us in the standard features of the CPK we used. See Appendix A for a list of the features that CPKs provide. Compilation (Builds) were done from the same files and directory structure that the standard Service Pack Two was built from. To ensure consistency Beyond Compare was used to check for file integrity and location between a server with the Windows Service Pack GUI and the CPK.

Environmental Considerations:

Java usage: NetWare Remote manager is heavily dependent on Java as are a lot of Third party utility s built on NetWare. Consider including Pre and Post-Distribution scripts for your Distributions to unload these in advance of the CPK rollout as some java classes may prevent other Java classes (those in the CPK) from unloading or loading.

IISADMIN: This exe is unloaded in the Windows CPK so we can patch Middle Tier servers. In testing we noticed that Windows servers under heavy load reach a state where they will not allow you to unload this IISADMIN service manually. Consider re-booting these servers in advance to alleviate this problem. In other words if you can't unload IISADMIN manually, the CPK will also be unable to.
NOTE: The symptom we noticed on these heavily loaded servers was that when you attempted to unload IISADMIN (right-click on the service and stop) was that it would complain about a dependent (or child) process that needed to be unloaded first- HTTP_SSC. A reboot and application of the CPK worked, however.

Windows Services

If you have any of these services disabled: Simple Mail Transfer Protocol, Network News Transport Protocol, World Wide Web Publishing Service, the CPK will fail when it attempts to reload them. A workaround to this issue is to enable these services prior to rollout then disable them and/or reboot your Windows servers.

Component Grouping

In the design of each of the ZENworks Desktop Management CPKs we attempted to follow a simple Component structure. We grouped each component into a maximum of three components: the first being a component that only stops services; the next being the component that copies in the files, edits properties files and sets the registry; the last component of the group we start back the services.

By grouping and naming the components in this manner we simplify troubleshooting with the TED.LOG file. Increasing your logging level to 6 will show you which component the CPK failed on. For example, if the CPK had trouble stopping imaging a note saying "Imaging Stop services" with the exception will be logged.

Requirements

Each CPK will not run unless ZENworks Desktops Management is installed and the correct operating system is running. This prevents NetWare CPKs from running on Windows servers and vice versa.

Each component of the group has a requirement of at least having itself installed. For example we won't run the component group of Imaging if imaging has never been installed on that server.

Pre-installation Requirements

To ensure your Java Virtual Machine environment (JVM for Net ware and JRE for Windows) you must Roll out the corresponding CPK for ZENworks Server Management prior to rolling this ZENworks Desktop Management CPK. In other words, If you are rolling out the ZENworks Desktops Management sp2 CPK you need to roll out the ZENworks Server Management SP2 CPK first. If you do not do this your Sybase inventory databases will never upgrade themselves. The file name for the ZENworks Server Management CPK is ZSM65SP2_POLYDIST.cpk and is found on the component CDROMS of the Service Pack.

Services loading and unloading

In some cases we use NCF and/or batch files to stop and start services.

  1. Imaging on Windows uses a DLM (DS loadable Module). The only way to unload DLMs individually is programmatically. The CPK cannot do this so we used two batch files that start and stop the NDS (NDSserver0) service. This also ensured the CPK did not continue to process until NDS was completely shutdown.

  2. Imaging on Windows needed inventory and wake-on-lan services to be stopped (if installed) to copy in some of its files. The Stop Component for imaging does this.

  3. To ensure Apache is unloaded properly on NetWare 6.0 servers we use the Nvxadmdn.NCF file. However with NetWare 6.5 we unload the apache.nlm using the native CPK unload command.

  4. To prevent the ZENworks agent on Windows Middle Tier servers reloading before we get a chance to copy in files we rename c:\windows\system32\novell\ncpw32.dll prior to unloading the service.

  5. On Windows Middle Tier services we unload these services prior to unloading Middle Tier and the IIS server. If they are not installed on your server the CPK continues anyway. We also start them, which may mean you need to stop them with a Post-distribution process if you don't want them started. You can use Pre and Post-distribution services to do this - a new feature provided for in ZSM 6.5.

      1. Simple Mail Transfer Protocol.

      2. Network News Transport Protocol.

      3. World Wide Web Publishing Service.

      4. IISADMIN (IIS itself).

  6. For NetWare servers Helper CPKs are used. We had to do this because the inventory servers was falsely triggering the CPK to continue (telling it had finished) before it had. We were copying in the inventory files and attempting to re-load inventory before it had even stopped properly. So you must roll out the helper stop CPK prior to the main CPK rollout.

  7. Application management needed only one component as there were no services to start and stop.

  8. On NetWare we edited the ZENworks .properties files for inventory, remote management, Wake on LAN and the database. Because of the limitations in the CPK text search and replace features an entry of [removed by the CPK] is left and the new values are appended at the bottom.

Variables:

All CPKs use two standard hard-coded Variables. As each new CPK is built going forward we change these variables to suite. Windows CPKs use nested variables that are hard coded as well- these I mention in detail in the table.

%SP-VALUE% = 2
%VERSION% = 6.5.2.50913

Below is a table of variables you need to define for your own environment. You do not need to configure a variable for a servers that don't have that component installed. The drive or volume should only be written with the : and \ as in C:\ or SYS:\. You only need a folder name if you have installed ZENworks to a drive or a volume and a non-standard folder. If you have, add in this folder name to the variable. For example if you have installed ZENworks to c:\APPS\ZENworks or, in the case of NetWare Data:\APPS, you will need your variable to reflect the extra folder name. Do not put in the ZENworks folder name as this is already written into the CPK.

Main CPK Name and Description Variables Needed Helper CPKs
zdnbksp2.cpk

This is the main backend CPK for NetWare servers. It patches any backend component installed on the NetWare server. (You will need to run the relevant Middle Tier CPK if you have Middle Tier services installed on the same server.)
1. DEST_INV – <ZENworks installation Volume> for the inventory files.

2. DEST_WOL – <ZENworks installation Volume> for Wake on LAN and Remote files.

3. DEST_XML – <ZENworks installation Volume> for the inventory files. ONLY used if you have XML only running on a server.
1. Startinv.cpk, Stopinv.cpk. Used to start and stop Inventory services before and after the rollout of patch. Will stop your Sybase database without a prompt.

2. StopWol.cpk, startwol Stops and starts WOL services.
zdwbksp2.cpk

This is the main backend CPK for Windows servers. It patches any backend component installed on the Windows server that is Not Middle Tier. (You will need to run the relevant Middle Tier CPK if you have Middle Tier services installed on the same server.)
1. %Winsdrive% Default Variable nested in the CPK – turns into %systemdrive% Variable when CPK runs. (you do not need to define these)

2. DEST_INV – <ZENworks installation Drive Letter> for inventory files.

3. DEST_WOL – <ZENworks installation Drive Letter> for Wake on LAN and Remote management files.

4. DEST_XML – <ZENworks installation Drive Letter> for XML Files. ONLY used if you have XML only running on a server.
There are no helper CPK files for this CPK.
zdnbksp2.cpk

This is the main backend CPK for NetWare servers. It patches any backend component installed on the NetWare server. (You will need to run the relevant Middle Tier CPK if you have Middle Tier services installed on the same server.)
1. DEST_INV – <ZENworks installation Volume> for the inventory files.

2. DEST_WOL – <ZENworks installation Volume> for Wake on LAN and Remote files.

3. DEST_XML – <ZENworks installation Volume> for the inventory files. ONLY used if you have XML only running on a server.
1. Startinv.cpk, Stopinv.cpk. Used to start and stop Inventory services before and after the Rollout of patch. Will stop your Sybase database without a prompt.

2. StopWol.cpk, startwol Stops and starts WOL services.
zdwmidsp2.cpk

This Main Middle Tier CPK patches your Windows servers only. (You will need to run the relevant backend CPK if you have backend services installed on the same server.)
1. DEST_IIS – The Drive letter of your IIS files.

2. %Windsdrive% - becomes %systemdrive% when we run the CPK.

3. %WinsDIR% - Becomes %systemroot%

4. WINS-DR-NAME – Becomes the Windows directory name.
There are no helper CPKs for this CPK.
Zdnmidsp2.cpk

This Main Middle Tier CPK patches your NetWare 6 and greater servers only. (You will need to run the relevant backend CPK if you have backend services installed on the same server.)
No variables need to be defined by you on this CPK. No helper CPKs are needed.
zdnbksp2.cpk

This is the main backend CPK for NetWare servers. It patches any backend component installed on the NetWare server. (You will need to run the relevant Middle Tier CPK if you have Middle Tier services installed on the same server.)
1. DEST_INV – <ZENworks installation Volume> for the inventory files.

2. DEST_WOL – <ZENworks installation Volume> for Wake on LAN and Remote files.

3. DEST_XML – <ZENworks installation Volume> for the inventory files. ONLY used if you have XML only running on a server.
1. Startinv.cpk, Stopinv.cpk. Used to start and stop Inventory services before and after the Rollout of patch. Will stop your Sybase database without a prompt.

2. StopWol.cpk, startwol Stops and starts WOL services.
ZDMAGENT.CPK

This contains the updated Agent MSI files for the client in all languages. Each main CPK installs English by default.
Note: This contains two components that installs on Windows and/or NetWare.

1. NetWare – DEST_VOL- The location where you require the Agent files to go.

2. Windows- DEST_DRIVE- The location where you require the Agent files to go.
No helper CPKs needed.
c165sp2.cpk

This contains the upgdated ConsoleOne snapins for all components.
DEST_C1 – The location you want your ConsoleOne Snapins copied to. Note: Be sure to include the directory names all the way down to and including 1.2 directory. No helper CPKs needed, however this CPK will fail on any server that someone has ConsoleOne open on.

Example of Windows Subscriber variable definition.

Conclusion

NetWare backend CPK was the only one needing a helper CPK. These CPKs need only be rolled out to servers that have the inventory services or the Sybase database loaded. For information about each component of the CPKs you open them up in a ConsoleOne that has the ZSM Snapins configured. We advise you to do this to familiarize yourself with each CPK prior to the rollout. Each Component is heavily documented with instructions on what they do and for the most part why they are doing it. Remember to always upgrade your ZENworks Server Management environment first with its CPK prior to the ZDM CPK rollout.

For each CPK we do not believe a re-boot is required as when tested all services reloaded cleanly. Always ensure you run both Middle Tier and Backend CPKs if both services are running on the same server.

The two extra CPKs provided allow for the installation at a volume and/or drive of your choice of ConsoleOne Snapins and agent MSI. Yes, all languages are installed with the MSI CPK but it doesn't require too much work to create your own CPK (copying the one provided) to only roll out a single language agent MSI file.

Appendix A: Default features available for each Software Package

Component Features of Software Packages

Feature Description Example
Base component processes on requirements with specific values 5. Operating system
6. Memory
7. Disk space
8. Set commands
9. Registry
10. Files
11. PRODUCTS.DAT
This is useful if you want just one software package to apply to multiple operating-system versions. Each component can be set to execute only for that operating-system version.
Execute the following items prior to each component processing 1. Load or unload NetWare loadable module commands
2. Load Java class
3. Start or stop services
4. Pre-execute a system, NetBasic or Perl script
This is useful when you back up a directory. Before you back up the files, you can unload the NetWare loadable module, Java process or services loaded from this directory.
Copy files around the server volumes or up to the server from the package.Copy or move files on the local server or copy new files from the server software package to the server.This is useful in copying files you are about to use as upgrade or patch. It is also useful in backing up files before patches and in placing them in patch directories so they are ready to patch.
Manipulate strings within existing text files (or those just copied onto the server)
  • Search and replace words in files.
  • Utilize an extensive array of tools.
  • Append or prepend.
  • Add words after or before.
  • Add lines before or after.
  • Nest variables here to add granularity.
See the Open Enterprise Server upgrade section for a good example of how to use this feature. The Open Enterprise Server strings needed a silent install script written specifically for each server. (Use this feature and rewrite them when they are run.) This is also useful for changing the /etc/hosts setting on all servers.
Apply a common "Set Parameter" configuration to NetWare servers and set, remove or modify registry settings Standardize settings, set and/or remove settings, and install or remove applications (Windows or NetWare registry-setting changes) The upgrade compiled packages for network-management agents use these to insert new registry settings.
Add, replace or modify PRODUCTS.DAT entries on a NetWare server Allow the installation of new applications This feature is commonly used in NetWare and eDirectory patches.
Perform post-installation tasks 1. Load or unload NetWare loadable module commands

2. Load Java class

3. Start or stop services

4. Run Red Hat Package Manager, Microsoft Installer or IPS scripts

(NOTE: To run a these, load the post-installation script and add the command line arguments. See the sections on eDirectory patches and the policy and distribution patches for examples of both.
See the ZENworks Server Management patch compiled package for an example of running Red Hat Package Managers.

The eDirectory patches on NetWare launch IPS scripts with arguments; see these sections for details.

See the eDirectory patches on Windows section for an example of running a Microsoft Installer update with a software package.

A graphical user interface will help you configure content application. You can set restrictions on each component; they can be as simple as a registry setting, a file, an entry in SYS:SYSTEM\PRODUCTS.DAT, or it can be as general as an operating-system version. For example, you could restrict a patch to be applied only to NetWare 6.5 but not to 6.0 or 5.1. If necessary, restrictions can be just as granular with the whole server software package.

Of course, Novell provides an array of ready-made compiled packages. ZENworks patches, Java update patches and ZENworks agent installations are available for download via the Novell Web site. You merely need to insert the relevant compiled package file into a distribution, schedule it, assign it a channel and send it out.

Appendix C: Credits and Legal Attribution

Author
  
Martin Irwin Global Resolution Engineer, ZENworks , Worldwide Support Services, Novell Inc.

Contributors and Reviewers

Yamini Prasad Developer ZENworks for servers, Novell Inc.
Jyothi Shetty Development Manager, Novell Inc.
Joseph Astin Developer of ZENworks Desktop Management install, Novell Inc.
Randy Funk Developer of ZENworks Desktop Management install, Novell Inc.
Bryan Nahrwold Testor for ZENworks Desktop Management, Novell Inc.
Larry Supino Testor for ZENworks server Management, Novell Inc.
Paul Hardwick Software Engineer, Novell NDS/eDirectory, Critical Problem Resolution, Novell, Inc.
P Rohini Developer of ZENworks Desktop Management install, Novell Inc.

*Windows is a registered trademark of Microsoft Corporation. Linux is a registered trademark of Linus Torvalds. Palm is a registered trademark of Palm, Inc. RIM and BlackBerry are trademarks of Research in Motion, Ltd. Tivoli is a registered trademark of the IBM corporation. HP OpenView is a registered trademark of Hewlett-Packard Development Company. Beyond Compare and the Beyond Compare Logo are trademarks of Scooter Software Inc http://www.scootersoftware.com/. All other third-party trademarks are the property of their respective owners.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell