Skip to main content

1E 23.11 (SaaS)

Integrating Nomad with WakeUp


Nomad integration with WakeUp is deprecated from 1E platform v23.11

Nomad integration with WakeUp enables Nomad to share content from its devices that are holding particular content, even if those devices are offline. 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 device has the content and can wake it up when it queried Content Distribution.

The wake up list is maintained by Content Distribution and is the same list that Single Site Download (SSD) uses. Separate lists of peers are returned for subnet and site. This feature requires Nomad SSD to be enabled, Content Distribution and a NightWatchman infrastructure. The feature is enabled during installation of NightWatchman Management Center. Please refer to Nomad Preparation for requirements.

Nomad and WakeUp architecture and ports
Nomad and Wakeup Architecture





Step 1

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

Refer to WakeUpBatchSize for details about how you can set the maximum number of machines to wake up in a single call.



TCP 139 (SMB)

TCP 445 (SMB over TCP)

Step 2

Without waiting for any devices 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.



Step 3

Content Distribution posts the wake message from Nomad to the NightWatchman Management Center Web API.


Step 4

NightWatchman Management Center tells the WakeUp server to wake the requested devices.

TCP 1776

Step 5

WakeUp Server signals the WakeUp Agent on the appropriate subnet to wake the requested devices.

UDP 1776

Step 6

The WakeUp agent on the subnet sends a wakeup request to the requested devices.

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 device 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 device'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 Content Distribution 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, in the site (i.e. neighboring subnets not the local subnet), or 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 device 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 Content Distribution, which relays it through NightWatchman Management Center to WakeUp servers and ultimately the 1E agents to wake these devices up.


Nomad does not wait for devices 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 devices 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 Content Distribution again, as some subnet and/or site devices will have woken up and is able to provide the content.


In addition, Content Distribution 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 device.

Reasons for not being a content provider are:

  • Running under WinPE

  • A domain controller

  • Content not to be registered with Content Distribution (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 devices 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 Content Distribution), 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 Content Distribution 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 devices 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.


Please note the following restrictions.



Nomad running under WinPE cannot use wake up if Windows authentication is enabled in Content Distribution.

This is because a WinPE device 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 Content Distribution database must be populated.

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.

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.