Novell Documentation: ZENworks for Servers 3 - Planning Your Distribution System

Planning Your Distribution System

Use these sections in the following order:

Overview of Policy and Distribution Services

Policy and Distribution Services contains three components:

Tiered Electronic Distribution is a distribution system for your network.
- It is a way to manage your network servers through the distribution of electronic data between servers.
- It uses a tiered architecture for distribution efficiency. For example, workload sharing: one server can service many others, then each of those many servers can also service many more, and so on to any number of tiers.
- It provides Distribution scheduling for efficient bandwidth usage, such as distributing during off-peak hours.
- It provides security to prevent unauthorized tampering with the Distributions.
Server Policies is a system for managing the configuration and behavior of your servers.
Server Software Packages is a feature for automating the installation and upgrading of software on your servers.

TED is usually involved when using any of these components. Therefore, in planning how to configure Policy and Distribution Services, we will concentrate on understanding and configuring TED.

The following sections provide basic information that will help you to understand TED and what you will need to know to configure it:

What Can You Distribute?

The types of electronic data you can distribute using TED include:

Distribution Type	Explanation
File	Files and directories contained on the Distributor server's file system
FTP	Files and directories from an FTP source
HTTP	Content from an HTTP source
RPM	RPM packages for Solaris* and Linux* servers (but only for Solaris if RPM is installed to the Solaris machine)
Desktop Application	Desktop Application objects and files created in ZENworks for Desktops (ZfD)
Policy Package	Policies for controlling servers
Software Package	Server Software Packages for automatically installing or upgrading software on your servers

From this list, you can see that there is a variety of electronic data types that you can distribute to your servers. In later sections, you will be able to understand, create, and configure the Distributions for each type.

How Is Data Distributed?

TED sends Distribution files from Distributor servers to Subscriber servers. The basic distribution process is as follows:

Decide what you want to distribute.
Create the Distribution.
Create a Channel for the Distribution.
Determine which Subscriber servers need this Distribution.
Subscribe the Subscriber servers to the Distribution's Channel.
Make sure the applicable schedules are set (Build, Send, and Extract).
Send the Distribution by refreshing the Distributor, which causes the Distribution to be built according to the Distribution's Build schedule, and sent according to the Channel's Send schedule.
The Distribution is extracted on the Subscriber servers according to their Extract schedules.
The Distributions are used by the Subscriber servers according to the Distribution's type.

From this process, you can see that there are several components of TED that will need to be created and configured.

What Will You Need To Know To Plan Your Distribution System?

You will need to know the following in order to fully configure Policy and Distribution Services:

The Distributions that you will want, including:
- Whether you want to distribute server files, HTTP content, FTP content, or RPM packages
- If there are any ZfD desktop applications to be distributed (affects how you set up Subscriber objects when you have multiple trees)
- Which policies you will need for managing your servers
- What server software should have automated installation
Whether you'll need additional Distributors
Whether you have both Novell eDirectory^TM 8.x and NDS^® 7.x in your environment, which adversely affects Distributors (a workaround is available)
How many databases you'll need for reporting purposes
Whether you need to complete installation of the Subscriber software to your servers
Which Subscribers will need which Distributions
Your network's topology (server platforms, slow WANs, firewalls, NATs, multiple trees, and so on)
Which types of Distribution security you'll need
The system resource and server behavior issues that TED might create
Whether you need to encrypt Distributions for certain servers
Whether you can use Subscriber Groups for channeling Distributions
How you want the Distributions to flow to the Subscriber servers (the tiered distribution model)
How you want to schedule the distribution processes to minimize network traffic, such as during business hours

To determine the above information, plan your configuration, and configure TED, continue with Selecting Your Distributions .

Selecting Your Distributions

This section provides you with basic information for each type of Distribution.

You can build your distribution system incrementally by adding Distributions a few at a time, then adding Distributors as you need them.

There are seven Distribution types. Each has configurable properties for determining how to build and extract a Distribution.

You can revisit this process at any time to add new Distributions.

Review the following Distribution type sections to select which ones you want to create at this time. Planning worksheet entries are provided for each Distribution type.

File

A Distribution Wizard is available for automating the process of creating the File and FTP types of Distributions. For more information, see Using the Distribution Wizard under Installing on NetWare and Windows Servers in Installing Policy and Distribution Services on NetWare and Windows Servers in the Installation guide.

With this type you can select files and/or directories from the Distributor server's file system for distribution, and select a destination location for extraction on the Subscriber.

By default, Cache and Forward is used. This process allows a parent Subscriber to begin sending a Distribution to subordinate Subscribers before it has finished receiving the Distribution. This allows entire Distributions to be sent more quickly through a chain of parent Subscribers in the Distributor's routing hierarchy than if they each had to wait until each Subscriber had completed receiving the Distribution before it started sending.

The File type keeps a list of the files and directories contained in a Distribution on the source machine. If a source file changes, a new Distribution is built the next time its Build schedule starts and consists of the files that are different between the previous version and the current version. To manually force a Distribution to be built, you can use iManager (see Forcing TED Agent Actions ).

For the File type of Distribution, the maximum number of revisions can be set in the Distribution object. When the version number reaches the number you set, the Distributor rebuilds the entire Distribution. For example, the first build will be the baseline Distribution (version 1), the first update (Delta 1) will be version number 2, the second update (Delta 2) will be version number 3, and so on until the number of revisions you set is reached, which triggers a new baseline rebuild. By default, this number is 10.

The File type is sequential, meaning it controls the order for the building and extraction of Distributions. This prevents the building and extracting processes from being performed out of sync.

IMPORTANT: UNIX* file systems are case-sensitive to allow paths and filenames that are identical except for case differences. However, if you select two such files, only the first file selected during extraction will be distributed, because the File type is not case-sensitive. Therefore, do not place two files into a File type of Distribution where their paths and filenames are identical except for case differences.

If synchronization is enabled, the File type can be used for removing files and directories from the Subscriber server's file system upon extraction of the Distribution in one of two ways:

Edit the Distribution object: Remove files from the list of files and directories in the Distribution object. When the Distribution is built again, those files and directories will not be included.
Remove files from the Distributor's file system: Remove files from the Distributor's file system that were part of the Distribution. When the Distributor is refreshed, it will rebuild the Distribution without those files and directories.

In both cases, upon extraction of the Distribution, and with synchronization enabled, those files and directories will be removed from the Subscriber server's file system.

Determine whether you want to create a File type of Distribution at this time:

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the File type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of the servers that will need a File type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the File type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of the servers that will need a File type of Distribution

FTP

With this type you can create a Distribution consisting of files from one or more FTP sources. Each source can contain one or more directories and/or files.

When an FTP site directory entry is a directory, all of the files and subdirectories are built for the Distribution.

A maximum number of revisions can be set in the Distribution object to conserve disk space. By default, the number is unlimited.

Whenever a Distribution's Build schedule starts, the FTP type will create a new Distribution only if the new version would be different than the previous version.

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the FTP type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of the servers that will need an FTP type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the FTP type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of the servers that will need an FTP type of Distribution

HTTP

With this type you can create a Distribution consisting of one or more HTTP sources. Each source can contain one or more target entries.

A maximum number of revisions can be set in the Distribution object to conserve disk space. By default, the number is unlimited.

Whenever a Distribution's Build schedule starts, the HTTP type will create a new Distribution only if the new version would be different than the previous version.

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the HTTP type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of the servers that will need an HTTP type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the HTTP type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of the servers that will need an HTTP type of Distribution

RPM

This is a UNIX platform Distribution. You can distribute Red Hat* Package Manager (RPM) packages using the RPM type of Distribution. Any RPM packages you have created can be distributed to your Linux or Solaris servers through TED. However, RPM must first be installed on a Solaris server, because it is not installed with Solaris software by default.

A maximum number of revisions can be set in the Distribution object to conserve disk space. By default, the number is unlimited.

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the RPM type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of the servers that will need an RPM type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the RPM type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of the servers that will need an RPM type of Distribution

Desktop Application

Distributes ZENworks for Desktops (ZfD) Application objects and associated files to specified locations on the eDirectory tree and target Subscriber servers.

You can distribute Desktop Application Distributions to a Subscriber server on a tree different from the Distributor server. However, this recipient server's Subscriber object and NCP object must reside on the same tree. The Desktop Application Distribution can be sent to such a server on another tree using an External Subscriber object on the Distributor's tree.

For the Desktop Application type of Distribution, the maximum number of revisions can be set in the Distribution object. When the version number reaches the number you set, the Distributor rebuilds the entire Distribution. By default, this number is 10.

The rebuild of a Desktop Application Distribution can also be triggered by any change to the Application object that changes its Revision value. In this case, the Desktop Application Distribution is built as a delta that contains only the files that have changed. For more information, see Rebuilding Desktop Application Distributions .

For more information on integration with ZfD, see Desktop Application Distribution .

This Distribution type is not supported for Linux and Solaris servers.

CONFIGURATION PLANNING WORKSHEET
Under item 3 and item 20,indicate that you will have Desktop Application Distributions, and therefore each server that will be receiving Desktop Application Distributions must have its Subscriber object and NCP Server object on the same tree. Under item 19, enter the Desktop Application type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of the servers that will need a Desktop Application type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 3 and item 20,indicate that you will have Desktop Application Distributions, and therefore each server that will be receiving Desktop Application Distributions must have its Subscriber object and NCP Server object on the same tree.

Under item 19, enter the Desktop Application type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of the servers that will need a Desktop Application type of Distribution

Policy Package

In ZfS 3, policies for Subscribers are enforced by being distributed. Previously, they were enforced through context associations.

With the Policy Package type of Distribution, you send policies directly to servers as Distributions, which are extracted on the receiving Subscriber server. The contained policies are then enforced on that server.

Policies for Distributors continue to be enforced through context associations.

A maximum number of revisions can be set in the Distribution object to conserve disk space. By default, the number is unlimited.

For more information on policies and policy packages, see Server Policies .

Select from the following policies:

Policy	Description
Copy Files	Enables copying of files on a server from one location to another by using policy configurations.
NetWare Set Parameters	Specifies and optimizes selected NetWare Set Parameters for a server or group of servers.
Scheduled Down	Schedules when a server should go down, and whether it should be brought back up automatically.
Scheduled Load/Unload	Automates the loading and unloading order of NLM^TM and Java* Class processes for the selected servers, and for starting and stopping Windows services.
Search	Used in ZfS to enable the Distributor Agent to locate and use policies in the Service Location Package.
Server Down Process	Controls which processes to follow and which conditions to meet before downing a server.
Server Scripts	Automates script usage on your servers.
SMTP Host	Sets the TCP/IP address of the relay host that processes outbound Internet e-mail.
SNMP Community Strings	Allows you to receive and respond to SNMP requests.
SNMP Trap Targets	Sets SNMP trap targets for associated eDirectory objects for reporting purposes.
Text File Changes	Automates changes to text files.
Tiered Electronic Distribution	Sets defaults for the Distributor and Subscriber objects.
ZENworks Database	Sets the DN for locating the ZENworks Database object. This policy must be in effect for Policy and Distribution Services to locate a database for logging successes and failures that are used in creating reports.
ZENworks for Servers	Contains basic configuration parameters for Policy and Distribution Services, such as status logging, defining the server console prompt for the Policy/Package Agent, setting its working path, and setting a database purging limit.

For more information on each policy, see Server Policy Descriptions .

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the Policy Package type as a Distribution to be created. Also indicate the following: Names of the policies For each policy, names of servers that will need the policy

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the Policy Package type as a Distribution to be created. Also indicate the following:

Names of the policies
For each policy, names of servers that will need the policy

Software Package

A Server Software Package is created in ConsoleOne in the Server Software Package namespace. It is first created as a .SPK file, then compiled into the .CPK file that is distributed.

With this Distribution type you can select .CPK files for distribution. This allows you to place a software product into a Distribution for automatic installation on the receiving server. This can include software updates to existing server software on the server.

Multiple .CPK files can be selected for one distribution. Then, individual .CPK files will be applied on the Subscriber, depending on if the .CPK file's prerequisites are met.

IMPORTANT: The order that the .CPK files are applied on a server is not guaranteed, and .CPK files contained in one Distribution that may start in a certain order might not all finish in that same order. Therefore, place each .CPK file in its own Distribution if you want them to be installed in a particular order and use Distribution scheduling to determine the order.

For more information, see Server Software Packages .

Determine the software packages you want to create at this time:

CONFIGURATION PLANNING WORKSHEET
Under item 19, enter the Software Package type as a Distribution to be created. Also indicate the following: A name for the Distribution that indicates its purpose Names of servers that will need a Software Package type of Distribution

CONFIGURATION PLANNING WORKSHEET

Under item 19, enter the Software Package type as a Distribution to be created. Also indicate the following:

A name for the Distribution that indicates its purpose
Names of servers that will need a Software Package type of Distribution

Understanding Your Network Topology

In order for you to efficiently manage Policy and Distribution Services, you will need to know your network's topology. For example:

What are your server platforms?
How many servers do you have per platform?
Where are your servers located in relation to WAN links and firewalls?
Is Network Address Translation (NAT) being used?
Where are your slow network links?

This type of information will be used to help you configure the best distribution management solution for your network.

Print a copy of the Configuration Planning Worksheet . You will be instructed to fill in the worksheet when reviewing the remaining planning sections.

Obtain the following information concerning your network:

Note the trees where you extended the schema for ZfS.

CONFIGURATION PLANNING WORKSHEET

Under item 1, enter the names of the trees in your network where you extended the schema for ZfS.

Draw a diagram of your network structure.
You will use this diagram to determine distribution routes.

Indicate the following on your diagram:
- Where slow links exist
- The number of servers on each LAN (for Subscriber candidates)
- The number of servers outside a firewall
- The number of servers using NAT
Draw tree diagrams that show how your trees are currently organized. Include the main containers, such as:
- The containers that represent geographic locations (a physical tree design)
- The containers that represent the corporate organization (a logical tree design)
- The containers where servers reside (for Distributor and Subscriber candidates)
Indicate the following on your tree diagrams:
- Where servers are located that could be Distributors (NetWare, Windows, or UNIX servers that exceed the minimum ZfS requirements)
- Containers where there are slow network connections
  This should match where you indicated slow connections on your network diagram.
Indicate the following on your network diagram:
- Where the servers are located (as you just noted on the tree diagrams) that could be Distributors

CONFIGURATION PLANNING WORKSHEET
Under item 1, enter the names of the trees in your network where you extended the schema for ZfS.

Are Additional Distributors Needed?

When installing Policy and Distribution Services for the first time, you installed one Distributor with a database file. Generally, you'll need Distributors according to geographic locations or your corporate structure.

User your diagrams to determine whether you need to install additional Distributors.

IMPORTANT: Because Distributions belong exclusively to their Distributors, you will not be able to transfer its Distributions to another Distributor should you later change your mind about using your selected server as the Distributor. The Distributions would need to be re-created from scratch for another Distributor. For more information, see Deleting a Distributor Object and How Its Distributions Are Affected .

After you've seen how your Distributor servers handle their distribution building and sending workload, you can determine whether to add additional Distributors for spreading that workload.

CONFIGURATION PLANNING WORKSHEET
Under item 2, enter the names of the servers where you want to install the Distributor software.

You will also need to determine the following information for each Distributor:

Determining Distributor Properties

The following Distributor properties can be changed from the defaults during installation:

Object Name: If you want to rename the Distributor object, we recommend that you maintain the server's identity in the name, including the fact that it is a Distributor.

TED Container: Plan on using the TED container where you previously installed TED objects.

If eDirectory is not installed on the Windows NT or Windows 2000 server that you want to be a Distributor, a default container object will not be displayed for that server during installation. Therefore, determine a TED container for that Distributor object.

Working Directory: You can use a different volume, drive, or directory path for the Distributor's working files than the default path.

Because the working directory has the potential to be quite large (depending on the size of the Distributions), make sure you have enough disk space.

The default volume on a NetWare server is SYS:. For NetWare servers we strongly recommend that you specify a different volume.

The default working directory path for NetWare and Windows servers is:

ZENWORKS\PDS\TED\DIST

For UNIX servers the path is:

usr/ZENworks/PDS/TED/Dist

The Distributor's working directory is also used whenever a Distribution is created. A subdirectory is created under the working directory using the DN of the Distribution object.

For more information on the working directory, see Working Directories .

CONFIGURATION PLANNING WORKSHEET
Under item 7, enter property information for the Distributor that you want to be different than the defaults. This includes object names, containers for the object, and working directories.

Determining ZfS Software Installation Paths

ZfS uses the following default installation paths:

NetWare: SYS:\ZENWORKS
Windows: C:\ZENWORKS
Linux or Solaris: usr/ZENworks

The Linux or Solaris path cannot be edited. However, you can use different paths for Distributors and Subscribers for NetWare and Windows servers.

IMPORTANT: During installation, ZfS updates .NCF files with installation path information. Because NetWare uses a DOS code page instead of a Windows code page, double-byte or extended characters cannot be used in the paths, or the .NCF files will not execute. Therefore, do not use double-byte or extended characters in any part of an installation path, including a NetWare volume name.

CONFIGURATION PLANNING WORKSHEET
Under item 5, enter the installation path information for the Distributor if it is different from the default path. Include the identities of the Distributors where you have different Distributor installation paths. Under item 6, enter the installation path information for the Subscriber if it is different from the default path. Include the identities of the Subscribers where you have different Subscriber installation paths.

CONFIGURATION PLANNING WORKSHEET

Under item 5, enter the installation path information for the Distributor if it is different from the default path. Include the identities of the Distributors where you have different Distributor installation paths.

Under item 6, enter the installation path information for the Subscriber if it is different from the default path. Include the identities of the Subscribers where you have different Subscriber installation paths.

Determining Whether a Distributor Server Will Host a ZENworks Database

You can have multiple ZENworks databases in the tree, and you can install the database to both NetWare and Windows servers.

The ZENworks database is used by Policy and Distribution Services to log successes and failures for the Server Policies or TED components. Policy and Distribution Services can function normally without using a ZENworks database, because it uses the ZFSLOG.DB file to only log information for reports. ZFSLOG.DB for Policy and Distribution Services does not contain any configuration information.

To determine whether you want each Distributor to have its own database, or have all Distributors share the same database, you need to determine how you want information reported.

Consider the following to determine how many databases to have in the tree:

WAN Traffic: TED does not perform a large number of database updates, so the actual impact on system resources should be minimal. The greatest impact could be the time it takes to perform the transaction. However, if you have slow WAN connections, you might not want database logging to occur over the WAN.
Multiple Distributors: If you have multiple Distributors in the tree, you can have one database for each, or have them share one or more databases. The type of Distributor reporting you want should determine whether to have a separate database for each. For example, are your Distributors specialized in the types of Distributions they'll send?
Consolidated Reporting: To have only one report for all of your TED information, install only one database object and file and have all TED Distributors log to that one file, regardless of WAN traffic considerations. Use the ZENworks Database policy (Service Location Package) to direct all Distributors to that database file.
Specialized Reporting: You might want reports that are specific to a region or group of servers. You can install a database object and file for each such region and have the Distributors in those regions or server groups log to that database. Use a separate ZENworks Database policy (Service Location Package) to direct each Distributor to its desired database file.

For more information, see ZENworks Database .

IMPORTANT: Make sure you select a server for the database where you are installing the Subscriber/Policies option. The Purge Database option in the ZENworks for Servers policy (Distributed Server Package) works only if the Policy/Package Agent software and the ZFSLOG.DB file are located on the same server.

CONFIGURATION PLANNING WORKSHEET
Enter the following information for each Database object to be created: Under item 4, enter the name of the Distributor server that will host the ZENworks Database files. Under item 9, enter the installation path information that is different from the default path. Under item 10, enter a name for the Database object, if different from the default. Under item 11, enter the eDirectory container where the Database object should be created.

CONFIGURATION PLANNING WORKSHEET

Enter the following information for each Database object to be created:

Under item 4, enter the name of the Distributor server that will host the ZENworks Database files.
Under item 9, enter the installation path information that is different from the default path.
Under item 10, enter a name for the Database object, if different from the default.
Under item 11, enter the eDirectory container where the Database object should be created.

Configuring Distributors in a Mixed eDirectory Environment

In ZfS 3, Distributor servers must be able to authenticate to the eDirectory 8.x tree. If your network has both eDirectory 8.x and NDS 7.x installed, you must edit the TED.NCF file on each of your NetWare Distributor servers to ensure that they can authenticate to an eDirectory 8.x tree.

Select an IP address of any server in your tree that is using eDirectory 8.x. This can even be the IP address of the Distributor server itself, if the server is running eDirectory 8.x.

CONFIGURATION PLANNING WORKSHEET
Under item 12, enter the IP address of a server using eDirectory 8.x.

Other Subscribers To Be Installed?

When you first installed Policy and Distribution Services, you might not have installed the software to all of your servers. If you determined that you wanted to install the Subscriber software incrementally to your servers, you can complete another stage at this time.

In setting up a distribution system, not all of your Subscribers need to be installed and running. Subscriber servers can be added to the distribution system at any time.

The following Subscriber properties can be changed from the defaults during installation:

Object Name: If you want to rename the Subscriber object, we recommend that you maintain the server's identity in the name, including the fact that it is a Subscriber.

TED Container: Plan on using the TED container where you previously installed TED objects.

You can use the same context for all Subscriber servers.

If eDirectory is not installed on the Windows NT or Windows 2000 server that you want to be a Subscriber, a default container object will not be displayed for that server during installation. Therefore, determine a TED container for that Subscriber object.

Working Directory: You can use a different volume, drive, or directory path for the Subscriber's working files than the default path.

Because the working directory has the potential to be quite large (depending on the size of the Distributions), make sure you have enough disk space. The default volume on a NetWare server is SYS:. For NetWare servers we strongly recommend that you specify a different volume.

You might need to provide different paths for your Subscriber servers. For example, SYS: for NetWare servers and D: for Windows servers. Variables can be used for path data, such as the volume/drive designation. For more information, see Variables .

The default working directory path for NetWare and Windows servers is:

ZENWORKS\PDS\TED\SUB

For UNIX servers the path is:

usr/ZENworks/PDS/TED/working/Sub

For more information on working directories, see Working Directories .

CONFIGURATION PLANNING WORKSHEET
Under item 3, enter the names of the servers where you want to install the Subscriber software at this time. For each Subscriber to be installed, under item 8, enter the property information that you want to be different than the defaults. This includes object names, containers for the object, and working directories.

CONFIGURATION PLANNING WORKSHEET

Under item 3, enter the names of the servers where you want to install the Subscriber software at this time.

For each Subscriber to be installed, under item 8, enter the property information that you want to be different than the defaults. This includes object names, containers for the object, and working directories.

Determining the Distribution Flow

The following sections provide information for determining distribution routes:

Understanding Distribution Routes

Each Distributor has a routing hierarchy that provides it with a hierarchical path for sending its Distributions. The routing hierarchy contains a list of Subscribers acting as parents for other Subscribers. The hierarchy of Subscribers can be many levels deep. Subscribers that are not used to pass Distributions on to other Subscribers do not need to be in this list.

Subscribers in a Distributor's routing hierarchy do not need to also receive Distributions from that Distributor. A Subscriber can merely act as a proxy for the Distributor to pass Distributions to other Subscribers.

The Distributor uses its routing hierarchy to determine the route a Distribution will take to get to any given Subscriber.

A Distributor determines the most efficient route to any given Subscriber as follows:

The Distributor identifies the Subscriber that is to receive the Distribution.
The Distributor determines whether that Subscriber has a parent Subscriber.
If the Subscriber has a parent Subscriber, the Distributor checks its routing hierarchy for that parent Subscriber:
1. If the parent Subscriber is in the routing hierarchy, the Distributor uses that route to send the Distribution to the Subscriber.
2. If the parent Subscriber is not in the routing hierarchy, the Distributor sends the Distribution directly to the parent Subscriber of the end-node target Subscriber.
If the Subscriber does not have a parent Subscriber, the Distributor checks its routing hierarchy for the Subscriber:
1. If the Subscriber is in the routing hierarchy, the Distributor uses that route to send the Distribution to the Subscriber.
2. If the Subscriber is not in the routing hierarchy, the Distributor sends the Distribution directly to the Subscriber.

In other words, if the Distributor can find a way to send the Distribution using its routing hierarchy, it will use the path in that hierarchy to get the Distribution to the Subscriber. Otherwise, it will send the Distribution directly to the Subscriber (or its parent Subscriber). For that reason, you should make sure every Subscriber that regularly receives Distributions from a Distributor have some connection to the Distributor's routing hierarchy. This connection can be made by being listed in the hierarchy or by having one of the Subscribers in the hierarchy be its parent Subscriber.

You should generally not allow the Distributor to send Distributions over WAN links, except to Subscribers in the first tier of its routing hierarchy.

Selecting Subscribers for the Distribution Routes

The purpose of the Distributor's routing hierarchy is to create the most efficient method for distributing to Subscribers. You need to determine which servers are best suited to be Subscribers in a routing hierarchy, and how many servers to include in the hierarchy.

Select a server that is robust in its physical configuration. For example, a fast CPU, plenty of RAM, and plenty of free hard disk space (especially on volumes other than SYS: on NetWare servers).

Use the following criteria to determine which Subscribers to include in a Distributor's routing hierarchy:

Is the Subscriber needed to minimize the Distributor's workload?
Do you need other Subscribers to share the workload of a parent Subscriber on a given LAN?
Is the Subscriber needed to minimize network traffic (such as through WANs or firewalls)?

To identify the Subscriber servers that will be used in a Distributor's routing hierarchy, create a list of the servers in your network that you want to use as parent Subscribers in a Distributor's routing hierarchy.

To help minimize network traffic, select at least one server on each LAN.

Identify the server objects that can be parent Subscribers in the Distributors' routing hierarchies:

CONFIGURATION PLANNING WORKSHEET
Under item 16. enter the names (including full context) for your parent Subscriber servers.

Configuring the Distribution Routes

Enter the following information on your network diagram:

CONFIGURATION PLANNING DIAGRAM
Write "parent=1" next to every location on the diagram that is separated from the Distributor's location by a WAN link or firewall (unless there is only one Subscriber at that location).

Enter the following information on your network diagram:

CONFIGURATION PLANNING DIAGRAM
For every location on the diagram that requires additional parent Subscribers because of the high number of Subscribers, change "parent=1" to "parent=#" where # is the number of parent Subscribers the site will need for load-balancing. Also note whether you want to use one parent Subscriber in a given location as the primary parent Subscriber (the only one at that location in the Distributor's routing hierarchy) for receiving Distributions and passing them on to other parent Subscribers in that location. Be sure to include parent Subscribers at the Distributor's location, if needed.

CONFIGURATION PLANNING DIAGRAM

For every location on the diagram that requires additional parent Subscribers because of the high number of Subscribers, change "parent=1" to "parent=#" where # is the number of parent Subscribers the site will need for load-balancing.

Also note whether you want to use one parent Subscriber in a given location as the primary parent Subscriber (the only one at that location in the Distributor's routing hierarchy) for receiving Distributions and passing them on to other parent Subscribers in that location.

Be sure to include parent Subscribers at the Distributor's location, if needed.

Using the information from your network diagram, design your Distributors' routing hierarchies using the Subscribers you have selected:

CONFIGURATION PLANNING WORKSHEET
Under item 15, create a hierarchy for each Distributor's routing hierarchy. You can reuse Subscriber servers in different Distributor's hierarchies.

Understanding Distribution Security

ZfS provides adequate security for Distributions that are sent within a secured network, such as certificates. However, Distributions could require additional security measures that are available in ZfS.

For more information about security, see Security in Policy and Distribution Services .

Review the following to determine whether you need any additional security for your Distributions:

Determining Whether You Need Inter-Server Communications Security

Policy and Distribution Services uses XMLRPC (Extensible Markup Language Remote Procedure Call) for its normal inter-server communications. XMLRPC optionally provides security for inter-server communication that can be used for communicating securely across non-secured connections.

Policy and Distribution Services can use this security for inter-server communications between servers across non-secured connections, or between a management workstation and servers across non-secured connections. For example, firewalls, intranets, NAT configurations, and so on.

This inter-server communications security ensures that data received across a non-secured connection is from a trusted source, that it has not been tampered with en route, and that the data received can be trusted by other machines. This is accomplished through the use of signed security certificates and digital signatures.

This security requires modifications to certain text files, and is installed using a ZfS wizard.

The following are instances when you would want inter-server communication security:

ConsoleOne Administration: When you use a workstation to manage a Distributor server across a non-secured connection.
SET Parameters: When you create a SET Parameter policy or a software package for SET parameters, inter-server communication takes place to provide the target server's SET parameter information. This communication could cross a non-secured connection.
Server Down Policy: When you use this policy to down a server, the communication between the downed server and another server watching for it to come back up could cross a non-secured connection.

For more information, see Security for Inter-Server Communication Across Non -Secured Connections .

CONFIGURATION PLANNING WORKSHEET
Under item 13, enter the NetWare and Windows servers where you need to install the inter-server communications security software.

Determining Whether You Need Encryption Security for Windows Servers

You normally do not need to encrypt Distributions that are sent within your secured network. However, you can use encryption to provide security for when you send Distributions outside your network. The NICI software is used for encrypting Distributions.

For NetWare servers, NICI is automatically installed. Therefore, you do not need to do any setup to use Distribution encryption for NetWare servers.

For Windows, Linux, and Solaris servers, you must install NICI on the Distributor and Subscriber servers where you expect encrypted Distributions to be built and extracted.

If you need to install the NICI software on a Windows, Linux, and Solaris server, you must also install that same version on all Distributor and Subscriber servers in your network. Encryption will not work correctly if there are two different versions of NICI installed in your network.

For more information on Distribution encryption, see Distribution Security Using Encryption .

CONFIGURATION PLANNING WORKSHEET
Under item 14, enter the Windows, Linux, and Solaris servers where you need to install the NICI software.

Determining the Channels for the Distributions

Channels are used to group Distributions, to establish a schedule for passing a Distributor's Distributions on to Subscribers, and to list the Subscriber that are subscribed to the Channel so that the Distributor will know where to physically send the Distribution files.

A Channel can be created for a specific type of Distribution (such as virus pattern files, operating system support packs, or policy packages), or for a specific Distribution time (such as off peak Distributions).

A Channel can be associated with Distributions from many Distributors. A Channel can be subscribed to by many Subscribers.

Subscribers subscribe to Channels in order to receive certain Distributions. Distributors associate their Distributions with the Channels so that the subscribed Subscribers can receive those Distributions.

If you are installing multiple Distributors, they can share Channels for their Distributions. For example, if Distributor A and Distributor B both want to send some of their Distributions to the same set of Subscribers, one Channel can be used by both Distributors.

Channels are used in providing Distributions to Subscribers. Consider the following:

A Channel is not owned by any particular Distributor
Distributors associate their Distributions with the Channels
A Channel can have Distributions from multiple Distributors
A Channel can be used to group related Distributions
A Channel's schedule determines when the listed Distributions will be sent
A Subscriber subscribes to one or more Channels to receive all of the Distributions listed in those Channels
A Subscriber cannot select an individual Distribution from the several that could be listed in a Channel (it must receive all of the Channel's Distributions)

In naming Channels, use a descriptive method. For example:

VirusProtect VProtectPatterns VirusProtection NW51patch4 NW6patch1 AUTOEXECNCF000326

You will be able to manage your Channels more easily by:

Using names that are purpose oriented
Using a similar name for the Channel and its Distributions

CONFIGURATION PLANNING WORKSHEET
Under item 21, enter your Channel names. Make the names unique to help identify which Distributions they will send.

You would generally create a Channel for one or more related Distributions. However, for distribution flexibility, you could create one Channel for each application to be distributed.

CONFIGURATION PLANNING WORKSHEET
For each Channel, under item 22 enter the Distributions that belong to the Channel.

For ease of management, plan to create the Channel objects in the same context as your other TED objects, especially the Distribution objects.

CONFIGURATION PLANNING WORKSHEET
Under item 20, enter the eDirectory context where the Channel object should be created.

Determining Subscribers' Subscriptions

You need to subscribe your Subscribers to Channels before they can receive their Distributions. This is done by subscribing a Subscriber or Subscriber Group to the Channel that is associated with the Distribution it needs:

Subscribers

Because Subscribers do not access eDirectory, all configuration information in the Subscriber object's properties is pushed down to it from the configuring Distributor, if it is needed. This includes such information as working directory, log file level and location, console messaging level, variables, and so on.

Changes to a Subscriber object's properties are not in effect until the Distributor re-reads eDirectory and sends a new Distribution with the configuration information down to the Subscriber.

For each Distribution, determine which Subscriber servers will need a particular Distribution.

CONFIGURATION PLANNING WORKSHEET
Under item 24, enter the Channel name for a Distribution (see item 22) and list the Subscribers that need that Distribution. Repeat for each Channel you entered in item 21.

Subscriber Groups

You can create Subscriber Groups for grouping Subscribers that have the same Distribution needs. There is no need to create a Subscriber Group if it will only be associated with one Channel.

Subscriber Groups are useful when you will be sending several different Distributions to the same set of Subscribers. For example, Distribution A will be in Channel A, Distribution B will be in Channel B, and so on. Then, without using a Subscriber Group, you would need to subscribe each of your Subscribers to Channel A, then each to Channel B, and so on, which could be a very long process. However, by using a Subscriber Group, you will only need to create the group, add the Subscribers to it, then subscribe that one group to each Channel.

Another value of a Subscriber Group is when the group is associated with two or more Channels, because you can edit the group's membership more easily than making the same changes in multiple Channels. For example, to remove a Subscriber from one Subscriber Group, you just edit that one group's properties. To remove a Subscriber from several Channels, you would need to edit each Channel's properties.

CONFIGURATION PLANNING WORKSHEET
Under item 17, enter a unique name for the Subscriber Group. Under item 18, enter a list of Subscribers that need the same Distributions from the Channel (see item 21 and item 22) where the group will be subscribed. Under item 24, enter the Channel names for the Distributions that you want all of the Subscribers in the group to receive.

CONFIGURATION PLANNING WORKSHEET

Under item 17, enter a unique name for the Subscriber Group.

Under item 18, enter a list of Subscribers that need the same Distributions from the Channel (see item 21 and item 22) where the group will be subscribed.

Under item 24, enter the Channel names for the Distributions that you want all of the Subscribers in the group to receive.

Determining the Distribution Schedules

TED has different schedules so that you can coordinate the various distribution processes. Review the following to plan your TED schedules:

Understanding Scheduling in TED

Both TED objects and individual Server Policies can be scheduled.

TED uses schedules to control when Distributors are refreshed and Distributions are built, sent, and extracted. Schedules do not affect the total resources used by a Distribution, but rather when the resources will be used.

Some policies must be scheduled before they can be enforced. If you enable a policy, but do not schedule it, it will be activated according to the schedule currently specified in the Default Package Schedule, which provides a default for scheduled policies. The default schedule is Run At System Startup.

If you configure several policies with the same schedule, the order they are run depends on the time stamps created when you created the policies. Therefore, when you view a list of policies, the order they are listed is the order that they will be run.

If you want to control the order that certain policies are run, you should stagger their schedules, rather than rely on the time stamps to determine when they will run. Therefore, consider the TED schedules you select when scheduling your policies, so that you do not have undesirable overlap, or out-of-sequence events that could cause some scheduled items to fail.

Other issues you may need to understand:

How time zones can affect scheduling
How policy schedules are affected by distribution schedules
How distribution schedules can be affected by Distributor and Subscriber servers' non-ZfS software usage
How the Randomly Dispatch option can affect scheduling
How the Active and Inactive object options for the TED objects can affect scheduling and distribution flow

For more information, see Scheduling .

Determining the Distributors' Refresh Schedule

The Refresh schedule determines when the Distributor will re-read eDirectory for configuration changes.

This enables the Distributor to respond to a request to build a Distribution. The Distributor rebuilds a Distribution when it discovers that there are configuration changes within eDirectory.

You will also be instructed to manually refresh your Distributors to start the distribution process, because that schedule is set to Never by default. You can change this schedule later after you have reviewed and understood Scheduling .

Determining the Distribution's Build Schedule

The Build schedule determines when a Distributor will be requested to build the individual pieces that comprise the Distribution.

During configuration, you will be instructed to set each Distribution's Build schedule to allow the Distribution to be sent immediately after building it.

Determining the Channels' Send Schedules

The Send schedule provides a window of time for when a Distributor can send its Distributions to the Subscribers.

During configuration, you will set each Channel's Send schedule to an interval of every 5 minutes, meaning that the Distributor can send its Distributions at any of the 5-minute intervals when the Channel's schedule fires.

Determining the Subscribers' Extract Schedules

The Extract schedule determines when a Subscriber can start to extract a Distribution that has been received.

Before a Subscriber can use a Distribution that is sent to it, it must first extract the Distribution. Therefore, the Subscriber's Extract schedule should be set before you send the Distributions.

Determine when you want the various Subscriber servers to be active extracting Distributions. Depending on a Distribution's size, it could be best to have Distributions extracted during off-peak hours. For more information on scheduling issues involving time zones, see Scheduling Issues , especially Calculating Time Differences .

CONFIGURATION PLANNING WORKSHEET
Under item 23, enter the Subscribers' extract schedules.