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-seperated 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 whats 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 concideration 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.
(CustomSettings.ini)
USMTMigFiles1=CustomData.xml
USMTMigFiles2=AppsData.xml
OSDMigrateConfigFiles=CustomData.xml,AppsData.xml
So for the last couple days I have been trying to get this to work and finally it hit me what I was doing wrong. If you want to set this up all you need to do is first use an MDT imported Task Sequence into SCCM so it takes advatange of the MDT scripts and settings. This will setup a task in your task sequence called Install Software and the settings should already be set to the Install Multiple Applications option with the Base property being PACKAGES (Which we all know is the property BDD/MDT uses to assign SMS packages). Second is you can simply follow the documentation in the Deployment Customization Desktop Samples doc that is included in the Microsoft Deployment Tools install. The section is called Deploying Applications Based on Previous Application Versions on page 39.
What is the trouble you ask? Well if you are like me and have never set this or even referenced a SMS package and program combo via BDD or MDT before then you'll probably just follow the documentation word for word. And here is the key problem! The documentation gives the following example for putting a package into your PackageMapping table:
INSERT INTO [PackageMapping] (ARPName, Packages) VALUES('Office8.0', 'XXX0000F-Install Office 2003 Professional')
Those that are familiar with referencing SMS packages in their customsettings.ini or their BDD database will instantly spot the flaw with this syntax. They are mapping to the Office 2003 Profession install using the [PACKAGEXXX-Program] format (notice the dash) when in fact it is suppose to be a colon such as [PACKAGEXXX:Program]! So the correct example should look like this:
INSERT INTO [PackageMapping] (ARPName, Packages) VALUES('Office8.0', 'XXX0000F:Install Office 2003 Professional')
Simple mistake yet I should've noticed this right away since this is the format displayed in the BDD console you when use the Add Package option in the database section.
The documentation references the same syntax error again in the same section as noted below. Just keep in mind it should be a colon and not a dash and you will be in good shape.
(XXX0000F-Install Office 2003 Profession). This indicates that package XXX0000F-Install Office 2003 Professional will be installed by the ZTI process during the State Restore Phase.