Use these sections in the following order:
Policy and Distribution Services contains three components:
Tiered Electronic Distribution is a distribution system for your network.
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:
The types of electronic data you can distribute using TED include:
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.
TED sends Distribution files from Distributor servers to Subscriber servers. The basic distribution process is as follows:
From this process, you can see that there are several components of TED that will need to be created and configured. For more information, see Understanding the Distribution Processes and The Basic Distribution Process.
You will need to know the following in order to fully configure Policy and Distribution Services:
To determine the above information, plan your configuration, and configure TED, continue with 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 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.
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.
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.
For information on the File type of Distribution, see File.
Determine whether you want to create a File Distribution at this time:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 19, enter the File type as a Distribution to be created. Also indicate the following:
|
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.
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.
For information on the FTP type of Distribution, see FTP.
Determine whether you want to create an FTP Distribution at this time:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 19, enter the FTP type as a Distribution to be created. Also indicate the following:
|
With this type you can create a Distribution consisting of one or more HTTP sources. Each source can contain one or more target entries.
For information on the HTTP type of Distribution, see HTTP.
Determine whether you want to create an HTTP Distribution at this time:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 19, enter the HTTP type as a Distribution to be created. Also indicate the following:
|
This is a UNIX platform Distribution. You can distribute Red Hat Package Manager (RPM) packages using the RPM Distribution.
For information on the RPM type of Distribution, see RPM.
Determine whether you want to create an RPM Distribution at this time:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 19, enter the RPM type as a Distribution to be created. Also indicate the following:
|
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.
For information on Server Software Packages, see Server Software Packages.
For information on the Software Package type of Distribution, see Software Package.
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:
|
Distributes ZENworks for Desktops (ZfD) Application objects and associated files to specified locations on the eDirectory tree and target Subscriber servers.
This Distribution type is not supported for Linux and Solaris servers.
For information on integration with ZfD, see Desktop Application Distribution.
For information on the Desktop Application type of Distribution, see Desktop Application.
Determine whether you want to create a Desktop Application Distribution at this time:
| 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:
|
Provides the mechanism for applying policies to servers. In previous versions of Policy and Distribution Services, policies were enforced through eDirectory object and container associations. With ZfS 3.0.2, policies are now distributed for enforcement on the receiving Subscriber servers.
Select from the following policies:
For more information on each policy, see Server Policy Descriptions.
For information on policies and policy packages, see Server Policies.
For more information on the Policy Package type of Distribution, see Policy Package.
Determine whether you want to create a Policy Package Distribution at this time:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 19, enter the Policy Package type as a Distribution to be created. Also indicate the following:
|
In order for you to efficiently manage Policy and Distribution Services, you will need to know your network's topology. For example:
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:
| CONFIGURATION PLANNING WORKSHEET |
|---|
Under item 1, enter the names of the trees in your network where you extended the schema for ZfS. |
You will use this diagram to determine distribution routes.
Indicate the following on your diagram:
This should match where you indicated slow connections on your network diagram.
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:
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. |
ZfS uses the following default installation paths:
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. |
You can have multiple ZENworks databases in the tree, and you can install the database to both NetWare and Windows servers.
The 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 a 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 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:
|
In ZfS 3.0.2, 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. |
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. |
The following sections provide information for determining distribution routes:
For more detailed information, see Understanding Distribution Routing.
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. The hierarchy of Subscribers can be many levels deep.
Subscribers in a Distributor's routing hierarchy do not need to also be recipients of the Distributions from that Distributor. A Subscriber can merely act as a proxy for the Distributor to pass Distributions to other Subscribers.
Not all Subscribers are needed in a routing hierarchy; only those that will be used to pass Distributions on to other Subscriber servers. Most of your network's Subscriber servers will likely be end-node Subscribers; meaning, Subscribers that only receive and extract the Distributions.
The Distributor determines the most efficient route to any given Subscriber as follows:
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 such Subscribers that may be in the first tier of its routing hierarchy.
Consider the following in designing your Distributor's routing hierarchy:
End-Node Subscribers: The only Subscribers that you need to add to the routing hierarchy are those you want to be used to pass on Distributions. End-node Subscribers that will only receive Distributions and not pass them on do not need to be added to the routing hierarchy.
Configuring Distribution Routes: To create the distribution routes, consider your network design and the number of Subscribers on each LAN. Then design the routing hierarchy to mimic your network topology.
Selecting Multiple Subscribers: During hierarchy creation, you can place multiple Subscribers at the same tier under a single Distributor or Subscriber.
IMPORTANT: The most efficient routing hierarchy is to have more tiers and fewer Subscribers per tier, than just a few tiers with many Subscribers per tier. Therefore, only select a few Subscriber servers per tier. This minimizes the workload for the Distributor or Subscriber server that is sending Distributions to other Subscriber servers. Tiering helps to share the workload of sending Distributions throughout the network.
Using Multiple Distributors: Multiple Distributors can use the same routing hierarchy of Subscribers, so that the same distribution route can be used by each Distributor.
Reusing Subscribers: You should consider whether you might overload a Subscriber server if it should be a parent Subscriber in a routing hierarchy that services multiple Distributors.
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:
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. |
Enter the following information on your network diagram:
Enter the following information on your network diagram:
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. |
ZfS provides adequate security for Distributions that are sent within a secured network using 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:
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. |
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 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. |
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:
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:
| 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. |
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:
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. |
A Subscriber Group is used for grouping Subscribers that have the same Distribution needs.
Subscriber Groups are useful when you will be sending several different Distributions to the same set of Subscribers. There is no need to create a Subscriber Group if it will only be associated with one Channel.
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 use of a Subscriber Group is that when the group is associated with two or more Channels, 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 that same 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. |
TED has different schedules so that you can coordinate the various distribution processes. Review the following to plan your TED schedules:
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:
For more information, see Scheduling.
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.
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.
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.
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 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. |