Nomad integration with WakeUp enables Nomad to share content from its machines that are holding particular content, even if those machines are shut down. One reason why peers in the local subnet may not respond to the request even though they have content in their caches is that they are offline (shutdown, in hibernate or sleep mode). However, if WakeUp is integrated, the Nomad client would know which offline machine has the content and can wake it up when it queried ActiveEfficiency. The wake up list is maintained by ActiveEfficiency and is the same list that SSD uses. Separate lists of peers are returned for subnet and site. This feature requires Nomad SSD to be enabled, an ActiveEfficiency server and a NightWatchman infrastructure. The feature is enabled during installation of NightWatchman Management Center. Please refer to the Nomad  Preparation  for requirements. 

On this page:

Architecture and ports



Step 1

Nomad Master contacts ActiveEfficiency and gets a list of Nomad machines that hold the content it requires. Nomad sends a request to wake the top 5 machines on the list.

TCP 139 (SMB)
TCP 445 (SMB over TCP)

Step 2

Without waiting for any machines to be awoken the Nomad master starts to download content from the DP. This communication depends on how the DP is configured. It may be one of the following:
  • HTTP
  • SMB
  • SMB over TCP

For Configuration Manager the default setting is HTTP or HTTPS.
TCP 1801 (MSMQ)

Step 3

ActiveEfficiency posts the wake message from Nomad to MSMQ for the NightWatchman Management Center to retrieve.

Step 4

NightWatchman Management Center tells the WakeUp server to wake the requested machines
TCP 1776

Step 5

WakeUp Server signals the WakeUp Agent on the appropriate subnet to wake the requested machines
UDP 1776

Step 6

The WakeUp agent on the subnet sends a wakeup request to the requested machines
TCP 139 (SMB)
TCP 445 (SMB over TCP)
UDP 1779 (connectionless P2P)

Step 7

As part of its standard behavior Nomad holds regular elections (every 5 minutes) to determine the most appropriate master. If a machine is found (i.e. one that has been recently awoken) that holds more of the required content, it stops downloading from the DP and fetches the content from the new machine's cache. This may be via SMB or via connectionless P2P, depending on the configuration of Nomad.

How it works

When a Nomad client wants to download content it broadcasts a request for peers in the local subnet, if no peers respond then:

  1. If single-site download (SSD) is enabled, it queries ActiveEfficiency for peers on other subnets for the content.
  2. If SSD is not enabled, it downloads from the DP.

WakeUp integration can be for:

  • Peers on the local subnet
  • Peers in the site (i.e. neighboring subnets not the local subnet)
  • Peers on the local subnet and in the site

These lists are sorted in descending order by:

  1. Highest percentage of content.
  2. Server, followed by desktop, then laptop. (for Nomad's purposes, whether a machine is a server or a desktop depends on the operating system, not the hardware.)
  3. Most recent timestamp on the content (because recent information is more likely to be correct than older data).

Nomad sends a wake up request to ActiveEfficiency which relays it through NightWatchman Management Center to WakeUp servers and ultimately the 1E agents to wake these machines up. These requests are encrypted, contain an authentication token to prevent spoofing and timestamped so that they are discarded if the requests are delayed by more than 10 minutes as there is probably no point in waking up any peers as the content will probably have been completely fetched from the DP.

Nomad does not wait for machines to wake at this point. It carries on immediately after sending the wake up requests and starts downloading from the DP. Nomad also uses a fire and forget policy: it does not keep track of which machines do and do not get woken.

Meanwhile, periodic elections occur and when a master is elected, the download from the DP is interrupted and the download process begins again. The difference this time is that Nomad will not query ActiveEfficiency again as some subnet and/or site machines will have woken up and is able to provide the content.

In addition, ActiveEfficiency will not return devices that do not match the following criteria:

  • The network adapter registered for the device matches the criteria for local subnet or site wakeups
  • Device must be enabled as a content provider
  • Device is not an unknown machine

Reasons for not being a content provider are:

  • Running under WinPE
  • A domain controller
  • Content not to be registered with ActiveEfficiency (ContentRegistration = 0)
  • Peer-to-peer communication disabled (P2PEnabled = 0)
  • Sensitive server (P2PElectionWeight = 0)
  • SSDEnabled = consumer-only
  • Using wireless adapter (so cannot be woken)
  • Inhibited subnet being used
  • Inhibited AD site being used

Batching WakeUp requests and other configuration

WakeUp can be enabled for just the local subnet, the site (of neighboring subnets), or both. This is configured by the WakeUpEnabled setting. Note that if site wake up is required, then SSD consumer mode must also be enabled (SSDEnabled is 1 or 3).

If WakeUp integration is enabled, the number of machines in each list (subnet and site, separately) is specified by MaxDevicesFromAE.

Not all devices need be woken at once. After all, it is desirable to awaken as few devices as necessary because they were shut down in the first place for a good reason – to save power. They can be collected into batches (separately for subnet and site wake ups), controlled by the WakeUpBatchSize setting.

By default, this is the same as MaxDevicesFromAE so there is usually just one wakeup iteration. But if WakeUpBatchSize is less than MaxDevicesFromAE (obviously it cannot be greater), then some devices will be left over after the first batch of wake ups has been sent (assuming that at least MaxDevicesFromAE devices were actually found in ActiveEfficiency), and these remainders will be woken if Nomad falls back to the DP on its second and subsequent periodic elections.

MaxDevicesFromAE and WakeUpBatchSize are applied to the subnet and site lists separately, but different values for site and subnet cannot be specified – the same are used for both. For example, if MaxDevicesFromAE is 10 then up to 20 devices will be fetched (if there are sufficient registered in ActiveEfficiency with the content), 10 for the subnet plus another 10 for the site.

Finally, if the content is small then there might not be time for a periodic election to occur, because Nomad gets everything from the DP in the first iteration. In this situation, there is no point waking up machines because they will not be ready in time. For this reason the WakeUpMinPackageSizeMB setting controls the lower cutoff size limit at which wake ups occur.

Support for Nomad running under WinPE

WakeUp integration, like SSD, can be used when running under WinPE to download the full operating system. WakeUp is particularly useful in this case because OS .wim files tend to be large. WakeUp integration is not enabled by default. This example shows a task sequence action where it has been enabled.


  • Nomad running under WinPE cannot use wake up if Windows authentication is enabled in ActiveEfficiency. This is because a WinPE machine is not in a domain
  • The WakeUpMinPackageSizeMB setting is effectively always 0 in WinPE and for standalone Nomad downloads, so WakeUp will be invoked even for small packages. This is because the size of the content cannot be easily determined (under normal conditions the size can be found from Configuration Manager policy. And in the situations where WakeUpMinPackageSizeMB is used, even if enough of a package has already been downloaded to take it under the limit, wake up requests are still sent.
  • Even if just local wake up is used (i.e. within the local subnet but not the site), the Locations table in the ActiveEfficiency database must be populated. In other words, the Locations table must always be configured for Nomad WakeUp integration to work.
  • If, when a periodic election occurs, a different master host is elected, the whole WakeUp process starts again, i.e. the new host queries for devices with the content and the batched wake up requests start from the beginning. However, in practice, if a given host gets elected as master, it is very likely to be re-elected when a periodic election occurs. Also, if a master is shut down while a transfer is running, when it is restarted it will start the WakeUp process again.
  • The mechanism does not support alternate source copy downloads, i.e. downloading an older version of a package from a LAN neighbor then filling in the changes.
  • IPv6 is not supported.