If you want to make more efficient use of your network when distributing the same data to many end-points, 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.

On this page

Nomad multicast requires a separate license and is available on a 30 day evaluation.

Your networks 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 implementation results in efficient distributions to large numbers of clients.

Comparisons of transfer methods

Network implementations vary widely and are complex. The sections below describes the basic features of each transfer method and the conditions that best suit each of these.

Not using Nomad

If you are not using Nomad to manage your downloads, the DP is likely to be saturated with requests and large amounts of redundant transfers being made across the WAN as each target machine 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 machine. There is a limitation of six concurrent connections for a workstation but is unlimited for a server, though this limitation on workstations can be alleviated using Nomad FanOut.

Local multicast

Local multicast is designed to reduce LAN network traffic at the branch and reduce the load on the elected Nomad master machine.  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 clients on a subnet with no local DP – multicast is the most efficient mechanism when there are a large number of 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 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 clients – due to the method of file transmission multicast is most efficient when there are a large number of 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 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.

Guidelines for using multicast

We have some guidelines to help you decide which transfer method to use in your evaluation or production environment.

Scenario 1

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 far outweigh the overhead as it results in efficient distributions to large numbers of clients.

Peer-to-peerLocal multicastCentral multicast
 Alternative transfer method. Likely to provide efficient re-distribution on the branch network.Recommended transfer method. Likely to be the most efficient means of distributing large packages across the entire network

Scenario 2

Large branch networks – WAN multicast not allowed

Peer-to-peerLocal multicastCentral multicast
 Recommended transfer method. Likely to provide the most efficient means of locally re-distributing large packages once they have been downloaded over the WAN. 

Scenario 3

Large branch networks with multiple subnets

Peer-to-peerLocal multicastCentral multicast
 Alternative transfer method. Likely to provide efficient re-distribution on the branch network.

Recommended transfer method. Likely to provide the most efficient utilization of the WAN link and distribution throughout the branch network.

Scenario 4

Small branches less than 100 computers

Peer-to-peerLocal multicastCentral multicast
Recommended transfer method. Simple to implement and may provide the most efficient transfer of data.  

Scenario 5

Internet distribution

Peer-to-peerLocal multicastCentral multicast
If the local branch is small, this is likely to provide the most efficient method of local re-distribution.If the local branch is large, this is likely to provide the most efficient method of re-distribution.Usually not applicable as it is likely that multicast over intervening routers are liable to be disabled by the ISPs.

Setting-up central multicast

To setup central multicast:

  1. Set up a Configuration Manager package to use Nomad and update the Configuration Manager DP.
  2. Deploy the package for some point in the future – this window must be farther than the Configuration Manager poll interval.
  3. On the Configuration Manager DP, run this command-line referencing the deployment ID.

    %ProgramFiles%\1E\NomadBranch\NomadBranch.exe -central=<AdvertID>

When the deployment is sent to each target machine, the local Nomad joins its machine 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 2012, 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)

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 machines 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. Machines 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 machine 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 client machines
  • Influence the election weighting for laptops so that they are not considered as candidates for a master
  • Synchronize client downloads so that they are all 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 2003 or 2008 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 machines) 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.

Defining the MADCAP scope properties

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.

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 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 2000/2003/2008, refer to the DHCP documentation in the Microsoft Windows TCP/IP Core Networking Guides.

Multicast is not supported when a device is only on a wireless connection.