Provides support for encryption in PBA. Also enables PBA to be used for computer replace scenarios. This task can be configured to run under either the capture phase or the restore phase. Its behavior differs depending on which phase it's run under.
|Actions||When run, this task:|
Get Migration Settings integrates with Nomad Peer BackUp Assistant (PBA), providing a cryptographic key that can be used to secure captured user data stored on a PBA host. For WSA type deployments, it is also possible for user data to be encrypted and stored onto USB media, if PBA is not available. Step behaviour will depend on user requirements and deployment scenario.
Before describing the operation of Get Migration Settings fully, a brief explanation of the different deployment scenarios in which the step operates is provided.
This is where the user is being migrated to new or replacement hardware. A computer association in ConfigMgr is a native object that defines the logical relationship between the old and new computer. When the computer association is created in the site, an encryption key is automatically created and stored in the site database.
In this scenario, the step will attempt to identify the appropriate computer association in order to obtain the key. For non-WSA type deployments, the presence of a valid computer association is mandatory and the step will fail if it is not found. WSA deployments also allow users to enter the name of the new computer at the time the Assistant runs, forgoing the need for the pre-provisioned computer association.
Wipe and Load
A Wipe and Load can be destructive (disk reformat and data loss) and non-destructive (file level wipe of the disk where areas of the file system can be preserved). Wipe and Load non-destructive user state capture utilizes file system hard links and therefore does not require external storage or data encryption.
Wipe and Load destructive requires user data is saved off onto another device (Nomad PBA) or external device before reformat of the disk (USB media can be used as an alternative to Nomad PBA when using WSA). For this scenario, a ConfigMgr Computer Association is not used. Get Migration Settings will itself generate a unique encryption key based upon the ConfigMgr client identifier and AES 256 hashing algorithm. The key is stored in the task sequence environment for access during capture and restore in the native variable OSDStateEncryptDecryptKey.
Get Migration Settings is designed to support both the Replace and Wipe and Load (Refresh OS) deployment scenarios. The step's behaviour is different depending on deployment scenario. The step, by default will assume a Replace scenario. In order to operate for Wipe and Load (Refresh OS), the task sequence variable DEPLOYMENTTYPE = REFRESH, must be set prior to executing the step.
As well as provisioning the USMT encryption key, the step is also responsible for instantiating TS variables SourceComputerName and PBAComputerName. During the restore process, the source machine name is used to identify the location of captured user data if using Nomad PBA (PBAComputerName) as well as resolving the list of applications to install as defined by 1E Application Migration (SourceComputerName).
By default, the step will attempt to provide a key for encryption of captured user data.
The following is new functionality in Nomad 6.3.200
All WSA type deployments require Nomad 6.3.200 and above
Task sequence position
The table below indicates the use of the step for different deployment sc enarios. The Get Migration Settings step can operate in one of 2 modes: Capture and Restore. Mode is set in the step UI. For a Replace Capture and Wipe and Load task sequence, the step must be used in Capture mode and inserted into the TS prior to the Capture User Files and Settings step. For Wipe and Load, having implemented the step in Capture mode, it is not necessary to insert the step again before the Restore User Files and Settings step. Typically, in Capture mode, the step will reside in the Capture User Files and Settings group.
For a Wipe and Load Non-Destructive task sequence, the step does not provision an encryption key as file system hard-links are used negating any requirement for secure storage, in this case the step will only set the SourceComputerName variable for use in 1E Application Migration.
The step must be used in Restore mode for a Replace Restore type task sequence. The step must be positioned before the Restore User Files and Settings step. Typically, in Restore mode, the step will reside in the Restore User Files and Settings group.
If you need to recover the key generated by the step (perhaps your Wipe and Load Destructive or Replace Restore TS failed before restoring the user data) you can do so using the command line tool 1eUsmtKeyGen.exe. This tool is part of Nomad Configuration Manager console extensions and is installed at location <ProgramFiles>\Microsoft Configuration Manager\AdminConsole\bin\NomadBranchAdminUIExt. It can be called via the Windows Console as shown below:
It takes the SCCM client guid of the source machine as an argument and generates the exact key that would have been generated during the TS. To know the SCCM client guid of any computer, please consult the 'SMS_Unique_Identifier0' column in the view 'dbo.v_R_System' of the config manager database.
While entering the argument, please remember that:
The generated key will be printed in base64 format on the Windows Console. You can copy it and use it as is with the usmt "/key" option to recover the user data.