Get Migration Settings
Provides support for optional encryption in Nomad PBA, and Provides computer association details in 1E Application Migration. Used in computer Replace and Refresh (Wipe and Load destructive and non-destructive) scenarios, it is configured to run under either the capture phase or the restore phase, depending on the scenario.
Note
It is independent of 1E Nomad PBA task sequence actions but is designed to be used in conjunction with them.
This custom action is available in the 1E Nomad task sequence actions.
Actions | When run, this task:
The end result of successful execution is the following three variables are set:
| |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Context | 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. Replace Scenarios 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. Operation Get Migration Settings is designed to support both the Replace and Refresh (Wipe and Load) 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 Refresh (Wipe and Load), 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. NoteThe method of generating an encryption key depends on the deployment scenario, summarized in the following table.
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 scenarios. The Get Migration Settings step can operate in one of 2 modes: Capture and Restore. Mode is set in the step UI. In Capture mode, the step is inserted prior to the Capture User Files and Settings step, and will typically reside in the Capture User Files and Settings group. This is used for Replace Capture and Wipe and Load task sequences. In Restore mode, the step is inserted prior to the Restore User Files and Settings step, and will typically reside in the Restore User Files and Settings group. This is only used for a Replace Restore type task sequence. It is not required for Wipe and Load task sequences. ForWipe and Load Non-Destructive task sequences, 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.
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 Installing Nomad Branch Tools 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 Configuration Manager 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 Configuration Manager 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. | |||||||||||||||||||||||||||||||||||
Associated variables |
| |||||||||||||||||||||||||||||||||||
Configurable parameters |
| |||||||||||||||||||||||||||||||||||
Notes | Get Migration Settings contacts Content Distribution via the proxy feature of the Tachyon Background Channel. It gets the URL for the Background Channel from the Nomad registry PlatformURL setting, which is configured automatically by Nomad on startup by querying the value that the Tachyon client is using (stored in the 1E.Client.conf file). | |||||||||||||||||||||||||||||||||||
