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 HTTPs, a firewall-friendly protocol, allowing content to be provisioned to devices in any location, even outside the corporate firewall.
From ZENworks Update 3 onwards, ondemand streaming of content is supported for all content types such as bundles, policies, system updates, and Patch content. Based on requirements, administrators can decide if the content has to be pre-cached or not.
This section covers the following topics:
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 provides an integrated content repository for being able to deliver application, update and policy content to managed devices via the firewall-friendly HTTPS 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.
HTTPS is used to deliver content, rather than SSL or HTTP, 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.
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.
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.
ZENworks 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.
NOTE:The benefits of this distribution method include the following:
ZENworks 20.3 or higher provides the ability to serve content on demand without using a third-party http proxy like squid for caching the content. So as mentioned above, “managing the content on the HTTP Proxy server outside the purview of ZENworks” is no more a drawback anymore, as the content satellite can manage the on-demand content along with the replicate content. But, that said, you may still want to continue using your HTTP proxy for network abstraction but stop proxy caching of the content on, say squid proxy for instance.
For content that should be on the local site, you can pre-replicate the content through Satellite Server precaching.
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.
The benefits of using ondemand content replication include the following:
For content that you know beforehand to be on the local site, you can pre-replicate the content through normal Satellite replication means
For content that you do not know beforehand to be on the site, but which might be required by a user, if the content is already not replicated on the content satellite, the satellite may go on WAN for the first time to fetch the content from its upstream servers and cache it locally and then serve it for all the subsequent requests, pretty much in the same way a third party http proxy would have done
Also, if the same content is configured to replicate and the content has already been cached due to an on-demand request, it would then move the file to the same folder in which it would have otherwise precached on schedule. Hence there wont be two copies of the same file as it would be in case of using the third party proxy caching solution.
Another advantage is that the content will be cleaned up automatically if not accessed after a configurable number of days, thus removing the need for managing the content manually which is needed in case of a using a third party proxy caching solution
If the content is not pre-cached during non-business hours, then huge data can be cached during working hours and might consume more bandwidth. Hence to avoid such issues, it is recommended to pre-cache the content at a suitable time or use a content blackout schedule to block the on-demand replication at a specific time.
If may still want to continue using HTTP proxy like squid for routing other agent requests, but now there is no need use proxy caching of content with squid so no need to manage that content independently.
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.
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 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.
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:
Pre-caching is a mechanism to cache the data on all the servers and satellites mentioned as part of the content servers list. We can define precaching for Windows, Linux, and Mac content. Pre-caching can be configured in ZCC > Configuration > Bundle, policy, and Content > Pre-cache Content.
The content will always be available on the server where the content was created/uploaded. If the content is not pre-cached, then the content will be served on-demand to other servers. On-demand content has a configurable expiry time. In the worst-case scenario if the server where the content was created/uploaded goes down and content on other servers got cleaned up due to expiry, then the content may not be available on any servers. So, it's recommended to pre-cache the content on more than two servers to support fault tolerance.
By default, the system update content will be pre-cached to all the Primary Servers in the zone. The System Update checkbox determines if the system update content should be pre-cached to all content Satellite Servers or none. The checkbox is effective only for the subsequent system updates that will be imported into the zone. If you want to replicate the system Update content for the already imported system Update in the zone, select the system-update check box and run zman ccpe <Satellite_Guid> to replicate the content to the satellite server.
Pre-caching of patches can be overridden at Device level and device folder level.
When overridden at device level, this takes the precedence over folder and zone level settings. We can override the content types at device level, which needs to be pre-cached.
When overriding at the folder level, this is the second precedence that takes place over the zone-level settings. All the child folders and devices under the folder level will have the same settings mentioned as part of the folder-level settings.
We can have pre-caching schedule based on when the patch content needs to be downloaded on all the content server list mentioned at the zone level settings. Schedule can be based on Days of week, monthly and fixed interval. The patch gets replicated based on the scheudle type configured as part of the system.
For the changes in the property file to take effect, no service restart is required. However, changes do not take effect immediately. We will have to wait anywhere from 0 to a max of "sync.interval.ms" milliseconds for the changes to take effect. Of the many properties, following are properties that will be potentially modified by administrator:
sync.interval.ms determines
How quickly are the UI configuration changes (replicated to all PS/SS and stored into local OndemandContentProxy.json file) detected by precaching.
How frequently/quickly is metadata downloaded from upstream servers.
download.disabled – if an Administrator wants to stop precaching which is in-progress, this has to be set to true. Setting it back to false will resume downloads.
download.parallelism determines how many content download threads would be allocated for precaching?
By default, it is one. This can be increased if the upstream server can handle more load & bandwidth is available. For example, if a PS serves 10 satellites, increasing this property by 1 on every satellite causes an additional 10 threads to be dedicated for precaching in PS.
max.elapsed_time_since_compaction.ms determines how quickly the expired content is deleted.
corruption_detection.interval.ms determines how frequently are the metadata backups taken.
file.unavailability.interval.ms determines how long precaching waits before it tries to re-download a file that failed to download with an irrecoverable error.
max.file.download_time.ms determines how long precaching waits before assuming an in-progress content download as no longer in-progress.
min.wait_time.host_recovery.ms determines how long precaching waits for an inaccessible/busy upstream server to come up.
min.download.duration.percent is used when the trigger for schedule misfires. If configured as 50, it means that we have to trigger if there was a misfire but less than 50% of schedule duration has elapsed so far.
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.
ZENworks 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 later versions of ZENworks, several content types are exposed in ZENworks Control Center. The list of content types have been expanded since.
The following figure highlights the specific content types that you can configure in ZENworks.
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.
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.
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:
Promote a managed device to a Satellite device.
Assign the content role to the Satellite device.
Set the content synchronization schedule to None.
Specify the content that is needed at the location.
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.
Copy the content to a removable media and send it to the remote location.
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).
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.