Summary:

This tech note discusses some options and scenarios for configuring Prism Deploy in a WAN environment.

Assumptions:

The example below illustrates a network environment consisting of three regions.  One assumption is that all Prism Channel administration is done from the central server. The satellite offices within each region are connected via T1 to a regional server. The three regional servers are connected via Frame Relay to a central server at headquarters. This could be an Active Directory environment with an OU for each region, although Prism’s Channel configuration does not have to mirror the Active Directory structure. Below is simple sketch of the environment. Given this environment, what are the potential scenarios for setting up Prism Deploy Channels?

First, a quick explanation of Prism Deploy and how it communicates. Prism Deploy’s Channel Server communicates with the target computers that have the Prism Client installed via TCP/IP, default port 3133. The Client computers poll the Channels to which they are subscribed during a configurable interval; default is once a minute. Bandwidth usage for this communication is minimal.

When a Task is assigned to a target computer, the Prism Client runs the command-line defined in the Task. A Task can be a Package, a Script that calls several Packages and other commands, or any executable such as a batch file, a URL, or even a DOS Copy command. Prism has logic to optimize bandwidth usage when installing Packages. Only files and settings that need to be installed on the target computers are pulled across the wire. However, you should always carefully plan how and from where Tasks will be pulled, and time the running of them when bandwidth is not a concern, especially when running non-Prism commands.

Solutions:

Three potential solutions are discussed below. All three solutions propose that Task files (Packages, Scripts, Commands) should be pulled from a regional server. This will ensure that Tasks are pulled across a fast T1 connection, thus saving bandwidth over the slower frame connection. For further information about setting up tasks to run from distributed servers, please see our KB article link at the bottom of the page.

Solution 1:  Create a single Channel on a central server.

• Advantages: 
• Single channel for central administration.
• All target computers are subscribed to the same channel.
• Disadvantages: 
• You potentially need to create 3 Tasks, one for each region pointing to \\region1server\packages\app.pwc, \\region2server\packages\app.pwc, \\region3server\packages\app.pwc. Note that you could define a variable on target computers or use the OS built-in variable %LOGONSERVER% when defining the Task, e.g., “%LOGONSERVER%\packages\app.pwc”. When the client computer launches the Task, the variable points to the appropriate server. Using the %LOGONSERVER% variable might not be a good choice if there are multiple servers that could handle the logon.
• Client computers are polling to the central server over the slower frame connection.

Solution 2:  Create three channels (one for each region) on a central server.

• Advantages: 
• Each channel represents a single region; regions are self-contained.
• Fewer computers to manage in each channel.
• Disadvantages:
• Three channels to manage.
• Client computers are polling to the central server over the slower frame connection.

Solution 3:  Create three channels (one for each region) on each regional server.

• Advantages: 
• Client computers are not generating traffic over the slower frame connection.
• Disadvantages:
• Three channels to manage.
• Potentially slower management by the central administrator over the frame connection. Note that you may want to increase the timeout time when managing Channels by opening the Console and selecting File | Channel Settings | Connection tab.

To further discuss any of the above information, please contact the New Boundary Technologies Support Center at support@newboundary.com or 612-379-1851.