This is one of the biggest challenges you are likely to face in the process of moving to a Windows 7 SOE. Microsoft have done a lot to ensure as many apps as possible ‘just work’ under Win7, however those that don’t, can often be difficult to coax into running.
The first issue you are likely to face with regard to App Compatibility is identifying the applications that are installed on your fleet and prioritising those that need to be mitigated.
To help with this, Microsoft provide the Application Compatibility Manager, part of the Application Compatibility Toolkit (one of my favourite SOE management toys), Version 5.5 with Windows 7 support, can be found here.
A small MSI package is created and deployed to the fleet, installing an agent on the machine which will inventory the software and hardware and deliver an XML report back to the Server of your choosing. Have a read of the deployment guide found here if you are unsure of server requirements etc.
The first time a machine reports in it will send between 1mb and 5mb of data, each subsequent transition will usually only be a few kb. Worth noting is that if you use some kind of WAN accelerators in your environment, you are likely to see significant reductions in the amount of traffic sent. In one case recently, we deployed the agent to 25 PC’s on the other side of a slow and highly latent satellite service. the first machine sent 3mb of data back to the server in the data centre, whilst each subsequent machine only sent about 10kb. The reason being that so much of the XML report is common amongst machines on the same SOE, that the WAN accelerator, in this case a Cisco WAAS solution, was able to chop out all the duplicated data and only send the differences. This represents some clever thinking on Microsoft’s behalf in the way the clients send the data back, resulting in a very agile product that scales nicely and is quite practical under challenging network conditions.
A file listener on the Server then analyses the data in it’s own time and imports it into a SQL database. The information gathered then needs to be filtered and rationalised down to a list including only the actual applications you need to deploy. Those filtered may include duplicate entries with slightly different version numbers, driver packages that left an entry in Add/Remove Programs and as such were captured, and lastly applications that won’t be required for some reason in the new environment (perhaps because the functionality they provide is built into Windows 7).
OK, so you now have culled 17 000 entries down to several hundred. you know what you have to deploy, most applications are packaged and tested without issue, But what about those that don’t work? Why don’t they work? Perhaps the application does an operating system check when it launches and demands Windows XP to run. Perhaps the application is looking for a system dll in a location it no longer exists. Various problems may come about if your new environment will not give admin rights to users by default, poorly written applications may be coded to write to files or the registry in locations that aren’t user writable (such as c:Program Files).
The answer in a lot of cases is to shim the application. In engineering, a shim is a thin and often tapered or wedged piece of material, used to fill small gaps or spaces between objects, In computing, using the ACT, we are able to create a shim file or sdb, which contains various fixes, such as redirects etc. This shim is installed into the operating system, and will intercept various action made by the application, fooling the answer, or redirecting the write, in order for the application to run correctly. This is quite a powerful process, however I’m conscious to mention that I don’t think it should not be used in all cases and it certainly shouldn’t be the first solution you try.
Briefly, this is the thought process I would go through when mitigating a troublesome application. I’ll write more on each of these processes at a later date.
Get the right version
Before you go knocking down the door of an unsuspecting programmer, or spending time and money repackaging or shimming your application, don’t forget to check for the existence of a new version with support for Vista/Seven. I must admit it has happened a few times that I’ve hacked away at an application in order to make it run on my Vista box, only to later find that the manufacturer had released a compatible version whilst I wasn’t looking.
Recode it
Most app compatibility issues are due to poor programming. Sorry to all those code warriors out there, but there it is. Hard coded file locators, OS checks and coding file and registry writes to restricted areas are the most common issues faced by engineers integrating applications into corporate SOE’s. With this in mind, I feel the best solution to poor code is to rewrite it. Naturally, this won’t often be possible, given that you usually won’t have the source code for the application. Nor the time (and possible the know-how) to recode the program. That said, if you’re having issues with in-house written applications, or maybe you have a good relationship with the software manufacturer, rewriting the inoperable code should always be your first port of call.
Repackage it
So, you might not have the source code, but hopefully you have an MSI package. Many problems are isolated to the installation process, the application may run perfectly if only could get the installer to run. If this is the case, you may with to consider using a tool like AdminStudio to repackage the application. Whether it be a minor tweak to the MSI to remove an OS check, or performing an install capture and creating an entirely new package, with a bit of practice, these tools can really save the day. Worth noting is that if your problem relates to UAC getting upset about the install, it won’t likely be an issue if you plan to deploy the application using SCCM or during an MDT task sequence, these tools get around that kind of issues by default as they do not install user shell’s context.
Shim it
If you go through the above mentioned steps and are still having issues, it’s probably time to look at mitigating the problem using a shim. This is going to get you out of trouble in most cases really, unless you are trying to get your old Windows for workgroups application to run under Windows 7. If this is the case, I’d suggest you skip the rest of the options and go get a new job.
Virtualize it
As you know, I have some very strong opinions about App Virtualisation, thus why this option is so far down the list here. Don’t get me wrong, technologies like App-V and ThinApp are fantastic… In their place. Within the context of resolving App Compat issues, be careful not to lean on these tools to fix the problem as they often won’t. Save these for circumstances where you have 2 apps that are unsociable (rather than one app with is unsociable with the OS) or where you wish to take advantage of streaming or portability features.
Run it in an environment where it works
If you get this far and still have no luck, then you’re unlikely to win. Time to bury your pride, accept that the sucky little program has beaten you, and figure out where you can run it without issue. This may be on a Citrix server, a spare PC, or dare I say, Windows XP mode. Whilst the tools available at present to manage a large number of Windows XP mode VM’s would appear to be lacking in maturity, I’m told that updates will be available before the end of the
calendar year that may make this option a little easier to swallow for those who would seek to manage this tech in a zero touch fashion. That said, if you are in a position where you need to deliver your application to only a few users and don’t mind setting it up 1 machine at a time, then by all means, you should check XPmode out.
Michael Watkins : November 13, 2017