远程执行Get-AppVServerPackage结果不一致的技术求助

Hey Holger, I’ve run into similar headaches with remote PowerShell and complex App-V object types before—let’s break down what’s going on and fix this for you.

The Root Cause #

When you use Invoke-Command to pull objects from a remote session, PowerShell serializes (converts to XML) those objects to send them back to your local machine. Complex custom types like Microsoft.AppV.Server.AppVMgmtDataTypes.Application lose their original property metadata during this process. That’s why $test.Applications[0] | gm only shows generic methods and a Length property—you’re looking at a serialized "shell" of the original object, not the full, functional type you see locally.

The reason Entitlements works fine is that it’s a simpler collection type that survives serialization much better.

Fix 1: Extract Application Data Directly in the Remote Script Block #

The most reliable solution is to pull the exact application properties you need before sending data back to your local machine. This skips the serialization problem entirely:

# Create your remote session
$s = New-PSSession -computerName myAppVServer -Authentication Kerberos

# Fetch packages with pre-extracted application details
$appVPackages = Invoke-Command -Session $s -ScriptBlock {
    Get-AppVServerPackage | ForEach-Object {
        # Build a custom object with all the data you care about
        [PSCustomObject]@{
            PackageID = $_.PackageId
            PackageName = $_.Name
            PackageVersion = $_.Version
            # Extract every relevant application property you need
            Applications = $_.Applications | Select-Object Name, Version, Publisher, Path, AppId
            Entitlements = $_.Entitlements
        }
    }
}

# View the complete results locally
$appVPackages | Format-List

When you run this, $appVPackages.Applications will show all the same detailed properties you see when running the command directly on the App-V server—no missing data.

Fix 2: Use XML Serialization to Preserve Full Object Types #

If you need the complete Application object (not just selected properties), you can export the data to XML on the remote server, then import it locally. This preserves more type information than direct serialization:

Invoke-Command -Session $s -ScriptBlock {
    # Export packages to XML on the remote server (ensure the path exists and is writable)
    Get-AppVServerPackage | Export-Clixml -Path "C:\Temp\AppVPackages.xml"
}

# Import the XML data back into your local session
$fullPackages = Invoke-Command -Session $s -ScriptBlock {
    Import-Clixml -Path "C:\Temp\AppVPackages.xml"
}

# Now you can inspect the full Application objects
$fullPackages[0].Applications[0] | Get-Member

Just remember to clean up the XML file on the remote server afterward if you don’t need it anymore.

Fix 3: Load the App-V Assembly in the Remote Session (Less Reliable) #

Sometimes forcing the remote session to load the App-V management assembly can help preserve type data, though this doesn’t always work due to core serialization limitations:

$test = Invoke-Command -Session $s -ScriptBlock {
    # Load the required App-V assembly
    Add-Type -AssemblyName Microsoft.AppV.Server.AppVMgmtDataTypes
    Get-AppVServerPackage
}

# Check if Applications now show full properties
$test.Applications[0] | Get-Member

Stick with Fix 1 or 2 for consistent results—they’re far more dependable for most real-world scenarios.

Hope this gets you the full App-V application data you need!

内容的提问来源于stack exchange，提问作者user6203435