Back to basics #6 – Application Compatability: Things You Shouldn't Do But Are Tempted To

  • Article

I can't profess to be an Application Compatibility guru like Chris Jackson or Aaron Margosis, but I do work on a lot of deployment projects where I am tasked with helping the client with this area. As such, I have compiled a list of the top 5 most common Application Compatibility mistakes/not-recommended practises that I see out in the field; this list is likely to differ from the next guy though :-)

 

Most of the items in this list are actually quick-fixes that people think are the result of one (or a combination) of the following:

  • It seemed a good idea at the time
  • Not understanding completely the problem, or the future consequences that the great "solution" will have
  • The desperate need for a quick fix

 

If you know of any other common ones, feel free to add them in the comments section!

  1. Make users local administrator on their computer in order to eliminate errors associated with a lack of permissions – Tracking down exactly what permissions are required can be a complex task to complete, but is always a better option to making users administrators on a computer.
  2. Disable User Account Control (UAC) – The UAC can be a valuable tool for protecting a computer from unwanted changes. However, it is often disabled because it is perceived as being too verbose. But, if configured correctly, this verbosity can be reduced without compromising security.
  3. Open up ACLs on Folders and Registry Broadly – This is a valid solution to an application compatibility problem if executed correctly, by only making changes where absolutely necessary. However, ACL changes are often made much higher up the tree, and then applied on all sub-objects. This grants a user too many permissions on what might be files or registry keys that should be protected.
  4. Disable Internet Explorer Protected Mode – One of the hardest compatibility problems to solve is when an application requires a specific version of a browser to work, and is not compatible with later versions; usually because security is stricter in the later version of the browser than the application expects. A common approach to alleviating this issue is to lower the level of security in the browser, commonly by disabling the Protected Mode in Internet Explorer or using the Internet Zones feature. The Protected Mode feature of Internet Explorer can provide a user with a high level of protection from all the "bad stuff" lurking out on the Internet, and should be correctly configured rather than simply disabled.
  5. Software add-ins/plug-ins are often overlooked – These components are equally as important as the rest of the applications, but are commonly overlooked. Not considering and evaluating these components at the right stage can result in a situation where a user has been deployed a newer version of an application, such as Microsoft Office 2010, but subsequently discovers that a business critical add-in they need/require/use in Office does not work in Office 2010, leaving them stranded!

 

There are two tools though which are indispensable when beginning any Application Compatibility assessment, the Microsoft Application Compatibility Toolkit, and the Microsoft Assessment and Planning Toolkit. These tools are extremely helpful in getting started and working out the best approach to a problem. Also be sure to check out the Application Compatibility section of TechNet.

 

I recognise that pointing out the problems but not giving any solution to them is easy to do. I am unable though to provide any alternatives to these quick-fixes in a single blog post as every single Application Compatibility problem is unique, and the solution to it will also be unique and personalised. Some solutions can take extremely long times to identify and then develop, and sometimes it is also just down to a little luck. The best approach in my opinion is that, if you really don't understand the problem or the solution, then get help; don't apply a heavy-handed solution such as those mentioned above because you will be creating a future problem for yourself further down the road. More often than most people realise an application compatibility problem can be resolved correctly without resorting the one of the fixes above and compromising security, you just need to understand the problem better and be aware of all the options! I strongly recommended regularly reading Chris and Aaron's blogs (I provided the links above) as they both provide some great information on Application Compatibility and Microsoft Windows.

 

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use