Recommendations for group distribution configuration

Schedule

Start and end times (distribution lifetime)

Usually it is more efficient to define rather short distribution lifetimes. The benefits of shorter group distributions in comparison to one lasting for a long time are:

Using short group distribution lifetimes (in comparison to long lifetimes):

• It is easier to monitor the deployment status and to keep track of fixed failed installations. Long lifetime forces you to keep a separate list of fixed installations, where you can easily remember which devices you fixed in a short distribution.

• Even the distribution ends sooner than using long lifetime, it is quite easy to redistribute package to non complete targets. Each end of distribution drops out the completed targets and makes the target list shorter and easier to manage.

• Each end of distribution is also a place for a status check, where as long distributions are more like "fire and forget" actions: you may not remember all the details.

Distribution lifetime should be longer than the client polling interval. Otherwise some of the clients might have the chance to connect server during distribution lifetime.

Allowed time frame

Allowed time frame can be used in two modes.

Server time zone is good option if:

• most of the targets are on same time zone

• you need to know exactly when the package installations start on targets

• you want to define a group distribution which lasts for several days, but tries the installation only at specific time each day (on one time zone, i.e. server's time zone)

Client time zone is a good choice if:

• targets are scattered across time zones

• you have certain maintenance window defined in local time

• you want to schedule package installations to happen at a specific time, e.g. during night time

• you want to define a group distribution which lasts for several days, but tries the installation only at specific time each day (local time on each time zone)

When using server time zone, the allowed time frame must be within the distribution lifetime.

Using client time zone allows you to define allowed time zone across the 24 hour clock.

Allowed time frame should be longer than the client polling interval. Otherwise some of the clients might have the chance to connect server during time frame (unless you use long distribution lifetime and this way try to randomize installations to happen on several days).

Number of retries

Maximum number of retries you can define is 9, but in practice this may not be a wise option. Using numbers greater than 2 or 3 may not give you any better end results. If the installation will not work with a couple of retries, the target and/or the package may need some special attention.

Retrying installation is a good option, if the package to be distributed requires some specific condition, for example that the user may not use certain application at the time of installation.

Minimum wait time between retries (min)

Wait time between retries is heavily depending on the Miradore client polling interval. Using here a value shorter than client polling interval will not make the target to retry installation any faster, unless you wake up the client or reboot the target device. Without any special actions all wait times shorter than client polling interval mean that retries will follow client polling interval.

Recommended way to define wait time is to think how long time after failed installation would be needed before installation conditions on target will change any better.

Exception return codes

Exception return codes are meant for packages which may fail into a known error which means there is no sense to retry the installation again.

For example, if the target does not meet all the prerequirements for this package (e.g. some required software is not installed). In this case this package may always fail into same error you are able to recognize. Retrying this package will not make the installation work until the prerequirements are met. Defining this known error as exception return code will prevent group distribution failing into the same error over and over again.

Add package to asset configuration page

Use this option if you are distributing a package which you want to be installed on these devices also after reinstallation of whole device. Do not use the option if you distribute a package which is:

• a hotfix which does not need to be applied in reinstallation (initial installation)

• are already a part of initial installation via some other configuration item (e.g. defined as organisation specific package)

Use Wake-On-LAN for offline devices

This is an excellent option if you want to reach all targets by any means, for example when distributing a security update in a tight schedule. Before using this feature notice following:

• Wake-On-LAN has to be enabled on target device’s BIOS in order to get it started

• Target device must be connected to network

• As Wake-On-LAN request is not a routed protocol, it requires a proxy in each LAN containing targets. Request uses one online Miradore client on that LAN as a proxy.

• When computer wakes up, it is up to its BIOS and boot order configuration which is the media it tries to use when booting up.

• If you start up the devices with Wake-On-LAN, remember that they will stay powered on.

Distribution specific package timeout (min)

This timeout will override the values defined in system settings and on package configuration. Use this group distribution specific option for example if you know you are distributing package over slow network connections which would make too many installations to expire even if they would succeed if just given enough time.

Distribution specific installation point

Use this option if you are distributing something:

• In a rapid schedule and there is no time to replicate files to all installation points before group distribution starts

• Which would otherwise require replicating some media which is not needed anymore after the distribution is finished

• And you know that some of the configured installation points are not available. Using fixed installation point prevents unnecessary failures when trying to connect unavailable installation points.

Distribute only to known network locations

Use this option, if you want to prevent package distribution to unknown (i.e. possibly too slow) networks. This option relies heavily on the subnet and location configurations in your environment. All subnets which are not activated in Miradore and which are not bind into any location are considered as unknown networks.

This option is useful if you have lots of devices using for example mobile data connections and you don’t want to distribute packages to these devices. Defining office location subnets and binding them into locations in Miradore will enable the distribution to reach all targets connected from these locations, but prevents installation to mobile devices. If these mobile devices change their location into any of the known office locations during the distribution lifetime, they will get the package as well.