5.2 Migrating from a Previous Version of ZENworks

In addition to the topics described in the previous section, a number of key factors should be taken into consideration when migrating from a previous version of ZENworks to ZENworks Configuration Management:

5.2.1 Application Deployment Strategy

If a customer already has a mature deployment of ZENworks Desktop Management in place, it is likely that there is an extensive application repository. In many cases, the customer is using the Tiered Electronic Distribution component of ZENworks Server Management to tightly manage the distribution of application software code to the file servers needed to support deployment to users. In addition to these components, the customer might have already invested in the processes and workflows to facilitate application delivery and might be reluctant to start again with a new system.

ZENworks Configuration Management provides an encrypted data store known as the Content Repository, which stores delivery content for applications, patch remediations, and ZENworks system updates. When an application bundle is created, the delivery content is uploaded to the Management Zone, encrypted, and subsequently synchronized to all ZENworks Primary Servers. This process allows for applications to be delivered securely to devices by using HTTP, regardless of the physical location of the device.

However, it is possible to create application bundles that refer to application repositories that are external to ZENworks. For example, a customer might want to deliver applications with ZENworks Configuration Management but refer to the same application content (MSIs) that ZENworks Desktop Management is pointing to. This approach has several advantages:

  • The existing repositories can be used.

  • The existing processes for application management can be used. If a customer has heavily invested in these processes, this is a compelling case to use the existing methods.

This approach also has some disadvantages:

  • The management of content is controlled outside of ZENworks Configuration Management, where the files reside. Therefore, the user rights to these locations must be managed outside of the ZENworks Configuration Management management tools.

  • Using the standard file and print delivery mechanisms restricts content delivered to devices inside the firewall.

With the ZENworks Content Repository, the devices download content though HTTP, which allows the content to be made available to external users through a Primary Server location in the DMZ.

5.2.2 Application and Policy Migration

ZENworks Configuration Management ships with a migration utility designed to migrate applications, policies, and associations from a ZENworks Desktop Management system to ZENworks Configuration Management. When applications are migrated to ZENworks Configuration Management by using this tool, the data for the applications is automatically placed in the Content Repository. If a customer wants to use the existing application repositories, the migration tool should not be used for these applications.For more information on the migration tool, see the ZENworks 11 SP2 Configuration Management Migration Guide.

5.2.3 Active Directory

If the preferred server and directory platforms of your organization are Windows Server and Active Directory, and you are currently using ZENworks middle tier architecture and Identity Manager directory synchronization, ZENworks Configuration Management makes it possible to eliminate both of these stepping-stone technologies and interact directly with Active Directory for user authentication and content association. This can be done by simply configuring the ZENworks Configuration Management Zone to point directly at Active Directory as a user source.

5.2.4 Repurposing Hardware Used by Previous ZENworks Products

Customers commonly want to reuse hardware when possible. If a customer is migrating from the previous ZENworks technologies such as ZENworks Patch Management, ZENworks Asset Management, eDirectory, and ZENworks Desktop Management, the hardware utilized for this functionality can be repurposed.

In some instances, it might be beneficial to reuse the hardware to provide the additional ZENworks Primary Servers and ZENworks Satellite devices required by the migration project. Planning reprovisioning of hardware is an important step in a migration project and can help reduce the architecture costs for ZENworks Configuration Management deployment.

5.2.5 Introducing ZENworks Patch Management to an Existing ZENworks Zone

Patch Management

ZENworks 11 provides an integrated and common architecture for ZENworks Configuration Management, ZENworks Patch Management, ZENworks Asset Management, and ZENworks Endpoint Security Management. Conceptually, introducing one of these products into an existing ZENworks Zone is as simple as entering a license key. However, for ZENworks Patch Management, it is important to understand the implications of enabling the product so that the introduction of the product can be tightly controlled.

Discover Applicable Update Bundles

Discover Applicable Updates (DAU) bundles are created for each instantiation of the operating system, service pack, and CPU architecture that is currently under management in the ZENworks Zone. Each DAU bundle contains all of the patch signature files (.pls) in a ZIP file. When the signature collection for a given OS, SP, and CPU changes, such as when a new patch is released, the entire ZIP file is rebuilt, the bundle version is updated, and the entire payload is distributed to each managed device that needs it.

It is important to understand the implications of enabling ZENworks Patch Management for all devices at the same time, because each DAU bundle contains approximately 20 MB of data and each device requests its DAU bundle content on a set schedule. In addition to the requirement for delivering the DAU bundle to all devices that are to be patched, the DAU bundle is updated on a daily basis. Another point to bear in mind is that remote sites with satellites inplace should have the latest DAU bundle in order for local devices to perform vulnerability scans.

If no additional signature files are present, the DAU ZIP file is rebuilt at the back end, but the checksum of the ZIP file should be the same. This means that the ZIP file should not be distributed to devices unless a new patch has been released.

When you configure Patch Management, the Subscription Download page has a number of important options. First, select only the languages of interest are selected to ensure that the patch repository is kept to the minimum size necessary. Next, make sure you understand the Cache patch bundles to satellite servers option. If this option is enabled, all bundles related to the patch are synchronized to all satellite servers. This option has the potential to drastically increase the network and storage requirements of ZENworks and should only be selected after careful consideration.

Enabling ZENworks Patch Management in an Existing ZENworks Zone

Because of the DAU bundles and the potential for causing network disruption, you should follow these steps when enabling ZENworks Patch Management in an existing ZENworks Zone:

  1. In ZENworks Control Center, enter the license key to enable the Patch Management features.

    ZENworks Control Center should show Patch Management in the left pane and in the Configuration page.

  2. At the Zone level, in Configuration > Device Management > ZENworks Agent, disable the Patch Management agent module.

  3. Connect the devices to the Zone and receive this configuration before proceeding.

  4. When you are ready to start, choose the Primary Server that is responsible for downloading patches and assign it to the Patch Management role. This server needs Internet access.

  5. In Configuration Management > > Patch Management > Subscription Download, choose the subscription settings for language and platforms.

    IMPORTANT:Select Cache patch bundles to satellite servers only if you are sure that you want to do this.

  6. If you are patching LINUX go to Configuration Management > Patch Management > Patch Subscription Credentials, and configure the credentials to be used for Novell Customer Center and Red Hat Network access.

  7. After the Patch Subscription process runs, the Zone is populated with vulnerabilities and patch management bundles.

  8. Enable the Patch Management agent module on test devices either through folder or device settings.

    This step overwrites the Zone level settings to disable Patch Management.

  9. Use folders to control the introduction of Patch Management by enabling the agent module in a controlled manner.

Deploying Patches to Remote Sites with ZENworks Patch Management

When you deploy a patch remediation, ZENworks creates a deployment bundle that delivers each of the patch bundles for that deployment bundle. As shown below, each patch bundle to be distributed is automatically configured as an Install action of the patch deployment bundle.

If several patches need to be deployed to a remote location with Content Satellite devices, each of these patch bundles needs to be configured so that they are available on the remote Satellite device. To address this, you have three options:

  • Automatically synchronize all patch content to all satellites.

  • Identify each patch bundle individually, then set the content synchronization behavior.

  • Define the content synchronization behavior on the deployment bundle.

The third option is preferred because it requires the least amount of administration and also ensures that only the required patch data is synchronized to remote locations. If the content synchronization behavior is configured on a patch deployment bundle, ZENworks automatically applies this to the child bundles, or to the bundles that are configured as Install actions. The following example shows how the content synchronization behavior can be set on a Patch Management deployment bundle.

When you manage patch remediation content this way, it is important to ensure that the remediation schedule is set well in advance such that the content can be synchronized to the relevant remote locations. The patch remediation schedule should be based on a number of factors:

  • Whether the patch content synchronization is daily, weekly, or hourly.

  • For how long the schedule is open and how often it is repeated.

  • The available bandwidth.

  • Whether bandwidth throttling is enabled.

    Finally, remember that patches of different severities can have different settings.