xPackage: fails if url doesn't end with .exe or .msi

[BatmanAMA]

Problem description

Hi! I'm trying to use the xPackage resource to install packages that are accessed from Azure Storage using a SAS uri and it fails saying that the file doesn't "appear" to be an exe or msi.

Verbose logs

Error: Failed to Run Consistency for 'ApplicationInstall' Error : PowerShell DSC resource DSC_xPackageResource  failed to execute Test-TargetResource functionality with error message: The specified Path 'https://azurepolicyartifacts.blob.core.windows.net/installers/WindowsSensor-651.exe?skoid=<clipped for privacy>' does not appear to specify an EXE or MSI file and as such is not supported. (Parameter 'Path')

DSC configuration

. .\classes.ps1
Configuration ApplicationInstall {
    param(
        [Application[]]$Applications
    )
    Import-DscResource -ModuleName xPSDesiredStateConfiguration -Name xPackage

    Node localhost {
        foreach ($application in $applications) {
            xPackage $application.Name {
                Name        = $application.Name
                Ensure     = "Present"
                ProductId  = $application.ProductId
                Path       = $application.Path
                Arguments  = $application.Arguments
                FileHash = $application.FileHash
                HashAlgorithm = "MD5"
            }
        }
    }
}

Suggested solution

it would seem to me that changing the test to strip off anything after a ? is the simple answer with converting it into a uri and using the localpath property the (lower performance) more slick option.

$pathExtension = [System.IO.Path]::GetExtension(($Path -replace '\?.*$',''))`
#or if you want to make sure you're really certain to get the right thing
$pathExtension = [System.IO.Path]::GetExtension(([uri]$Path).LocalPath)

https://github.com/dsccommunity/xPSDesiredStateConfiguration/blob/main/source/DSCResources/DSC_xPackageResource/DSC_xPackageResource.psm1#L1092

Operating system the target node is running

OsName               : Microsoft Windows 11 Pro
OsOperatingSystemSKU : 48
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 22000.1.amd64fre.co_release.210604-1628
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

PowerShell version and build the target node is running

Name                           Value
----                           -----
PSVersion                      7.3.4
PSEdition                      Core
GitCommitId                    7.3.4
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

xPSDesiredStateConfiguration version

Name                         Version Path
----                         ------- ----
xPSDesiredStateConfiguration 9.1.0   C:\Users\Batma\OneDrive\Documents\PowerShell\Modules\xPSDesiredStateConfiguration\9.1.0\xPSDesiredStateConfiguration.p…

[gaelcolas]

Out of interest, if the check is dumb, have you tried to add a dummy get parameter like so: https://azurepolicyartifacts.blob.core.windows.net/installers/WindowsSensor-651.exe?skoid=<clipped for privacy>&dummy=myexe.msi

Maybe that's enough of a workaround for now and the blob will ignore that unknown 'dummy' parameter. Otherwise, I think that check is not really "modern" and should either be removed, or have a way to be ignored.

[BatmanAMA]

fantastic workaround, thank you