A new feature in USMT 10 (from the Windows 10 ADK technical preview) is it's ability to migrate 3rd part drivers (and apps) via the new provisioning packages in Windows 10. I'm not sure why anyone would migrate drivers this way (yet), but it least it caught my interest enough to play around with the the feature 🙂 Another interesting thing is that there is a ARM version of USMT as well.
Note: The drivers capture feature in USMT 10 is quite similar to use the Export-WindowsDriver cmdlet that was introduced with Windows 8.1, except that it stores the drivers in a WIM file (provisioning package, PPKG extension,). In the Windows 10 ADK Technical Preview, the PPKG (WIM) files that are created are not compressed. I don't know why, but I hope that will change in the released version.
New command line switches for Scanstate to migrate apps and drivers
There is a bunch of new command line switches to scanstate, but the /ppkg /drivers and /apps controls the apps and drivers migration feature. The /apps feature seems to be broken in the Technical Preview, but the /drivers feature is working fine in my testing.
Disclaimer: Since drivers are normally handled by the deployment solutions, I haven't yet figured out any real world usage for this new feature. Please comment below if you find this feature useful (and why).
Anyway, the command line switches that controls apps and drivers migrations are the following:
- /ppkg
Specifies that the migration store is a provisioning package. Can't be used with /nocompress, /hardlink or /p. - /drivers[:]
Specifies that USMT should migrate 3rd party drivers. By default all drivers are migrated. can be used to select drivers to migrate. They are of the form +n:, -n:, +p:, -p:,+c:, -c:, where +-n can filter the migrated driver by the name of the INF file, +-p can filter them by publisher and +-c by class name or class GUID. Multiple /drivers are allowed, The last pattern matching a particular driver wins. /drivers must be used with /ppkg. - /apps
Specifies that USMT should migrate 3rd party applications. A provisioning package captured this way can only be applied during the deployment process, it cannot be used with a normal apply process with Loadstate.exe. Also, /apps implies that no user data will be migrated, /ui /ue will be ignored. /apps must be used with /ppkg. /apps cannot be used with any /target switches.
Note: 3rd party applications are Windows store applications, not Windows Desktop applications.
Testing the drivers feature
To capture drivers from a system and create a provisioning package you run the following command (the /ue switch is optional but I didn't want to capture any profiles):
canstate.exe /drivers /ppkg /ue:*\* \\FS01\MigData\PC0001
When running this on my machine, it generated a PPKG file of 1.63 GB.
The output from running scanstate with the new /drivers switch.
Looking into the drivers provisioning package
If you seen my earlier video on create provisioning packages using Windows ICD you know the PPKG file is really just a WIM file, meaning it's easy to either mount with ImageX/DISM. For most of the provisioning packages, but not all, I have also been able to use 7-Zip to open the file since it can open some WIM files.
As I mentioned before, when running scanstate to capture the drivers on my machine, it generated a PPKG file of 1.63 GB. As I mentioned earlier, in the Windows 10 ADK Technical Preview, the PPKG files that are created are not compressed (don't know why), but I hope that will change in the released version.
The resulting provisioning package.
After mounting the PPKG (WIM) file to E:\Mount, you see the following:
In the Drivers folder, there is a bunch of subfolders, one folder for every drivers, and also a Driver.xml file holding a list of all drivers.
There is a snippet of the Driver.xml file.
ARM version of USMT
Happy Deployment, Johan