MDT 2012 Update 1 contains a nice little and very easy to use feature known as Package Mapping. This feature enables software to be automatically (re-)installed during a refresh scenario task sequence if it is installed in the current OS instance/installation. It does this by mapping the software listed in Add/Remove Programs on the existing OS installation (by querying ConfigMgr’s hardware inventory information for that system) to ConfigMgr packages and then adds those packages (and programs) to the package install list. To easily set this up, follow Brad Tucker’s blog post: Dynamically Installing ‘Computer Specific’ Applications Using Configuration Manager with MDT. Note that are other blog posts out there on setting this up and improving upon the process, but Brad’s is a great starting point that should work for most folks initially.

Unfortunately, MDT’s built-in capabilities only take into account the “classic” packages and programs and not the new Application Model of ConfigMgr 2012; however, it is actually very easy to add this in.

1. Create the dbo.ApplicationMapping table

This is easily done by simply duplicating the existing dbo.PackageMapping table by right-clicking on the dbo.PackageMapping table in SQL Management studio, and select Script Table as –> CREATE To –> New Query Editor Window.


This opens up a new query windows with the data definition language (DDL) to create the PackageMapping table. Change DDL to reflect the name of our new table: ApplicationMapping. Also change the name of the Packages column to Applications (it is very important that you name it Applications because this is known to and used by the magic of ZTIGather. Hit Execute and the new table will be created.


Just like the PackageMapping table, you will need to populate this table with the display name of applications from Add/Remove Programs. Instead of using the package ID and program name separated by a colon though, use the name of the Application in the Applications column. You do not specify which deployment type to use because those are chosen dynamically at application installation time based upon the requirements of the deployment types just like during a normal application deployment.

2. Create the dbo.RetrieveApplications stored procedure

We’ll once again duplicate an existing object for this: right-click on dbo.RetrievePackages and select Modify.


This will also open a query window displaying DDL; this time it’s the DDL for the dbo.RetrievePackages stored procedure. Change this DDL to reflect the new stored procedure’s name, RetrieveApplications. Also, update the table it is querying from PackageMapping to ApplicationMapping. Finally, change the DDL to create the new stored procedure by changing ALTER to CREATE as highlighted in green below. (Note that the DDL will initially be mostly on a single line that requires you to scroll to the right to see and modify it – you can easily add a few new lines if you would like though to make it easier to read and modify as I have done in the screenshot below.) Note also the changes highlighted in red below for the name of my ConfigMgr DB and the highlight in purple to use the display name from ARP instead of the program ID – these changes are detailed in Brad’s post. Hit Execute and the new stored procedure will be created.


3. Add a section to your customsettings.ini

Similar to the section you added for the package mapping (and detailed in Brad’s post), except with the new stored procedure referenced:








Make sure to add DynamicPackages to the Priority line under the Settings section in your customsettings.ini file also.

That’s it. As mentioned above, the magic of ZTIGather will automatically do the rest. Here’s a quick overview of what ZTIGather will do though once it executes the section:

1. Run the RetrieveApplications stored procedure, passing it the MAC address of the current system. This in turn queries the ConfigMgr DB for all ARP entries for the system with that MAC Address. These are then matched up, by display name, to the rows in the ApplicationMapping table and all matches are returned.

2. The returned, matched rows all have two columns: ARPName and Applications. We really don’t care about ARPName at this point and neither does ZTIGather; however, ZTIGather sees the Applications column and recognizes it as a “special” column because it is defined as a list in ZTIGather.xml. Thus, it adds the value of the Applications column from every returned row to the Applications MDT property list. Note that through more magic of ZTIGather, if the Application is already in the list, it won’t be added again.

3. ZTIGather translates the Applications property list into a series of task sequence variables, one for every application in the list, named Application01, Application02, Application03, etc.

4. Finally, the Install Applications task in the task sequence uses Applicationxy task sequence variables to install the applications from the ConfigMgr applications.

While I haven’t always been an ardent fan of MDT, it is pure magic sometimes and always works really well.