Archive

Archive for January, 2015

App-V 5: Further into COM and Dynamic Virtualization

January 13, 2015 3 comments

It has been addressed to me by the MVP community that more clarification is needed with regards to the architecture of how App-V 5 implements COM and how that may now differ as a result of the changes in Service Pack 2. The differences are simplified to the difference between the standard COM virtualization subsystem for normal virtualized applications and how Dynamic Virtualization handles COM objects for native processes that do not initially start off running virtually.

COM Virtualization

I have included a visual diagram to represent how the base virtual COM subsystem works to process virtual COM in-process and how out-of-process COM servers are managed in conjunction with the App-V Client Service and the Virtual Services component in preventing COM server conflicts among native and virtual applications and among applications running in different virtual environments.

The COM API’s are hooked by way of the injected App-V DLL. Depending on the COM settings, the Virtual COM service will be responsible for dynamically cloning COM registration within the virtual environment using generated spoofed GUIDS (or CLSIDs if you prefer that term – I use them interchangeably.) It will maintain a per-package (or Connection Group) GUIDS mapping of these spoofed-to-actual GUIDS. It will also be responsible for instantiating the cloned COM server(s) needed.

 

Enter App-V 5 Service Pack 2 and Dynamic Virtualization

Do not confuse the above with the added support for Dynamic Virtualization (also may be referred to as just-in-time virtualization or JITV.) The basic concept behind Dynamic Virtualization is that it allows the virtualization of shell extensions and ActiveX controls automatically within the native processes which would house them (Explorer.exe and Iexplore.exe) allowing for more tighter integration with the operating system.

Dynamic Virtualization modified App-V to allow:

  • Multiple Virtual Environments (VEs) to be associated with a single process.

  • Processes not running as a virtual process to have VEs associated with it.

 

App-V 5, through dynamic virtualization, allows virtualization of an in-process COM object implementing a shell extension or ActiveX control from the process that hosts it so long as that process appears under the ProcessesUsingVirtualComponents configuration item within the registry. Dynamic virtualization switches on for a thread that is executing within the object’s code or other code that is called from the object – rather than at the process level with standard virtualization. You can read up more on Dynamic Virtualization in a previous article mentioned here: http://blogs.technet.com/b/gladiatormsft/archive/2014/02/05/app-v-5-on-run-virtual-rds-run-virtual-virtualizable-extensions-and-dynamic-virtualization.aspx

A native process never has a package’s virtual environment associated with it by default unless it is hooked by App-V. Without dynamic virtualization, the only way for it to be hooked and associated with a primary VE would be to have a shortcut configured to the application within the package (in the case of App-V 5, also configured within dynamic configuration as being a virtual application.)

With dynamic virtualization, a process can have secondary virtual environments. These secondary virtual environments are differentiated from the primary virtual environment in that they are associated with one or more DLLs that are loaded into the process, and are used for virtualization only when they are dynamically activated and associated with a particular thread of execution. For any thread in which dynamic virtualization has not been activated, virtualization will be controlled by the primary virtual environment, if any.

When a shell extension DLL handler from a particular package is loaded into a native process or a process from a different package, a new secondary virtual environment will be created to associate the shell extension’s package with the process. When a thread of execution enters that DLL, dynamic virtualization will be switched on for that thread only and associated with the correct VE. When the thread exits the DLL, dynamic virtualization will be switched off for that thread, and finally, when the DLL is unloaded from the process, the corresponding secondary VE will exit.

If you want to control Virtual ActiveX controls (huh-huh – cheap pun there) in the old fashioned way for Internet Explorer where you launch a Shortcut to IE within the virtual environment, and not allow any other native instance of IE to launch that control you will want to remove Iexplore.exe from the ProcessesUsingVirtualComponents key within the registry key at HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization.

I would advise against turning off Dynamic Virtualization altogether as the dynamic virtualization features work great with the shell extensions that would be leveraged by Explorer.

It’s actually not entirely new to Service Pack 2

Dynamic Virtualization was actually part of the flattened Office 2013 package from the initial release of App-V 5.0. The Integration subsystem included with Office allowed for native processes that needed to load a DLL from the Office package – i.e. MAPI.

Advertisements
Categories: Uncategorized Tags: , , , , , ,

Manageability Lingo, Standards, & Acronyms, Oh My!

January 10, 2015 Leave a comment

acronyms

Since the dawn of the 21st century (and even before) you have been hearing many items related to acronyms interchangeably describing manageability features within Microsoft products (as well as others.) For example, WMI has been at the heart of most Microsoft Manageability products and solutions given the fact it is one of the primary interfaces within the Windows operating systems. While Microsoft’s WMI ties mostly to its products, it is based upon a series of open, universal standards. And this is the heart of deciphering how acronyms and standards can be interchangeably used to describe the same entity.

So let’s weave through the sometimes confusing relationship between these manageability acronyms – WBEM, WMI, CIM, DMI, DTMF, WSMAN, WinRM, and SNMP of protocols/interfaces/standards. In this little game, I will try to go through these acronyms within the average blog post attention span. WMI is Microsoft’s implementation of the open Web-Based Enterprise Management (WBEM), which comes from the Distributed Management Task Force (an industry organization.) WBEM relies on protocols – which can come from legacy standards such as RPC (Remote-Procedure Call) or DCOM (Distributed Component Object Model) or more modernized http-based SOAP standards such as WinRM (Windows Remote Management) based on the WS-MAN (Web-Services Management) standard. SOAP (Simple Object Access Protocol) itself, is is a command extension protocol designed to be used with HTTP (Hyper-Text Transport protocol – or the web) or SMTP (Simple Mail Transport Protocol – or internet email.)

The WMI interface – based upon the WBEM standard – is built upon an infrastructure centered upon the Common Information Model (CIM) and its respective Object Manager (CIMOM), is what links management applications and providers. The infrastructure also serves as the object-class store and, in many cases, as the storage manager for persistent object properties. WMI implements the store, or repository, as an on-disk database named the CIMOM Object Repository. As part of its infrastructure, WMI supports several APIs through which management applications access object data and providers supply data and class definitions.

Beyond WMI, WBEM’s architecture extends to a variety of underlying technologies besides WMI and Win32 because not everything is or will always be on Microsoft technologies – including the Desktop Management Interface (DMI), and the Simple Network Management Protocol (SNMP)  Some of these standards define data storage schemas as well as interfaces. Some define commands within communication protocols. Some or more modernized. SNMP has been deprecated in the most recent versions of Windows in favor of technologies such as WinRM.

I like to use the relationship of WinRM and WMI (alongside their open counterpart standards WS-MAN and WBEM) by stating that one is a management protocol and one is a management interface.

industry

To Read more, check out the standards themselves:

App-V 5: On the LocationProvider and the IgnoreLocationProvider Feature


In a previous blog entry, (http://blogs.technet.com/b/gladiatormsft/archive/2014/12/10/app-v-5-on-the-packagesourceroot.aspx) I discussed the PackageSourceRoot override and how it can be used to control source content locations for packages. There is another option for overriding source content locations for App-V packages: the LocationProvider registry value located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming.

This registry value is not designed to be changed or adjusted manually. It is simply a configuration item that denotes the COM interface and its subsequent registration. When this value is empty, that means there is no LocationProvider interface registered. If one is registered {by GUID} than whatever its setting for the package source root per package takes precedent over the PackageSourceRoot registry setting or other per-package settings. This is how the Configuration Manager client hooks into the App-V client. It uses the COM provider called the VAppLaunchManager which essentially takes over package management with an event-driven methodology.

From the context of how is overrides the PackageSourceRoot, think of this as being a replacement for the manual registry setting of the OverrideURL setting done in previous versions of App-V and SCCM integration. If the application has not been streamed or fully loaded, the App-V Streaming Subsystem will reference this interface to retrieve the Override URL for the package (i.e. the SCCM Distribution Point) from which the package will stream from. This will happen under each time there is a:

  • First connection to a package.

  • Reconnection after a previous session was closed or a user has logged off.

  • Change in the network (move to new network, network interface reset, etc.)

The interface will be registered initially once the clients receives the first targeted advertisement of an App-V 5 virtual application from Configuration Manager. This is a much improved experience from the implementation of Configuration Manager 2007 and App-V 4.6 as existing packages will remain on the client

Now this brings up another likely question: Can you create exceptions to clients being controlled by the Configuration Manager client or some other ISV that might leverage the LocationProvider interface? Let’s say you have a subset of computers within a collection that you not only do not want receiving virtual advertisements from Configuration Manager, but you may also desire managing the applications by way of another mean altogether. In previous implementations of Configuration Manager and App-V integration, field resources came up with using custom policy exceptions (see Rob York’s old blog here: http://blogs.technet.com/b/virtualworld/archive/2010/07/07/using-sccm-local-policy-to-selectively-restrict-app-v-integration.aspx) and this worked.

So if you wanted to globally manage all of your resource physical machines, virtual machines, and devices through Configuration Manager (including the delivery of virtual applications) except for possibly a subset of machines in which you may want to manage the applications in a stand-alone fashion (i.e. RDS Servers, etc.) – how do you go about setting that exception in App-V 5? You could probably easily go about the same process – but what if you wanted to use Configuration Manager to publish the applications but still take advantage of the PackageSourceRoot? Why? Well, for reasons such as:

  • Having multiple App-V delivery systems but would like to reduce duplicity on content between content servers and distribution servers.

  • You want to manage affinity with content locations out-of-band from Configuration Manager

  • You want to provide streaming high availability with better failover than the distribution point failovers in Configuration Manager (which are not instantaneous as load-balanced shares.)  

You can have this by setting the value IgnoreLocationProvider to 0x1 (DWORD) in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming. This setting will force the client to ignore the path returned by the LocationProvider interface and instead use the Package Source Root. This was first introduced in App-V 5 SP2 but it was somewhat problematic. The feature works well now in Service Pack 3.