General Information on Distribution

In an DSM environment, you need to ensure that the required data are available at every site on all depots. Ivanti DSM has its own distribution mechanism to distribute data to the depots: the distribution (copying the files "from node to node") is executed by a separate Distribution Service.

The distribution mechanism is designed to keep the amount of transmit­ted data and hence the network load as low as possible.
It has the following features:

  • Cascading
    For distributing data to several locations and servers, Ivanti DSM uses so-called cascading distribution: the data is passed on from one node (depot) to all directly subordinated nodes.
  • Polling Intervals
    Distribution is not continuous and does not occur immediately after source data have changed; it occurs at specific intervals, so-called polling intervals. Due to cascaded replication, it can take several polling intervals until a change reaches the lowest node.
  • Differential Operation
    Distribution only takes place if data have changed in the corresponding source. During every poll, the distribution service checks each distribution tar­get or "node" (depot) to see whether new data exist in the source, i.e., the parent node. If yes, this data (and only this data) is distributed. If data deleted in the source, they are also deleted in the target by means of the distribution function.
  • Transmission of Application Sources Files in Compressed Form
    To reduce the network load, the package files are generally distributed in compressed form.
    There are exceptions for certain package types for which a compressed distribution is not advisable, for example MSI Packages and all OS package types (when using DSM OSD).
  • Definable Network Load
    If required, you can customize the network load that is produced during distribution by specifying the frame size and a general timeframe for each site.

Distribution of Packages

New packages are initially unavailable for managed computers.
Distribution enables a package to be made available throughout the context of its repository. The scope of a repository corresponds to all objects starting with the context in which the repository is attached in the site structure.

Background: The package exists initially only as a working copy in the master repository; this is located on the master depot for the object in whose context the repository is located.
However, the managed computers require an installation copy on the depot of their assigned site to be able to execute the package. This installation copy is initially created during distribution of the package (ClosedShow example)

In the site structure illustrated below, the MunichDB database is located in the context of the Munich site. The packages in MunichDB can only be distributed to depots in the Munich site.
The packages in GermanyDB can be distributed to the Munich and Stutt­gart sites.
The Enterprise-DB repository is located in the context of the Enterprise ORG. The packages in this repository can be distributed to all depots in all sites.

For more information, see Distribution within the Site Structure.

Distribution of Package Revisions

DSM packages can be revisioned. In order for the packages to be distributed correctly, all revisions of all packages have to be available on all (required) depots in a repository’s context.

To prepare for the distribution, the current ”work” revision is compressed (except for MSI and OS packages) and stored in the revision directory.
When you set up the distribution you also have to define distribution targets (distribution job). Usually, a new revision uses the existing distribution definition.
If you set up the distribution, the revision is included in the automatic distribution.

Therefore, the following applies to distribution:
All released revisions of the package are stored in the package’s directory REV as compressed file(s) _NI5.ZIP. For non-compressed packages the individual, uncompressed installation files are stored in the REV directory.
Only the contents of the REV directory are distributed.
After revision 2 all revisions only contain the delta of the previous revision.

After releasing the package, the current revision is frozen and cannot be changed any more.
If the package is to be changed again, you have to make a new revision which has to run through all procedures including the distribution and the release again.