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 State Migration Point servers to hold the backup data, as peer computers can be used to provide this storage. The risk of losing user data through the migration process is also greatly reduced in the process.
On this page
In this section
There are two types of computers involved in the PBA feature:
The host aspect is disabled by default but can be enabled by a Nomad administrator, whereas the client aspect is always available.
The PBA feature is implemented in the Configuration Manager OS deployment process using custom Task Sequence steps that complement the built-in Capture User State and Restore User State steps to completely automate the migration of user data and settings using available storage on peers during an OS refresh or computer replacement.
The initial step in the process initiates a local election to request the required amount of storage space from peers. Peers that are configured to act as PBA Hosts will respond to this election if they match the administrator-defined 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.
The requesting system will then evaluate the responses and selects the best candidate. The selected host then reserves the storage space. When the Capture User State step has completed, PBA transfers the migration data to the selected host, where it is stored ready to be restored later in the Task Sequence. Data can be encrypted using the built-in encryption capability of the User State Migration Tool that is behind the scenes in the Capture User State step. At this stage, Nomad can transfer copies of the data to other peers (High Availability feature) to increase the availability of the data should any of the hosts go offline before the data has been restored.
The OS deployment 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 device and deletes it from the host. The diagram illustrates the PBA task sequence actions (in orange) and the data flow (in blue). If for any reason the restore step is not executed or fails, the migration data will remain available on the host(s) for 7 days (configurable), after which it will be deleted.
Peer Backup Assistant (PBA) enables Nomad clients to use local storage on peers to temporarily store user state data during an OS deployment, removing the need for Configuration Manager State Migration Points. By default is uses network broadcasts to identify peers with available storage on the local subnet. Single-Site Peer Backup Assistant (SSPBA) uses the single-site download features to enable Nomad to use storage available on PBA hosts in adjacent subnets. This enables you to:
To setup SSPBA, you need to ensure the following:
SSPBA can be enabled at install time using the MODULE.NOMAD.SSPBAENABLED installer property. Post-installation SSPBA can be enabled by setting the following registry values:
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 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:
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.
|If the task sequence variable 1EDisablePBA_HA = True, then High Availability is disabled. This variable is automatically set for Remote WSA deployments.|
To configure a suitable Nomad client in the local branch to be a potential Peer Backup Assistant (PBA) host:
NomadBranch\NMDSregistry key, update the
MaximumMegaByteregistry value to the maximum combined size of the caches you want the PBA host to support. The default value is
0which means that Nomad client will not reply to PBA requests.
You can configure a number of computers in a branch to be PBA hosts for scalability.
By default, Nomad uses Windows file shares to share content and PBA storage with peers over SMB. You can configure Nomad to use HTTP or HTTPS to avoid the use of file shares and SMB (refer to Peer copy over HTTP or HTTPS). When Nomad is configured to use Peer copy over HTTP or HTTPS, a file share is not created. In this scenario the storage is exposed to peers through the HTTP server implemented in Nomad for sharing its cache. A local user account is created to secure access to the migration data store through Windows authentication.
When Nomad is configured to use HTTPS for peer-to-peer communication, you can optionally enable Certificate-basedAuthentication. In this scenario a local user account is not created. Access to the user state store is authenticated using a client certificate.
To integrate PBA into a Configuration Manager migration task sequence for a computer targeted to get a new OS:
%NMDS_REMOTE%variable into the
OSDStateStorePathtask sequence variable.
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 Command-Line Interfaces,
NomadPackageLocator.exe is the preferred and safer interface to use. We recommend that you implement PBA using the custom PBA Task Sequence steps described above, but for reference the table below identifies the commands that are executed by these steps.
|Task sequence step||NomadBranch command-line arguments|
|Peer backup assistant – provision Nomad PBA data store||NMDS_POLL|
|Peer backup assistant – close Nomad PBA data store||NMDS_COMPLETE|
|Peer backup assistant – high-availability||NMDS_HA|
|Peer backup assistant – locate existing Nomad PBA data store||NMDS_FIND|
|Peer backup assistant – release Nomad PBA data store||NMDS_DELETE|
In addition to these commands, the following registry values can be updated in
HKLM\Software\1E\NomadBranch\NMDS 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.
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:
MaximumMegaByteregistry value to the maximum amount of space in MB that can be used for all the PBA data stores combined
To disable PBA:
MaximumMegaByteregistry value to
The following installer arguments can be set on the Nomad installer command-line to configure NMDS:
The following illustrates the high-level order that the PBA process is initialized, used and completed during Task Sequence execution.
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.