Posts Tagged ‘powershell’

App-V 5: On AddPackage and ConfigurePackage

June 22, 2014 2 comments

The other day I was troubleshooting a package add issue where I was running into a brick wall that turned out to be an awfully simple solution. While troubleshooting this, it came to me that I have not really gone into much depth as to what happens during an AddPackage or a ConfigurePackage operation in App-V 5. I mention both because they both refer to the process of laying down the necessary assets that will be needed for publishing and streaming the application. Whether we are adding the package manually using PowerShell (Add-AppvClientPackage) deploying through Config Manager, or synchronizing with the App-V Publishing Server, the methodology is the same.

You’ll notice that all of the critical XML files extracted from the APPV file will be fully cached in the base package directory even in shared content store mode. You’ll also notice the registry hive will be downloaded as well. The base catalog assets will be laid down as well in the packages catalog root. Finally, all of the assets required for publishing (under FB0 Feature Block 0 – the publishing block – mostly icons) will be cached. This is why even if Shared Content Store mode, all of these small files are usually fully populated files and not just sparse files. All of this before the actual publishing events regardless of targeting. If all goes well, you will see a value of 1 under the PackageState registry value for each package under:


The values possible for PackageState are:

1 – Package has been staged/configured successfully.

2 – Package has been deleted.

3 – The package has been fully mounted (loaded) into the App-V cache.

0 or anything else (HRESULT) – means a problem has occurred.

If you are running in Shared Content Store mode, the only files that will be fully cached into the sparse files will be publishing assets and probably most of the initial executables for the applications. Prior to streaming, this will also be the case with the default stream-to-disk scenario. Once the package has been streamed down, the files will be fully populated. Note that EVEN in Shared Content Store mode, if you pre-cache the application using Mount-AppVClientPackage all of the files and assets will be fully streamed to the disk or cached for that particular package.

Package Rollback

If for some reason, the AddPackage/ConfigurePackage event fails, the AppV client will try to clean up everything be it a script failure (where rollback action is selected) or an issue with the package itself. The PackageState will be 2. If the package cannot be removed because files are in use (which could be the case when scripts are involved) the package will be marked for pending deletion. Look for 0x8007012F which means “Pending Delete.” When the client service is restarted, the client will re-attempt the deletion of packages that are in the deleted state. Once the removal is successful, the registry entries for the package will be gone.

App-V 5: On Using Sequencing Templates

March 18, 2014 5 comments

Sequencing Templates (.APPVT) files are designed for automating the sequencing of applications. While you can take advantage of some of the benefits of templates with manual, interactive sequencing, be careful making assumptions when sequencing following the importing of a template in the Sequencer GUI. Sequencing Templates are also essential for the upgrading of packages.

Remember this from the App-V Sequencing Guide:

“Templates are also very important for upgrade scenarios.  The Sequencer does not save state so when a new Sequencer session is open and a package is opened for upgrade, the settings are in the default state.  If certain sequencer settings were changed when sequencing a package, the changes will not remain at time of upgrade.  Therefore, it is recommended to save a template for any package that has Sequencer customizations, and re-apply them on upgrade.  A template may also contain additional options such as Package Deployment Settings and Advanced Monitoring Options.”

Creating a Sequencing Template

Creating a sequencing template is pretty straight forward. You launch the App-V Sequencer and first set your advanced options for sequencing. You do this by going to the “Tools” menu and selecting “Options.”

All of the General Items and Exclusion Items can be adjusted using this dialog box. All of these settings will be saved into the template.

If you plan on only using these settings in your template, you can proceed to save as template using the “File” menu to “Save as Template.” However, if you want to include additional settings (for automated sequencing with PowerShell) instead of saving as template, proceed and go through the process of creating a blank dummy package. Make sure you click through to the advanced options so you can configure:

  • Operating System Options
  • Advanced Interaction



Once you have all of these settings the way you want them then you can proceed to save the template. Notice you will get a specific alert when doing so.


While it implies that the additional settings (OS, COM, objects) will not be saved in the template, you will find that they are, in fact, saved. What the effect of this message is any settings other than General Options or Exclusion Items will NOT be imported if you import the template into the sequencer GUI for the sequencing of a new package.



All of the settings will however be used if the template is used in conjunction with the New-AppVSequencerPackage PowerShell cmdlet. It will support the use of all of the template items. The use of PowerShell with templates opens the door of many possibilities for automating the sequencing of your packages. Here is an example:


Once the package has been created, you can verify the configuration held by observing the information in the App-V manifests.


Happy Automation!!

App-V 5: MSI Wrapper Caveats (Oh, and App-V WMI classes are different in 5.0)

For those enterprises using 3rd-party ESD (Electronic Software Distribution) products to deploy and manage software, use of the MSI-wrapper makes it easy to incorporate these types of applications into their environments. In App-V, when you “install” a virtual application using the MSI wrapper, all that is being done are custom actions that add and publish the package globally to all users on that machine. In addition, it will place an entry in the “Program and Features” list (formerly Add/Remove Programs.) This entry in the programs list is pretty much the difference between using the MSI to publish the application instead of manually using the PowerShell AppV cmdlets. Because of this entry, it is also advised to always use the programs list (or the msiexec /uninstall command) to remove the application instead of the manual PowerShell commands in order to prevent an orphaned entry from remaining.

It is also important to note that the MSI checks are more resilient in v5, where if you try to uninstall an application that is currently in use, it will echo a 0200000508 error:  

Following the warning, the uninstallation stops, the package will remain and the entry will remain in the programs list. This is different from 4.6 where the entry would get removed while the virtual application would remain published and you would have to manually remove the application using SFTMIME cleanup commands. The specific error in 4.6 would be:

The Application Virtualization Client could not complete the operation.

The operation failed to complete because the package is still in use. Report the following error code to your System Administrator

Error code: xxxxxx-xxxxxx04-00001808


In 4.6, once you got the 1808 error, at this point you had to remove the application using the manual SFTMIME command (SFTMIME DELETE PACKAGE)


If you are using a 3rd-party ESD (Electronic Software Distribution) product to manage applications, you can query the WMI namespace for App-V to determine if a package is still in use in order to prevent this from happening.

If the package is indeed in use, you can then use the Stop-AppVClientPackage and/or Stop-AppVClientConnectionGroup cmdlet although the standard caveats apply with regards to open documents and unsaved information.

Speaking of WMI

In V5, the WMI classes are now located in a different namespace (rootappv) and the classes have been expanded to align with PowerShell objects. The classes are:

  • AppVClientPackage
  • AppVClientApplication
  • AppVClientConnectionGroup

You can use PowerShell, VBScript, WMIC, or native/managed code to query WMI to get information about virtual applications, packages, and connection groups. For example, you can inventory packages using these PowerShell commands:

$VPackages = Get-WmiObject -Class AppvClientPackage -Namespace rootappv

$VPackages | Format-List -Property Name, InUse, PercentLoaded


What is really great about App-V 5.0’s WMI is the inclusion of Connection groups which allows extensibility for management of not only applications, but super-bubbles (especially with Configuration Manager 2012 SP1 – which actually refers to them as virtual environments.)

Categories: Uncategorized Tags: , , , , , ,

App-V 5 Scripting: Change

It is almost easier to pretend you know nothing about App-V 4.x scripting when looking at scripting in 5.0. That is often my first response to many rumblings about difficulty getting scripting set up in 5.0. These rumblings come mostly from users of App-V 4.x. Change is hard, I know, but we have a better set of options and frankly, in my opinion, it’s much better this way in the long run. It is just a paradigm shift that does require somewhat of a translation process for bringing older scripts from 4.x over to 5.0.

No More SCRIPTBODY (Embed in the Package, not the XML)

First of all, there are no more <SCRIPTBODY> elements. Instead of embedding the script inside the XML, the intent is to have the script embedded inside the package in the .Scripts folder. This is the ideal place for it as it will be one of the default search paths when calling a script. If you have already sequenced a package (or converted a package) and want to add a SCRIPT element into the dynamic configuration, you will need to specify the path to the script interpreter and script file. So in essence you have as the command and argument the script interpreter as the command and the script (and options) as the argument.

Not Enabled by Default

Before you even begin to start testing scripts, you will have to make sure the client is set up to allow for package scripts. The quickest way to do this is through PowerShell using the following

Set-AppvClientConfiguration -EnablePackageScripts $true

You can also do it by GPO or manually in the registry. Always verify this before testing scripts.

Security Context

Some scripts will run in the SYSTEM context or the currently logged on user depending on the scripts package event. Later I’ll discuss workflows that will also help you determine the context (Machine or User) for running the script (which is another new concept in 5.0.) The following table outlines how the security context relates to the package event.


Runs As

When the package is added

Local System

When the package is published globally

Local System

When the package is published to a user

Current User

After a Virtual Environment (Package) is built

Current User

After a virtual application is started

Current User

After a process exits

Current User

When the VE shuts down

Current User

Right before a package is unpublished to a user

Current User

Right before a package is unpublished globally

Local System

Right before a package is removed

Local System


Package Events?*

You need to forget the concept of PRE and POST events. Scripts can be called based on specific events in the lifecycle of the package. You will need to know at what point you want the script to be triggered. If your script needs to run in a specific context, this will help determine your event. If you decide your script needs to be triggered during application initialization (at the start of the virtual environment, the start of the process, when a process exits) you will need to also specify the specific application, rollback options, and whether you want to run it inside or outside the virtual environment.

*I so want to call this “event trigger” but it would be confusing.

To explain how the PRE and POST Options of before evolved into Package Event Elements – but not directly – look at the table below:

Package Event



When the package is added



When the package is published globally



When the package is published to a user



Before a Package is Streamed



After a Package is Streamed



After a Virtual Environment (Package) is built



When a virtual application is started


N/A – but same effect can be achieved with StartVirtualEnvironment

After a virtual application is started


StartProcess WAIT=TRUE

After a process exits



When the VE shuts down



Right before a package is unpublished to a user



Right before a package is unpublished globally



Right before a package is removed



The key is to know what package/app event you want to trigger execution: (AddPackage, PublishPackage, StartVirtualEnvironment, StartProcess, ExitProcess, TerminateVirtualEnvironment, UnPublishPackage, RemovePackage)

Wait Options

In addition to the command <Path> and <Arguments> you have your “Wait” options (Wait, RollbackOnError, Timeout.) If you have a <Wait> element with nothing else, it will default to RollbackOnFailure=”True” and Timeout=0.

Element Flow

When we put it all together, you will see the element flow follows this basic process:


      [EVENT TO TRIGGER EXECUTION?] [IF VE or Process Event – Also the option of running inside the VE]

        [MY Command Path]

        [MY Command’s arguments]

        [My Wait Options]

          [Optional AppID EXE w/ tokenized path if this is a Process event]


Where an example of a machine targeted script looks like this:





        <Arguments>-f file.ps1 </Arguments>

        <Wait RollbackOnError=”true” Timeout=”30″/>



As another example, if a script was targeted for a user, set for PRE LAUNCH/ABORTRESULT=1/PROTECTED=TRUE in 4.x, and was only needed for one app, you could call it this way in 5.0 



      <StartProcess RunInVirtualEnvironment=”true”>



        <Wait RollbackOnError=”true”/>




Deployment Configuration and Dynamic User Configuration

Many of the problems with testing scripts come with proper placement in deployment and dynamic configuration files and how they are targeting. Scripts that need to be called during package add and global publishing events should be part of the DeploymentConfig.XML file. These scripts will also run in the context of the local system account so scripts that map drives, for example, should not go here. Those need to be called as a <UserScript> element. I use the following visual workflow to help me determine targeting and publishing.

In the case of global publishing, the deployment configuration also has a UserConfiguration element in addition to MachineConfiguration which means that scripts appearing during these events will apply to all users when the package is published globally. This would be the appropriate place to have scripts which map network drives.





App-V 5.0: Launching Native/Local Processes Within the Virtual Environment

April 23, 2013 24 comments

Update 12/6/2014: With the release of App-V 5.0 SP3, there is an additional option now available. You can now use the RunVirtual registry for user-targeted applications. You might prefer this to the /appvve switch. Please read more about it here:

Back in 4.x, we pretty much had one of two ways to launch an application inside the virtual environment or “bubble” as it is often called. One way was through the use of a pre-launch script. This was cumbersome in that you had to either modify the cached OSD or even worse, modify the original OSD file and re-deploy/refresh. Since I always used this for troubleshooting purposes, I found it easier to modify the cached copy of the OSD file. Starting in version 4.5, we also had a way of launching an alternative native executable inside the virtual environment by simply adding parameters to the SFTTRAY.EXE command:

C:Program Files (x86)Microsoft Application Virtualization Clientsfttray.exe" /exe cmd.exe /launch "DefaultApp MFC Application

App-V 5 offers us even more flexibility in this regard. To start off, do not use the scripting elements in the dynamic configuration XML. It is completely unnecessary and a waste of time. APP-V 5 offers many ways of getting inside "the bubble."


You can use the Start-AppVVirtualProcess cmdlet such as the following example to retrieve the package name and start a local process within the specified package's virtual environment:

$AppVName = Get-AppvClientPackage *name*

Start-AppvVirtualProcess -AppvClientObject $AppVName cmd.exe

This way allows you to do something similar to the previous variant of SFTTRAY in which you can initialize an App-V virtual environment substituting a local command as the process running within that virtual process.


The Command Line Hook Switch “/appvpid”

This allows you to apply the /appvpid switch to any command which will allow the command to run within the virtual process of the virtual process you selected by its PID (Process ID) as in the example below:

cmd.exe /appvpid:8108

The Command Line Hook Switch “/appvve”

Where the /appvpid switch requires the virtual process to already be running, this switch allows you to start a local command and allow it to run within the virtual environment of an App-V package and will initialize it. The syntax is as follows:


The syntax is a but cumbersome as it requires both the package GUID and the version GUID:

cmd.exe /appvve:bcfdbe1b-8bff-4502-b4e2-5a773e82d86c_2ef3aaf9-9864-44a3-85dd-bf99a6b4d8f2

Run Virtual

If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:


For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID> or such as in the figure below:

Each native process that needs to run locally will require its own subkey beneath the Run Virtual key. As long as there is one version of the EXE on the system, placing the packageversion GUID combination in the default key value will suffice. If there is more than one version of the EXE installed on the machine, you will need to create a new REG_SZ value beneath the subkey and specify the value name by using the full path to the EXE.


The above options give you much flexibility in how you merge native processes with virtual environments. With App-V 5, these not only add interoperability options, but they enhance our troubleshooting toolkits.  There will not be any reason to go into dynamic configuration XML in order to do this.

PS: Yes, I know I have not been blogging enough on APP-V 5. I promise to change that. I do have customers to tend to, you know! 😉

Update 12/6/2014: With the release of App-V 5.0 SP3, there is an additional option now available. You can now use the RunVirtual registry for user-targeted applications. You might prefer this to the /appvve switch. Please read more about it here:


MED-V: How to Customize and Repackage a Workspace using PowerShell

 One of the benefits of MED-V 2 was the introduction of PowerShell to control, manage, and deploy the MED-V workspace. A good example of where PowerShell comes in handy is when you have a workspace that you have already configured and packaged – but now you need to make an adjustment to the configuration for future deployments of that workspace. A walkthrough of how to do this is as follows:

  1. Navigate to the directory where the workspace package was created.
  2. After making a backup of this directory, notice that you have both a .REG file and a .PS1 file. The .REG file contains the basic configuration. You can use the PS1 file to set advanced settings an regenerate the MED-V workspace.
  3. Open the .PS1 file in the integrated script editor. You will notice it looks like the script below:

    import-module -Name “Microsoft.Medv”
    $regFileInfo = New-MedvConfiguration -VmNetworkingMode “BRIDGED” -UxLogonStartEnabled “False” -UxCredentialCacheEnabled “True” -FtsMode “Attended” -VmMultiUserEnabled “False” -FtsAddUserToAdminGroupEnabled “True” -FtsStartDialogMsg “A virtual environment is being created for application compatibility. The first time setup process can take several minutes to complete.” -FtsFailureDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsRetryDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsSetUserDataEnabled “True” -FtsSetJoinDomainEnabled “True” | Export-MedvConfiguration -Path “C:medv2-packagesWindows XP Compatibility.reg” -PassThru
    if ($regFileInfo) #If the .Reg file was created, then create the workspace package
     New-MedvWorkspace -WorkspaceName “Windows XP Compatibility” -VhdFilePath “C:vpcMedv-ws-xp.vhd” -SettingsFilePath “C:medv2-packagesWindows XP Compatibility.reg” -VhdRegPath “C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_InternetZoneHighSecurity.reg,C:Program FilesMicrosoft Enterprise Desktop VirtualizationMEDV_RestrictedBrowsingMode_Apply.reg” | Export-MedvWorkspace -Path “C:medv2-packagesWindows XP Compatibility.msi” -Overwrite


Let’s say you wanted to adjust the FtsAddUserToAdminGroupEnabled option and set it to “false.” You could simply make the adjustment in the .PS1 file and repackage the workspace.

    You could even add in additional advanced options (Boolean.) For example, if you wanted to disable host guest network printer sharing, you could add an additional parameter to the script to add the –UxPrinterSharingEnabled parameter and set it to “False.” Once you have made the changes, save the new .PS1 file and close the Powershell ISE. By the way, you can use the WMI reference for additional options:

    Repackaging a Workspace Using PowerShell.

    If you are doing this customization, you will need to re-package the workspace using the PS1 file.

    1. Open a PowerShell command prompt as Administrator.
    2. Change to the current directory of the of the workspace package.
    3. Execute the PS1 file. This will start the process of creating the workspace package with these customized settings. Once the packaging process is complete you can deploy the newly created setup, MSI and workspace package.
    Categories: Uncategorized Tags: , , , ,