Application Compatibility
Getting Apps to work...
Wednesday 7 October 2009, 10:07 AM
Application Compatibility: Microsoft Shims
I was doing some thinking about a central database of application compatibility shims. Shims are a Microsoft application compatibility technology that is "baked" into the Windows 7 operating system to assist with installation and run-time compatibility issues.
I have a couple of concerns regarding the implementation/deployment of these compatibility shims – but these may be more due to my ignorance rather than the limitations of the design/deployment of this compatibility technology.
First, is that the shim is “attached” to the application object and is not related to the user and second, I have found it hard to separate shims into “machine” shims and "user" shims; effectively separating changes to the target desktop or server environment based on machine or user privileges .
This is important for deployment reasons and that we may not want to apply a particular shim to a particular user on a particular machine or a particular machine etc… you get the kind of matrix of deployment scenarios that one could encounter - a pretty complex mesh of possibilities here.
So, following along these lines, I wanted to move up the problem tree and start dealing with the compatibility problem on a larger (let’s call it Enterprise) level.
Some of the things that I would require from an application compatibility framework/approach would include the following “pillars”;
- Leverage existing management approaches and technologies covering
- Deployment
- Reporting/Audit
- Updating/Removal
- Support for central management, remote access and disconnected use
- Support for machine, user, grouping and domain focused management
- Support for versioning, incremental updates and roll-backs
Using these pillars of Enterprise Compatibility Management, my thinking led me to use Active Directory as a central store for all compatibility settings. These GP objects would contain either the machine or the user appropriate settings for each app compatibility issue and would benefit from both GPO deployment and reporting technologies.
I have a couple of concerns regarding the implementation/deployment of these compatibility shims – but these may be more due to my ignorance rather than the limitations of the design/deployment of this compatibility technology.
First, is that the shim is “attached” to the application object and is not related to the user and second, I have found it hard to separate shims into “machine” shims and "user" shims; effectively separating changes to the target desktop or server environment based on machine or user privileges .
This is important for deployment reasons and that we may not want to apply a particular shim to a particular user on a particular machine or a particular machine etc… you get the kind of matrix of deployment scenarios that one could encounter - a pretty complex mesh of possibilities here.
So, following along these lines, I wanted to move up the problem tree and start dealing with the compatibility problem on a larger (let’s call it Enterprise) level.
Some of the things that I would require from an application compatibility framework/approach would include the following “pillars”;
- Leverage existing management approaches and technologies covering
- Deployment
- Reporting/Audit
- Updating/Removal
- Support for central management, remote access and disconnected use
- Support for machine, user, grouping and domain focused management
- Support for versioning, incremental updates and roll-backs
Using these pillars of Enterprise Compatibility Management, my thinking led me to use Active Directory as a central store for all compatibility settings. These GP objects would contain either the machine or the user appropriate settings for each app compatibility issue and would benefit from both GPO deployment and reporting technologies.
Previous
