Freigeben über

Allowing Better Interaction to App-V Virtual Applications

  • Artikel

Each time I work on a Windows deployment project, App-V figures more and more in the conversations that I have with customers.  It is, in my opinion, now a vital tool that is needed in order to successfully migrate an existing platform (or deploy a new one) to Windows 7.  The uses for App-V vary but two of the most common that I see are for eliminating side-by-side Application Compatibility issues and for abstracting applications from the base OS in order to "componentise" the desktop.  One of the caveats with using App-V is that sometimes these virtual applications “don’t play nice” with locally installed applications, creating all sorts of user-unhappiness.  Depending on the applications and their level of interaction, some or all application functionality can be lost because of the processes that are blocked by the SystemGuard feature of App-V.

This very issue came up in a project I have been working on recently.  The issue was that some locally installed accessibility programs that provide a text-to-speech service were unable to read information from virtual applications, so instead of the software saying “File Menu” when clicked, it simply said “Context Menu” for everything.  This was creating a serious problem for the App-V deployment because the IT department are obliged to provide full accessibility options for their users upon request.  The way to solve this issue is to allow better interaction between these locally installed applications and the virtual ones, and to do this there are two common options:

  • Use the LOCAL_INTERACTION_ALLOWED tag in the OSD file.  When this tag is enabled certain named objects and COM objects are created in the global namespace rather than isolated inside a particular virtual environment.  This can allow some locally installed applications the chance to interact better with the virtual application.  The downside to this solution is that potentially you could introduce new application conflicts unknowingly (see linked blog post for more info) as it is a global setting and App-V package specific.
  • Discover the exact objects that need to be allowed to pass through SystemGuard, and enable only these.  This is by far the better option as it is not a global setting and is object specific and per-application, thus limiting to a maximum the chances of any subsequent application conflicts.  The downside is that it can be a very tricky and time consuming task to complete.  However, a very important upside to this solution is that you get to play with the Sysinternals Process Explorer and can show off your skills with this tool!

 

In this post I am going to explain how to implement the second of the two options presented above.  You must be aware though that the process I describe requires a lot of trial and error and may not work for every single application.  In order to discover the objects that need excluding it is vital that you work through the steps in a very methodical manner and do not take shortcuts.  Although I only document how to do this with one specific application, the process should be the same for any application but your mileage may vary.

The steps to follow are:

  • Prepare a clean test machine that has your text-to-speech software and your virtual application installed only.  This machine should also have the Process Explorer executable already copied to it.  For the example in this post, I am testing the JAWS screen reader program.
  • Open Process Explorer and then run the locally installed text-to-speech application.
  • Locate in the Process column the executable for the application, and select it (in this example, jfw.exe).
  • Go to the View menu in Process Explorer and select “Handles” from the Lower Pane View sub menu.  You will also need to enable this lower pane from the same menu if it is not shown.
  • In the lower pane you will see a list of all the Handles that the process currently has open, click on the Name column heading in order to sort the list alphabetically by this column.  You can see an example of this in the below screenshot.

 

  • At (or near, the top) of this list of Headers you will see many objects that begin with the string “\BaseNamedObjects\”, amongst this list will be the object(s) that need excluding from SystemGuard in order to make the text-to-speech software read the virtual applications.
  • Click on the File menu and choose “Save As”, then specify a location to save all the process information into a text file for the selected process.  You can now close Process Explorer as you no longer need it.
  • The next part of the process is to clean out all the non-essential information from this recently saved text file.  Open the text file and delete every line that does not contain the string “BaseNamedObjects”.  Once complete, your text file should look similar to the one in the screenshot below.

You need to remove all the duplicate entries in the file (there may be many) so that each line of the text file is a unique object record.  Additionally, depending on your level of expertise, you can remove any entries that you know are not related to either application or the functionality that they use; do this with caution though and don’t remove anything you are unsure about.

This is now a list of potential objects that need to be excluded from SystemGuard, it is highly unlikely that all of them need excluding, and I wouldn't recommend doing this anyway.  Next is the slow and laborious phase…!

 

  • Open the registry editor and navigate to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard\ObjExclusions, you’ll see that there are already 93 excluded objects from SystemGuard by default.

 

  • Now, you need to add one-by-one each of the objects from your text file and then test the applications to see if they work after each addition. You should not need to restart the computer or the App-V services on the computer, but at the very least you will need to close and re-open the virtual application each time you make a registry change.  The format for each object is as shown in the screenshot below, you will need to manually increment the numbered name of the REG_SZ entry for each new object you add.

You should trim the text from each line until it only includes the object name, and nothing else before or after it. For example, the line “Mutex    \BaseNamedObjects\JAWSOBJHELPEREVENT” becomes “JAWSOBJHELPEREVENT”.

 

An alternative method, and one I recommend, is to add all of the objects at the start and test the applications.  The benefit of this approach is that, by adding all the objects at the start rather than one-by-one, you can verify whether or not the object that needs excluding is actually in the list in the first place and that the applications work together with this registry change.  If they do work after adding all the objects, you can then simply remove objects one-by-one until the applications stop working correctly; when they stop working correctly you know that they object you just removed is the one that needs excluding.  If you need to add a lot of objects I would suggest scripting this change in order to save time, as the manual addition of each one will take considerable time.

 

There are a couple of other things you need to understand before commencing.  The first is that it is likely that more than one object needs excluding from SystemGuard, and the only way to identify this is through trial-and-error until you find the right combination of objects.  The second is that if you have multiple objects that begin with the same name then you can use wildcards in the registry strings rather than specifying each full name.  However, I prefer to avoid wildcards wherever possible and name the objects explicitly.  An example of wildcard usage is: ConfigSettings_SectionList_*

 

Just in case you are wondering, the objects that I had to exclude from SystemGuard in order to allow JAWS to work correctly are the ones below:

  • JawsDdiData
  • JAWSFOCUSCHANGED
  • JAWSIMEEVENT
  • JAWSMSAARefreshed
  • JAWSOBJHELPEREVENT
  • JAWSVD_CLIENT_RESET_EVENT_E9075180_85D8_42ea_967D_46F542B86E2E
  • JAWSVD_DATA_EVENT_0F9277D6_2CEE_41b5_A57C_5EBAC435A720
  • JAWSVD_FINISH_EVENT_53351F6B_E1B0_429f_B87E_4F2D671EFF47
  • JFWHodCaretMoved
  • jfwmacrokeys_jfw
  • jfwMSAAShare232640
  • JFWSendMsg
  • JFWSingleInstance

 

Finally, you should check with the application vendor to make sure that what you are doing with their applications will be supported by them.  The reason for this is that you could potentially only exclude some of the required objects from SystemGuard which might cause application issues internally within these applications further on down the line.

 

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

Comments

  • Anonymous
    January 01, 2003
    @Jørn  -  the exclusions apply to the App-V SystemGuard which is local on the machine rather than to the App-V packages.  In the example i described above, JAWS is installed locally on computers and with the solution provided here it allows it to work with the applications virtualised with App-V. I have not tried Skype in App-V I'm afraid so don't have any help there.

  • Anonymous
    January 01, 2003
    Daniel, I have done a "follow-up" post on my own on this very subject: blog.gridmetric.com/.../working-with-named-object-virtualization-exclusions

  • Anonymous
    January 01, 2003
    @ Kalle That is right, you'll need to include the keys in the client's registry.  i prefer it this way because it allows you to make these settings only on the computers that require it, rather than at a package level which means that every computer running the app has these exclusions whether they need them or not. so, using the example from the post, these settings i only rolled out to the computers running the text-to-speech software rather than using LOCAL_INTERACTION_ALLOWED which would have meant that all users would have had this setting. Daniel

  • Anonymous
    January 01, 2003
    I put together a couple of Powershell commands to automaticaly parse the Process Explorer log and import it into the registry. social.technet.microsoft.com/.../f42f8092-1da0-4a50-a482-39f4ef548714

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    But if the app requires passthrough settings in the first place, why wouldn't you want to have them for all users? Note that I'm not referring to LOCA_INTERACTION_ALLOWED, but rather doing those exclusions in the Sequencer's  HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5SystemGuardObjExclusions -key, if it indeed propagates customized exclusions inside App-V package to all clients (and only for that app/package)..

  • Anonymous
    January 06, 2012
    The comment has been removed