App-V: On COM+

  • [アーティクル]

Throughout the history of App-V and Softgrid, you have likely read from many sources that COM+ cannot be virtualized. Many tools, including the App-V sequencer, contain detection logic that will also notify you of the presence of COM+ components when you are attempting to sequence an application.

COM+ evolved from DCOM (Distributed Component Object Model) and has historically been used to develop components that leverage transactional technologies including SOAP, JIT (Just-in-time) activation, queued components, and more. If you want to dive into this further, you can find some good developer references are here:

https://msdn.microsoft.com/en-us/library/ms685978(VS.85).aspx

https://msdn.microsoft.com/en-us/library/ms973847.aspx

Be careful not to confuse COM+ with an out-of-process COM server, which can be communicated with by enabled local interaction in the virtual application in 4.x or configuring out-of-process integrated COM in the deployment configuration of an App-V 5.x application.

For an application to be able to use COM+ Services, they will need to be configured within the COM+ Catalog. One easy way to do this is using the COM+ Component Services Snap-in that comes with Windows where you can configure most of the settings for COM+. Since Com+ actually generates dynamically at run time not during the actual installation, the sequencer is not able to process it, therefore is cannot be captured into a static state like other installation assets. When COM+ came on the scene in Windows 2000 with distributed transaction servers, application virtualization was not taken in to consideration.

When Microsoft developed Server App-V, the Server App-V sequencer was designed to capture COM+ components created by the application installer along with other elements such as local groups and WMI. Since there is state separation and not isolation, COM+ is not sandboxed, but laid down during deployment through its normal registrations so it can function normally at run time.

Remediating COM+ Limitations with App-V

If your sequencer happens to detect and notify you of a COM + component, it is telling you that this application may not function correctly as expected with the package as-is. Does this mean that the application cannot be virtualized with App-V and delivered via an App-V delivery system? Not necessarily. Like other components that cannot be virtualized (such as drivers,) it does not necessarily mean that you are completely out of luck. In fact, there are possible remediation options. And with App-V, we have more options to implement these remediation fixes. In a sense, you can package the component to be laid down during deployment in a similar manner (but not identical) as it is with Server App-V.

Once you are made aware of a COM+ component within an application, you will need to install the application natively on a test machine. Then you will need to launch the Component Services management console (HINT: I am always confused as to which operating system launches this so I just launch DCOMCNFG and it always launches it.) You should likely find the component or components within the COM+ Applications folder under "My Computer."  

 

Once you locate it you can then right-click the component and select “Export.”

 

This will launch the COM+ Application Export Wizard.

 

You will then give the path and name to the destination MSI file you want to export this application to. 

 

Accept defaults and select ‘Next’ then ‘Finish’.

Now you will need to either re-sequence the application or update the existing package and during sequencing or updating, add the MSI file to the package. In the case of a V 5 package, I would usually add it into the \scripts folder.

If you are using App-V 4.x, you will want to edit the OSD file and add in a script that will install the Copy out the MSI file and run the installer. You do this by adding the following beneath the <DEPENDENCY> tag.

<SCRIPT TIMING="PRE" EVENT="LAUNCH"WAIT="TRUE" PROTECT="TRUE">

  <SCRIPTBODY>

        echo off \n

       if exist C:\<PATH_TO_WHERE_I_PLACE.MSI> goto end \n

        mkdir <PATH_TO_WHERE_I_PLACE_MSI> \n

        copy /y "q:\<PATH_INSIDE_PACKAGE>\mymsi.msi ” “C:\<PATH_WHERE_I_PLACE.MSI> ” \n

  </SCRIPTBODY>

</SCRIPT>

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="FALSE">

  <SCRIPTBODY>

        echo off \n

        if not exist C:\<PATH_TO_WHERE_I_PLACE.MSI> goto end \n

       C:\<PATH_TO_WHERE_I_PLACE MSI>\mymsi.msi /quiet \n

        del /f /q C:\<PATH TO WHERE_I_PLACE_MSI>\mymsi.msi \n

        :end \n

  </SCRIPTBODY>

</SCRIPT>

Now, let’s be realistic. For the above to work, you must accept two siginifcant caveats. 1) The user executing the application will need to be a local administrator. This is often a deal-breaker. 2) The user will have to encounter a delay upon launch due to the installation.

App-V 5.x

Enter App-V 5 and its enhanced scripting model. On either a global publish or add package event, you can add deploy the component in a secure manner as those events will execute under the context of the SYSTEM account. You can place the MSI and the scripts installing\uninstalling it into the embedded scripts folder inside the package. HINT: Since the script event only allows for one command element, my advice is to but all of the installation commands into a batch file or PowerShell script and call that script for the event. Since the scripts and package root directory in the package are automatically searched, you do not have to worry about specific paths.

     
<AddPackage>

        <Path>Powershell.exe</Path>

        <Arguments>-F deployComPlus.ps1</Arguments>

        <Wait RollbackOnError="true" Timeout="30"/>
     
</AddPackage>

<RemovePackage>

        <Path>Powershell.exe</Path>
       
<Arguments>-F removeComPlus.ps1</Arguments>

        <Wait RollbackOnError="false" Timeout="60"/>

</RemovePackage>

In the interest of full disclosure - with regards to this working seamlessly, I am 3 for 4 as I write this. In my opinion, .750 is a good batting average! Understand that this is meant to be an option for remediation as COM+ still technically cannot be virtualized.

Comments

  • Anonymous
    November 08, 2013
    The comment has been removed

  • Anonymous
    November 08, 2013
    Maybe you can write up a similar article on DCOM?

  • Anonymous
    November 08, 2013
    @Tim: Now bear in mind, the sequencer detects DCOM and COM+ separately for a reason. Don't have anything for that yet. @Rory - that is good feedback.

  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

  • Anonymous
    December 07, 2016
    Hi all, small question : if a manufacturer MSI, at runtime (after logon via application interface), queries the COM3\COM+Enabled registry key and then loads the clbcatq.dll + makes some FileOps on Windows\Registration\R000006.clb files , is it possible to virtualize this app with App-V 5.x ?

  • Anonymous
    July 03, 2017
    If you are going for finest contents like me, just pay a quick visit this web site everyday as it offers feature contents, thanks