New! Powershell in App-V 5; some example scripts

Using App-V 4.x we have become acquainted to the somewhat cumbersome command line management implementation of the App-V Client. Both options (SFTTRAY and specifically SFTMIME) did the job but they were only focused on the client, tough to understand and learn and even harder to customize to your need. Needless to say not the most powerful tools in the world.

In App-V 5 all command line scripting has been replaced with PowerShell (requires PoSh 3.0 as a minimum). As we’ve seen from other products of Microsoft the options that are available in the GUI are also available on command line.

There’s only one caveat: we have to learn it! (at least I did clip_image001)

There are several modules available in App-V 5, depending if you’re on the server, sequencer or on the client they are named [AppVServer], [AppVSequencer] or [AppVClient]. A new feature of using PoSh 3.0 is that the App-V cmdlets no longer need to be imported before they can be used. Each of the modules has a variety of cmdlets available for you to use. They can be queried by using the help command. Here’s an example for the AppVClient


As there are many of them I’ve chosen to write about the “getting started” cmdlets that you might want to use before or during an evaluation or migration to App-V 5.

Note: I’m no PowerShell guru, so there are probably better, quicker and shorter ways to achieve similar functionality. These worked for me, but feel free to comment if you have any comments.

Note 2: Some of the cmdlets require admin privileges.

Converting Legacy App-V packages

If you are an App-V 4.x customer you would have to migrate you App-V 4.x applications to be compatible with the new format. Don’t worry you don’t have to re-sequence your entire application estate!

The conversion process can be initiated by the [Test-AppvLegacyPackage], which will test the App-V 4.x package for compatibility and output any error and warning but does not convert the package, and the [ConvertFrom-AppvLegacyPackage] which does the same but also actually converts it. Some of the conversion process caveats are further described here:

# ConvertPkg.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
# This script enumerates through a given source dir and convert the App-V package to the given destination dir
# All actions will be logged in a log in the destination directory

# Remember to set execution policy (as administrator):
# Set-ExecutionPolicy Unrestricted
# Remember to import the AppVSequencer modules (as administrator):

#Define Source and Destination directories and create log file
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "C:\Convert\Source"
$TargetRoot = "C:\Convert\Destination"
$LogFile = $TargetRoot + "\Convert_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Enumerate through folder structure and find App-V packages to convert
$DirArray = Get-ChildItem -path $SourceDir -recurse | where{$_.PsIsContainer -and $_-notmatch ‘Icons’}
ForEach ($Dir in $DirArray)
$TargetDir = $TargetRoot + "\" + $Dir
If (Test-Path $TargetDir) {
} else{
  Write-Host "Creating $TargetDir" -Foregroundcolor Green
  New-Item -path $TargetDir -type Directory | Out-Null

# Convert or Test any found App-V package. Remove remark if required
# $Dir | Test-AppvLegacyPackage >> $LogFile
$Dir | ConvertFrom-AppvLegacyPackage -Destinationpath $TargetDir >> $LogFile | Out-Null

Adding App-V 5 package to the local App-V client

So if you have App-V 5 packages created, either converted or created, you’d want to test them on the new App-V client. The quickest way to test if the packages actually works is to add them locally to the App-V 5 client. The following table shows the old and new command line options to achieve this:

App-V 4.x

App-V 5







The following script allows you to import all packages from a certain source directory:

# AddPublishClient.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
# This script enumerates through a given source dir and adds and/or publishes and/or mounts the package to the client
# All actions will be logged in a log in the %temp% directory

# Remember to set execution policy (as administrator):
# Set-ExecutionPolicy Unrestricted
# Remember to import the AppV Client module (as administrator):

#Define Source directory and create log file
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "C:\Temp"
$LogFile = $env:TEMP + "\Import_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Loop through folder structure and find App-V packages
$Packages = Get-ChildItem -path $SourceDir -recurse | where{$_-match ‘.appv’}

ForEach ($Package in $Packages)
    #For package found add / publish / mount the package to the client
    #Remove quotes when required

    #Write-Host "Importing $Package" -Foregroundcolor Green
    #Add-AppvClientPackage $Package.FullName >> $LogFile | Out-Null

    Write-Host "Importing and publishing $Package" -Foregroundcolor Green
    Add-AppvClientPackage $Package.FullName | Publish-AppvClientPackage >> $LogFile | Out-Null

    #Write-Host "Importing, mounting and publishing $Package" -Foregroundcolor Green
    #Add-AppvClientPackage $Package.FullName | Publish-AppvClientPackage | Mount-AppvClientPackage >> $LogFile | Out-Null

Write-Host "Check out the log file $LogFile for any warnings or errors" -ForegroundColor Green

Adding Packages to the Management Server

Having a management server enhances the customization capabilities of deploying an App-V 5 application. Adding to and deploying applications through the management can be a manual process but can be automated as well. Remember that this was not possible in App-V 4.x (i.e. there are no API’s for importing packages into the server). Extremely useful to build a quick test environment or to automate a production environment!

The cmdlet [AppVServer] holds the possibility to add, grant and publish a package to the environment through scripting. The following script is an example of these actions:

# AddPublishServer.PS1
# by Ment van der Plas, Login Consultants
# October 2012 - version 0.1
# This script enumerates through a given source dir and adds and/or publishes and/or grants the package in the management console
# If required it can replace the UNC path (used for enumeration) with an HTTP path (used for streaming)

# Remember to set execution policy (as administrator) and import AppVServer module:
# Set-ExecutionPolicy Unrestricted

#Define Source and HTTP directory, create log file and set the group for publishing permissions
$Now = Get-Date -Format yyyyMMdd_HHmmmss
$SourceDir = "\\appvsrv3\content$"
$HttpDir = "
$Group = $env:USERDOMAIN + "\Domain Users"
$LogFile = $env:Temp + "\Import_" + $Now + ".log"
Write-Host "Creating $LogFile" -Foregroundcolor Green
#New-Item $TargetRoot -type Dir | Out-Null
New-Item $LogFile -type File | Out-Null

#Loop through folder structure and find App-V packages

$Packages = Get-ChildItem -path $SourceDir -recurse | where{$_-match ‘.appv’}

ForEach ($Package in $Packages)
    #Import, Grant and Publish the package to the App-V Server   
    #Write-Host "Importing, Granting and Publishing package: [$Package]" -Foregroundcolor Green
    #Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) | Grant-AppvServerPackage -Groups $Group | Publish-AppvServerPackage 2>&1 >> $LogFile | Out-Null

    #Import and Grant the package to the App-V Server. Not publishing! 
    Write-Host "Importing and granting: [$Package]" -Foregroundcolor Green
    Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) | Grant-AppvServerPackage -Groups $Group 2>&1 >> $LogFile | Out-Null

    #Import the package to the App-V Server. The packages are not granted not published!
    #Write-Host "Importing: [$Package]" -Foregroundcolor Green
    #Import-AppvServerPackage $Package.FullName.Replace($SourceDir, $HttpDir) 2>&1 >> $LogFile | Out-Null

Write-Host "Check out the log file $LogFile for any warnings or errors" -ForegroundColor Green

As you can see having PowerShell as an automation framework foundation really extends the product and allows extreme customization!

I hope these scripts help you get started with App-V 5!

Old habits die hard - Q: drive discussion resurrected with App-V 5

Note: all the information in this article is based on the publically released App-V 5 Beta 2 bits (available on connect) and may be subject to change in the final product.

In the past I’ve had many discussions with Microsoft, MVP’s, peers, customers and students about the need for installing to the Q: (Asset Folder) and many people, like Falko Graefe and Tim Mangan have written about it on their blogs. Microsoft’s best practice is to install to Q: and there are several reasons to do so. However they are also debated. Like the infamous performance decrease if one would install to C; which was never measured nor proven. Or like the increased success ratio of virtualized applications.

While talking to some of the attendees after a presentation I did last week we had a nice discussion on the topic in relation to the upcoming release of App-V 5. Making Microsoft’s best practice questionable.

Anyone who has been looking at, hearing of or seeing some the goodness of the upcoming App-V 5 release may have noticed that many things are different. One of them being the package format. Where the App-V 4.6 format was proprietary and had application metadata located externally in the package directory, the App-V 5.0 format is open (extended ZIP) and has all the relevant information inside a single file. This primarily makes the App-V 4.6 and 5.0 format incompatible for their clients, meaning that an App-V 5.0 client is unable to read and apply an App-V 4.6 package and vice versa.

Because Microsoft realized that re-sequencing an entire application landscape isn’t a good marketing pitch they have delivered a legacy package converter with the sequencer, which is operated through PowerShell. The converter is available in two flavors:

  • Test-AppvLegacyPackage (which test the legacy package for warning and errors)

  • ConvertFrom-AppvLegacyPackage (which actually convert the package, but also includes the warnings and errors)

Question that automatically raises is: “What will be the success rate of the conversion process?”

Because no application (nor package) is the same and the administrator may have customized it heavily, it is very hard to do an automatic conversion of one format to another. Therefor it won’t come as a surprise that there are some small caveats to the conversion process (which are also reported if applicable). Let me explain some of them.

OS Value

Microsoft App-V 5 is not supported on operating systems older then Windows 7 and Windows 2008 R2. This means that the converter actively checks if the <OS VALUE> is set and if unsupported operating systems are found, the following error is raised:

The package converter detected one or more applications in your package that is targeted for an unsupported operating system. This package cannot be converted unless the target operating system restriction is removed from the .osd file.

Having an OS limitation in the package doesn’t actually mean that the package won’t work on the target OS, but Microsoft wants to make sure that you manually configure this setting and most importantly test the application!

If you feel confident: OSD files can be batch-converted through scripting. An example of a powershell script can be found here:

Dynamic Suiting

If an OSD holds the <DEPENDENCIES> tag (used for Dynamic Suiting Composition) this will not be converted and will display the following warning:

This package has a dependency on the following package(s). To re-link these packages, apply an app connection group: Package: Camtasia.600.sft, Guid: 75AF56CD-62F3-4CB5-9097-8CC8CBB9E12D

Important: warning messages in the conversion process will still result in a converted, but slightly adjusted, package, whereas errors don’t convert the package at all.

To be fair, I can understand why Microsoft left this out. DSC has been replaced by Connection Groups and they are implemented quite differently. DSC was implemented in the package where connection groups are configured in the infrastructure environment or on the client. There’s basically no way to automate this process.

Scripts and Registry

The legacy package converter doesn’t migrate any <SCRIPT> or <REGISTRY> tags that are part of the package and gives the following warning:

The package converter detected the following script(s) in the legacy package. The script was not converted into the package. Please evaluate whether the script applies to the new package. Instructions for how to add scripts into an App-V 5.0 package can be found in documentation.

The package converter detected but did not convert the following registry variable(s) in the legacy package. If the package does not function correctly, consider manually implementing the registry variable override via policy.

As scripts or registry have deliberately been added to the package by the engineer, it’s probably well documented why this script needed to be applied (yeah right). At least hopefully someone can remember and identify if the script needs to be applied to the new package.

Important: these tags now end up in the manifest.xml file inside the package or can be overruled by the Deployment or User configuration xml files outside the package file. This does bring a small functional change to the table: 4.6 scripts and registry tags could differ per application (OSD file) but in App-V 5 they can only be implemented per package. This architectural change might have influence on the application and/or script behavior.

So what’s the link to the Q: drive discussion?

Well, basically Microsoft recommends that all applications are preferably sequenced to Q: and that only exceptions should be installed to C:. And you are probably also aware of the fact that App-V 5 no longer requires (or actually has) a Q: drive. From what I’ve seen from the conversion process I would like to argue that sequences that are NOT sequenced to Q: are more likely to work after conversion to App-V 5.0.

Allow me to explain: the 4.x sequencer would replace common locations with App-V variables (CSIDL_*) as much as possible. However this was limited to values in for example the registry and environment variables.

Environment Variables

If a package would for example extend the PATH variable with [C:\Program Files\Common Files\Application] because it has installed some dll’s at that location, the sequencer would pick that up and replace it with %CSIDL_PROGRAM_FILES_COMMON% variable.




The legacy package converter recognizes this variable and replaces it with {ProgramFilesCommonX86} in the Manifest.xml files.


<Variable Name="PATH" Value="[{ProgramFilesCommonX86}]\Application" />


And on the client this is resolved to the corresponding (virtual) directory in the VFS:


Note: this does not guarantee that the application will actually work, like in the example below:


Configuration files

Many applications save configuration in designated files and not in the registry. Unfortunately the
sequencer is unable to detect those text-based files and replace them with variables, like in the example below:


Just like the sequencer, these files are also not picked up by the converter and the file is identical after the conversion. Because it holds a location that is not available, the package will probably behave differently or
not function at all.


Now what if these applications were sequenced to the C: drive instead of the Q: drive?

Configuration files that were created during installation would hold a location that is not App-V specific (like on the Q: drive) but generic (like on the C: drive). The conversion process would literally migrate the value to the new App-V 5 format. In both cases the file would end up in the Virtual File System (VFS) of the application package and the configuration entry would point to that location as well. Which is good because that location is identical in both cases and the App-V engine would make sure that it’s redirected to the corresponding folder.

So my conclusion is that, if other aspects of the environment don’t change (like you simultaneously migrate from an x86 to x64 operating system) and it’s an “in-place” upgrade of the App-V environment, applications that are / were sequenced to C: have a much higher chance to be successfully converted then applications that were sequenced to Q:.

So if you are planning to migrate anywhere in the future, this might be a good time to rethink your sequence strategy. It might be beneficial in the future!