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:
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:
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…!
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:
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
Very interesting article, thank you for it.
One question however about the object exclusion method you are describing: although it is not explicitly said I assume from the advice for service restart that you are adding the exclusions into App-V _Client_'s registry? This hardly is a "better" option than LOCAL_INTERACTION_ALLOWED per se because you need to touch each and every App-V Client's registry ;-)
However, there is also a object exclusion in the Sequencer's registry which - if I have not been mistaken (not yet tested it) - actually affects a list of object exclusions stored inside the SFT package (inside the osguard.cp file). Have you tested if App-V Client honors this objects exclusion list as I cannot fathom any other reason why the App-V package would carry such information? If it does work like this, too bad that the Sequencer does not expose this information in the GUI anywhere for editing per package basis, you just have to do it into registry prior to launching Sequencer.
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.
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_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard\ObjExclusions -key, if it indeed propagates customized exclusions inside App-V package to all clients (and only for that app/package)..
I have done a "follow-up" post on my own on this very subject: blog.gridmetric.com/.../working-with-named-object-virtualization-exclusions
I put together a couple of Powershell commands to automaticaly parse the Process Explorer log and import it into the registry.
I have the same challenge as Daniel, making Freedom Scientific JAWS and MAGic process events and objects from AppV packaged applications. Again, the registry solution is good as only some machines (XenApp 6.5 servers in my case) should run the accessibility software.
From what I read here, the exclusions applied to the registry refers to the locally installed JAWS? Bur it would appear that the exclusions should refer to the AppV packaged application. This is to a large extent confirmed by Kalles very good Skype example.
Is JAWS in your (Daniels) case packaged together with the AppV application so that it works with the Freedom Scientific DLL hook? That'd make for a very large package. Any help on understanding these two examples of exclusion (JAWS local and Skype as an AppV application) would help.
@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.