App-V: On Application Compatibility and Shims with Regards to Applications Virtualized with App-V 4.x and 5.x

While the origins of Softgrid may have revolved around addressing some application compatibility issues, the primary tenets of using Softgrid then (and App-V now) still are to provide on-demand application delivery, “installation-footprint-free” assets, as well as application-to-application isolation. This does not include being a solution for application compatibility. The old notion of “If you can’t fix it with shims, you can just use App-V and sequence it on XP! - Then run it on Windows 7 or 8” is not true. If this solved one of your application issues when migrating to Windows 7 or 8 – it was only a case of luck. App-V has not, does not, and will not fix App-to-OS bugs.

So where does App-V fit into the Application Compatibility Process?

Application Virtualization is a packaging technology that contains both state separation and isolation. But it alone, does not remediate compatibility issues. Laying out the industry accepted AppCompat process, virtualization/sequencing is considered a form of packaging.

 

The sequencing of applications for a target operating system should occur only after that application has been verified for operating system compatibility directly or through remediation. Yes, that remediation may include a shim containing compatibility fixes.

But I heard you can’t shim App-V applications!

You heard wrong. If you must shim that internal custom LOB application for which you can no longer locate the source code, you can certainly apply the same shim to an application running natively or virtualized so long as you have deployed the shim locally. This is so the Application Experience service can work with the fixes properly. I, personally believe in Shims as a last resort, especially with App-V. Remember, some global compatibility flags (__COMPAT_LAYER) can also be applied to App-V applications as environment variables. Zarbie mentioned this a while back in one of his blogs: (https://blogs.technet.com/b/virtualworld/archive/2010/04/13/the-requested-operation-requires-elevation-2c-000002e4.aspx.) You should always look for the simplest of solutions first.

But for that application that may require several fixes, there have been many questions and requests regarding guidance on how shims developed to address compatibility issues (also known as AppCompat Shims) can be implemented with App-V.

Using the Stock Viewer application that comes with the ACT, I will demonstrate both the relationship of how most compatibility issues affect App-V packages as well as how we apply compatibility shims to App-V packages. The well-known Stock Viewer Demo App (from the ACT) is a great teaching tool to demonstrate applying some of the issues that will rear their ugly head exactly the same way in a virtual App-V application the same way they would in a native application. So if we wanted to implement the ElevateCreateProcess, ForceAdminAccess, LocalMappeObject, and VirtualizeHKCRLite fixes into an application virtualized with App-V, we would go about it the same way we would using a normal local installation of the Stock Viewer application along with the rest of the ACT. I create my shim as follows:

1. Start the Compatibility Administrator application (COMPATADMIN.)

2. Click yes to the UAC prompt.

3. In the left pane click Custom Databases and then select “New Database(1) [Untitled_1].”

4. On the toolbar, click Fix.

5. In the Create new Application Fix wizard, on the Program information page, in name, type StockViewer, in Location, type c:\Program Files\Microsoft Application Compatibility Toolkit\Compatibility Administrator (32-bit)\Demo Application\StockViewer\StockViewer.exe, and then click Next.

6. On Compatibility Modes page select None for Operating Systems Modes, and then click Next .

7. On the Compatibility Modes page, click Next.

8. On the Compatibility Fixes page, check ElevateCreateProcess, ForceAdminAccess, LocalMappedObject, VirtualizeHKCRLite, and then click Next.

9. On the Matching Information page, click Finish .

10. On the toolbar, click Save.

11. In the Database Name dialog box, type StockViewerFixes, and then click OK.

12. On the Save Database browse window, in filename, type C:\SDBShare\StockViewerFixes, and then click Save.

So now we have a shim StockViewerFixes.sdb that can later be applied with a simple command:

sdbinst.exe -q

The –q installs it in quiet mode.

 

Shims and App-V 4.6

When Stock Viewer is virtualized and executed as a standard user, you will find that the user encounters the same initial launch error virtualized as it would when it is installed natively.

Permission Denied

You must be an administrator to run this application.

 

So if we wanted to apply this shim to the computers local database, we could do so by quietly deploying the shim (using sdbinst as an administrator.) Then you would want to add in a Service Inclusion for the Application Experience service (AeLookupSvc) in the App-V Client Configuration so the Application Experience service can work inside the App-V virtual environment and ensure all shims are applied properly. I discussed Service Inclusions last year in the following blog: https://blogs.technet.com/b/gladiatormsft/archive/2012/08/01/app-v-4-6-using-service-and-process-inclusions.aspx

Service Inclusions can be useful not only for Anti-Virus applications, but other key services as well. For example, this is how we allow for AppLocker to work with virtualized applications. For the Application Experience service, you would need to create the service inclusion for the service – AeLookupSvc by simply creating a string value (REG_SZ) under the following key:

X86

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\<version>\Client\AppFS\ServiceInclusions

X64

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\<version>\Client\AppFS\ServiceInclusions

Value: AeLookupSvc1

Data: AeLookupSvc

The main challenge will be if you want to deploy the shim “on-the-fly” when you deploy the application. My good friend and idol Chris Jackson mentioned this a while back in his Technet Magazine article:

https://technet.microsoft.com/en-us/magazine/ff458340.aspx

He mentions the use of a pre-launch script in the OSD file to apply a shim using sdbinst. This works well except that it requires administrator access and the command will be running in the security context of the user. Also note that he also addressed the problem with using a centralized shim database due to problems with elevation and the AppV Bubble. The use of creating a Service Inclusion for the AE Lookup service addresses this issue now.

 

Shims and App-V 5

With App-V 5, the process is more straight-forward. You can use individual shims or a centrally managed shim database without the need to have a service inclusion included due to the new App-V file system and hook model. You even have better options of applying the shim for each virtualized application individually by taking advantage of the more advanced App-V script model. Since the desired workflow is to be able to apply the shim without unnecessarily elevating the security context of the user or application itself, you can apply the shim using the AddPackage event within the deploymentconfig.XML file. This will run under the context of the SYSTEM account.

    <MachineScripts>

      <AddPackage>

        <Path>sdbinst</Path>

        <Arguments>-q stockviewerfixes.sdb </Arguments>

        <Wait RollbackOnError="true" Timeout="15"/>

      </AddPackage>

 

Likewise, you can reverse this when the package is removed by assigning a script on the RemovePackage event.

    <MachineScripts>

      <RemovePackage>

        <Path>sdbinst</Path>

        <Arguments>-u stockviewerfixes.sdb </Arguments>

        <Wait RollbackOnError="true" Timeout="15"/>

      </RemovePackage>

Bear in mind, these events will only occur when deploying using PowerShell. If you want to deploy this shim using the publishing server, you will want to target the machine and not the user and assign the shim installation to the PublishPackage event.

With Windows XP hitting end of life, there is a rapid increase in the movement to Windows 7, Windows 8, and Windows 8.1. While modernization of your legacy applications still should be your ultimate goal, remediating your application into a working solution that is both compatible and portable is, in many cases, the next best thing from a transitional perspective.