The Microsoft Compatiblity database - Dynamic Shims

I was doing some thinking about a central database of application compatibility shims. 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 get the kind of matrix of deployment scenarios that one could encounter.

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.

If this has not already be done, I think that we would probably not want to store all of the shim data in AD… we may need a translator that sits between the deployed AD registry settings and the local machine SDB database. Something like the following rough diagram ;



Using this approach we could deploy shims to the user, desktop, group or by domain. We could also determine what settings have been put in place and be able to audit the results. Also, no major technology needs to be created. We could use the existing SDB database (which incidentally gets recompiled every time a change is made anyway). We would require the creation of a Active Directory GPO2SDB converter and the WMI interface but that could done relatively easily now that the SDB API's have been made available on MSDN and their is an XML converter for viewing the contents of the SDB database.

The WMI interface would be required to interrogate the closed SDB database and enable auditing and reporting of the result SHIM changes to the local machine.