3.3 Distributors

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

3.3.1 Understanding Distributors

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

Functional Relationship with Other Tiered Electronic Distribution Objects

Figure 3-4 illustrates that a Distributor sends its Distributions to Subscriber servers:

Figure 3-4 Distributor Sending to Multiple Subscribers

Figure 3-5 illustrates that a Distributor can list any one of its Distributions in several Channels, and several of its Distributions in one Channel:

Figure 3-5 Distributor Listing Distributions in Multiple Channels

Distributor Description

The Distributor server’s main Tiered Electronic Distribution function is to create and send Distributions. It also logs information to a database file, if you have one assigned for the Distributor.

The Distributor Agent builds a Distribution file on the Distributor server from the information you provide when you create and configure a Distribution object. A Distributor can own multiple Distributions.

When a Distributor builds a Distribution, it can optionally create a digest that provides an MD5 checksum for the Subscriber to compare against. Digests are used by Subscribers to verify that the Distributions have not been tampered with while in transit. Creating a digest is optional per Distributor, so the digests might not always be available for a checksum comparison by any Subscriber where this option is enabled.

Digests also detect corruption in a Distribution’s package. In the case of corruption, the Subscriber renames the distfile.ted Distribution file to distfile.corrupt and the Distribution is rebuilt and sent the next time the Channel’s schedule fires.

A Distributor lists its Distributions in Channels. Distributors do not own Channels. However, a Distributor is the sole owner of its Distributions.

The Distributor sends its Distributions to Subscribers (usually parent Subscribers for passing on the Distributions). If an end-node Subscriber does not respond to a Distributor (or a parent Subscriber) that is trying to send a Distribution to it, the Distributor retries sending a Distribution every two minutes for 30 minutes, then stops. It does not attempt to re‑send the Distribution until the Channel’s Send schedule starts again.

Scheduling

A Distributor’s Refresh schedule determines when it reads eDirectory for changes to its Distributions and other Tiered Electronic Distribution objects. A Distributor builds all new Distributions it finds and rebuilds any of its Distributions that have changed. The new or rebuilt Distributions are then available to be sent when a Channel’s Send schedule starts.

IMPORTANT:We recommend that the Distributor’s Refresh schedule be left at the default of Never, unless you have a reason to schedule the refresh. If you set the Refresh schedule, it is possilbe that the Distribution building and sending processes can be interrupted and restarted. This could possibly cause an infinite loop situation where the Distributions never get built or sent.

A Distributor can build its Distributions any time its Refresh schedule starts.

If you delete a Distribution, you should also refresh the Distributor immediately so that it recognizes the deletion and not try to build a Distribution that no longer exists. For information on deleting Distributions, see Section 3.4.8, Deleting a Distribution.

For information on scheduling, see Section 8.0, Scheduling.

Routing Distributions

The Distributor contains a distribution route, which is a hierarchical list of Subscribers that indicate the routes the Distributor can take to send its Distributions to its Subscriber servers. For information on routing hierarchies, see Understanding Distribution Routes.

Multiple Distributors in the Tree

You can have multiple Distributor objects in the tree; however, you can only have one Distributor installed per server. The need for multiple Distributors is dependent on several factors. For more information, see Section 1.1.4, Are Additional Distributors Needed?.

Database Logging

Individual Distributors can log information to their own database files, or all Distributors can log information to one common database file. For information on databases, see Section 10.0, ZENworks Database.

3.3.2 Understanding Distribution Routing

A distribution route represents the most efficient path to any given segment of your WAN. A distribution route is a list of parent Subscribers that relay Distributions on to other parent or end-node Subscribers. You can use Parent Subscribers to minimize the workload for a Distributor because they can pass on Distributions to other Subscribers.

The following sections explain how a Distributor moves its Distributions to your network’s servers:

Understanding Parent Subscribers

A parent Subscriber is a Subscriber that acts as a proxy for the Distributor to store and pass Distributions so that the Distributor does not need to send its Distributions directly to every Subscriber. Parent Subscriber servers do not need to be recipients themselves of a Distribution to temporarily store it for passing on to other Subscriber servers.

Distributors Send Distributions Using Parent Subscribers

A Distributor server must actually send each of its Distributions, because the Distribution files reside in its own file system.

Sending Distributions can create an enormous workload for a Distributor if it must individually send each of its Distributions to every Subscriber server on the network. Therefore, parent Subscribers are used to help send Distributions.

A detailed understanding of your network’s topology is important for properly configuring distribution routes and selecting parent Subscribers. If necessary, create a diagram of your network showing all WAN links to determine how to use parent Subscribers.

Passing on Unsubscribed Distributions

A Subscriber does not need to subscribe to a Channel containing a Distributor’s Distributions to be in the Distributor’s routing hierarchy. A parent Subscriber itself does not need to be the recipient of the Distribution it is passing on.

Further, a parent Subscriber does not need to subscribe to the same Channels as its subordinate Subscribers to be able to pass on those Channel’s Distributions.

Sharing the Distribution Load

In the illustration under The Routing Hierarchy, each Subscriber listed could be a parent to other Subscribers on its LAN. For example, if every Subscriber listed in the illustration was a parent to 20 end-node Subscribers, the Distributor could service 210 total Subscribers while only physically sending its Distributions to three of the Subscribers (the first-tier parent Subscribers, numbers 01, 04, and 09).

To further illustrate, parent Subscriber 04 would be servicing 104 Subscribers while only directly sending to two parent Subscribers (05 and 06) and its own 20 end-node Subscribers.

Balancing Workloads

A Distributor can use parent Subscribers in a routing hierarchy to explicitly determine routes for its Distributions. This eases its workload in distributing to Subscribers.

A parent Subscriber can also help a Distributor with its workload by acting as a proxy for the Distributor to pass on Distributions to other Subscribers. You can have multiple parent Subscribers on a given LAN to share the distribution workload on the LAN.

We estimate that the number of Subscribers and/or parent Subscribers that any one Distributor or parent Subscriber should service to be about 40. This figure is dependent on such factors as network speed, sizes of Distributions, and so on.

You should place parent Subscribers where they can help in load-balancing for Distributors and other parent Subscribers.

Figure 3-6 illustrates a WAN environment with parent Subscribers:

Figure 3-6 WAN Environment with Parent Subscribers

Note the following from this illustration:

  • Assume that the three parent Subscribers that the Distributor’s distribution lines point to are the first-tier Subscribers in the Distributor’s routing hierarchy.

  • Assume that the other four parent Subscribers (in LAN B and LAN C) are listed in the second tier of the distribution hierarchy.

  • The Distributor does not need to send the Distributions directly to the 30 Subscribers on LAN A because the parent Subscriber in LAN A does that.

  • The Distributor only sends its Distributions directly to the three parent Subscribers, but a total of 157 Subscribers can receive those Distributions.

  • One parent Subscriber in LAN B (and the same for LAN C) was used solely for receiving Distributions directly from the Distributor, then passing them on to other parent Subscribers, which in turn passed them to their 60 Subscribers. For large systems, this scheme can make a parent Subscriber on the other side of a WAN link more available to a Distributor, instead of that parent Subscriber being so busy passing Distributions to its many other end-node Subscribers that it can make the Distributor wait. Consider this hierarchical design where it might be applicable in your network.

The Distributor has the workload of reading eDirectory for Distribution changes, building the Distributions, sending the Distributions, and writing to the Server Management database. By minimizing the number of Subscribers that a Distributor itself must directly send Distributions to, you can give the Distributor more resources for its various functions.

Understanding Routing Hierarchies

Tiered Electronic Distribution provides a routing hierarchy to automate sending your Distributions from the Distributor servers to your Subscriber servers.

The Routing Hierarchy

To ease a Distributor’s workload in sending Distributions, each Distributor has its own routing hierarchy, which is a hierarchical list of Subscribers that indicate the routes Distributions can take to send a Distribution to a Subscriber. The Subscribers in the routing hierarchy are the parent Subscribers. You can nest parent Subscribers many levels deep.

A parent Subscriber can receive a Distribution and extract it, as well as pass that same Distribution on to other Subscribers.

You can modify distribution routes at any time by editing the properties of the Distributor objects.

Figure 3-7 illustrates a Distributor’s routing hierarchy:

Figure 3-7 Distributor’s Routing Hierarchy

The only Subscribers you need to include in the Distributor’s routing hierarchy are those that are used to pass on Distributions to other Subscribers. Subscribers that are not used to pass on Distributions are referred to as end-node Subscribers.

Distributing Using the Hierarchy

Assume that Subscriber 07 is a parent to Subscriber 11 (which is not in the routing hierarchy). The distribution route from the Distributor to Subscriber 11 would be as shown in Figure 3-8:

Figure 3-8 Distributing Within the Hierarchy

The Distributor used four parent Subscribers (04, 05, 06, and 07) to send the Distribution to Subscriber 11.

Subscribers Orphaned from the Routing Hierarchy

If Subscriber 11 did not have a parent Subscriber (such as Subscriber 07), the Distribution would come directly from the Distributor as shown in Figure 3-9:

Figure 3-9 Subscribers Orphaned in the Distribution Hierarchy

The only Subscribers you need to include in a routing hierarchy are those that are used to pass Distributions on to other Subscribers. The end-node Subscribers (Subscribers that are only receiving and not passing on Distributions) do not need to be listed in the hierarchy. They have links in eDirectory to their parents.

Subscribers that exist in a routing hierarchy are generally parent Subscribers, although this is not required.

IMPORTANT:Subscribers that do not utilize parent Subscribers can increase the workload on the Distributor and increase network traffic across WAN links. All Subscribers should have a parent Subscriber, except for the first tier Subscribers that receive Distributions directly from the Distributor.

Rerouting Because of Changes to the Routing Hierarchy

If a parent Subscriber is changed, or the routing list (on the Routing Hierarchy tab of the Distributor object’s properties) is changed, the change is reflected in the routing slip (data file used in the distribution process), because it is calculated each time the Channel schedule starts. A refresh is required for the Distributor to read eDirectory and obtain the new routing hierarchy.

If a Subscriber server is removed from the network, and it was being used in a Distributor’s routing hierarchy, you need to edit the Distributor object’s properties to adjust the routing hierarchy because of that Subscriber’s removal. Then refresh the Distributor so it can recognize the newer routing hierarchy.

Sharing Parent Subscribers with Other Distributors

If you have multiple Distributors, they can share portions of each other’s distribution routes, meaning Subscribers can be listed in the distribution routing hierarchies of more than one Distributor. This is because the route to a Subscriber is dependent on the Distributor, and can be different for any given Distributor to Subscriber path.

Figure 3-10 illustrates the use of multiple Distributors and parent Subscribers in sending Distributions:

Figure 3-10 Using Multiple Distributors and Parent Subscribers

The arrows and lines indicate the subscription and Distribution connections to the Channels (dotted lines) and the distribution paths from the Distributors to the Subscribers (solid lines).

Figure 3-10 does not show distribution route hierarchies. For the purpose of this illustration, assume the following:

  • Subscriber 1 is in Distributor A’s hierarchy

  • Subscriber 1 is a parent to Subscribers 2 and 3

  • Subscribers 3 and 4 are in Distributor B’s hierarchy

  • Subscriber 4 is not in Distributor A’s hierarchy

Note the following from the illustration concerning the use of multiple Distributors and parent Subscribers in sending Distributions:

  • Distribution ownership: Distributors have ownership of their own Distributions and build and send each of their Distributions.

  • Multiple Distributors: Multiple Distributors can list their Distributions in the same Channel. This means a Subscriber can receive Distributions from multiple Distributors.

  • Channel usage by Distributors: Distributors can list their Distributions in any Channel, and they can list one Distribution in multiple Channels.

  • Multiple Distributions per Channel: A Channel can have multiple Distributions from one or more Distributors.

  • Channel subscriptions: Each Subscriber subscribes to any of the Channels that have the Distributions it needs. A Subscriber can subscribe to multiple Channels, and a Channel can have multiple Subscribers subscribed to it.

  • Parent Subscribers: A parent Subscriber is used as a proxy for the Distributor to pass on Distributions to other Subscribers.

  • Orphaned Subscribers: If a Subscriber is not in a Distributor’s distribution route, or the child of a parent Subscriber in that hierarchy, the Distributor sends the Distribution directly to the Subscriber. This can be an issue for WAN links and other topology issues.

Distributing Across WAN Links

When you include parent Subscribers in the routing hierarchy, this can minimize network traffic by limiting the number of times a Distributor needs to pass a Distribution across a WAN link.

Because Distributors can send Distributions to parent Subscribers, which in turn can send them on to other Subscribers, a way is provided to send Distributions over a WAN link just once, instead of many times to reach every Subscriber on the other side of the WAN link.

Generally, you should have at least one parent Subscriber on every LAN to minimize the number of times a Distribution needs to cross a WAN link. Even if there are only two Subscribers on a LAN, you can reduce network traffic by using one of them as the parent Subscriber to the other.

Parent Subscribers are especially helpful with slow WAN links.

Consider the following when you determine how to distribute across your WAN links:

  • Parent Subscribers on the Distributor’s LAN segment: You should assign at least one Subscriber to be a parent Subscriber for all of the other Subscribers on a Distributor’s LAN segment. That way the Distributor can have more resources for sending Distributions across WAN links.

  • Parent Subscribers for bridging WAN links: You can minimize the number of Subscribers that a Distributor must directly service across WAN links by assigning at least one parent Subscriber on all other LAN segments and including those parent Subscribers in the Distributor’s routing hierarchy.

    For example, your WAN has four LANs. With the Distributor in one LAN segment, it must send Distributions across three WAN links to get to Subscribers on the other three LAN segments. Let’s assume each of the other LANs has 160 Subscribers that all need a Distribution from the Distributor. Without using parent Subscribers in the Distributor’s routing hierarchy, the Distributor would need to send the Distribution 480 times across WAN links. In using parent Subscribers (four per LAN segment to share the Distribution workload on the LAN), the Distributor would only need to send the Distribution nine times.

  • Primary parent Subscribers on a LAN: You can further minimize WAN traffic by tiering parent Subscribers on the other side of a WAN link from the Distributor. In other words, you can have just one parent Subscriber in the routing hierarchy that would also be a parent to several other parent Subscribers on its LAN segment.

    Using Figure 3-10 as an example, Subscriber 1 on each LAN segment could be the parent Subscriber for Subscribers 2, 3 and 4. In turn, parent Subscribers 1, 2, 3, and 4 would each service their own Subscribers. That would allow the Distributor to just pass a Distribution across a WAN link once to Subscriber 1, which would take care of passing that Distribution on to the other three parent Subscribers, saving the Distributor three extra WAN link transmissions. Therefore, in contrast to Figure 3-10, the 9 transmissions would be paired down to only three.

Out-of-Tree Distributions

To use Policy and Distribution Services in multiple trees, you must install the software separately in each tree. However, you only need to install the Server Management objects to one of the trees.

For example, if your network topology is as shown in Figure 3-11:

Figure 3-11 Network Topology with One Distributor

You could have the Tiered Electronic Distribution configuration shown in Figure 3-12 for the Distributor’s routing hierarchy:

Figure 3-12 Distribution Flow in One Tree

In this example, the Subscriber and server objects all exist in Tree_A. This allows you to have centralized management of the Tiered Electronic Distribution objects, regardless of your network topology.

Although you can create the Distributor and Subscriber objects in only one tree, you can install the Policy and Distribution Services software to any server in your network, whether the server’s eDirectory object resides in the same tree where the Tiered Electronic Distribution objects are created, or the server does not have an eDirectory server object in any tree (such as a Windows server in a domain). This allows you to have centralized management of Tiered Electronic Distribution in environments where you have multiple trees and mixed server operating systems (such as NetWare and Windows servers).

For information on how External Subscribers are used for sending Distributions between trees, see Section 3.10.4, Sending Distributions between Trees.

Routing Hierarchy Configuration Guidelines

You should place parent Subscribers in the routing hierarchy using the following guidelines:

  • Include at least one parent Subscriber on each LAN segment to minimize WAN traffic

  • Include multiple parent Subscribers on each LAN that has 40 or more Subscribers to minimize a parent Subscriber’s workload

  • Make sure that every Subscriber that is not included in a Distributor’s distribution route is assigned to a parent Subscriber on its LAN

Parent Subscribers are not always required for a WAN link. For example, if you have only two Subscribers on a LAN connected by a fast WAN link, the traffic difference between sending the Distribution once versus twice could be negligible. However, for a slow WAN link this might not be the case.

The factors in determining whether a Subscriber can receive Distributions directly from the Distributor instead of through a parent Subscriber are:

  • Network connections

    For example, are you distributing:

    • only within a LAN?

    • across a slow or fast WAN?

    • across firewalls?

    • in a NAT?

  • Frequency of sending Distributions

  • Size of the Distributions

3.3.3 Creating Distributors

By understanding your network’s topology, your Distributions (how many, their sizes, and how often you might expect them to be rebuilt), and how many Subscribers receive the various Distributions, you can determine how many Distributors you need.

Distributors must be created by installing their software and eDirectory objects using the ZENworks 7 Server Management with Support Pack 1 Program CD. For more information, see Policy-Enabled Server Management Installation in the Novell ZENworks 7 Server Management Installation Guide.

To determine whether you need multiple Distributors, see Section 1.1.4, Are Additional Distributors Needed?.

3.3.4 Configuring Distributors

Distributor objects are automatically created when the Distributor’s software is installed to a server. You can edit your Distributor object’s properties at any time.

Not all properties associated with the Distributor object are required. Required properties are noted in the following steps; all others are optional.

  1. In ConsoleOne, right-click the Distributor object, then click Properties.

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

    Use policy: Select to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field is displayed if a Tiered Electronic Distribution policy has been created, distributed to the Distributor server, extracted by the Policy/Package Agent, and enforced on the server. If you select this option, the rest of the fields are dimmed and the policy settings are used instead.

    Input rate: The rate Distributions received (for its Subscriber). The default is the maximum that the connection can handle. This rate is used to control a Distributor server’s use of narrow bandwidth links.

    Output rates based upon Distribution’s priority: Sets the default output rate to minimize network traffic for Tiered Electronic Distribution objects. This determines the send rate for Distributors. The default value is the maximum that the connection can handle. Blank means that bandwidth is taken from third-party software.

    There are three output priorities where you can specify a rate:

    • High priority: These Distributions are sent before any Medium or Low priority Distributions.

    • Medium priority: These Distributions are sent after all High priority and before any Low priority Distributions.

    • Low priority: These Distributions are sent after all High and Medium priority Distributions.

    For more information, see Section 3.4.5, Prioritizing Distributions.

    Maximum concurrent Distributions to build: Specifies the maximum number of distribution threads that can be running concurrently for building Distributions. The default value is 5. Valid values are from 1 to 10.

    This number can help in load-balancing a Distributor’s building activity.

    Maximum concurrent Distributions to send: Specifies the maximum number of distribution threads that can be running concurrently for sending Distributions. The default value is unlimited (a blank field).

    This number can help in load-balancing a Distributor’s sending activity and spread network traffic over an entire scheduling window.

    Connection time-out: Specifies the allotment of time before the Distributor server times out when connecting to another node. The default value is 300 seconds (five minutes), after which it ends the connection and does not retry until the send schedule starts again. The available range in seconds is 1 to 60,000.

    You can increase or decrease this setting to allow messages to pass back and forth between the agents during the distribution process. If one node is expecting to receive a message from another, there should be a reasonable time to wait before assuming that the sender is no longer available.

    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 is:

    • NetWare: sys:\zenworks\pds\ted\dist

      IMPORTANT:The default volume is sys: on NetWare servers. We recommend that you do not use the sys: volume because the directory’s content can become quite large.

    • Windows: c:\zenworks\pds\ted\dist

    • Linux and Solaris: /var/opt/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, see Section 3.12, Working Directories.

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

    Use policy: Select to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field is displayed if a Tiered Electronic Distribution policy has been created, distributed to the Distributor server, extracted by the Policy/Package Agent, and enforced on the server. If you select this option, the rest of the fields are dimmed and the policy settings for messaging are used instead.

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

    For more information on the message notification levels, see Section 3.11.5, Minimizing Messaging Traffic.

    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 Distributor object. The default is:

    • NetWare: sys:\zenworks\pds\ted\dist\ted.log

      IMPORTANT:The default volume is sys: on NetWare servers. We recommend that you do not use the sys: volume because the log file can become quite large.

    • Windows: c:\zenworks\pds\ted\dist\ted.log

    • Linux and Solaris: /var/opt/zenworks/zfs/pds/ted/dist/ted.log

    For information on creating custom log files for all Distributor objects by using the Tiered Electronic Distribution policy, see Section 4.3.5, Creating Custom Log Files Using Policies.

    Delete log entries older than __ days: Log file entries for a Distributor are deleted after they are older than the number of days specified. The default is six days.

    E-mail: Specifies which level of messages are sent 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 provide 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. Select the Schedules tab.

    The schedule for a Distributor determines how often it reads the information contained in the Tiered Electronic Distribution objects in eDirectory. It reads the Channel, Distribution, and Distributor objects based on this schedule. You can set this up to reflect how often you expect information in these objects to change, or how often new objects might be created. However, we recommend that you leave its schedule set to the default of Never to prevent the possibility of the refresh interrupting the building or sending process, which could cause an infinite loop where the Distribution never finishes being built or sent.

    We recommned that you after you create a Distribution, you force the Distributor to read eDirectory by right-clicking the Distributor object and selecting the Refresh menu option.

  5. Select a schedule and fill in the fields:

    Use policy: Select to use the effective policy if you want to use the values set in the Tiered Electronic Distribution policy. This field is displayed if a Tiered Electronic Distribution policy has been created, distributed to the Distributor server, extracted by the Policy/Package Agent, and enforced on the server. If you select this option, the rest of the fields are dimmed and the policy settings are used instead.

    Schedule type: The Refresh schedule you selects determines when the Distributor reads eDirectory again.

    IMPORTANT:We recommend the Distributor’s Refresh schedule be daily, unless changes to Distributions warrant a more frequent refresh. However, do not refresh the Distributor more often than every five minutes. The following can need up to five minutes to complete their processes: Distribution building, eDirectory replication, and tree walking (when no Search policy is defined).

    For information on available schedules, see Section 8.0, Scheduling.

  6. Select the Routing tab and create the Distributor’s routing hierarchy.

    Subscriber routing hierarchy: Configure the routes the Distributor uses when sending Distributions to the Subscribers. You should plan this hierarchy in advance.

    Use the following method to create the hierarchy:

    1. Select the Distributor.

    2. Click Add, select one or more Subscribers, click Select, then click OK.

      You can have multiple Subscribers directly under the Distributor.

    3. Select one Subscriber.

    4. Click Add, select one or more Subscribers, click Select, then click OK.

      You can have multiple Subscribers directly under each Subscriber.

    5. Repeat Step 6.c and Step 6.d for each Subscriber until you have created the desired hierarchy.

  7. Select the Distributions tab to view the Distributions being serviced by this Distributor.

  8. To edit a Distribution, select the Distribution, click Details, edit the properties, then click OK to exit the Distribution object’s properties.

  9. When you have finished configuring the Distributor and its Distributions, click OK to exit the Distributor object’s properties.

    IMPORTANT:Changes made to Tiered Electronic Distribution objects (other than Distribution) are not in effect until the Distributor reads eDirectory.

3.3.5 Manually Refreshing the Distributor

Any time you make a change in eDirectory that affects the Distributor, you must manually refresh the Distributor so that it knows of that change.

For example, when you create a new Distribution, the Build schedule does not make the Distributor aware of the new Distribution. You must manually refresh the Distributor so that it can detect the change in eDirectory.

To refresh the Distributor:

  1. In ConsoleOne, right-click the Distributor object.

  2. Click Refresh Distributor.

    This causes the Distributor to read eDirectory and obtain all of the changes that were made in eDirectory. The Distributor Agent can then act on any changes applicable to the Distributor.

    To perform this task in iManager, see Forcing Policy and Distribution Services Agent Actions.

Distribution building begins according to the current Build schedule. The Distribution is sent according to the Send schedule.

As soon as Subscribers receive an entire Distribution, they extract the contents to their working directories that are specified in the Subscriber objects’ properties.

3.3.6 Deleting a Distributor Object and How Its Distributions Are Affected

You can delete Distributor objects from eDirectory. However, you can lose the following important information that you might want to reuse for the Distributor’s replacement:

  • The Distributor’s distribution hierarchy

    This is part of the Distribution object’s properties, and it shows which Subscriber servers are used for passing on the Distributions.

  • The list of its Distributions

    The Distributor’s Distributions become orphaned and unusable.

For information on how to handle orphaned Distributions, see Section 3.4.10, Handling Orphaned Distributions.