The Peer Backup Assistant (PBA) feature enables files and settings data to be backed-up to a peer computer so that they can be maintained when the computer is being migrated to a new Operating System. Using PBA, you can avoid the cost of specifically provisioning state migration points or servers to hold the backup data, as peer computers can utilized to provide this feature. The risk of losing user data through the migration process is also greatly reduced in the process.

On this page

In this section


The NMDS_POLL argument is available on either the NomadPackageLocator.exe (recommended) or NomadBranch.exe service command-line. When run, it places a request for a network share and size associated with it. It must only be used within a task sequence.


The NMDS_COMPLETE argument is available on the NomadPackageLocator.exe (recommended) or NomadBranch.exe service argument-line. It indicates that all user data has been copied to the PBA share and the connection can be closed. When run, it disconnects from its associated share and fixes its contents for the duration defined in the Nomad PostCompleteTimeoutHours registry value on the machine where the share is hosted. It is only for use within a task sequence.


The NMDS_HA argument is available on the NomadPackageLocator.exe (recommended) or NomadBranch.exe service argument-line. It creates additional backup copies of the user data that has been copied to the PBA share, so it must be run after the share has been closed using NMDS_COMPLETE. It is only for use within a task sequence.


The NMDS_FIND argument is available on the NomadPackageLocator.exe (recommended) or NomadBranch.exe service argument-line. When run, it locates and connects to the share associated with it. It is only for use in a task sequence.


The NMDS_DELETE argument is available on the NomadPackageLocator.exe (recommended) or NomadBranch.exe service argument-line. When run, it deletes the share, contents and user associated with the shared cache. It is only for use in a task sequence.

Secondary PBA backup data store

Support for this configuration is deprecated and is currently provided for backwards compatibility only. Use high-availability PBA instead. The PBA task sequence dialogs do not support this option, therefore some scripting would be required to achieve the same functionality.

The Nomad PBA Task Sequence steps are not designed for use with offline USMT or WinPE.

The -NMDS_POLL command-line option for the NomadPackageLocator.exe tool cannot be used in WinPE.

The -NMDS_<command> command-line options for NomadBranch.exe have not been tested in WinPE so their behavior might be unpredictable in that environment.

An overview of PBA

There are two types of computers involved in the PBA feature:

  • PBA hosts – computers running Nomad that have been configured to host a data store
  • PBA clients – computers running Nomad that ask for PBA data stores by broadcasting a request on the local subnet for suitable hosts. Local PBA hosts respond to these requests and the winner is chosen according to its suitability. 

The host aspect is disabled by default but can be enabled by a Nomad administrator, whereas the client aspect is always available.

PBA mainly integrates into the Configuration Manager task sequence engine – it may also be run independently using Nomad migration data services (NMDS) – so that the process of moving data to peer systems is completely automated during a migration. This is managed by the process which kicks off a local election when initiating a peer storage request. PBA queries other PBA enabled systems on the local network to see if they match the administrator controlled criteria (Is there enough disk space on a system to store the data? Are there other connections already in place? Are disk quotas enforced?) to store the User State Migration Tool (USMT) data.

As these election criteria are evaluated, PBA receives a response if a peer system is able to host the USMT data. If the data can be stored on a peer, PBA will begin the process but only by securing the data location with appropriate NTFS security. PBA notifies the system hosting the backed-up data with appropriate storage timeline settings. By default, the data is automatically deleted after 7 days but this is configurable for longer or shorter periods.

The OS migration proceeds until the state restore phase takes place, at which point PBA locates the backed-up data using a broadcast query and restores the data to the rebuilt or provisioned system (when used in a hardware refresh) and purges it from the host. The diagram illustrates the PBA task sequence actions (in orange) and the data flow (in blue).

PBA Sequence

Single-site PBA

Peer Backup Assistant (PBA) enables Nomad clients to act as equivalents to Configuration Manager state migration points. It sits on top of Nomad's peer communication mechanism which is normally limited to the local subnet and prevents neighboring subnets on the same site from being used for potential Nomad PBA stores. Single-Site Peer Backup Assistant (SSPBA) uses the single-site download features to enable PBA data stores to reside not only on the local subnet but also on nearby subnets. This enables you to:

  • Designate appropriate machines to provide the Nomad PBA data store for all machines on the site, not just the local subnet
  • Avoid the issue where clients on particular subnets do not have sufficient disk space to offer the role of a Nomad PBA data store
This feature replaces previous functionality where the local subnet limit for PBA requests was mitigated by enabling control multicast which resulted in modifying the MulticastSupport registry value to either 2 or 3 and configuring your routers to allow the multicast traffic.

To setup SSPBA, you need to ensure the following:

  • ActiveEfficiency v1.9.700 or later is installed and running successfully (we recommend using the latest version)
  • The ActiveEfficiency database is populated with information about sites and their associated subnets
These Nomad features make use of ActiveEfficiency – SSD, Single-site peer backup assistant, Integrating with WakeUp and Nomad pre-caching. We recommend you use the latest ActiveEfficiency version to benefit from added functionality from these features. ActiveEfficiency installation has information on setting up an instance to work with Nomad.

High-level overview of how to enable Single Site Download (SSD)

The following information applies to both new and existing installations of Nomad. 

  1. Make sure that 1E ActiveEfficiency is installed in your environment.  ActiveEfficiency is included with your Nomad license and is used as a content location metadata repository.  You can view further information here:  AES19
  2. Within ActiveEfficiency, populate the SSD sites and subnet information.  A sample PowerShell script is included in the Nomad installation files.  You can also configure ActiveEfficiency to synchronise with an existing master source, such as Active Directory Sites and Services.
  3. If not configured already, modify HKLM\Software\1E\NomadBranch\ActiveEfficiency\PlatformURL to "http://[servername]/ActiveEfficiency".
  4. Enable SSD on all Nomad agents, by modifying HKLM\Software\1E\NomadBranch\SSDEnabled to 3.  This will enable SSD for both "Provide" and "Consume" modes, specifically Nomad will provide content to other peers and consume content from other peers.
  5. If you already have Nomad installed and are only now enabling SSD, then ensure HKLM\Software\1E\NomadBranch\ActiveEfficiency\ContentRegistration is set to 1. In other words Nomad will register downloaded content with ActiveEfficiency, this is automatically enabled for new installations of Nomad and SSD.

Building a subnet profile in ActiveEfficiency

For ActiveEfficiency to build a subnet profile for SSD and the peer backup assistant feature, Nomad must communicate with its web service. When the Nomad service starts, it connects and registers the hosting device by name with ActiveEfficiency which returns a device ID in the form of a GUID that enables it to uniquely identify the Nomad machine and its default subnet.

If it is unable to communicate with the ActiveEfficiency web service, it retries every 5 minutes until it succeeds (as long as SSD is enabled). An attempt to communicate with ActiveEfficiency is also made prior to a package download to register its status.

The following points should be noted:

  • On a multi-NIC host, only one NIC gets registered and a wired interface takes precedence over a wireless interface during registration.
  • If Nomad fails initially to register an adapter, it retries every 5 minutes (for as long as SSD is enabled) until it succeeds.
  • Wireless adapters can be configured to act as SSD content providers and consumers. Use the ContentProviderOnWiFi registry setting to do this.
  • If the initial device registration was successful when the Nomad service started but the ActiveEfficiency web service later becomes unavailable, when Nomad subsequently downloads and caches a package it will not be able to register the package with ActiveEfficiency (see below for details). Nomad does not re-attempt package registration, so ActiveEfficiency will not know that this particular Nomad host has the package.

Configuring the Single-Site Download feature in the ActiveEfficiency documentation takes you through the setup process. There are also example PowerShell scripts for retrieving information about sites and their associated subnets from the AD and how to add these to ActiveEfficiency. Information about sites and subnets are typically obtained from the AD but you are free to get this information by other means.

Enabling SSPBA

SSPBA can be enabled at install time using the SSPBAENABLED installer property. Post-installation SSPBA can be enabled by setting the following registry values:

  1. Update the SSPBAEnabled registry value to 1.
  2. Update the SSDEnabled registry value to 0x3 to enable ActiveEfficiency integration required for this feature to work.

When SSPBA is enabled, PBA will initially attempt to find suitable PBA data stores on the local subnet. If it does not find one, it will send the request to neighboring subnets using the information held in ActiveEfficiency.

High-availability PBA

High-availability is implemented with the custom finalize Nomad PBA store task sequence action and requires no configuration of the underlying Nomad system. HAPBA ensures that USMT data is stored and made available on multiple machines during the migration process to minimize risk and maximize success. Implementing HAPBA enables you to:

  • Save USMT data in multiple locations (up to a maximum of 6) to help mitigate risk during migration
  • Save USMT data without the need to regenerate it using the USMT save action

Backups can be created synchronously or asynchronously. The administrator can set a value in the task sequence action that specifies the number of backups that must be successfully implemented synchronously before the task sequence continues; the remainder of the backups will be performed asynchronously while the other task sequence actions are running. This helps you manage the balance between enabling the task sequence to run promptly while ensuring sufficient backups are in place to maximize the chances of success.

HAPBA also works with SSPBA to enable the backups to reside on machines local to the site but external to the subnet of the machine being migrated.

Note: if the task sequence variable 1EDisablePBA_HA = True, then High Availability is disabled. This variable is automatically set for Remote WSA deployments

Configuring PBA hosts

To configure a suitable Nomad client in the local branch to be a potential Peer Backup Assistant (PBA) host:

  1. Under the NomadBranch\NMDS registry key, update the MaximumMegaByte registry value to the maximum combined size of the caches you want the PBA host to support. The default value is 0 which means that Nomad clients will not reply to PBA requests.
  2. Modify other PBA NMDS registry values to suit your environment and usage.

You can configure a number of computers in a branch to be PBA hosts for scalability.

Using PBA with Configuration Manager task sequences

To integrate PBA into a Configuration Manager migration task sequence for a computer targeted to get a new OS:

  1. Choose Nomad's estimation or provide a static estimate to reserve a minimum amount of disk space for user data retrieved with the User State Migration Tool (USMT) on the target computer. USMT is a Microsoft command-line utility program that integrates with Configuration Manager task sequences to transfer user files and settings between computers. For suggestions of how to estimate the migration store size see Microsoft's article on estimating migration store size.
  2. Use the provision Nomad PBA data store task sequence action to provision a data store with the name of the computer being migrated and the estimated size of the USMT data. It broadcasts a request on the local subnet, and any of the locally configured PBA hosts will respond if they have the estimated space available in their PBA store. The task sequence also stores the location of the winning PBA host and share using the %NMDS_REMOTE% variable into the OSDStateStorePath task sequence variable.
  3. Backup the USMT data to the stored share, using the USMT Capture User State task sequence action.
  4. Use the finalize Nomad PBA data store task sequence action to close the data store. This tells the PBA host that the copy is completed and disconnects from it.
  5. For increased security, create extra copies of the backed-up USMT data using HA features of the finalize Nomad PBA data store task sequence action. 
  6. Migrate the target computer to the new OS.
  7. Use the locate existing Nomad PBA data store task sequence action to locate an existing data store with the name of the computer being migrated. This finds the PBA host that holds the named data store on the local subnet and creates a connection to it for retrieving the data.
  8. Restore the USMT data from the data store on the located PBA host, using the USMT Restore User State task sequence action.
  9. Use the release Nomad PBA data store task sequence action to release the data store with the name of the computer being migrated.

PBA NMDS commands

The PBA task sequence actions use some underlying NomadBranch.exe command-line arguments to implement their actions which are invoked using a NomadPackageLocator.exe wrapper to set task sequence variables that NomadBranch.exe relies on. So of the two CLIs, NomadPackageLocator.exe is the preferred and safer interface to use. We recommend that you only use PBA task sequence events but if you want to use these commands outside a take sequence, the table below details the equivalent.

In addition to these commands, the following registry values can be updated to define the behavior of PBA on the computers that are to be used as hosts for PBA data stores. These registry values are only required on PBA hosts where the data store resides and not on PBA clients requesting the store.

In Nomad 5.0.100 and later, the NMDS registry value is created during installation. The instructions that follow show how to enable and disable the PBA feature.

To enable a computer to be a PBA host in Configuration Manager 2012 systems, modify the MaximumMegaByte registry value under: HKLM\Software\1E\NomadBranch\NMDS

Enabling NMDS

The MaximumMegaByte registry value is set to 0 by default which means the Nomad clients will not reply to PBA requests. To enable a Nomad client to be a PBA host:

  1. On the host, update the MaximumMegaByte registry value to the maximum amount of space in MB that can be used for all the PBA data stores combined
  2. Restart the NomadBranch service.

Disabling NMDS

To disable PBA:

  1. Update the MaximumMegaByte registry value to 0.
  2. Restart the NomadBranch service.

NMDS registry values

The following registry values relate to PBA and are set in HKLM\Software\1E\NomadBranch\NMDS on 32-bit systems and in HKLM\Software\Wow6432Node\1E\NomadBranch\NMDS on 64-bit systems:

Nomad installer command-line arguments

The following installer arguments can be set on the Nomad installer command-line to configure NMDS:

Using PBA from a client

The following illustrates the high-level order that the PBA is initialized, used and completed from the client.

  1. Run the NMDS_POLL command from the PBA client that requires a network share to store its data. This requests a named PBA share on the local subnet. The locally configured PBA hosts will hold an election to decide the PBA host for this request.
  2. Copy files to the network share created on the winning PBA host.
  3. Run the NMDS_COMPLETE command from the PBA client that requested the share. This tells the PBA host that the copy to the named share is been completed and disconnects from it.
  4. Optionally, create extra backups by running NMDS_HA.
  5. Perform the OS refresh.
  6. Run the NMDS_FIND command from the PBA client that requested the share. This locates the PBA host that holds the named share on the local subnet.
  7. Copy files from its share.
  8. Run the NMDS_DELETE command from the PBA client that requested the share. This deletes the named share from the PBA host.

More details on the NomadBranch.exe commands can be found here. NomadPackageLocator.exe can also accept the PBA NMDS commands but it invokes NomadBranch.exe to do the work.