3.11 Content Management

The content in this guide is data that has been uploaded to the ZENworks zone for distribution to a managed endpoint. After the content is uploaded, it may be compressed and encrypted and then distributed to other Primary Servers and Satellite Content Servers in the zone. The ZENworks content repository is accessed by managed devices, by using HTTP, a firewall-friendly protocol, allowing content to be provisioned to devices in any location, even outside the corporate firewall.

A few examples of content include Windows Bundles, Patch Remediation data in ZENworks Patch Management, and ZENworks System Update content. After the content resides centrally on the Primary Servers of the zone, the next stage is to define which content belongs at which Satellite Server location and how to send the content to that location.

This section covers the following topics:

3.11.1 Content Delivery Mechanisms

ZENworks provides a number of different methods for distributing content to managed devices. This allows you to use the method(s) that are appropriate for your environment and management goals. The supported delivery methods include:

ZENworks Content Repository (Tomcat via HTTP)

ZENworks provides an integrated content repository for being able to deliver application, update and policy content to managed devices via the firewall-friendly HTTP protocol. When you use this method to distribute bundle content you receive the following benefits:

  • ZENworks controls the replication of content to the various Satellite devices and Primary Servers that exist within the Management Zone.

  • By default, data is encrypted within Tomcat, so anyone with file access to the server will not be able to access applications. When you upload content to a bundle you can select whether the content should be encrypted and compressed or not.

  • HTTP is used to deliver content, rather than SSL, so there is no overhead to re-encrypt the content for transmission.

  • Access to data is based upon the relationships defined within ZENworks. If you are not a target device or user of ZENworks you have no access to application, image, or policy data.

  • Because the ZENworks Content Repository is a replicated content repository, and because devices receive a list of closest servers, this method offers built-in fault tolerance and load balancing capabilities across servers to deploy the content.

  • This is a firewall-friendly solution. It is very easy to allow DMZ access to content for remote, Internet-based devices, without cumbersome configuration changes on routers, switches, and firewalls.

Drawbacks related to using the ZENworks content repository include:

  • The ZENworks server becomes less scalable because it is serving more HTTP requests from managed devices. Most ZENworks servers are capable of serving between 200-1000 http requests simultaneously, based on the configuration of the server.

  • It can take some time before an application has finished encrypting and injecting its data into the Web server.

  • You need to know where the content needs to be available, so that the appropriate Primary Servers and Satellite Servers can have the content included.

ZENworks Content Repository (via CIFS)

Versions of ZENworks after 10.3 allow the ZENworks agent to leverage a CIFS share path as its primary content repository source. When this is configured in the network environment or location that the device is at, it will first attempt to retrieve the encrypted and compressed content from the URL specified. This allows you to offload the content distribution from the Tomcat HTTP stack. In this case, you are still using the ZENworks content repository, you are simply making that repository available via CIFS. The benefits of this are:

  • ZENworks controls the replication of content to the various Satellite devices and Primary Servers that exist within the Management Zone.

  • By default, data is encrypted within Tomcat, so anyone with file access to the server will not be able to access applications. When you upload content to a bundle you can select whether the content should be encrypted and compressed or not.

  • CIFS is used as a protocol to distribute the content to the agent. This means that the Tomcat server can continue to serve HTTP/HTTPS requests while the CIFS modules on the server serves up the content.

  • Access to data is based on the relationships defined within ZENworks. If you are not a target device or user of ZENworks you have no access to application, image, or policy data.

This method has the following drawbacks:

  • Because CIFS is typically not opened on the firewall, this method is not useful for distributing content to devices outside of the corporate firewall. However, this can be addressed by not specifying a CIFS share for locations or network environments that indicate the device is outside the firewall.

  • Only a single CIFS share can be specified for a given location, failback is always to a HTTP server.

  • You must manually share the content repository and ensure that it is publicly accessible.

Proxy Distribution of Content in ZENworks Content Repository via HTTP

ZENworks 11.2.3a or higher provides the ability to have network environment or location-specific HTTP proxies defined. This opens up yet another method for deploying content to the device. With this method you could place an HTTP proxy server on the agent’s local network and then all the content calls will be sent to the Proxy Server first. Content can then be requested from the closest servers that have the content and cached by the HTTP proxy. This option is typically used in conjunction with the ZENworks Content Repository via the HTTP method. Many times you may have the proxy and the Satellite installed on the same machine. This way if the Satellite can answer the request, it will, and if not, the proxy server will and can cache the content. This is useful if you do not know what content needs to be available at a site and want is to be delivered in a more on-demand fashion.

The benefits of this distribution method include the following:

  • For content that you know needs to be on the local site, you can pre-replicate the content through normal Satellite replication means.

  • For content that you do not know needs to be on the site, but which might be required by a user, you can simply ensure that the content is available on some server in the agent’s closest server list. If the content is needed it will be requested on the WAN the first time, but then cached by the HTTP proxy for subsequent requests.

  • This method is firewall friendly as it utilizes the standard HTTP port.

The drawbacks of this distribution method include the following:

  • You will need to manage the HTTP Proxy server independently from ZENworks.

  • Not all content that the agent uses will be directly on the local satellite, only the pre-cached content will be on the local satellite.

Network File Servers (CIFS, NCP, or other supported servers)

ZENworks can also leverage files that are stored on other network servers such as Novell NetWare servers, Novell Open Enterprise Server servers, Microsoft Windows servers, WebDAV servers, or other servers for which a Windows file system provider exists. Strictly speaking, this is not content as defined throughout the rest of this section. This option provides the following benefits:

  • Uses the existing infrastructure.

  • Less overhead is required on the ZENworks server.

While this does have some advantages, it also has the following disadvantages:

  • ZENworks has no control over the distribution of application content. The replication of content must be managed outside ZENworks with products such as ZENworks Server Management or rSync.

  • ZENworks has no control over who has access to the data.

  • Application content is not encrypted and can potentially be installed by anyone with access to the server.

  • This is not a firewall-friendly solution. Access from outside the firewall requires VPN access in order to deliver applications.

Micro Focus Recommendations for Bundle Content Delivery

The mechanism you decide to use for delivering your content depends on your objectives. However the following general rules apply:

  • Use the ZENworks Content Repository unless you have a good reason not to. This provides the best way to manage content that needs to be delivered by ZENworks.

  • Use CIFS or Network options to offload the Tomcat instance on the Primary Server if want your Primary Server to scale to more clients.

  • Ensure that you mark any sensitive content that you upload in a bundle as Encrypted, Compressed so that the content can only be read by designated clients.

  • Use HTTP Proxy servers if it makes sense in your environment.

  • ZENworks 11.2.3a and later provide an option to have Satellite Servers replicate their content from other servers defined in their closest server rules, make sure you leverage this if your organization’s network layout makes it more efficient to do so.

  • Properly tune the Primary Servers that will serve content requests as discussed in Tuning the ZENworks Primary Servers.

3.11.2 Defining the “What” in Content Management

An important improvement in Content Management is the ability to define content replication at the bundle-folder level. This ability provides several advantages over previous releases of ZENworks because it allows groups of applications or patches to be sent to sites with a few mouse clicks.

To define the Satellite devices to which the content located in the folder should be replicated, click the Details hyperlink of any bundle folder and click the Settings tab. If bundles are subsequently created in the folder, the content synchronization rules of the bundle folder are automatically applied.

In the following screen shot, all bundles in the Human Resources bundle folder are sent to the Stockholm remote office. A bundle created in the Human Resources bundle folder is automatically marked as Include for the Stockholm location.

The technique of configuring content synchronization at the bundle-folder level is particularly useful when dealing with patches. As patches are stored in bundle folders organized by the vendor, and then by month or year of release, groups of related patches can be sent to a given site in one operation. For example, automatically synchronizing all Microsoft patches for the previous month is extremely easy because this can be accomplished by configuring the relevant ZENworks Patch Management bundle folder, as displayed in the following screen shot:

3.11.3 Organizing Bundles

Before considering content management, you should organize bundles into separate folders for ease of administration. Bundles can be grouped into folders by function such as Productivity Applications Collaboration Applications, or by business function, such as Finance Applications and Human Resources Applications. Introducing content control at the bundle-folder level means that the decision of how to organize bundles can also take into account the locations from where the applications will be accessed. For example, if a particular remote location has specific application needs unique to that site, consider creating a bundle folder for that location, thus allowing the content settings to be configured once for the core applications for that site.

If bundles are to be presented to users in the Windows Start menu, the default folder structure is a mirror of your bundle folder structure. For example, if the Micro Focus Vibe Login bundle is associated with a user or device and instructed to be included in the Start menu, the Start Menu displays Core Applications > Collaboration Applications > Micro Focus Pulse Login.

This behavior can be overwritten in each bundle object, allowing the administrator to define for each bundle what the Windows Start menu structure should look like. This process can be cumbersome for each bundle. Therefore, you must consider the balance needs of content replication, ease of administration, and end-user presentation to decide about the folder structure for your bundle objects.

3.11.4 Defining the “How” in Content Management

ZENworks 11 contains power mechanisms for granular control over content that should be hosted at specific locations. When you distribute content to Satellite locations, the concept of creating a window of opportunity for synchronization becomes very important. A window of opportunity involves defining the amount of time and the amount of bandwidth available to transfer a particular piece of content. In the versions of ZENworks prior to ZENworks 10 SP3, all content was treated the same way. However, in ZENworks 11, several content types are exposed in ZENworks Control Center. The list of content types have been expanded since version 10 SP3.

The following figure highlights the specific content types that you can configure in ZENworks 11.

After you have defined what content should be available, the next stage is to define how and when it gets to the defined locations. For each content type, the administrator can specify the window of opportunity for synchronization, the recurrence period, and the bandwidth to be consumed during these operations. Administrators can now ensure that other services at remote sites are not affected by content delivery. If the window of opportunity and throttled bandwidth rate is not sufficient to completely synchronize all content, the process resumes from where it stopped when the window of opportunity opens again.

The following screen shot shows that Critical Security Patches have the opportunity to synchronize every 4 hours for up to 2 hours, consuming only 300 KB/s during the transfer.

In this scenario, the customer wants to ensure that critical security patches are available promptly but still wants to protect bandwidth at the same time. If the content to be synchronized takes only 10 minutes to complete, the window of opportunity closes after 10 minutes. If the transfer takes more than 2 hours, the remainder of the content is synchronized 2 hours later when the next window of opportunity opens, because of the 4-hour interval.

3.11.5 Critical Information Required To Determine Content Synchronization Settings

Before defining the content rules for a given location, you must collect the following information:

  • The customer's content priority. For example, what should be available as soon as possible and what content can wait until after hours, or perhaps weekend transfers.

  • The network bandwidth available from the data center to each site, and the network utilization at each site. In some cases, a site might have a large data pipe but it might be subject to high utilization because of other applications and services that are running.

The following screen shot shows that each content type can be configured with its own window of opportunity so that it can accommodate any customer requirement.

ZENworks offers the administrator significant flexibility in managing content synchronization, ensuring that content is always available at only the relevant locations, and more importantly that ZENworks does not consume all the bandwidth during this process.

3.11.6 Offline Content Replication and Management

ZENworks allows you to easily promote any managed device to a Satellite device with the roles of content repository, inventory and status collection point, imaging server, or an authentication point for local Active Directory or eDirectory instances. These roles are defined centrally in ZENworks Control Center and are applied automatically when the device checks in next.

Consider a situation where you need to launch a new site for management that is behind a very slow or saturated link. ZENworks can easily automate the delivery of content and throttle bandwidth to get the data needed to that location without adversely affecting other services hosted at that location. However, if the location needs GBs of application content, this process might take days or even weeks if small windows of opportunities and low-bandwidth throttles have been configured. If network providers charge customers on the basis of network utilization, sending large amount of content across WAN links should be avoided. ZENworks 10 Configuration Management SP3 provides the ability to export the content required by a Satellite device. Subsequently, the content can be transferred to a site through removable media, and imported into the content repository of the local Satellite. The process can save the customer unnecessary bandwidth consumption along with the associated time and financial costs.

The process for offline content synchronization is as follows:

  1. Promote a managed device to a Satellite device.

  2. Assign the content role to the Satellite device.

  3. Set the content synchronization schedule to None.

  4. Specify the content that is needed at the location.

  5. Export the content by using the zman command line utility with the Satellite Server Export Content option.

    C:\>mkdir \content 
    C:\>cd content 
    C:\content>zman ssec "Devices/Workstations/EMEA/novell-f7d8d036" c:\content 

    The command looks up the content that is marked as Include for a given Satellite that is currently not available, and exports the content to the defined location. If this is a new site, Step 3 and Step 4 ensure that this is all the required content to launch the site.

  6. Copy the content to a removable media and send it to the remote location.

  7. After the data is available at the remote site, import it by using the zac command line utility with the Content Import option.

    C:\>zac cic c:\tools\content -l:c:\content.log 
    Importing 125 items for content type Default...
    Imported 125 items.
    Successfully imported content (125 items).
  8. After the content has been successfully imported, configure the content schedule and bandwidth throttling as is required for the site.

After this process is complete, setting the content synchronization schedule instructs ZENworks to ensure all subsequent delta changes are automatically synchronized.