Subscribers

The following sections provide concepts and instructions for the Subscriber object:


Understanding Subscribers

The Subscriber object (TED Subscriber) is an eDirectory object that defines the properties for the Subscriber.


Functional Relationship with Other TED Objects

The following illustrates a Subscriber's relationship with the Channels:


A Subscriber that subscribes to multiple Channels

The Subscriber subscribes to the Channels.

The following illustrates the Subscriber's relationship with Distributors and Distributions:


Multiple Subscribers can receive the same Distribution from a Distributor.


Subscriber Description

The Subscriber is a service that receives and extracts Distributions to obtain the software, files, or policies it needs.

Any server where you want to distribute applications, files, or policy packages must have the Subscriber software installed and a Subscriber object in the eDirectory tree. The Subscriber object can be in a different tree than the server's NCP server object, because IP addresses or DNS names are used for moving Distribution files to the Subscriber servers.

Distributions are copied to the Subscriber server's hard drive. The Subscriber Agent receives the Distributions and extracts them to install the software, files, or policies.


Scheduling

A Subscriber's Extract schedule determines when it can extract its Distributions.

For information on scheduling, see Scheduling.


Subscribing to Channels

Subscribers can subscribe to a Channel to receive all of the Distributions listed in that Channel. A Subscriber object's properties lists the Channels it is subscribed to.

Subscribers can receive Distributions from multiple Distributors because:

  • Multiple Distributors can list their Distributions in the same Channel
  • Subscribers can subscribe to multiple Channels


Parent Subscribers

Subscribers can be parent Subscribers, which are proxies for the Distributor to pass Distributions on to other Subscribers. This helps the Distributor by providing load-balancing for sending Distributions to many Subscribers.

The Subscriber object's properties lists the parent Subscriber through which it receives all of its Distributions. A Subscriber can receive its Distributions directly from the Distributor if it does not have a parent Subscriber and is not listed in the Distributor's routing hierarchy.

Parent Subscribers can also be used to bridge WAN links to ensure that Distribution packages are sent across WAN links a minimum number of times.


Creating Subscribers

Subscribers must be created by installing their software and eDirectory objects using the ZENworks for Servers Program CD. For more information, see "Reinstalling ZENworks for Servers" under "Installing ZENworks for Servers" in the ZfS Installation guide.

If a Subscriber object is inadvertently deleted, you can re-create it in ConsoleOne. However, the revision number of the new Subscriber object will be less than its revision number in the ted.cfg file. Therefore, the Subscriber cannot accept any updates to its configuration, because the lower revision number causes it to assume that the configuration data is older than what it has. To resolve this problem, delete the ted.cfg file on the Subscriber server, and the next time a Distribution is sent to the Subscriber, a new configuration is accepted, and a new ted.cfg file created.


Configuring Subscribers

Subscriber objects are automatically created when you install the Subscriber software to a server.

Not all properties associated with the Subscriber object are required. Required objects are noted; all others are optional.

To configure the Subscriber object's properties:

  1. In ConsoleOne, right-click the Subscriber object > click Properties.

  2. Click the General tab > click Settings > fill in the following fields:

    Use Policy: Click to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field will display if a Tiered Electronic Distribution policy has been created, distributed to the Subscriber server, extracted by the Policy/Package Agent, and enforced on the server.

    If you enable this option, the rest of the fields are dimmed and the policy settings are used instead. The current policy is displayed in parentheses.

    Input Rate: The rate Distributions are received or sent. The default is the maximum that the connection can handle. This rate is used to control a Subscriber's use of narrow bandwidth links. This also defines the rate between a parent Subscriber and its subordinate Subscribers.

    Output Rates Based Upon Distribution's Priority: Sets the default output rate to minimize network traffic for TED objects. This determines the send rate for Subscribers. The default value is the maximum that the connection can handle. There are three output priorities where you can specify a rate:

    • High Priority: These Distributions will be sent before any Medium or Low priority Distributions.

    • Medium Priority: These Distributions will be sent after all High priority and before any Low priority Distributions.

    • Low Priority: These Distributions will be sent after all High and Medium priority Distributions.

    For more information, see Prioritizing Distributions.

    Maximum Concurrent Distributions: Specifies the maximum number of distribution threads that can be running concurrently. The default value is unlimited (blank field). This applies to parent Subscribers that will pass on Distributions to subordinate Subscribers.

    Connection Time-out: Specifies the number of seconds a Subscriber will wait for a response from a Distributor (receiving) or a Subscriber (sending) before ending the connection. If a connection is ended during sending or receiving, the send will not start again until the next time the Channel schedule starts. It will then pick up where it left off. The default value is 300 seconds (five minutes). The available range in seconds is 1 to 60,000. This setting should be a reasonable time to wait for a response from one node to another.

    IMPORTANT:  This interval must be increased on slow or busy links where longer delays are frequent.

    Working Directory: Specifies the directory to be used by the Distribution. It contains Distributions, persistent status, and temporary working files. The default path for NetWare and Windows servers is:

    ZENWORKS\PDS\TED\SUB

    For UNIX servers the path is:

    usr/ZENworks/PDS/TED/Sub

    The working directory defaults to SYS: on NetWare servers. The contents of the directory can become very large. Therefore, we recommend that you change the default from SYS: to a volume with adequate free space.

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

    Parent Subscriber (optional): Specifies a parent Subscriber from which Distributions can be received.

    This field is where you can specify a parent Subscriber in the routing hierarchy for passing on the Distribution if you do not want the Distributor to send Distributions directly to the External Subscriber's server in the other tree.

    Disk Space Desired To Be Left Free: Use this value to ensure there will be enough free disk space for receiving Distributions. A Subscriber will not attempt to receive a Distribution if the disk space value set here is insufficient.

  3. Click the General tab > click Messaging > fill in the following fields:

    Use Policy: Click to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field will display if a Tiered Electronic Distribution policy has been created, distributed to the Subscriber server, extracted by the Policy/Package Agent, and enforced on the server.

    If you enable this option, the rest of the fields are dimmed and the policy settings for messaging are used instead. The current policy is displayed in parentheses.

    Server Console: Specifies the level of output messages to send to the Subscriber console on the server console.

    SNMP Trap: Specifies the level of messages to send via SNMP.

    Log File: Specifies the level of messages to send to the log file.

    Path and Filename: You can specify a custom log file's name and location for this Subscriber object. For example:

    ZENWORKS\PDS\TED\SUB\SUBSCRIBER.LOG

    The default volume is SYS: on NetWare servers. Because the log file can become quite large, we recommend that you do not use the SYS: volume.

    For information on creating a custom log file for all Subscriber objects, see Creating Custom Log Files Using Policies.

    Delete Log Entries Older Than __ Days: Log file entries for a Subscriber will be deleted after they are older than the number of days specified.The default is six days.

    E-Mail: Specifies which level of messages to send via e-mail.

    Users: Specifies e-mail users for notification.

    Address Attribute: Specifies e-mail addresses for notification.

    You can add users or groups stored in eDirectory or enter the e-mail addresses for users who are not contained in eDirectory. The e-mail Address Attribute associated with an eDirectory user is the default attribute.

    IMPORTANT:  If you select e-mail as a method for receiving notification, be aware that additional network traffic can be created.

  4. Click the General tab > click Working Context > browse for a working context.

    This is the eDirectory context where the Subscriber will create the objects related to the Desktop Application Distributions it receives.

  5. Click the Schedules tab > select a schedule > fill in the fields:

    Use Policy: Click to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field will display if a Tiered Electronic Distribution policy has been created, distributed to the Subscriber server, extracted by the Policy/Package Agent, and enforced on the server. If you enable this option, the rest of the fields are dimmed and the policy settings for scheduling are used instead.

    Schedule Type: This schedule determines when the Subscriber will extract the Distributions.

    For information on available schedules, see Scheduling.

  6. Click the Channels tab > fill in the fields:

    Active: To activate a Channel for this Subscriber server so it can receive the Channel's Distributions, click a Channel > check the box to enable it. To deactivate a Channel so that the Subscriber will not receive the Channel's Distributions, uncheck the box to disable it.

    Channel: Click Add to create a Channel. Click Details to edit a Channel.

  7. Click the Variables tab > fill in the fields:

    Include Policy: Click to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field will display if a Tiered Electronic Distribution policy has been created, distributed to the Subscriber server, extracted by the Policy/Package Agent, and enforced on the server.

    If you click this option, the variables specified in the Tiered Electronic Distribution policy will be added to the list of variables. However, if there are duplicate variables, the variables in the Subscriber will prevail.

    Variable: Name of the variable. It should indicate how the variable will be used. For example, WORKINGVOL.

    Value: The value that the Subscriber will use when this variable is specified. For example, DATA:.

    To ensure that extraction will take place, provide an absolute path to the Subscriber. For example, if the path is only the DATA volume, make sure the colon (:) is included, because it is a necessary part of the full path.

    Description: Describes how the variable will be used. For example:

    Volume for the working directory.

    For information on variables, see Using Variables to Control File Extraction.

  8. To include this Subscriber in a group, click Group Membership > click Add > browse for a Subscriber Group object > click Select > click OK.

  9. When you are finished configuring the Subscriber object, click OK to exit the Subscriber object's properties.


Updating Subscriber Configurations

The Subscriber software cannot run on a server if the Subscriber does not know its TED configuration, such as where it's working directory is. Therefore, during the installation process, you determine a basic TED configuration for each of the Subscribers that you are installing.

Using this input, the installation program creates a TEDNODE.PROPERTIES file on each Subscriber server that contains the Subscriber's initial TED configuration. Until a server receives its first Distribution, this TEDNODE.PROPERTIES file provides the server with its TED configuration information, so that it can function as a Subscriber.

A Subscriber server can only receive configuration information from a Distributor server whose Distributor object is in the same tree as the server's Subscriber object. This is known as the trusted tree, which is established during the installation process. For information on when knowing the trusted tree is necessary, see Subscriber Software Configuration and Trusted Trees.

When a Distributor server sends a Distribution to a Subscriber server, the Distributor first checks to see if that Subscriber server has a current TED configuration in the form of a TED.CONFIG file. If this is the first time the Subscriber has received a Distribution, it will not have that file. The Distributor then sends the TED.CONFIG file to the Subscriber, and the TEDNODE.PROPERTIES file is no longer used by the Subscriber. Then the Distributor checks again to see if the Subscriber server has a current TED.CONFIG file. Upon confirmation from the Subscriber, the Distribution is sent. In other words, the Distributor will never send a Distribution to a Subscriber server whose configuration information is not current.

The TED.CONFIG file can be updated any time you make configuration changes to the Subscriber object's properties. However, Subscribers do not read eDirectory, so when a change is made to the Subscriber, it must rely on the Distributor server to discover those changes and send the new configuration information to the Subscriber server, updating its TED.CONFIG file.

If you should install the Subscriber software to a server that will not have a Subscriber object in any eDirectory tree, such as a Microsoft domain server, the TEDNODE.PROPERTIES file will be used by such servers, in lieu of having its TED configuration updated by a Distributor server. In this case, for configuration changes, you would need to edit the server's TEDNODE.PROPERTIES file. For more information, see The TEDNODE.PROPERTIES File Requirement and Editing the TEDNODE.PROPERTIES File.


Associating Subscribers with Channels

Before a Subscriber can receive a Distribution, you need to associate the Subscriber to a Channel. This can be done either from the Subscriber or Channel object's properties.

To associate a Channel with a Subscriber:

  1. In ConsoleOne, right-click the Subscriber object > click Properties.

  2. Click the Channel tab > click Add > add the needed Channels.

  3. Click OK to save the changes.

  4. Click the Schedule tab > select a schedule.

    The schedule determines when Distributions that have been received are extracted or installed.

    For information on the available schedules, see Scheduling.

  5. Click the Variables tab > fill in the following fields > click OK:

    Variable Name: Can be used to determine the location of the destination directory where files will be extracted. Enter the name of the variable exactly as you will be using it within the %...% symbols.

    Value: This is the value of the variable, which can be another variable's name.

    Description: Text field to enter details about the variable.

    For information on variables, see Using Variables to Control File Extraction.


Deleting Subscriber Objects That Are Part of a Distributor's Routing Hierarchy

If a Subscriber object is removed from eDirectory, or a Subscriber server is removed from the network (whether its Subscriber object is also removed or left in eDirectory), and that Subscriber was part of a Distributor's routing hierarchy, you will need to edit the Distributor object's properties to adjust the routing hierarchy accordingly. Otherwise, Distributions that were being sent through that parent Subscriber would not reach the designated Subscriber servers.