Working with named object virtualization exclusions

On a fairly recent post over at Deployment Guys blog about ways of enabling local interaction, its author discussed about (better known) way of using LOCAL_INTERACTION_ALLOWED policy in OSD to enhance virtual application interaction with local applications, and a much lesser known feature of setting specific named object exclusions. The gist of the article is that it might be smarter to enable only those named objects (meaning events, mutexes, mailslots etc.) that virtual application needs to expose to local applications instead of having all objects be excluded as result of using the policy.

At this point you might already wonder about what all of these strangely sounding things mean – objects and namespaces and whatnot – so brief introduction of the concepts might be a good idea as a starter.

Basically, when application is run under App-V virtualization, nearly all of its named object resources that are registered in to Windows Object Manager are privatized to appear only for that virtual environment in either global or in session specific namespace (session specific namespaces were introduced to Windows because of Terminal Services and isolate applications between sessions. However not all applications at the time played well with multi-user scenario, most likely because they used the global namespace for their named objects. Fortunately this is less of a problem today than before, but it is still possible that some legacy or badly written applications do not take this factor into account; it is here where App-V’s isolation of objects can help making applications multi-user system friendly).
This means that App-V modifies the name of the object so that it is unique to that virtual environment and not how application intended it to be. Now, obviously any API calls using those object names made by application or other applications in the same package are also modified by App-V Client so that they will always find it. But any external (to VE) process trying to find such objects using original name won’t see them as the names don’t match anymore. And this can cause some interaction issues with local applications, since not all object resources privatized pre VE are coming from application itself but are result of virtual application accessing functionality from the local system, causing potential mismatch when applications interact between each other.

By using LOCAL_INTERACTION_ALLOWED  policy set to TRUE, App-V won’t change any of the object names to private but instead they will appear both in global namespace as well as in [Windows user] session specific namespace in their original names.

To illustrate this, let’s take a virtualized Skype as an example. When Skype is running under App-V, when looking at it using Process Explorer, you can see that nearly all objects under BaseNamedObjects path (global ones starting with \BaseNamedObjects\ and session specific ones starting with \Sessions\SessionNumber\BaseNamedObjects\) are prefixed with “sg” and something which looks like Yet Another GUID:

Note that there are some objects which aren’t prefixed; these are likely because of the default set of object exclusions already present in the client registry (which Daniel tells to edit to add custom ones) or in the package or both. Yes, there are also object exclusion entries in the App-V packages themselves and they for the most part come from the list of exclusions in the Sequencer registry.

But let’s get back to this little bit later on, for now let first see the effect of enabling LOCAL_INTERACTION_ALLOWED policy for the package. For quick testing I just edited cached OSD file for Skype in App-V Client OSD cache, you will need to launch Notepad or other editor as administrator and copy-paste the path to the cached OSD from application properties in App-V Client Management Console:

When launching Skype again, we can see that all the previously privatized object names are now completely untouched by App-V Client and appear as they would for a locally installed version of the same application:

This, along with the way how COM object instantiation rules changes when policy is enabled, is what makes applications to “interact” better with the local system. Now not only can virtual applications see local applications’ objects in the object namespace (as expected always), but the reverse is also true.

Seeing that how we can enable everything, let’s get back to our original intention of making only some of these objects to be created without privatization process much like what was mentioned in the Deployment Guys blog post but without needing to  touch the client registry. At this point it should also be repeated that the decision on what to exclude is of course dependent on you knowing what to exclude so that of course would be the first step before starting to enable stuff.

As I mentioned earlier – and what I tried to query from Daniel on that other blog post’s comments and then went on and verified myself – it is possible to make object name exclusions also per package basis as compared to editing client’s registry which will affect all virtual applications. Not to mention the whole deal of having the hassle of needing to touch all client machines for this purpose. And there’s two ways of doing this exclusion thing per package basis..

The first one is to edit Sequencer’s registry as it contains the exactly same ObjExclusion key under SystemGuard key listing the exclusions as separate values, like the identical key in the client registry used in the linked blog article. Sequencer takes all name exclusion entries inside this key and stores them into the package as part of the sequencing process. And when stored inside the package, App-V Client will use it in addition to what’s said in the client’s registry!
However it looks like that if you don’t actually launch anything during the sequencing process (either when installing and/or doing package optimization phase), package does not contain exclusion entries at all making it rely on entries at the client registry only! I have noticed this from several of my packages, more so in packages done with recent versions of App-V, and I think it indeed is because of not launching the applications which has been habit of mine in recent years since I have not used App-V streaming infra much anymore (hence FB1/FB2 division doesn’t matter that much if at all). But when Sequencer records this list into the package, it takes all your custom object name exclusion entries added to the Sequencer’s registry key in addition to what’s there by default. And this neatly customizes exclusions without needing to touch the client’s registry.

On a related note: what I am pretty sure of – but haven’t verified yet – is that the one option in the Sequencer’s Options screen, called “Allow virtualization of events”, and which has never been properly documented anywhere, affects the process described above so that if the setting is off (i.e. non-checked) Sequencer will not write any object exclusion items into package. Thus the resulting package would only use whatever object exclusions are set at the client level:

(Note that in 4.6 SP1 there’s also a separate setting called “Allow all named objects and COM objects to interact with the local system”, which sets the LOCAL_INTERACTION_ALLOWED policy for the package.)

 As an example for specific exclusion and its effect on the object namespace, let’s look at that Skype again. We can identify one very clear Skype –specific object in the list of many different objects (here shown without privatized name as we still have our policy in effect in the OSD file), called “SkypeMutex”:

If we want to exclude that one object, let’s add new entry to the Sequencer registry and re-do the Skype sequence (remember to run the Skype during process so that the exclusion list won’t be empty inside the package!):

After sequencing and deploying to the client, we can see with Process Explorer if the change has any effect. Client registry has not been touched so object exclusion entries over there won’t exclude our SkypeMutex. And indeed, among the list of still excluded entries we now have one of the previously privatized objects now “visible for all” and all without needing to do changes to App-V Client itself!

Just what we needed so mission accomplished (note that this is fully fictious case in that enabling local interaction for “SkypeMutex” object does not improve the Skype in any way but could actually cause two separate sequences of Skype to conflict each other in the same session, if you were to sequence Skype in two separate App-V packages. That’s because named of the said mutex very much sounds like a mechanism for Skype to check if there’s already an instance of it running on the session, not that I know that for sure).

Granted, setting these exclusions pre-sequencing in the registry is a very time-consuming as compared to setting them on the client registry, because in order to have exclusions written into package requires that you start from the scratch for you App-V package. I’m not sure if exclusions in the Sequencer registry affect package upgrade scenarios in any way, but it does not sound likely that Sequencer just goes and overrides things already in the existing package. And in either case, it makes iterative cycle of trying to find correct object exclusion very, very time consuming.

And that kind of leads us to the promised second way of setting the object exclusions.
It’s not actually available yet, but it will be in the next version of our AVE product and was the main reason I was inspired to go digging little bit deeper on how they work exactly. As you may know, AVE has always showed most everything there is to the App-V package save for this very thing: object exclusions. Now in upcoming 2.3 we will add plugin to show and modify list of object exclusions found inside the package, which makes it much faster to do customization of the list should you need to add app-specific object exclusions but do not want to use LOCAL_INTERACTION_ALLOWED trick:

As you can see, my Skype package actually did not contain any exclusion items by default (the result of what I mentioned earlier about not running application during sequencing). And I just added one object name there manually and re-saved the package, imported into client and was immediately able to see the change in Process Explorer’s list.

To compare, here’s screenshot from some other package that shows that Sequencer has indeed stored list of exclusion items inside the SFT file (in osguard.cp file):

Note that some of the entries use asterisks in what looks like a wildcard fashion, so it seems that wildcarding is supported. Selecting one of them – *msfthistory* – and trying to do handle search in Process Explorer for “msfthistory” string yields several results which all would indeed not had been matched with explicit object name:

It should also be noted that the list of object exclusion items has somewhat evolved over time in different versions of App-V, probably in part due to numerous support cases etc. to Microsoft complaining that some specific application or technology does not work correctly when in virtual bubble. For example, I noticed that packages created with older Sequencer do not seem to have any wildcarded entries like in the screenshot above, so it’s possible that capabilities of the object exclusions has been improved over time in that way as well. On the other hand, old object exclusion entries did show entries that were clearly partial words so maybe the implicit assumption in the past has been to do “fuzzy” matching and currently use of asterisks are required for it.

As a closing note, I have to say that it does looks like that more and more applications needs local interaction enabled in App-V (to at least some degree) in order to function properly, so hopefully this post gave more pointers on what to look for and why things are like they are. And I don’t know if the increased need for local interaction has been general evolution on how Windows applications are and how they interact with the system as opposed to applications (and operating systems!) of the past, or if it’s due to change in App-V’s internal implementation (especially since 4.6) with regards to virtualization and isolation itself. In either case, you can shoot with big gun (LOCAL_INTERACTION_ALLOWED) or with sniper precision (named object exclusions), each having their own share of hardships.