Export (0) Print
Expand All

Custom Shim Database-Management Strategies

If you have decided to use shims as part of your application compatibility mitigation strategy (for certain classifications of applications), the next question is, which strategy should you employ for managing custom shim databases? The customers Microsoft consultants have worked with have tended to select one of two approaches to managing their custom shim databases: deploying fixes as part of the application package or managing a centralized custom shim database.

Regardless of the approach your organization chooses, here are general recommendations for improving the management of custom shim databases:

  • Define standards for when to apply shims. You also want to define the scenarios in which shims are appropriate to use, as discussed earlier, based on the specific business and technology needs of your organization.

  • Define standards for custom shim databases. You may want to define standards for how to map shims to particular applications. For example, you may want to ensure that shims always include a version check so that the shim stops being applied to subsequent versions of the applications.

  • Define a resource responsible for addressing questions and enforcing standards. Having an individual or a team responsible for being familiar with the technology and standards around the use of shims has consistently been an important predictor of success. Many customers ramp up on shims and mitigations in general in response to an operating system migration but soon forget the details when the migration is over. As the databases are managed over time, you will want to ensure that some resource continues to remain familiar with these details.

Deploying fixes as part of an application package

One strategy for deploying application fixes is to include the custom shim database—containing a single entry for the application the package is installing—directly into the installation package. During the early phases of compatibility testing, this can seem like the easiest approach. However, over time this approach can grow more complex.

Microsoft consultants recommend evaluating the following considerations prior to selecting this approach:

  • How many applications will you end up shimming? The thing to keep in mind is that custom shim databases are still databases. Consequently, if you were to have 1,000 shimmed applications, it takes longer to open and query 1,000 different one-row databases looking for a match to a given application than it would to open a single database and query against 1,000 rows.

  • Can you track which applications you have deployed to which computers? It is possible that you will eventually find that the shims assigned to resolve a set of compatibility issues in an application are not comprehensive and that later you will need to deploy an updated version of the custom shim database that resolves the additional issues your organization later discovered. If you deployed the original custom shim database as part of the installation package, you will need to locate each client that has installed this application and the original custom shim database for it to replace it with the new version.

While this strategy can be a good approach if you are shimming only a few applications, most customers eventually opt against using it.

Managing a centralized custom shim database

An alternate strategy most customers consider (and most end up using) is to manage either a single custom shim database or several custom shim databases for large subsets of the organization. Doing so makes it easier to enforce policy and provide consistent updates to application mitigations you discover that you need to support your migration to Windows 7.Microsoft consultants recommend evaluating the following considerations prior to selecting this approach:

  • Do I have deployment tools to deploy and update custom shim databases to all the target computers? If you are planning to manage a centralized custom shim database, ensure that the tools are in place to deploy and update this custom shim database across all the computers in your organization that require this. As additional applications have shims applied to them, ensure that the target computers have the updated shim database installed prior to using the application.

  • Do I have centralized resources in place I can dedicate to managing and updating the centralized custom shim database? If you are taking the centralized approach, make sure that you have identified appropriate owners and that the application owners and testers have a clear path for escalating a request for a shim to result in deployment of an update to target computers.

Microsoft consultants have found that this strategy tends to be the best approach, when you have a solid deployment infrastructure in place and centralized ownership of the process. The primary advantages have been accountability and simplifying support (as the deployment of a particular version of a shim is more consistent across the organization).

Merging custom shim databases

Customers who have selected a centralized custom shim database approach benefit from the improved performance of searching a single database to determine whether Windows should apply a shim to a particular executable file. A frequent question Microsoft consultants receive is how to merge custom shim databases to create a single custom shim database. Customers have generally taken the following approach:

  • Application compatibility testers generally run on a computer containing the latest version of the organization’s custom shim database (which still may be a preliminary version).

  • If an application requires an additional shim, the tester will create a second custom shim database containing the shims required for that application, which the tester uses to verify the fixes, and through customer acceptance testing.

  • If the application passes all the functionality and integration tests, the single-application custom shim database is forwarded to the team that manages the custom shim database.

  • The central team opens the master copy of the organization’s custom shim database. This step is important, because the database contains a globally unique identifier (GUID) that makes updating the database easier (installing a new version of a database with the same GUID as an existing database installed on the computer uninstalls the old version).

  • The central team can then copy and paste the shims that were applied in the new custom shim database into the master shim database for the organization. (These are options on the right-click menu of Compatibility Administrator.)

  • The central team then redeploys the new version of the custom shim database containing the additional application fix to all users.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft