Difference between revisions of "Microsoft App-V"

From WPKG | Open Source Software Deployment and Distribution
Jump to: navigation, search
(Do a global unpublish, since we did a global publish. Technically this is not necessary because it's always used with a remove, but should someone modify this, it'll be important.)
(clarified some wording and added notes based on my recent operational experiences)
Line 23: Line 23:
 
             for details-->
 
             for details-->
 
         <install cmd="&quot;%SOFTWARE%\AppV\%PKG_VERSION%\Client\appv_client_setup.exe&quot; /ACCEPTEULA /MUOPTIN /q"/>
 
         <install cmd="&quot;%SOFTWARE%\AppV\%PKG_VERSION%\Client\appv_client_setup.exe&quot; /ACCEPTEULA /MUOPTIN /q"/>
 +
        <!-- This looks like a good place to do configuration with
 +
            set-appvclientconfiguration, but without a check condition
 +
            to verify your configuration is in place, it won't actually
 +
            work because App-V isn't ready for you to do this until
 +
            after a restart. -->
  
 
         <upgrade include="install"/>
 
         <upgrade include="install"/>
Line 33: Line 38:
  
 
Once the client is installed, it can operate with an App-V server or in [http://blogs.technet.com/b/virtualvibes/archive/2013/03/12/app-v-5-0-standalone-mode-adding-and-publishing-a-package.aspx stand-alone mode]. With a server, there is no WPKG involvement once the client has been installed and configured. Without an App-V server, WPKG either delivers MSI packages or executes PowerShell scripts to inform the client of new App-V packages. Don't mix MSI and PowerShell deployment: pick one for your environment and stick with it.
 
Once the client is installed, it can operate with an App-V server or in [http://blogs.technet.com/b/virtualvibes/archive/2013/03/12/app-v-5-0-standalone-mode-adding-and-publishing-a-package.aspx stand-alone mode]. With a server, there is no WPKG involvement once the client has been installed and configured. Without an App-V server, WPKG either delivers MSI packages or executes PowerShell scripts to inform the client of new App-V packages. Don't mix MSI and PowerShell deployment: pick one for your environment and stick with it.
 +
 +
PowerShell deployment works well with WPKG.
  
 
== Deployment with PowerShell ==
 
== Deployment with PowerShell ==
Line 42: Line 49:
 
=== Package template ===
 
=== Package template ===
  
−
This template will work for a typical App-V package. Change the ID, the name and the two variables.
+
This template will work for a typical App-V package. Change the ID, the name and the <code>PKG_SHORTNAME</code> and <code>PKG_PATH</code> variables.
  
 
<source lang="xml">
 
<source lang="xml">
Line 54: Line 61:
 
     <depends package-id="appv_client" />
 
     <depends package-id="appv_client" />
  
 +
    <!-- If your package works on all architectures: -->
 
     <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage\MyPackage.appv" />
 
     <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage\MyPackage.appv" />
 +
 +
    <!-- If your package doesn't: -->
 +
<!--
 +
    <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage_32\MyPackage.appv" architecture="x86"/>
 +
    <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage_64\MyPackage.appv" architecture="x64"/>
 +
-->
 +
 
     <variable name="PKG_SHORTNAME" value="MyPackage" />
 
     <variable name="PKG_SHORTNAME" value="MyPackage" />
  
Line 63: Line 78:
 
     <install cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; if (add-appvclientpackage -path $env:PKG_PATH | publish-appvclientpackage -Global | mount-appvclientpackage ) { exit 0 } else { exit 1 }&quot;" condition="exitcodeequalto" />
 
     <install cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; if (add-appvclientpackage -path $env:PKG_PATH | publish-appvclientpackage -Global | mount-appvclientpackage ) { exit 0 } else { exit 1 }&quot;" condition="exitcodeequalto" />
  
 +
    <!-- Unpublishing may be overkill -->
 
     <upgrade cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; unpublish-appvclientpackage -Global $env:PKG_SHORTNAME; remove-appvclientpackage $env:PKG_SHORTNAME" >
 
     <upgrade cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; unpublish-appvclientpackage -Global $env:PKG_SHORTNAME; remove-appvclientpackage $env:PKG_SHORTNAME" >
 
       <exit code="any"/>
 
       <exit code="any"/>

Revision as of 00:29, 4 March 2014

Microsoft App-V is an application-virtualization product available to Software Assurance customers as part of the Desktop Optimization Pack.

While App-V is technically not an application compatibility solution, it can be helpful in getting old or poorly-designed software to work on Windows 7 or Windows 8. Applications packaged for App-V are isolated from each other, so two applications that conflict with each other can run on the same computer. App-V is also very good for deploying software that has a messy or complicated installation or removal process, so long as the software doesn't require DCOM, shell extensions, special drivers or machine-specific customization.

Client

App-V Client 5.0 SP2

The 5.0 SP2 client requires the Microsoft .NET Framework 4.5 and Microsoft Windows Management Framework 3.0. These are included with Windows 8 and Server 2012. Although Windows is not a .NET Framework delivery channel, App-V is so tightly bound to the operating system that a new App-V will be needed with future Windows releases anyway. 

<package id="appv_client" name="Microsoft App-V 5.0 SP2 Client" revision="%PKG_VERSION%" reboot="false" priority="2">

        <variable name="PKG_VERSION" value="5.0_SP2"/>

        <depends package-id="dotnetfx45" os=".+6\.[0-1]\.\d{4} "/>
        <depends package-id="wmf3" os=".+6\.[0-1]\.\d{4}" />

        <check type="uninstall" condition="exists" path="Microsoft Application Virtualization (App-V) Client 5.0 Service Pack 2"/>

        <!-- Edit this as required in your environment. See
             http://technet.microsoft.com/en-us/library/jj713460.aspx
             for details-->
        <install cmd="&quot;%SOFTWARE%\AppV\%PKG_VERSION%\Client\appv_client_setup.exe&quot; /ACCEPTEULA /MUOPTIN /q"/>
        <!-- This looks like a good place to do configuration with 
             set-appvclientconfiguration, but without a check condition
             to verify your configuration is in place, it won't actually
             work because App-V isn't ready for you to do this until
             after a restart. -->

        <upgrade include="install"/>

        <remove cmd="&quot;%SOFTWARE%\AppV\%PKG_VERSION%\Client\appv_client_setup.exe&quot; /UNINSTALL /q"/>
</package>

Deploying App-V Packages

Once the client is installed, it can operate with an App-V server or in stand-alone mode. With a server, there is no WPKG involvement once the client has been installed and configured. Without an App-V server, WPKG either delivers MSI packages or executes PowerShell scripts to inform the client of new App-V packages. Don't mix MSI and PowerShell deployment: pick one for your environment and stick with it.

PowerShell deployment works well with WPKG.

Deployment with PowerShell

Deployment with PowerShell uses two steps: first, the package is added with Add-AppvClientPackage, and then it is published with Publish-AppvClientPackage. Typically you'll use the -Global flag to publish a package to all users, but you could use a login script or a script dropped into the Start menu to publish packages to only the logged-in user instead.

You may want to use Mount-AppvClientPackage to cache the package to local disk so that it will work even if the network is disconnected the first time the user tries to run the program. This is not necessary if you specify a PKG_PATH that will be available the first time the user tries to run the program.

Package template

This template will work for a typical App-V package. Change the ID, the name and the PKG_SHORTNAME and PKG_PATH variables. 

<package
     id="MyPackage"
     name="MyPackage via App-V"
     revision="4"
     reboot="false"
     priority="2">

    <depends package-id="appv_client" />

    <!-- If your package works on all architectures: -->
    <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage\MyPackage.appv" />

    <!-- If your package doesn't: -->
<!--
    <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage_32\MyPackage.appv" architecture="x86"/>
    <variable name="PKG_PATH" value="%SOFTWARE%\AppV\packages\MyPackage_64\MyPackage.appv" architecture="x64"/>
-->

    <variable name="PKG_SHORTNAME" value="MyPackage" />

    <check type="execute" path="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; if (get-appvclientpackage -name $env:PKG_SHORTNAME ) { exit 0 } else { exit 1 }&quot;" condition="exitcodeequalto" value="0" />

    <!-- The mount-appvclientpackage command caches the package locally and can be removed if undesired -->

    <install cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; if (add-appvclientpackage -path $env:PKG_PATH | publish-appvclientpackage -Global | mount-appvclientpackage ) { exit 0 } else { exit 1 }&quot;" condition="exitcodeequalto" />

    <!-- Unpublishing may be overkill -->
    <upgrade cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; unpublish-appvclientpackage -Global $env:PKG_SHORTNAME; remove-appvclientpackage $env:PKG_SHORTNAME" >
      <exit code="any"/>
    </upgrade>
    <upgrade cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; if (add-appvclientpackage -path $env:PKG_PATH | publish-appvclientpackage -Global | mount-appvclientpackage ) { exit 0 } else { exit 1 }&quot;" condition="exitcodeequalto" />

    <remove cmd="powershell -executionpolicy bypass -noprofile -command &quot;&amp;Import-Module AppvClient; unpublish-appvclientpackage -Global $env:PKG_SHORTNAME; remove-appvclientpackage $env:PKG_SHORTNAME" >
      <exit code="any" />
    </remove>
</package>

Additional information

If you require additional features or if you're using connection groups (sets of AppV packages that share an environment), see:

Sequencing

To save time, sequencing a package should be performed on a virtual machine. Install and patch the base operating system, then install the sequencer and then take a snapshot. You'll revert to this snapshot every time you want to sequence a new package or edit an existing package. Do not install WPKG on the sequencing VM.

For further details:

Retrieved from "https://wpkg.org/index.php?title=Microsoft_App-V&oldid=11985"