If you want to make more efficient use of your network when distributing the same data to many devices, you may want to consider using multicast – it may already be used in your environment for multi-media tasks such as providing video content. Multicast is a complex technology that requires complete buy-in from both your system and network administrators.
Network implementations vary widely and are complex. To use Nomad multicast solutions your network needs to be correctly structured and the appropriate hardware must be used and correctly set up so there is a small overhead in terms of extra support, but the advantages outweigh the overhead as it results in efficient distributions to large numbers of Nomad clients.

Multicast is not supported when a device is only on a wireless connection.
On this page:

Comparisons of transfer methods

The sections below describes the basic features of each transfer method and the conditions that best suit each of these.

ScenarioPeer-to-peerCentral multicastLocal multicast
1Small branches with less than 100 computersP2P is simpler to implement than multicast and may provide the most efficient transfer of content. Optionally use the Nomad FanOut feature.


Large branch networks with multiple subnets

If multicast is not possble then use the Single-site download feature (which requires an ActiveEfficiency Server) to re-distribute content between fast-connected subnets.Central multicast is recommended if possible. It is likely to provide the most efficient utilization of the WAN link and distribution throughout the branch network.Alternative if Central multicast (multicast over WAN) is not possible. Local multicast provides the most efficient means of locally re-distributing large packages once they have been downloaded over the WAN.
3Internet distributionIf the local branch is small, then P2P is likely to provide the most efficient method of local re-distribution.Usually not applicable as it is likely that multicast over intervening routers are liable to be disabled by the ISPs.If the local branch is large, then local multicast is likely to provide the most efficient method of re-distribution.

Not using Nomad

If you are not using Nomad to manage your downloads, you will probably require a local Distrution Point, or your central Distribution Point server is likely to be saturated with requests and large amounts of redundant transfers being made across the WAN as each target computer on the target subnets requests its own copy of the download.


Nomad peer-to-peer transfer is the basic method used to locally re-distribute downloads on a branch network. It relies on the use of share connections to the locally elected Nomad master computer. Windows workstation OS versions have a limit of six concurrent connections, which can be alleviated using Nomad FanOut.

For large branch networks with multiple subnets you can use the Single-site download feature (which requires an ActiveEfficiency Server) to define SSD sites that are interconnetced by fast LAN connections. SSD sites can be based on Configuration Manager sites, Active Directory Sites, or other methods of grouping subnets.

Local multicast

Local multicast is designed to reduce LAN network traffic at the branch and reduce the load on the elected Nomad master computer.  Use this feature in preference to central multicast if multicast traffic is prohibited over the WAN. Nomad local multicast utilizes all the functionality of Nomad, but once the download is at the branch, it is distributed locally using multicast. Local multicast improves the performance of Nomad across the LAN and is ideal for branch offices containing hundreds of computers.
It is best to use local multicast:

  • When sending a package to a large number of Nomad clients on a subnet with no local DP – multicast is the most efficient mechanism when there are a large number of Nomad clients. In this scenario local multicast reduces the load on the locally elected Nomad master.

Central multicast

Package data is sent from a central multicast transmitter to all deployed Nomad clients prior to execution. The central multicast job is manually set-up by an administrator making this a suitable transfer mechanism for sending the same package source to most of the organization. Data sent from a single source location to multiple subnets is only transferred once over each connection. This greatly reduces load on the DP and increases the number of subnets that it can service whilst significantly reducing network traffic going across any intervening WAN links. Central multicast improves the performance of Nomad across the WAN.
It is best to use central multicast:

  • When sending a package to a large number of Nomad clients – due to the method of file transmission multicast is most efficient when there are a large number of Nomad clients.
  • If the network topology is suited to multicast – for example, in topologies where network traffic is routed over a single communication pipeline and subsequently distributed to large numbers of branches, normal transfer to all of the Nomad clients can lead to saturation at the pipeline. This is because the transfer may need to be performed once per branch. Central Multicast helps in this case as the packets that form the multicast are sent just once over the pipeline and subsequently routed to all the branches on the other side.
  • If the number of DPs in the Configuration Manager hierarchy is small – if there are large numbers of DPs in the Configuration Manager hierarchy, these may already contain the package being centrally multicast. In this case the package will already be distributed throughout the network and downloading directly from each DP is likely to be preferable to using central multicast.

Setting-up central multicast

To setup central multicast:

  1. Update the application or package content on the Configuration Manager Distribution Point (DP). 
    • If multicasting a package, ensure it is configured to use Nomad
    • If multicasting applications or software updates, ensure the global 
  2. Create a deployment scheduled for some time in the future – this schedule must be at least beyond the poll interval defined in Configuration Manager client settings.
  3. On the Configuration Manager DP, run this command-line referencing the deployment ID.

    %ProgramFiles%\1E\Client\Extensibility\NomadBranch\NomadBranch.exe -central=<DeploymentID>

    Nomad client is module in 1E Client, and has a different default install location to previous versions of Nomad.

When the deployment is sent to each target computer, the local Nomad joins its computer to the multicast session, just prior to the its scheduled time, and waits for multicast to begin. Scheduling in this way increases the efficiency by enabling the Nomad clients to start receiving the multicast data at around the same time.

  • To use central multicast on packages in Configuration Manager, the Copy the content in this package to a package share on distribution points option must be enabled
  • Central multicast can only be used with a DP on a Site server, not on a standalone DP (Distribution Point that is not on a Site server)
  • Central multicast is not supported with SIS (single-instance store). For information about SIS please refer to:

Schedule set too soon in the future

If the mandatory scheduled time is set too soon in the future for the size of the package, the central multicast job will be cancelled as it will not have time to prepare and start the job. When this happens, this notification appears in the Nomad log files Sorry – Multicast job cancelled – Too late to start this job with these parameters.

You will need to change the original schedule so that sufficient time is allowed for Nomad to perform its preparations – 30 minutes is a reasonable amount of time. Do not add a new schedule as Nomad will use the first available deployment that is in the future.

When the scheduled time arrives, Nomad on the DP starts the multicast and the simultaneous transfer of blocks to all computers begins. By design, multicast was never intended to be a reliable network protocol. This means that in normal circumstances data packets are not acknowledged by the recipients.

Although this allows for increased scalability and network efficiency, some network packet loss is expected in any multicast transmission. Nomad has built-in patented technology that ensures that missed network packets are recovered. Computers that miss data blocks communicate with their local Nomad master. Requests for the repeat sending of specific blocks are then pooled at the master and communicated back to the DP in one go.

Cache management

If you are going to manage the caches, the cache cleaner will automatically take into account the space required by all the concurrent jobs running before purging a cache. There is no additional configuration needed for this to happen.

Setting-up local multicast

To setup local multicast:

  1. Edit the package properties.
  2. Select the Nomad tab and check the Multicast checkbox. (see Configuration Manager 2012)
  3. Click OK.

If the computer receiving the package is not licensed for Nomad multicast but is licensed just for Nomad, the deployment is distributed locally using standard branch functionality – multicast is not used.

Things to avoid if you are using multicast

We recommend you take note of the following when using multicast:

  • During multicasting avoid the use of hibernation or sleep on Nomad client computers
  • Influence the election weighting for laptops so that they are not considered as candidates for a master
  • Synchronize downloads so that all Nomad clients are ready to receive the multicast at the same time
  • Send the multicast overnight when there is minimal disturbance to the networked computers
  • Limit the number of simultaneous active deployments


Configuring multicast on your network

To fully realize the potential of using multicast, it must be enabled on your network. Multicast is typically enabled on routers so there should not be any specific changes required. Nomad multicast uses Multicast Address Dynamic Client Allocation Protocol (MADCAP) to get its range of multicast addresses. One implementation of MADCAP is bundled with Microsoft’s implementation of the Dynamic Host Configuration Protocol (DHCP) standard and is used to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks. Ordinarily, DHCP scopes provide client configurations by allocating ranges of unicast IP addresses. MADCAP scopes can be used to allocate separate ranges of IP multicast addresses on a standard Windows DHCP server.

Nomad can be configured to use:

  • A MADCAP scope name – where an environment uses multiple MADCAP servers or
  • A specific server IP, scope IP and TTL setting – where the location of a specific MADCAP server is known

This configuration can be done during installation with the MADCAPSCOPE installer command-line argument or post-installation by modifying the MultiCastMADCAPScope registry value.

If company policy prohibits multicast traffic from crossing your routers, you can still benefit from using Nomad multicast. Multicast communication can simply be restricted to each subnet and downloads over the WAN is done once per subnet instead of once per branch. Local multicast is an excellent option for large branches (typically more than 100 computers) as it reduces LAN traffic and the load on the elected Nomad master.

Nomad registers each package it downloads with a key derived from the package name/version. In this way, a unique multicast address is designated for each package advertised using Nomad. The size of the MADCAP scope used should allow for sufficient concurrent package distributions.

To enable multicast to work across your network, you need to open UDP port 2535 in Windows Firewall.

Configuring MADCAP

MADCAP configuration is fairly complex and there are many different implementations of it, so complete coverage is beyond our scope. However, we will instead focus on the specific settings for Nomad.

To enable Nomad and MADCAP to work correctly:

  • Set a short time to live for the Multicast packets.
  • Set a short lease time for the Multicast Scope.
  • Exclude the first Address in the range to enable its use by Nomad. The first address in the range "*.*.*.0" is used by Nomad as a control channel.

Microsoft's implementation of MADCAP is integrated with the DHCP server where you can configure its settings. Our example shows the properties for the SMSNomad multicast scope.

There is a bug in certain versions of the MADCAP implementation where the entire address range gets excluded by default. If this occurs, delete the exclusion and create a new one that just references the first address in the range.

In our example, the start address of should be excluded. This is done as an action on the Address Pool in the MADCAP configuration interface.

Defining the MADCAP scope properties

Control multicast

Nomad is capable of performing control multicast with or without a MADCAP server on the network, although the server is necessary if data multicast is being used. To use this feature, you will need to use the installer argument which configures the MultiCastMADCAPScope registry value on Nomad clients. The notation to use is:


where <MADCAP_ServerIP> is if there is no MADCAP server installed on the network. For example, the notation:,,3

describes a non-existent MADCAP server, a scope of and a time to live of 3 in the registry value.

For more general information about MADCAP and its support in Windows Server versions, refer to the DHCP documentation in the Microsoft Windows TCP/IP Core Network Guidance (