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 SP3

The 5.0 SP3 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 may be needed with future Windows releases anyway.

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

        <variable name="PKG_VERSION" value="5.0_SP3"/>
        <variable name="PKG_VERSION_INTERNAL" value="5.0.10107.0"/>
        <variable name="PKG_VERSION_APPEND" value="-3"/>
        <variable name="PKG_NAME" value="appv_client_setup.exe" os="7.+(enterprise|ultimate|professional|premium).+6\.1\.\d{4}" />
        <variable name="PKG_NAME" value="appv_client_setup.exe" os="windows +8.+6\.[23]\.\d{4}" />
        <variable name="PKG_NAME" value="appv_client_setup_rds.exe" os="windows.+server" />  

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

        <check type="uninstall" condition="versiongreaterorequal" path="Microsoft Application Virtualization (App-V) Client" value="%PKG_VERSION_INTERNAL%"/>

        <!-- This is a workaround for a defect in KB2984972 -->
        <check type="registry" condition="equals" path="HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions\93" value="TermSrvReadyEvent" />

        <!-- 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 /NORESTART /q">
          <exit code="0" />
          <exit code="1638" />
          <exit code="3010" restart="true" />
        </install>
        <install cmd="&quot;%WINDIR%\system32\reg.exe&quot; add HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions /v 93 /t REG_SZ /d TermSrvReadyEvent /f" />



        <!-- 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 cmd="&quot;%WINDIR%\system32\reg.exe&quot; add HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions /v 93 /t REG_SZ /d TermSrvReadyEvent /f" />
-->


        <remove cmd="&quot;%SOFTWARE%\AppV\%PKG_VERSION%\Client\%PKG_NAME%&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:

Microsoft documentation
Other resources
- App-V Recipes & Tips
- New! Powershell in App-V 5; some example scripts, especially valuable if you've used App-V 4
- PowerShell Script to test App-V 5.0 Packages

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:

Microsoft App-V