Introducing Nomad 6.3
Working with Nomad
Deploying Office 365 updates
Integrating with WakeUp
Managing large package distribution with multicast
Nomad Download Pause
Peer Backup Assistant (PBA)
OS deployment task sequences
The Download Monitor
The Nomad Baseline Wizard
- Client health
- Core features
Operational best practices
Frequently asked questions
- Feature Reference
Technical support for Nomad
Nomad integration with WakeUp enables Nomad to share content from its machines that are holding particular content, even if those machines are shut down.
On this page
When a Nomad client wants to download content, it does so in the following order:
- Broadcasts a request for peers in the local subnet.
- If no peers respond and if single-site download (SSD) is enabled, queries ActiveEfficiency for peers on other subnets for the content.
- If no peers exists or if SSD is not enabled, it downloads from the DP.
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.
Architecture and ports
|TCP 80 (HTTP)|
Step 1Nomad 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 80 (HTTP)
Step 2Without 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:
For Configuration Manager 2012 the default setting is HTTP or HTTPS.
|TCP 1801 (MSMQ)|
Step 3ActiveEfficiency posts the wake message from Nomad to MSMQ for the NightWatchman Management Center to retrieve.
Step 4NightWatchman Management Center tells the WakeUp server to wake the requested machines
Step 5WakeUp Server signals the WakeUp Agent on the appropriate subnet to wake the requested machines
Step 6The 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 7As 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.
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:
- Highest percentage of content.
- 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.)
- 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.
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.
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.
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
WakeUpMinPackageSizeMBis 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
Locationstable in the ActiveEfficiency database must be populated. In other words, the
Locationstable 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.