How To: Creating Shims

If you do not have the luxury of using an Application Compatibility tool such as Citrix AppDNA, Quest ChangeBase or Flexera Application Compatibility Pack you will not have the capability of creating automatic compatibility fixes. Which will mean you will rely on creating shims of manifest files to resolve some of your compatibility issues. Microsoft recommends developers to use manifest files for their developed applications, the manifest file lives with the .exe of the app and mitigates certain compatibility issues. Manifest files are not meant to be applied to third party applications. Instead, Microsoft suggests us to use Shims.

Shim are like a trick or a lie to your operating system. You create one per application with an issue. As you will see illustrated below you can target per application. The shim will then live on your systems alongside the application. It acts like a listener, waiting for the application you targeted during the creation of the shim to launch and when the application attempts to invoke the action which without the shim applied was generating an error, the shim kicks in and tells the application to allow the application to function. This may seem a little confusing. I hope to clarify as I go.

SHIM1

 

You can open Application Compatibility Administrator and you will see the above Interface.

SHIM2

 

If you expand applications you will see a long list of application within. Each represents valid shims for these applications. These are canned and ready for your use. This list does seem to be pretty outdated but I guess it would be, considering newer applications will be compatible. The list contains a large variety of application types but seems to be mainly for games.

Read more

Flexera Application Compatibility Pack

The Flexera Application Compatibility Tool leverages the existing Application Manager tool that is part of AdminStudio. Application Manager is typically something that is used at the integration phase of the packaging process, meaning after the application is packaged and tested, UAT is signed off you import your application into the database. The database then exists as a software repository which can flag any application conflicts through-out your entire estate of applications and can be used for querying package content.The application compatibility piece can be used a little different, instead of being used after packaging and testing has been completed it can be used before packaging to determine the amount of remediation work which may be required. The fact the tool can be used in a couple of different ways, it is this reason, why I feel we will require 2 Databases for the Application Manager, one will be a throw away database used for compatibility testing. The other will exist as an inventory manager and for checking application conflicts in the production environment.

Read more

Deploying ACT Collectors

You can download the Application Compatibility Toolkit (ACT) from the Microsoft download site HERE

ACT requires access to a SQL server as this is where it stores the processed collector information.

Once you have ACT Downloaded you can install it on a machine or Virtual Machine, whichever you may please. Run the “Application Compatibility Toolkit.msi”. Accept all defaults.

Launch the Application Compatibility Manager from Start -> All Programs -> Microsoft Application Compatibility Toolkit 5.5 -> Application Compatibility Manager. Follow these steps to configure ACT:

ACT1

Click “Next”

ACT2

Leave default option “Enterprise Configuration”

ACT3

Read more