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!

Diagnostics in the App-V 4.6 SP1 Sequencer

About 12 months after the initial release of App-V 4.6, Microsoft released the first Service Pack of version 4.6 of its Application Virtualization product. App-V 4.6 SP1 covers many exciting new features and the most interesting part of it is that practically all of them are around the sequencer! As far as I know this is the first time in the history of App-V that so much effort and improvement is done only in the tool to transform traditional applications into virtual ones. In this post I will address one of the features I like the most and have been asking for and talking about for years: internal diagnostics.

Most organizations turn to App-V because they want to reduce the Total Cost of Ownership (TCO) of their IT infrastructure. For App-V this cost efficiency lies in the fact that the process of creating virtual applications is simplified compared to traditional applications. Traditional applications are more difficult to create because they make assumptions about their execution environment and make changes to the target system, which could potentially decrease the stability of the system or cause other applications to malfunction. Virtual applications however never make changes to the system and their dependencies can be either virtualized together with the main application or suited as a separate virtual application.

But as with any piece of technology, App-V also has its limitations. Some applications, or parts of an application, may not work correctly when they have been virtualized. Applications that are tightly integrated with the operating system or for example use COM+ or kernel-level drivers, contain components that are not supported with App-V. The issue with all previous versions of the sequencer is that to know that an application has such components, you’d have to virtualize and test it on a target machine. This means that you’ve already went through the entire virtualization process.

Service Pack 1 of App-V has been altered just for this scenario. When the sequencer notices that the applications uses unsupported components it will bring this to your attention during the sequencing process. This way you don’t have to go through the process of testing and troubleshooting the application only to find out it can’t be virtualized. The following possible issues are detected by the sequencer:

  • Drivers
  • COM+
  • SxS Conflicts
  • Shell Extensions


Picture 1: 7zip uses shell extensions which were reported by the sequencer.

Another great addition to the sequencer’s intelligence is that it also gives you an extensive report of files and registry keys that were excluded from the package. With earlier versions you could spend a lot of time figuring out why the application was running on your sequencer machines and wasn’t running on your target machines. This information is not only presented during the sequencing process but it’s also saved as report.xml in your project directory for later reference.


Picture 2: Google Chrome installs its main executable in an excluded directory, which was reported by the sequencer.

When you are updating an application and the sequencer notices that the machine you are currently running on does not have the same baseline as the one you created your sequence on, it will give you information about these differences. System differences might influence the way the application is behaving, which is not preferred. If you think the application might have issues with these differences, you can change the system accordingly. The sequencer looks in your Add/Remove Programs control panel applet to find installation differences.


Picture 3: The .NET Framework was updated compared to the version that was installed on the machines where the sequence was created on.

Improving the success rate of virtual applications can also be done before the sequencing process. Microsoft has summarized many best practices in the whitepaper [Microsoft Application Virtualization 4.6 Sequencing Guide;]. However more than once, inexperienced people are not familiar with these best-practices and run into trouble during the rest of the process. The App-V 4.6 SP1 sequencer checks most of the common best-practices prior to starting the sequencing process.

It will warn you when certain services are running that can negatively influence your virtual application because they can lock certain files (like Windows Defender or Windows Search) or because they may update your system in the background (like Windows Update or the Configuration Manager client). If these changes accidently end up in your sequence it may become unnecessary large, slow or even unusable. But also pending reboots, non-reverted virtual machines or other running applications are reported.


Picture 4: Pending reboots, Windows Defender, Windows Search, Clean Machine, Disk Defragmenter, Configuration Manager Client; all were detected by the sequencer prior to starting the virtualization process.

Like I said in my introduction, I’m very excited by these new features because it will improve the predictability and success rate of App-V virtual applications. It definitely saves a tremendous amount of time troubleshooting applications because of malfunctioning.

Application virtualization candidates

Just Zarb wrote a nice approach when an organization is starting on virtualizing their application portfolio.

The first step in such a project is to identify which applications are installed and used in your environment. If your application delivery method currently consists of automating applications you probably have a good insight in this information. Software distribution mechanisms (like Microsoft System Center Configuration Manager) usually provide great reports for this particular scenario.

If you don’t have an ESD in your environment you might want to look at the freely available Microsoft Application Compatibility Toolkit, which has some basic inventory functionality as well.

Now having software installed on your enterprise workstations doesn’t mean that the application is mandatory for the end-user or the organization. More than once when I support customers in this particular process, application reduction is one of the most time consuming activities. Mostly due to political discussions.

Once you know which applications need to be deployed throughout your organization you should find out if there are good virtualization candidates.

Microsoft evaluates the potential candidate and places the application into one of three categories:

  • Ideal Candidate. Applications meet all of the possible candidate criteria and have no identifiable roadblocks to success.
  • Possible Candidate. Applications do not meet disqualifying criteria but may require additional research or validation.
  • Not a Candidate. Applications are more expensive to virtualize than the benefits achieved from virtualization. This category also includes applications that technically cannot be virtualized because of current limitations.
  • Remember that virtualization candidates are not only based on technical limitations of the application virtualization product you are using. Sometimes functional restrictions can weigh just as much.

    Original article here.
    Microsoft case study here.

    Desktop Control: Using ConfigMgr task sequences to chain App-V applications to MSI installations

    It is a fact that many applications require other applications to run properly. In App-V these dependencies can be sequenced along with the main application in the same virtual environment or they can be sequenced separately and joined together through Dynamic Suiting Composition.

    In the old days we could use the “Run another program first” on the Advanced tab of the Program properties option to chain two applications together. But since App-V applications don’t have Programs we can’t use this anymore.

    Luckily this issue can be solved by using Configuration Manager 2007 Task Sequences.(continue at source)

    Don’t forget to update your OSD’s if you are deploying on Windows 7

    So Windows 7 reached Release Candidate status last week and even earlier Microsoft released Cumulative Update 1 for App-V and now supports Windows 7 as a platform.

    So you got out and downloaded the RC as well as CU1 for App-V through either the MSDN or licensing websites. You deploy your virtual applications just like you did on your mainstream platform but it doesn’t work. The applications don’t seem to get added to the client cache. "This App-V technology should ease my future OS deployments, right?" So why isn’t this working?

    During the sequencing process you have selected Operating Systems that the application was supposed to work on. You have probably selected some or maybe all the available Operating Systems in the list, but definitely not Windows 7 as it was not available in earlier version than CU1.


    The behavior on the App-V client is that prior to adding the application it will check if the Operating System it is currently running on is supported by the application. It does this by checking the OS VALUE tag in the OSD.


    To be clear: this is done on application level, not on package level. It’s not likely but if the package has multiple applications associated with it (like Microsoft Office suite has) it might be that one application will be added while others might not depending on this tag and the way you have implemented it in your organization.

    Anyway, if the Operating System is not listed the application simply won’t be added.

    If you check the log you would see two messages related to this error:

    The Application Virtualization Client could not parse the OSD file ‘C:\PATH\xxx.osd’. Reason: No valid implementation for this machine (rc 07708804-00000007)

    The app manager could not create an application from ‘C:\PATH\xxx.osd’ (rc 07708844-00000007)

    The solution to this is fairly simple, just add the tags to the OSD. This can be done in different ways:

    Using the sequencer

    The sequencer that you created the applications with, doesn’t hold the Windows 7 key. The version that came with CU1 does, version

    Simply open the package and go to the deployment tab. You’ll see the Windows 7 option available here. It’s actually called Windows 7 32-bit already, probably preparing on future 64-bit versions of App-V.


    Edit the OSD directly

    By using a text editor or a script you could edit the OS VALUE tag in the OSD. The tag you want to add is Win7. So the result should look something like this:


    Note: Be aware that if you are using the MSI option to deploy your virtual applications the OSD’s used by the installer are inside the MSI. So after you edit the OSD you need to recreate the MSI. This has to be done through the sequencer either manually (Tools-Create MSI) or automatically (SFTSequencer.exe /MSI)

    Future Ready?

    So all applications are updated to Windows 7 and you can enjoy (hopefully :-) )testing them on the new platform.

    You should ask yourself however if you want to go through this situation again when the next Microsoft Operating System comes along. Because a new Operating System will probably bring a new tag along with it which then has to be updated throughout the OSD’s again.

    One way to avoid this situation is to have no limitation on the application whether it will deploy on a certain platform in the first place. Of course there is no guarantee it will work properly, but why restrict it from technical perspective? Another approach is to allow it to run on every platform except when you determined it isn’t suppose to.

    This can be achieved in App-V by not mentioning any OS VALUE tag at all, either by removing all of them from the OSD or not selecting any OS in the deployment tab of the sequencer.

    image image

    Now the client won’t decline any OSD on any platform, so you are ready for every operating system to come.

    Maybe something to consider if you go through updating all your OSD’s?

    Using the “Security Descriptors” within the App-V 4.5 Sequencer.

    Using Security Descriptors
    When using the new App-V 4.5 sequencer, Security Descriptors are switched on by default.

    But what is this security Descriptors function in the first place? How does it work? And is it of any use at all? In this article I will answer those questions.

    What are Security Descriptors?
    One of the big Advantages of SoftGrid always was that users could work with their applications like if they had Full Control rights. This was a huge advantage especially in Terminal Server environments where administrators usually put a lot of effort in getting applications to work on one hand and securing the Terminal Server environment on the other hand.

    By enabling Security Descriptors during sequencing an application (switched on by default), permissions on the windows file system are “pulled into the bubble” (not the registry, thanks for the heads-up by Brian Kelly).  The sequencer always captures security descriptors during sequencing, but only with the Enforce Security Descriptors setting checked, the client enforces them on the file system drive at runtime.

    So if a users group on the Sequencer had read rights on the D:\APP-X folder, these rights are stored in the Virtual Environment. Once streamed and run on the client, the user cannot edit in this particularly folder. In this manner you can set permissions on parts of the Virtual Environment and secure parts of being modified by a user.

    How does it Work?
    Like I mentioned before the enforcement of Security Descriptors is switched on by default. You can find the check box on the new Deployment tab of the Sequencer’s SFT-editor:


    So if the check box is switched on the permissions are stored inside the virtual environment.

    What’s the use?
    Good question! Like I mentioned above, one of the biggest advantages of SoftGrid always was that users had sort of Full Control rights within their virtual environment. The advantage especially for Terminal server environments was huge.

    I don’t see the advantage of switching the “Enforce Security Descriptors” setting on by default. I can imagine this option can be useful with some applications which need to have certain restricted permissions on parts of the virtual file system. For instance, some (badly written) applications need to have restrictions on parts of the virtual file system to ensure that settings don’t get corrupted or that .PKG files don’t grow excessively.

    Because this situation only applies to some applications it is my opinion that the Security Descriptors should not be switched on for every application but just for the applications where you’re facing a problem that can be solved by using Security Descriptor Enforcement.

    How to switch the enforcement off by default?
    This is not too difficult. The first step is to create a default.sprj (if you do not already have one):  Launch the Sequencer, go to the tools menu and select options. On the options screen go to exclusion items and click on “Save As Default”.


    I know this is a weird place for saving default settings. Don’t bother and just browse to the program directory of the Sequencer (by default  C:\Program Files\Microsoft Application Virtualization Sequencer) and open the default.sprj file. This is an XML file. Besides a lot of other settings, you can also set the Security Descriptors option in this file. Just set the value of the “UseSecurityDescriptors” option to “No” and you’re done.  


    Support for .NET in Microsoft Application Virtualization 4.5 (App-V)

    An article has come to my attention recently (whilst being available for some time) which addresses some issues in how to make the .NET framework available in conjunction with virtual applications.

    Microsoft has made several architectural changes in the implementation of Microsoft Application Virtualization (App-V) 4.5 to ensure that the product is aligned with our roadmap for future innovation. One such change entailed moving the API intercepts from kernel mode into user mode. This change had a side-effect of changing the App-V compatibility with the .NET Framework from previous versions of App-V.

    App-V 4.5 continues to be fully compatible with .NET applications. The change in compatibility only manifests itself with the .NET Framework.

    This table summarizes the requirements for .NET support in APP-V 4.5.


    Read more at source.

    SCCM Client and App-V client on the same box (continued)

    In my previous post on the coexistence of the SCCM client and the App-V client on the same box I mentioned that the SCCM client will take control of the delivery and streaming of virtual App-V applications once it’s installed.

    Aaron Parker posted a follow-up to this post in which he mentions that this behavior only occurs if you’ve allowed the virtual application package advertisement on the Advertised Programs Client Agent properties.


    I did indeed forgot to mention that. Thanks Aaron!

    Read more at source.

    SCCM Client and App-V client on the same box

    If you install the SCCM client on a machine on which the App-V client is installed, your current applications will no longer work and fail with the following error: Unable to initialize package information (0×00000000)


    After the installation of the SCCM client the App-V client cache will be flushed and if you set up a publishing server you will recieve the published applications but they will fail to stream and start.

    This is caused by a changed in registry during the installation of the SCCM Client:


    LaunchCommand "C:\Program Files\Microsoft Application Virtualization Client\sfttray.exe" /launch "<APP>"
    DDELaunchCommand "C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe" "<APP>" <DDE>
    With SCCM client installed:  
    LaunchCommand "C:\Windows\system32\CCM\VappLauncher.exe" /launch "<APP>"
    DDELaunchCommand "C:\Windows\system32\CCM\VappLauncher.exe" /launch "<APP>"

    This means that when the SCCM client is installed on the system it is expected also to handle virtual application launch and stream.

    I’ve seen that changing the registry back to the original value will make streaming available however if this is a supported scenario, I’m not sure. The SCCM client might change the value back in time.

    Using environment variables in App-V

    When it comes to environment variables in Microsoft Application Virtualization it’s good to know how the sequencer handles them.

    When an environment variable is changed during the monitoring phase of the sequencing process the sequencer picks it up. This works for both User environment variables as well as System environment variables.


    After the sequencing process is done and the project is saved they end up in the OSD file under the <ENVLIST> section.


    It’s good to know that the sequencer at this moment will detect if directories are referenced in the environment variable and automatically translates them to the appropriate %CSIDL_ or %SFT_MNT% variable.

    Be careful however with referring to the hardcoded drives because this directory will not always be replaced with the %CSIDL_ variable. For example if you created a directory in the root of C:\. If your destination doesn’t have the specific drive and directory the application might fail.

    During launch of the application all environment variables in the OSD will be treated as user variables during the use of the application. Also the ones that were captured as system variables. But be aware that the ENVIRONMENT tag in the OSD will override an existing system environment variable for that user’s session.

    Usually applications don’t care if the environment variable is user or system based. However there are cases where badly written applications don’t check the variable but check the registry instead. Environment variables are (normally) saved in:

    • HKEY_CURRENT_USER\Environment
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

    If your application is not working with the environment variables in the OSD you can always try adding the variable to one or both of the registry keys above.

    To do this you could use a prelaunch script to add the registry key:


    This cannot be done for the HKEY_LOCAL_MACHINE key due to limited user rights. Instead just simply add it in the sequencer, either in the Virtual Registry tab or during monitoring phase.

    Hope this saves some troubleshooting time!

    Next Page »