Skip to main content
Reference Read
Updated over 11 months ago

Lists the details of the Druva USMT tools.

This sections lists the following details of the Druva USMT tools:

Best practices

  1. Restart your machine after every restore.

  2. Source Operating System and destination Operating System bitness should be same.

  3. Ensure the destination machine contains the same or higher version of the application.

  4. Application on the source and destination machines should have the same bitness.

  5. Both the machines (where backup is taken, and where backup is restored) should have the same Username.

  6. For debugging, if multiple versions of same application are installed, ensure you backup only one version of application. This can be manually done through config.xml file.

Support for a new Windows component or a new application

  • Steps and reference blocks for adding any new application

  1. New application needs to be added under <components></components> section.

  2. To add new rules, refer to the Rules-block for firewall and Ip4/v6 application.

  • Steps and reference blocks for adding any new windows component:

  1. Navigate to Manifest folder in the build.

  2. Edit the conf.wcp file and make an entry in it for Component.

  3. Search for the Manifest file in winsxs folder and make a corresponding entry in Migsettings.xml.appManifestPartial.xml file under the manifest folder.

Limitations and known issues

Following are the limitations and known issues of the Druva-USMT tool:

  1. Difference in bitness between OS and application.
    Application upgrade from Office-13 32 Bit to Office-16 32 Bit on Windows 8 | 32 Bit to Windows10 |64 Bit combination.
    Rules have been written to support an upgrade from a lower version of Office to a higher version of Office, where bitness of application on source and destination is 32 bit and bitness of OS is also 32 bit.

  2. Refer Adobe block on migsettings.xml.
    If a specific source and destination is to be used for migration, RelativeMove() function should to be used.
    <locationModify script=”MigXmlHelper.RelativeMove(‘HKCU\Software\Adobe\AcrobatReader\10.0’,’HKCU\Software\Adobe\Acrobat Reader\11.0’)”>
    This will check for source (HKCU\Software\Adobe\Acrobat Reader\10.0) in backup and restore it in the destination (HKCU\Software\Adobe\Acrobat Reader\11.0.

  3. EDGE manifest id is not available on Windows 10.
    Migration of Edge settings from Windows 10 | 64 Bit to Windows 10 |64 Bit combination does not function based on a Manifest file. Rather rules have been added to migsettings.xml to accommodate this component. Manifest for Edge is not available, hence this provision has been made.

  4. Default Value settings for several applications like MS ODBC are not restored.

  5. It has been observed that Windows Word application intermittently fails to pick the latest value after restore, for the settings grouped under AutoCorrect (Option->Proofing- >Autocorrect). Reason could be related to syncing time of Office settings to registry.

  6. Some of the settings reflect back to Internet Explorer only after the machine is restarted. The machine has to be restarted after the Windows component restoration, if explorer.exe fails to restart automatically.

  7. Themes settings added like an application.
    The manifest that contains theme rules, does not have the supported components format with name contains “-DL”. For reference compare themeui.manifest and uxtheme.manifest. This was observed in the Win7 manifest file which is readable. Hence it is added as a Windows application.

Different types of files and their significance

Filename

Significance

Source

Catalog.mig

This file is created while creating a backup, this has a definite structure and it contains the settings. This can be comprehended by using a hex editor (e.g. 010 editor).

Created by tool

Manifest file

Each windows component has a manifest file. The correct manifest file is picked up based on the host processor type. Manifest files are encrypted Win8 onwards.

Provided by MS

migsettings.xml

Contains the migration rules that control the components to be migrated and their target location on destination system, this is for application settings and not for windows component. Yet migsettings.xml can be extended to accommodate certain Windows components for which Manifest file is not available or if some of the settings are not restored as desired. When new application/different bitness of application/different bitness of the OS/ different OS is to be supported, migsettings.xml needs to be extended with appropriate rules.

Provided by MS

config.xml

By processing migsettings.xml, this file is generated that contains entries of components, applications and settings that can be migrated. This file contains the application ID.

Created by tool

migstate.dat

This file is created while creating a backup. It contains user data, information, ID of backed up application,environment data etc.

Created by tool

AppManifestPartial

This is created by the tool, it has the linkage between the windows component and the manifest file.

Created by tool

CustomManifest

In code strCustomManifest = migSettings.xml

Provided by MS

SL_*.xml files present in Manifest/Metadata folder

In SL_*.xml, * stands for the display name of windows component listed in config file. For any windows component with display name “PQR”, a file called SL_PQR.xml is required at location build\manifest, if component’s corresponding manifest file contains group of settings under the node called <configuration></configuration&gt>. Existing SL_*.xml file can be referred to add new SL file.

Created by tool

Config.wcp

While adding any new windows component, corresponding entry for that component is made in this file. Windows components entries are read from this file by the tool.

Created by tool

Appendix

1. IPv4 block for reference
<!--Network Settings IP4 and IP6-->
<component context="User" type="Application">
<displayName _locID="migapp.IP4_IP6">IP4_IP6</displayName>
<role role="Settings">
<rules>
<include>
<objectSet>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\* [*]</pattern>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\Control\Nsi\{eb004a01-9b1a-11d4-9123-0050047759bc}\* [*]</pattern>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters\Interfaces\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>

2. Config.wcp windows component entry block for reference
<component displayname="Personalized Settings" migrate="yes" ID="appearance_and_display\personalized_settings">
<component displayname="Microsoft-Windows-uxtheme" migrate="yes" ID=" http://www.microsoft.com/migration/1...theme/settings "/>
<component displayname="Microsoft-Windows-themeui" migrate="yes" ID=" http://www.microsoft.com/migration/1...emeui/settings "/>
<component displayname="Microsoft-Windows-shell32" migrate="yes" ID=" http://www.microsoft.com/migration/1...ell32/settings "/>
<component displayname="Microsoft-Windows-CommandPrompt" migrate="yes" ID=" http://www.microsoft.com/migration/1...rompt/settings "/>
</component>

3. AppManifestPartial.xml windows component entry block for reference

<Component name="Microsoft-Windows-explorer-DL" ID=" http://www.microsoft.com/migration/1...er-dl/settings " manifest="%PROCESSOR_ARCH%_microsoft-windows-explorer_" file="" />

Did this answer your question?