Updates from QA Training

App-V 4.x to 5.0 Package conversion: Fixing the broken Pipeline!

The App-V 5.0 package format is very different from the previous 4.5/4.6 version, and the App-V 5.0 client is not compatible with the earlier package versions. To help protect your sequencing investment, Microsoft included two PowerShell commands on the sequencer to aid in migration: Test-AppVLegacyPackage and ConvertFrom-AppVLegacyPackage. The first tests the old package for known constraints, while the second attempts to convert the package to the new format


Mark Cresswell | 31 January 2014

The App-V 5.0 package format is very different from the previous 4.5/4.6 version, and the App-V 5.0 client is not compatible with the earlier package versions. To help protect your sequencing investment, Microsoft included two PowerShell commands on the sequencer to aid in migration: Test-AppVLegacyPackage and ConvertFrom-AppVLegacyPackage. The first tests the old package for known constraints, while the second attempts to convert the package to the new format

Before you use these commands, you must first understand some restrictions.

  • 32Bit packages must be converted on a 32bit Sequencer Machine.
  • 64bit packages must be converted on a 64bit Sequencer Machine, but the x86 version of PowerShell must be installed.
PowerShell Commands

There are several other tutorials online, which cover the commands in fair detail - from simple one-line examples, to full-blown, detailed scripts that will recurse a library of packages, testing and converting. An excellent pipeline example can be found here on a blog from Aaron Parker, a solutions architect and App-V guru.

The following basic example of PowerShell Pipelining is from TechNet . It shows how the output from one command can feed the inputs to another.

"dir .\ | Test-AppvLegacyPackage | ConvertFrom-AppvLegacyAppvPackage -Target .\ConvertedPackages"
Test-AppvLegacyPackage : The pipeline has been stopped.

 

Unfortunately, this pipelining no longer works and the example below - from Arron's blog, now returns the following errors:

C:\Windows\system32> $source = \\dc1\content
C:\Windows\system32> $dest = "c:\converted"
C:\Windows\system32> Get-ChildItem -Path $source | Test-AppvLegacyPackage | Where-Object {$_.Errors.Count -eq 0 } | ConvertFrom-AppvLegacyPackage -DestinationPath $dest
Test-AppvLegacyPackage : The pipeline has been stopped.
At line:1 char:32
    + Get-ChildItem -Path $source |  Test-AppvLegacyPackage | Where-Object {$_.Errors. ...
           + CategoryInfo             : NotSpecified: (:) [Test-AppvLegacyPackage], PipelineStoppedException
           + FullyQualifiedErrorId : NotSpecified,Microsoft.AppV.LegacyPackages. TestPackageCommand

Test-AppvLegacyPackage : The pipeline has been stopped.

At line:1 char:32

   + Get-ChildItem -Path $source |  Test-AppvLegacyPackage | Where-Object {$_.Errors. ...
            + CategoryInfo              : NotSpecified: (:) [Test-AppvLegacyPackage], PipelineStoppedException
            + FullyQualifiedErrorId: NotSpecified,Microsoft.AppV.LegacyPackages. TestPackageCommand
ConvertFrom-AppvLegacyPackage : Cannot find path
'C:\Windows\system32\Microsoft.AppV.LegacyPackages. LegacyAppvCommandResult' because it does not exist.
At line:1 char:97
+ ... ount -eq 0 } | ConvertFrom-AppvLegacyPackage -DestinationPath $dest
+ CategoryInfo        : ObjectNotFound: (C:\Windows\syst...pvCommandResult:String)
            [ConvertFrom-AppvLegacyPackage], ItemNotFoundException

 + FullyQualifiedErrorId : PathNotFound,Microsoft.AppV. LegacyPackages.ConvertPackageCommand


So, why is this now broken when it was obviously working in the past? 

During the development of 5.0, while still in beta testing, Microsoft made changes to these two commands.

They changed the name of the input parameter to both the  Test-AppVLegacyPackage and the ConvertFrom-AppVLegacyPackage  commands from the original  -Source to -SourcePath . The problem reflects through, as the Property Name for the Test-AppVLegacyPackage object still reads Source , therefore no longer matching the input to the ConvertFrom-AppVLegacyPackage cmdlet, which now expects SourcePath .


Hash Table to the rescue

Fortunately, until Microsoft is able to fix this error, the problem can be easily solved with a bit of additional PowerShell. By using the Select-Object cmdlet and a Hash Table, we can map the property .source to the name SourcePath.

Select-Object * , @{n='SourcePath';e={$_.source}}

Once inserted into the pipeline (as below) all should be good; the packages will be tested and providing there are no errors, converted.

Get-ChildItem -Path $source | Test-AppvLegacyPackage | Where-Object {$_.Errors.Count -eq 0 } | Select-Object * , @{n='SourcePath';e={$_.source}} | ConvertFrom-AppvLegacyPackage -DestinationPath $dest

All that's left is to test all the converted packages and cross your fingers they work!

A big thanks goes to my colleague, Bret Appleby, for pointing me in the right direction and coming up with a much neater solution than mine.

Mark Cresswell

Mark Cresswell

Principal Technologist

Prior to QA 16 years ago Mark had a long career with Unisys initially working on Mainframe and then Microsoft Server products. As a Principal Technologist he works on the leading edge of technologies and enjoys getting “under the hood” to see what makes things tick. Area of expertise: Microsoft Desktop deployment, Optimization and Collaboration. Specialising in Med-V, App-V , RDS, VDI, Forefront Edge and AV Products, Exchange, SharePoint and Microsoft Deployment Technologies.
Talk to our learning experts

Talk to our team of learning experts

Every business has different learning needs. QA has over 30 years of experience in combining the highest quality training with the most comprehensive range of learning services, ensuring the very best fit for your organisation.

Get in touch with our learning experts to talk about how we can help.