Use these sections in the following order:
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.
Tiered Electronic Distribution is usually involved when you use any of these components, because most policies and all Server Software Packages are distributed. Therefore, in this section we will concentrate on understanding and configuring Tiered Electronic Distribution. See the following sections for more information on the other two components of Policy and Distribution Services:
The following sections provide basic information that will help you to understand Tiered Electronic Distribution and what you will need to know to configure it:
The types of electronic data you can distribute using Tiered Electronic Distribution include:
Table 1-1 Distribution Types
From this list, you can see that there is a variety of electronic data types that you can distribute to your servers.
Tiered Electronic Distribution 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 Tiered Electronic Distribution that will need to be created and configured. For more information, see Section 3.2.2, The Basic Distribution Process and Section 3.10.1, Understanding the Distribution Processes.
The Distributions that you want, including:
Whether you want to distribute server files, HTTP content, FTP content, or RPM packages
If there are any desktop applications to be distributed (affects how you set up Subscriber objects when you have multiple trees)
Which policies you needed for managing your servers
What server software should have automated installation
Whether you’ll need additional Distributors
Whether you have both Novell eDirectory™ 8.7.3 and NDS® 6.x or 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 need which Distributions
Your network’s topology (server platforms, slow WANs, firewalls, Network Address Translation [NAT], multiple trees, and so on)
The system resource and server behavior issues that Tiered Electronic Distribution 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 during business hours
To determine the above information, continue with Section 1.1.2, Selecting Your Distributions.
This section provides you with basic information for each Distribution type.
You can build your distribution system incrementally by adding Distributions a few at a time, then adding Distributors when needed. You can revisit this process at any time to add new Distributions.
Print a copy of the Section H.0, Configuration Planning Worksheet. Worksheet fill-in instructions are given as you review the planning sections.
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.
This Distribution type allows you to distribute Application objects and associated files to specified locations on the eDirectory tree and target Subscriber servers.
For information on integration with Desktop Management, see Section 6.0, 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 |
|---|
|
If you want to maintain trustee rights in the Distribution, under item 3 and item 20, indicate that you have Desktop Application Distributions, and therefore each server that receives Desktop Application Distributions must have its Subscriber object and NCP™ server object in the same tree. Under item 19, enter Desktop Application as the type of Distribution to be created. Also indicate the following:
|
With this Distribution type you can select files and/or directories from the Distributor server’s file system to distribute to a selected location on the Subscriber server’s file system.
A Distribution Wizard is available for automating the process of creating the File and FTP types of Distributions. For more information, see Section 3.4.12, Using the Distribution Wizard.
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 File as the type of Distribution to be created. Also indicate the following:
|
With this Distribution 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 Section 3.4.12, Using the Distribution Wizard.
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 FTP as the type of Distribution to be created. Also indicate the following:
|
With this Distribution 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 HTTP as the type of Distribution to be created. Also indicate the following:
|
This is a Distribution of MSI packages that are installed by the MSI engine in a Windows environment.
For information on the MSI type of Distributions, see MSI.
Determine whether you want to create an MSI Distribution at this time:
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 19, enter MSI as the type of Distribution to be created. Also indicate the following:
|
This Distribution type provides the mechanism for applying any of the policies in Table 1-2 to Subscriber servers:
Table 1-2 Policies
For more information on each policy, see Section 4.1.6, Server Policy Descriptions.
For information on policies and policy packages, see Section 4.0, 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 Policy Package as the type of Distribution to be created. Also indicate the following:
|
This is a Linux or Solaris 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 RPM as the type of Distribution to be created. Also indicate the following:
|
This Distribution type allows you to distribute Server Software Packages that you create in ConsoleOne in the Server Software Package namespace. You first create a .spk file, then compile it into the .cpk file that is distributed.
For information on Server Software Packages, see Section 5.0, Server Software Packages.
For information on the Software Package Distribution type, see Software Package.
Determine the software packages you want to create at this time:
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 19, enter Software Package as the type of Distribution to be created. Also indicate the following:
|
In order for you to efficiently manage your distribution system, you 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 is used to help you configure the best distribution management solution for your network.
To obtain information concerning your network:
Note the trees where you extended the schema for Server Management.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 1, provide the names of the trees in your network where you extended the schema for Server Management. |
Draw a diagram of your network structure.
You will use this diagram later to determine distribution routes.
Indicate the following on your diagram:
Where slow links exist
The number of servers on each LAN
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 Distributors and Subscribers)
Indicate the following on your tree diagrams:
Where servers are located that could be Distributors (NetWare, Windows, Linux, or Solaris servers that exceed the minimum Server Management 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
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 your corporate structure or geographic locations.
Distributor server workload, including the ability to complete Distribution building tasks, should also determine how many Distributors you need. For example, if you have a very large Distribution that you want built during off-peak hours, which does not need to be sent immediately, and also have virus pattern Distributions that do need to be sent immediately, you might need two different Distributors, one with a daily refresh schedule (because you are only going to be building the Distribution once per day), and another with a frequent refresh schedule for discovering new virus pattern changes, so that their Distributions can be built and sent on time.
Use your diagrams to determine whether you need to install additional Distributors.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 2, provide the names of the servers where you want to install the Distributor software. |
You can always add Distributors later 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.
You also need to determine the following information for each Distributor:
You can change the following Distributor properties 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.
Container: Plan on using the container where you previously installed Distributor objects.
If eDirectory is not installed on the Windows 2000/2003 server that you want to be a Distributor, a default container object is not displayed for that server during installation. Therefore, determine the 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 Linux or Solaris servers the path is:
/var/opt/novell/zenworks/zfs/pds/ted/dist
The Distributor’s working directory is also used whenever a Distribution is created. A directory is created under the working directory using the DN of the Distribution object.
For more information on the working directory, see Section 3.12, Working Directories.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 7, provide the 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. |
Server Management uses the following default installation paths:
NetWare: sys:
You can select a different volume.
Windows: C:
You can select a different drive.
The Linux or Solaris path cannot be changed.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 5, provide 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, provide 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 Server Management 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 Tiered Electronic Distribution 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: Tiered Electronic Distribution 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 Tiered Electronic Distribution information, install only one database object and file and have all Tiered Electronic Distribution 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 Section 10.0, 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 Server Management 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 |
|---|
|
Provide the following information for each Database object to be created:
|
Server Management can run in a mixed eDirectory environment. For example, your network might have both eDirectory 8.x and NDS® 6.x or 7.x installed.
However, eDirectory 8.x (only 8.6.2, 8.7.1, or 8.7.3 or later) is required for Server Management so that its objects can be placed in the tree during installation of the product. eDirectory must be installed with the master replica somewhere in your network, but not necessarily on a server where you are installing the Server Management software.
Also, ZENworks 7 Distributor servers must be running eDirectory 8.x.
The only requirement for any Server Management server is that it can communicate with the server where the eDirectory master replica (of the partition where its NCP Server object resides) is installed. Therefore, you do not need to install eDirectory on each server where you will install Server Management.
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, provide 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.
You can change the following Subscriber properties 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.
Container: Plan on using the container where you previously installed Subscriber objects.
You should place Subscriber server objects in containers matching their operating systems. For example, a NetWare container for NetWare servers, and a Windows container for Windows servers.
If eDirectory is not installed on the Windows 2000/2003 server that you want to be a Subscriber, a default container object is not displayed for that server during installation. Therefore, determine the 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. You can use variables for path data, such as the volume/drive designation. For more information, see Section 9.0, Variables.
The default working directory path for NetWare and Windows servers is:
\zenworks\pds\ted\sub
For Linux and Solaris servers, the path is:
/var/opt/novell/zenworks/zfs/pds/ted/sub
For more information on working directories, see Section 3.12, Working Directories.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 3, provide 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, provide 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 Section 3.3.2, 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 the ones 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:
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:
If the parent Subscriber is in the routing hierarchy, the Distributor uses that route to send the Distribution to the Subscriber.
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:
If the Subscriber is in the routing hierarchy, the Distributor uses that route to send the Distribution to the Subscriber.
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 uses the path in that hierarchy to get the Distribution to the Subscriber. Otherwise, it sends 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 has some connection to the Distributor’s routing hierarchy. You can make this connection by listing a Subscriber 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 might 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 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, select only 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:
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 to use 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 you want to be parent Subscribers in the Distributors’ routing hierarchies:
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 16. provide the names (including full context) for your parent Subscriber servers. |
Specify 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. |
Server Management 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 Server Management.
For more information about security, see Section 7.0, 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 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 Server Management wizard.
The following are instances when you could 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 Section 7.3, Security for Inter-Server Communication Across Non‑Secured Connections.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 13, provide the NetWare and Windows server names 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 some NetWare servers, NICI 2.6 is automatically installed with the operating system. However, version 2.6.4 is supported in ZENworks 7 Server Management. You may need to upgrade your NetWare version of NICI. Version 2.6.4 is shipped with ZENworks 7, and is also shipped with ZENworks for Servers 3.0.2 (including version 3 SP2).
For Windows, Linux, and Solaris servers, you must install NICI 2.6.4 on the Distributor and Subscriber servers where you expect encrypted Distributions to be built and extracted.
IMPORTANT:If you have NICI 2.4.6 running on your network, it is optional whether you upgrade to NICI 2.6.4, because these versions are compatible with each other.
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 does not work correctly if there are two different versions of NICI installed in your network.
For information on Distribution encryption, see Section 7.2, Distribution Security Using Encryption.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 14, provide the Windows, Linux, and Solaris server names 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 Subscribers that are subscribed to the Channel so that the Distributor knows where to physically send the Distribution files.
You can create a Channel for a specific Distribution usage (such as virus pattern files, operating system support packs, or policy packages), or for a specific Distribution time (such as off-peak Distributions).
You can associate a Channel 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 are 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 can 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, provide your Channel names. Make the names unique to help identify which Distributions they will hold. |
You generally create a Channel for one or more related Distributions. However, for distribution flexibility, you can create one Channel for each application to be distributed.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 22, provide the Distributions that belong to each Channel. |
For ease of management, plan to create the Channel objects in the same context as your other Tiered Electronic Distribution objects, especially the Distribution objects.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 20, provide 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 reads eDirectory again and sends a new Distribution with the configuration information down to the Subscriber.
For each Distribution, determine which Subscriber servers need a particular Distribution.
A Subscriber Group is used for grouping Subscribers that have the same Distribution needs.
Subscriber Groups are useful when you are sending several different Distributions to the same set of Subscribers. There is no need to create a Subscriber Group if it is only associated with one Channel.
For example, Distribution A is in Channel A, Distribution B is in Channel B, and so on. Then, if you are not using a Subscriber Group, you 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 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 need to edit each Channel’s properties.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 17, provide a unique name for the Subscriber Group. Under item 18, provide a list of Subscribers that need the same Distributions from the Channel (see item 21 and item 22) where the group is subscribed. Under item 24, provide the Channel names for the Distributions that you want all of the Subscribers in the group to receive. |
Tiered Electronic Distribution has different schedules so that you can coordinate the various distribution processes. For more detailed information, see Section 8.0, Scheduling.
Review the following to plan your Tiered Electronic Distribution schedules:
Both Tiered Electronic Distribution objects and individual Server Policies can be scheduled.
Tiered Electronic Distribution 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 are used.
Some policies must be scheduled before they can be enforced. If you enable a policy, but do not schedule it, it is 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 are 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 run. Therefore, consider the Tiered Electronic Distribution 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 might 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-Server Management software usage
How the Randomly Dispatch option can affect scheduling
How the Active and Inactive object options for the Tiered Electronic Distribution objects can affect scheduling and distribution flow
The Distributor’s Refresh schedule determines when the Distributor should read eDirectory for new Distribution and Channel objects, or for configuration changes to existing Distribution and Channel objects. Upon a Distributor refresh, when the Build schedule starts the Distributor rebuilds the Distributions that it discovers to be new or changed, then sends them when the Send schedule starts.
The Refresh schedule is set to Never by default, which is recommended because an infinite loop could be encountered if the Refresh frequency is shorter than the time it takes to complete the building or sending of a Distribuiton. Therefore, you should normally refresh a Distributor manually.
If you want to use a different schedule than Never for Refresh, be certain that when the Distributor is refreshed it is not going to be in the middle of building or sending a Distribution.
As an example of when you might want to change the Refresh schedule from Never, if you create or change your Distributions daily and do not need to build and send them immediately, you can set the Refresh schedule to 1:00 AM daily to have your new Distribution objects or changes found by the Distributor so that it can build and send them during off-peak hours according to the Build and Send schedules.
The Build schedule determines when a Distributor is requested to build the individual pieces that comprise the Distribution.
During configuration, you are 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 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 extract its received Distribution.
Before a Subscriber can use a Distribution that is sent to it, it must first extract the Distribution. Therefore, you should set the Subscriber’s Extract schedule 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 Section 8.2.5, Scheduling Issues, especially Calculating Time Differences.
|
CONFIGURATION PLANNING WORKSHEET |
|---|
|
Under item 23, provide the Subscribers’ extract schedules. |