OSDCloud 24.9.17.1 Invoke-Webrequest

[MDMEverything]

Describe the bug When booting to WinPE the script stops before it can get the webscript url, its the Invoke-Webrequest that fails.

This is the error when actually booting into WinPE

To Reproduce Add webscript and supply URL when creating the bootimage Boot and the error should appear

Desktop (please complete the following information):

• OSDCloud 24.9.17.1

Additional context It looks like there is a problem when sending a system.byte[] to the parameter that expects system.string

[Baldderick]

Identical issue here this morning also, looks to have occurred with the last update as no issues ~24 hours ago.

[MDMEverything]

Looks like the error was introduced in this pull https://github.com/OSDeploy/OSD/pull/162

[joebartlett94]

Hi everyone,

This issue is caused when the 'Content-Type' header returned by the server hosting the PowerShell script is set to 'application/octet-stream'. This is the default MIME type used by Azure Blob Storage, which I'm guessing many of us are using to host these files.

You can fix the problem by going into the Azure portal, selecting the file, and changing the 'CONTENT-TYPE' property to 'text/plain'.

I'd suggest it may also be worthwhile updating the Invoke-WebPSScript.ps1 code to look out for 'application/octet-stream' responses and decode them back to text if possible using: [System.Text.Encoding]::UTF8.GetString($WebPSCommand)

[StevenVBeek]

@gwblok

[gwblok]

I don't do any hosting of my content in Azure, so I have not experienced this issue in any of my testing.

If someone who can replicate would like to create another pull request with the fix, I'd be happy to merge.

Or if people prefer, I can revert the merge and undo changes from PR 162

@OSDeploy will have to pull the trigger on creating a new module once fixes are done on GitHub

[gwblok]

pull 162 has been reverted.

As a work around, you can grab the 2 scripts on github and replace in your module until @OSDeploy updates the module again to release a new verison.

[jwinterberg]

Just getting around to read in here after vacation and I have to see this...

I thought providing the ContentType in the Invoke-WebRequest would make it that it this wouldn't happen, but it turns out that the Content-Type header is only relevant for POST/PUT/PATCH and is ignored in a GET request according to the HTTP standards.

The fix would probably just be to detect the output type and then do the [System.Text.Encoding]::UTF8.GetString() as @joebartlett94 suggested.

I'll take a second try at it at some point, with a lot more testing and without adding the extra functionality directly to be safe.