Category Archives: Application Compatibility

05/20/13

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.

Continue reading →

05/20/13

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.

Continue reading →

05/19/13

Application Compatibility – Deployment – Part 6

There’s a few considerations when deploying your OS and the Applications. Firstly, in terms of planning you need to get yourself a deployment schedule. It’s a good idea to get a good pilot group early on with only a small number of applications and who represent non-Techie users. It’s also a good idea to get your Service Desk some Windows 7 secondary machines or VM’s in order to provide support for both environments as your roll out. Once you are satisfied with the results of your first pilot group you should move onto a second pilot with a more varied group of applications. The first pilot should be used for fleshing out your process and also verifying that the image is solid rather than stress testing your applications. IT teams are bad candidates to be early pilot users as they do not reflect the majority of your user base (assuming!!) When you have deemed your processes and image are equipped to handle the migration you can begin to roll out to a wider base and at a quicker rate. This may partly be dictated by the readiness of applications but you should also consider external variables. Some departments may have training scheduled or possibly peaks in productivity which means they can only migrate during certain intervals. All Departments and Upper Management types need to be consulted.

The number of machines which can be deployed in a fixed time would also be dictated by tools being used and hardware and network resources. Is Multicasting a possibility on your network, if so you don’t have to worry about saturating the network but you may want to try and benchmark test how long it will take to do 50-100 machines at once. If you are using Unicasting you should really consult with your network team for guidance on what your threshold should be.

You should also consider your help desk capacity to support these users in case your pilot failed to highlights some repeatetive questions that may come their way en masse or even possibly issues with Data missing or a corrupted deployment.

For application deployments through a Distribution Tool you should ensure the tool does not have anything set which may interfere with the applications being deployed to Windows 7 or later e.g. An Operating System check. Are any properties changed in your MSI’s just being over-rided by your Distribution Tool?

Deploying applications for Windows 7 has not really changed from Windows XP. You should just beware of the different possible gotchas as mentioned above. You will likely also use the same deployment tool to deploy your OS to the users. Be that with tools such as Marimba, SCCM, Altiris etc. Or perhaps, if you would like to go for a more cost effective solution for OS Deployment you might consider using WDS. For more on this you can read my post HERE

That completes this series for migrating to Windows 7. I hope this was informative and useful to anybody who may have been seeking information on this.

Thanks for reading,
Rory