If you have played with the MDT & SCCM integration then you may have noticed that SCCM uses its own USMT package and settings for the State Migration node in the task sequence. This may get complicated for you if you are used to using the USMTMigFiles and the USMTConfigFile properties in your BDD/MDT rules previous to SCCM as SCCM does not use these values anymore. In fact it doesn’t support a Config File at all, only the mig files. You can achieve the same result of the USMTMigFiles property by setting the variable OSDMigrateConfigFiles to a comma-separated list of the file names that should be used (Thanks to Michael Niehaus for that tip).
Now here’s where the logs may confuse you if you are following along in a test environment. The BDD.log will indeed show it using the USMTConfigFile and USMTMigFiles variables and running USMT command. Don’t be alarmed, this is *only* to run an estimate step in the sequence to determine space required and location to store them, the same step that was in BDD before SCCM so nothing new there.
So what’s the catch? Well since the estimation step is using your old variables and the actual State Migration step is using the OSDMigrateConfigFiles variable you’ll want to sync these variables up. Why? Take this for example: If you have your USMTMigFiles assigned to a value of test.xml and in that xml you were testing the migration of MP3s and photos and videos even then the estimation will actually calculate those into consideration when it runs it estimate size. So in this example lets say the estimate returned that it requires 20GB of space for migration and the machine only has 10GB of available space. It will now tell the sequence to not use the local storage for State Migration because there is not enough space. Now if your OSDMigrateConfigFiles is assigned the value of UserData.xml and only contains a very small subset of what your Test.xml contained, then it may only need 1-2GB of space to migrate or even less, but will still not use the local storage to store this data because the estimate step told it not to based on its findings using test.xml.
You can see where this *may* become an issue or moreso of wasted resources when they are not in sync. So it seems currently that it would be a best method to make sure your USMTMigFiles variable has the same values as the OSDMigrateConfigFiles and that the USMTConfigFile variable is not used at all to make sure the estimate and the true migration data match up, and I’ll provide a quick example here.