Recently in a conversation with one of our Advanced Technical Training engineers I was asked to describe the use cases for the new HTTP Proxy and CIFS Content Repository options that were introduced in ZENworks 11.2.3a. He indicated the documentation does an acceptable job of explaining what they do, but not the why. So this blog post is an attempt to explain the why for these new options.
Use HTTP Proxy to Make Content Available Dynamically
There are several use cases where an HTTP proxy that is used by the agent to establish communications with the Primary and Satellite servers might be useful. The first of these scenarios is what I will refer to as the Dynamic Content scenario. This scenario occurs when you have a large amount of content (in the form of bundles and policies) that you want to make available to a large number of geographically diverse devices and you don’t really know where the user might access the content from. This is common in areas that have large numbers of branches such as banks, hospitals, retail, etc. In this case you really have two options: first, you can replicate all of the content to every server in your zone or second, you can use the HTTP Proxy as a means to cache the content.
The drawback of replicating all of the content to each site is that you might use bandwidth and storage space replicating the content to a server that will never actually be asked to provide the content. Instead, with the new Location Specific proxy configuration you can implement an environment similar to the one below:
In this diagram you can see the following components:
ZENworks Primary Servers or Content Satellite that has the actual content. These are the traditional content sources in a ZENworks environment. Essentially the content on these servers is populated by the normal, scheduled replication of the ZENworks content system. Content that has been Included on that server is automatically replicated when the replication schedule for that type of content is replicated.
Proxy Server that is being used to proxy content queries when needed. On sites with no Satellite server, or those with satellites that you don’t want to replicate certain content to, you can place an HTTP proxy. In this case, content will be cached in the Proxy server’s cache (as opposed to the ZENworks Content Repository) on the device. In the case of the diagram you can see that only some of the content has been cached. This would have happened the first time a device on that site requested that piece of content.
If you choose to do so, you can install the http proxy on the same machine as the Satellite server on a site, just be sure to properly configure closest server rules and content sources as described in the configuration section below.
Note: By default all ZENworks agent traffic is routed through the Proxy server when a Proxy server is configured. In some cases this may be undesirable because if the Proxy server goes down you would be unable to retrieve configuration information as well as content. In 11.2.4 you can configure a registry key that specifies which traffic is routed through the Proxy.
Managed devices. These are the devices that are requesting information from either the Primary or Satellite server and are running the ZENworks Adaptive Agents. In this diagram the PC with the monitor represents these devices. Each location would be configured to use its own local satellite as its closest content server, or the content server across the WAN if no local content satellite exists.
The content. The folders in the diagram represent the physical files that are associated with the bundle or policy. These files are stored either in the ZENworks content repository in the case of Satellites and Primaries or in the HTTP servers proxy cache after the first time the content is requested.
In order to have the agent attempt to get content from the Proxy server you need to do the following when configuring your ZENworks environment:
On the Settings tab of the Location or Network Environment object (shown in the screen shot below), specify settings for the HTTP Proxy so that the agent is using its local proxy. So in the case of the diagram each of the branch offices would be configured to use their local proxy.
On the Servers tab of the Location or Network Environment object (shown in the screenshot below), ensure that the content servers you want the device to use is listed as a Content Server. In the diagram Devices in REG1 and BRANCH2 would list the local Content Satellite listed as content servers. In BRANCH2 the Primary server at HQ would be listed, and in BRANCH3 and BRANCH4 the content satellite in REG1 would be listed.
Ensure that content you want to have replicated to content servers is assigned appropriately on the Content tab of the server, bundle or policy object (shown in the screenshot below). In the diagram, this means that on REG1 content is Included on the server. On BRANCH2 any content that you want to replicate to the local content server through normal ZENworks content replication should be included, but any content you want to be pulled and cached on demand should not.
In addition to the ZENworks environment changes you will also need to configure your Proxy server to not cache content when proxying itself and specify an appropriate time to live for cached content on your proxy server. You may also choose to configure proxy throttling if provided by your proxy to limit the bandwidth the proxy server is allowed to use when making requests.
Once you have properly configured the environment the following describes how content is distributed to workstations at each of the branches in the diagram:
HQ and REG1. Any managed devices at HQ will retrieve their content directly from the Primary servers or Content Satellites as configured in their closest server rules.
BRANCH1. Devices will see that the content is available from the HQ servers. They will request content through the Proxy to retrieve the content from the HQ servers. The first device will cause the proxy to retrieve the content. This content will then be cached by the Proxy server to be delivered for subsequent requests for the same content.
BRANCH2. Devices will see that content is available on both the local satellite server and the HQ servers. If the Bundle is configured to be Included on the local server, then the device will request the content through the Proxy from the local satellite server. You can configure the Proxy NOT to cache responses from this device. For content that isn’t included on the local satellite server, the device will request the content through the Proxy from the HQ servers. The first request will cause the content to be cached to fulfill subsequent requests.
BRANCH3 and BRANCH4. Devices will see that the content is available from the REG1 servers. They will request content through the Proxy to retrieve the content from the REG1 servers. The first device will cause the proxy to retrieve the content. This content will then be cached by the Proxy server to be delivered for subsequent requests for the same content.
Pros and Cons of Dynamic Content Delivery
The following are the advantages of this method of content delivery:
Only the content you know is going to be accessed at a site is replicated to the site. This could significantly reduce WAN traffic in certain network environments and may also reduce the content repository size on the local server.
You don't have worry about whether the content has been pre-replicated, as long as the device can access the content from a server reachable by the proxy.
The following are disadvantages of this method of content delivery:
Content is pulled across the WAN whenever the first user launches the bundle, policy or system update, instead of being scheduled like ZENworks content distribution.
You have to install and manage the proxy server software on some device on the site.
Other common HTTP Proxy Scenarios
Other common scenarios for using an HTTP Proxy between agents and their servers include:
Limit traffic to a single IP address from a branch to a site for security reasons.
Provide proxied access to Primary Servers to workstations on the Internet when you don’t want to open ports to the Primary Server on the external firewall.
Using a CIFS Server as a Content Repository
The other new capability introduced in the 11.2.3a UI is the ability to specify the path to a CIFS share that should be used as a content repository, as shown in the screenshot below:
This allows you to take advantage of the CIFS protocol to retrieve content vs using the HTTP protocol. The advantages of doing this include:
Allows you to utilize high performance file servers or clusters to distribute the content instead of relying on the Tomcat web server on the Primary Server.
Offloads the content distribution from the Tomcat instance on the Primary Server freeing up resources for other Primary Server tasks such as loading collection data or servicing configuration requests.
When a location or network environment has a CIFS server configured this is always treated as the first Content Server in the list and is never directed across the HTTP Proxy (if set) because it is a CIFS connection, not an HTTP connection. If the content cannot be pulled from that server then it will automatically failover to the list of Content Servers using the HTTP protocol.
Note: The CIFS path used as a content repository must provide Public access so that credentials are not required. Additionally, the CIFS path must be a share of the root of the content repository directory as it appears on a Primary Server.
Using the new location specific HTTP Proxy and CIFS Server settings you optimize the flow of network traffic related to the ZENworks Adaptive Agent and may be able offload the content distribution role.