Miscellaneous Tiered Electronic Distribution Issues


Directory Sync Granularity for File Distributions

The File Distribution has been enhanced with directory sync granularity:


Understanding Synchronization and Directory Sync Granularity

A File Distribution, with or without synchronization enabled, adds or updates files and directories on a Subscriber server. However, with synchronization enabled it also causes the deletion of files and directories. Therefore, file and directory deletion on the Subscriber server is the main function of synchronization.

Directory sync granularity allows you to specify synchronization at any directory level in the Distribution to provide synchronization "from here down."


How the Synchronization and Directory Sync Granularity Processes Work

The following example illustrates what a synchronized File Distribution does to the Subscriber server's file system if synchronization is turned on in the Distribution:

Files and directories located on the Distributor server that are contained in the File Distribution: Applicable directories on the Subscriber server before the Distribution is received and extracted: 
data:\zenworks\viruspatterns
data:\zenworks\nw65sp\nw65sp1.exe
data:\zenworks\nw65sp\nw65sp2
 
data:\zenworks\viruspatterns
data:\zenworks\nw65sp

Each of the end items in the above paths are synchronized in this Distribution.

One of the files is missing from the \viruspatterns directory on the Subscriber, and it is also missing the \nw65sp2 directory.

Upon extraction of the File Distribution, the following occurs on the Subscriber server's file system:

  1. The missing virus pattern file is restored in the \viruspatterns directory.

    The ...\viruspatterns directory is also made to exactly match the files and subdirectories contained in the Distribution by deleting any files or subdirectories on the Subscriber that are not contained in the Distribution.

  2. The nw65sp1.exe file is updated in the \nw65sp directory. Nothing else is synchronized in that directory, because synchronization was not enabled for the \nw65sp directory itself.
  3. The \nw65sp2 directory and its files and subdirectories are restored from the Distribution under the \nw65sp directory on the Subscriber.

Directory sync granularity also allows you to retain unsynchronized directories while synchronizing their peer directories. For example, you could select to synchronize the data:\zenworks\viruspatterns and data:\zenworks\nw65sp\nw65sp2 directories, but not the data:\zenworks\nw65sp directory.

However, if you synchronize the parent data:\zenworks directory, all of its subdirectories must also be synchronized, because synchronization occurs from the specified directory and downward. Therefore, when you select directories to be synchronized, you cannot select a parent directory to be synchronized, then select some of its child directories to not be synchronized.

All child directories are automatically synchronized when a parent directory is set to be synchronized, and a parent directory automatically loses its synchronization when one of its child directories has synchronization turned off for it.

For example:

Incorrect Plan Correct Plan

Synchronize:

data:\zenworks

Synchronize:

data:\zenworks\viruspatterns
data:\zenworks\nw65sp\nw65sp1.exe
data:\zenworks\nw65sp\nw65sp2

Do not synchronize:

data:\zenworks\nw65sp

Do not synchronize:

data:\zenworks
data:\zenworks\nw65sp

This does not work, because by synchronizing the \zenworks directory, the \nw65sp directory must also be synchronized.

This works, because the directories desired to not be synchronized are higher in the path than those that are desired to be synchronized.

The next few sections describe synchronization scenarios:


Synchronizing All Directories Under the Distribution's Target Directory

For the source, choose the directories on the Distributor server's file system to be synchronized. For the destination, the directories to be synchronized might or might not already exist in the Subscriber server's file system.

If the files already exist, when the Distribution is sent, their content is made to match that of the corresponding directory on the Distributor server's file system. If they do not exist, they are added on the Subscriber server's file system.

Determine where these directories should exist on the Subscriber server's file system. In other words, there is a parent directory under which the synchronized directories are located, or there are the synchronized directories located at the root of the Subscriber's file system. Variables can be used to specify the target on the Subscriber server's file system where the Distribution is to be extracted.

In the following illustration, the \viruspatterns and \supportpacks directories on the Distributor server are created and synchronized under the vol1:\servers directory on the Subscriber server.


%DEST_VOLUME% is the target with a servers directory under it. Associated with the servers directory are two directories on the Distributor server: viruspatterns and supportpacks. In this illustration, the servers directory is synchronized, causing the viruspatterns and supportpacks directories to also be synchronized.

Using Directory Sync Granularity to Synchronize Directories at Various Levels

You can synchronize at the target level (%DEST_VOLUME%). In the example above, we have defined it as vol1:\servers. In that case, the only subdirectories that will exist under that directory are viruspatterns and supportpacks. All other existing subdirectories are deleted.

To retain other directories under vol1:\servers, you would not enable synchronization at the target level (%DEST_VOLUME%). Instead, you would drop down to the subordinate directories and synchronize those. For example, the following illustrates synchronizing only the \viruspatterns directory. That means there could be other directories under vol1:\servers that would be unsynchronized, such as \supportpacks.


%DEST_VOLUME% is the target with a servers directory under it. Associated with the servers directory are two directories on the Distributor server: viruspatterns and supportpacks. In this illustration, only the supportpacks directory is synchronized.

Synchronizing a Subscriber Server Directory with Certain Distributor Server Files

If the File Distribution has certain files on the Distributor server selected to be associated with a directory in the Distribution, you would not normally synchronize that directory in the Distribution. If you did, you could lose valuable data in that directory on the Subscriber server.

For example:


Illustration showing a possible data loss scenario when the ted directory is synchronized and only one file is associated with it from the Distributor; and, showing that you would preserve existing files on the Subscriber by not synchronizing the ted directory.

The Possible Data Loss method would cause all files in the \nw65sp directory and any of its subdirectories to be deleted from the Subscriber server, except for the nw65sp1.exe file. The Preserving Other Files method just updates the nw65sp1.exe file in the \nw65sp directory, leaving all other files and subdirectories unchanged on the Subscriber server.


Synchronizing Directories for a File Distribution

  1. In ConsoleOne®, right-click a Distribution object, then click Properties.

  2. Select the Type tab, then select the File for the type of Distribution.


    Distribution object properties showing the Type tab with %DEST_VOLUME% as the target with the junkdir directory under it that is associated with two files from the Distributor server: data:\junk\delete\config.ini and data:\junk\delete\prepost.spk.

  3. Click New Target and %DEST_VOLUME% as the default variable that contains the target path on each Subscriber server.

    WARNING:  If you want to synchronize at the target level, make sure this variable does not contain the root of the Subscriber server's file system.

  4. Select the Add Directory and Add Files buttons to create the directory structure in the Files To Be Distributed box.

    The Add Directory button is for the Subscriber server's target paths and directories, and the Add Files button is for browsing the distributor's file system and selecting directories and files that are to be included in the Distribution.

  5. If necessary, click the plus signs to expand the directory structure.

    By default, no directories in the listing are selected for synchronization.


    Distribution object properties showing the Type tab with %DEST_VOLUME% as the target with two directories: junkdir and morejunk. The junkdir directory is associated with two files from the Distributor server: data:\junk\delete\config.ini and data:\junk\delete\prepost.spk. The morejunk directory is associated with a directory on the Distributor server: data:\junk\delete. The junkdir and data:\junk\delete directories are synchronized.

  6. To specify a directory to synchronize, select the directory in the Files To Be Distributed box, then click the Synchronize button.

    The Synchronize icon (Synchronize icon for directory sync granularity) is placed in front of that directory name.

    The Synchronize and Desynchronize buttons are dimmed when you select a filename instead of a directory name. You can only synchronize directories.

    Because directory synchronization is done for the directory you select and all of its subdirectories (in other words, "from here down"), there is no need to synchronize any directories below a directory that you select for synchronization.

    When you synchronize a directory and expand the directories below it, the Synchronize icon is displayed before each directory's name.

  7. To reverse your selection of a directory to be synchronized, select the directory name that has a Synchronize icon, then click the Desynchronize button.

    If you desynchronize a directory and its parent directory was synchronized, the parent directory is also automatically desynchronized. This includes all directories (grandparents) up the path that might have been synchronized. In other words, you cannot synchronize a directory, then desynchronize any directory below it without also causing the directory to be desynchronized.

  8. Repeat Step 6 for each directory to synchronize.

  9. Continue with configuring the Distribution.

    For more information on configuring Distributions, see Creating and Configuring the Distribution.

  10. Click OK when finished configuring the Distribution.

    For this Distribution, directory synchronization occurs with only the directories where you placed the Synchronize icon (Synchronize icon for directory sync granularity), including all of their subdirectories.


Understanding Dependencies in Tiered Electronic Distribution

Policy and Distribution Services agents (Policy/Package Agent and Distributor Agent) are dependent on one another and upon eDirectory. It is important to understand the following dependencies when using Policy and Distribution Services to manage your network:


Synchronization of Tiered Electronic Distribution Objects in eDirectory

Server Management uses eDirectory as the repository for information needed by the Tiered Electronic Distribution and Server Policies components. Because eDirectory is a distributed database and can have partitions and replicas throughout the network, it takes time to synchronize all of the replicas each time Server Management objects are created or modified.


Unloading Parent Subscribers

You must change the parent Subscriber attribute in the Subscriber object to change the parent Subscriber. Then, the next time a Distribution is sent, the distribution route to the Subscriber reflects the new parent Subscriber.

If a parent Subscriber Java process is unloaded (exited), the subordinates of the parent Subscriber do not renegotiate to another parent Subscriber. The subordinates wait until that parent Subscriber is loaded again and continue to use it. The reason for this is that if the parent Subscriber was the only server between twenty Subscribers and the Distributor (which is located across the WAN), you do not want all of the Subscribers to go across the WAN to get their Distributions if the parent Subscriber is unavailable.


System Resources and Server Behavior

Using Policy and Distribution Services can affect the behavior of your system:

Installing and using Tiered Electronic Distribution can affect any of the following:

To optimize your installation of Tiered Electronic Distribution, you should consider the following issues when selecting Distributor and Subscriber servers:


Controlling I/O Rates and Concurrent Distributions

If you need to control bandwidth usage for Distribution traffic, you can set the I/O rates and the maximum number of concurrent Distributions for Distributors and/or Subscribers.

Attributes of both the Distributor and Subscriber objects provide the following controls:

If there is only one Subscriber, the Distributor sends Distributions at the selected rate. If there are two Subscribers, the Distributions are sent at one half the rate. In other words, to determine the slowest distribution rate, divide the Distributor's output rate by the maximum number of concurrent Distributions.

Because Subscribers always receive another concurrent Distribution, the rate applies even though you cannot limit the number of incoming connections.


Minimizing Messaging Traffic

Tiered Electronic Distribution provides message notifications so that administrators and selected end users are kept informed. Notifications are sent in several ways:

The following sections explain notification usage:


Message Notification Levels

There are seven levels of message notification available. Each level adds its own information to the previous level.

Messaging Level Description

Level 0 - No messages

Messages are not sent.

Level 1 - Errors

Reports unusual or unexpected situations that can cause an operation to fail. They often require user intervention to correct the problem.

Level 2 - Successes and Level 1 messages

Reports completion of a successful operation.

Level 3 - Warnings and Level 2 messages

Reports unusual but not unexpected runtime conditions. These messages usually do not require user intervention, but in some situations an unusual runtime condition does.

Level 4 - Information and Level 3 messages

Informs the user about what has happened or is currently happening. They usually do not require any action from the user.

Level 5 - Trace and Level 4 messages

Reports detailed trace information that is used to troubleshoot unusual or unexpected situations that cause an operation to fail. This information might only be useful with the guidance of Novell Support..

Level 6 - Developer trace and Level 5 messages

Used for debugging code. This information is useful only to Novell Support and Development.

Regardless of the destination for a message, resources are directly affected by the level you choose.

For information on setting message notification levels, see:


Managing Message Notification Level Log Files

The level you choose for a log file affects the rate at which the log file grows. Because log files have no maximum size, you can control the size of a log file by choosing to delete entries after x number of days. For information on setting message notification levels for log files, see:


Sending Notifications Over LANs and WANs

The greatest impact on network traffic can come from the levels you choose for SNMP traps and for the remote console.

For information on setting message levels for SNMP traps, e-mail messages, and the server's console, see:


SNMP Traps

SNMP messages are sent only if there is an SNMP policy in effect for the receiving server, regardless of the level you choose for the messages. SNMP traffic is affected by both the level you choose and by the SNMP configuration in the policy on the server. There is one SNMP packet per message per destination in the SNMP Trap Target policy. IPXTM addresses are not supported for trap targets.


E-Mail Messages

E-mail messages can also affect network traffic. Like SNMP, e-mail sends only one e-mail per message per e-mail user defined. E-mail is also configured by a server policy. You must define and enable the policy on the sending server for e-mail messages to be sent.


Changing DNS Names or IP Addresses for Tiered Electronic Distribution Servers

Whenever there is a change to the identity of either a Distributor or Subscriber server, you must perform certain tasks so that the distribution processes for these servers can continue as before.

In the distribution process, Tiered Electronic Distribution servers identify themselves to each other by their DNS names or IP addresses. The following sections explain situations that can arise from changing these server identifiers.


If You Are Using DNS Names to Identify Your Servers

If you change the IP address of a Distributor or Subscriber server when you are using its DNS name to identify it to Server Management, this change does not affect the distribution processes.


If You Are Using IP Addresses to Identify Your Servers

Because reinstating valid certificates is involved in resolving server identity changes, see Handling Invalid Certificates for instructions.


When a Tiered Electronic Distribution Process Fails

It is possible, for many common computer-related reasons, that a Tiered Electronic Distribution process could fail. The following are a few possibilities: