The most common issues are listed below. Late-breaking information can be found in the online Help.

Communication issues

From Nomad version 6.0, there are two methods for encrypting its communications. The default is compatible with earlier versions; the advanced encryption method is FIPS compliant and may be used in high-security environments where restrictions on encrypted algorithm types are enforced. These two methods are incompatible, so you must ensure that all installations of Nomad are using the same encryption method.

In a scenario where Nomad is being upgraded from an earlier version to version 6.0, there may be an interim period where the old encryption method is being used to maintain compatibility with the older clients. When all the clients have been upgraded, a wholesale switch to the newer FIPS compliant encryption method can be carried out. It is possible that some systems may be overlooked during this process. Should this is the case, the NomadBranch.log will display messages similar to the following when a Nomad peer receives a message from another Nomad peer running a different encryption method:

Nomad firewall settings

By default, Nomad uses port 1779 to communicate during the election process for determining the master on a subnet. This port is opened during the Nomad installation, however further action may be required in environments which use alternative firewalls, other than the native Windows Firewall. The following command-line opens the port for access:

> netsh firewall set portopening udp 1779 NomadBranch
If you change the default port, ensure all Nomad clients are communicating on the same port.

P2P HTTP(S) firewall settings

If you're using HTTP or HTTPS as the protocol for P2P content transfer, then you'll also have to ensure there are firewall exceptions for TCP port(s) specified in settings P2PHttpPort or P2PHttpsPort.

Please note that Nomad service automatically tries to add required firewall exceptions on startup. So if you experience firewall problems, most times it may be enough to simply restart Nomad service and it'll add the missing exceptions.

File and print sharing

For best results, Nomad shares data with peer machines using file sharing – File and print sharing services must be enabled. If it is not available (the server service) Nomad can be configured to work in a connectionless mode either during installation using the P2PENABLED installer property or post installation by setting the P2PEnabled Nomad registry value.

Dynamic Block Size

In Nomad 6.3 the Dynamic Block Size (DBS) feature is enabled by default. If you encounter any issues that you think might be related to the use of DBS you can turn on debugging to see how this feature is behaving in your environment. To do this you will need to create the DebugDynamicBlock registry entry and set the debug level you want - 0x1 for basic level and 0x3 for verbose level, which includes 0x1 and 0x2. You should only set debug on in extreme circumstances as it may impact the efficiency of Nomad. Once you have finished debugging set the value to 0x0 to turn debugging off.

Package version changes

Nomad has significant built-in logic to ensure that package version updates are handled and recoverable. However in complex environments with many package version changes happening whilst software distributions are in progress, unexpected behavior may occur. To increase software distribution success, ensure the following:

  • Minimize unnecessary package version updates
  • Avoid package version updates when active advertisements are running for that package
  • Wait until all distribution points have been updated prior to advertising
  • If failures occur, update the distribution points and re-advertise.


Multicast is a reasonably complex technology, providing complete troubleshooting steps are beyond the scope of this topic, but the following provides some general pointers for IT administrators already familiar with multicast and configuring network environments:

  1. Check that the Multicast scope has been discovered, this can be done by looking in the NomadBranch.log file (details on the location of this file are provided in Technical Support for Nomad) – any timeouts reported at this stage will prevent Multicast from working.
  2. Windows firewall – make sure that UDP on port 1779 is allowed.
  3. Run the performance monitor – this can accurately chart the UDP Packets sent against packets received on a per machine basis and does not need installation.
  4. Managed switches –  check out the information that is available from the managed switch, typically it will have a web interface and will be able to show statistics and load histograms. Typically, switches can also show most used ports and differentiate between UniCast, Broadcast and Multicast traffic.
    • Ensure IGMP snooping is enabled (if available).
    • Turn network switch flow control off – 802.x flow control can reduce Multicast to the speed of the slowest device on the network.
    • In a mixed network environment where the majority of clients are connected to 100Mb (or even 1Gb switches), filter out any lower speed (for example, 10Mb) devices so that they don’t get saturated with unnecessary packets – this is the best way to check that Multicast is only going to those ports that require it.

To test multicast:

    1. Synchronize machine clocks before tests (this is important if logs need comparing).
    2. Automatically collect and clear logs (possibly using a Configuration Manager Job) after each sequence of tests – rename log to <MachineName>_Nomad.log as part of this process.
    3. Do not try to test Multicast on virtual machine based environments. Multicast technology is not well suited to delivering to multiple virtual machines running off a single network card.
    4. To make best use of Multicast, Configuration Manager packages need to be synchronized to start at the same time.

Cannot enable Nomad for a Configuration Manager Client package (in the Configuration Manager Console)

The built-in Configuration Manager Client package in Configuration Manager is locked, and therefore does not allow any modifications to be made to the package. In this instance, it is good practice to duplicate the existing client package for use with Nomad (for example, in OSD task sequences).

Verifying the speed or bandwidth utilization of a recent Nomad download

If you have the Nomad Download GUI already installed on the computer, you can use it to monitor the current download job in Nomad.

To review the download speeds of a recent Nomad download, open the NomadBranch.log file and locate the log entries related to the download job, taking specific interest of the blk/s values, as shown in the log extract below:

Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=85 (blk/s=6) 
Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=88 (blk/s=3) 
Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=95 (blk/s=7) 
PkgCacheStatusSet Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d(1) Format:0 12.553%
Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=99 (blk/s=4) 
Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=105 (blk/s=6)
Remote_http   0100007F 9000 "Content_fe7d375d-c77c-4776-88e7-232b9d2ee65d_Cache\Command_Monitor_x64.msi" blk=108 (blk/s=3)

The blk/s refers to the number of blocks downloaded per second. The default block size is 32768 bytes, so blk/s=6 equates to 196,608 bytes per second (or 192KB/s). It is important to be aware that the Nomad block size can change.