Skip Links

Dreading Windows 7 or 8 deployments? How advanced application mapping could be your silver lining

By Dave Harding, product manager, 1E, special to Network World
December 14, 2012 01:32 PM ET

Network World - This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

Supporting an ever-increasing number of enterprise applications has always presented a challenge, but this pain is especially acute when operating system (OS) upgrades -- such as from Windows XP to Windows 7 or Windows 8 -- are rolled out.

"Application mapping," the process of identifying and reinstalling users' application sets, can be automated and helpful, but the traditional process is highly inefficient. However, a new approach to application mapping substantially eases the impending aggravation of a Windows migration.

OVERVIEW: Why, when and how to migrate to Windows 8

MORE: 3 tips for migrating applications to Windows 7

With traditional application mapping, the process of identifying and reinstalling the user's application set can be automated by identifying relevant applications in the old system's inventory and translating, or "mapping," them to a ConfigMgr package and program. This process is often referred to as "Package Mapping."

In fact, the Microsoft Deployment Toolkit has included a little-known application mapping solution since it original release (BDD 2.5). Variations of the original solution can be found on various public blogs; all use some form of string comparison to match Add/Remove Program entries to ConfigMgr packages and programs. At the center of the process is a custom table, populated by an administrator, containing inventoried applications display names in one column and ConfigMgr package ID's in another. A sample of what this PackageMapping table may look like is below.

Table 1
Sample PackageMapping table

The potential time savings has an obvious appeal, especially when planning a large-scale migration; but application mapping can do more than save time. First, application mapping can be used to install an upgraded version of particular applications. In the preceding example, installations of Project Professional 2007 are automatically upgraded to Project Professional 2010 during the migration. Second, this process can rationalize and reduce the size of the organization's software portfolio. Again referring to the preceding table, installations of WinZip and jZip will be replaced with 7-Zip at deployment.

While application mapping can add value to a Win7 migration, the traditional approach can introduce new challenges and complexities. The default application mapping rule is to install nothing, meaning every application to be reinstalled during deployment requires an entry in the PackageMapping table. Any product that does not match a PackageMapping table entry will not be reinstalled. For an enterprise managing hundreds or thousands of software titles, populating and maintaining the PackageMapping table may be a daunting and lengthy task.

Also, the process relies on raw, un-normalized ConfigMgr inventory data. Any variation in display name for a particular product must be identified and manually added to the PackageMapping table. In the preceding PackageMapping table, five variations in the display name for Adobe Acrobat Professional 8 exist in the environment, requiring five separate table entries. Any overlooked display name variants for this product not listed in the table will not be reinstalled at deployment.

Our Commenting Policies
Latest News
rssRss Feed
View more Latest News