Get Migration Settings

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.

Note

The method of generating an encryption key depends on the deployment scenario, summarized in the following table.

• Customers that do not wish to use a ConfigMgr Computer Association in key provisioning have the option of using Get Migration Settings to generate the key instead.

• Customers that do not require encryption are able to disable key provisioning by setting the TS variable 1EDisableUSMTEncryption = True prior to running the step. In this case, the step's only function is in providing the source machine name for 1E Application Migration.

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.

Key recovery

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:

1. If the client guid contains the prefix "GUID:" it MUST be included (see above screenshot).

2. The case of the argument does not matter; two arguments differing only in case result in the same key being generated.

3. It should be the client guid of the source computer, i.e. the machine from where the user state is being migrated, not that of the destination computer where the state is being migrated to.

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.