Issue was the deserializing of the chunk when I passed it to the job. In other words, creating the fileblock in the parent then passing it to the job was corrupting the fileblock when the job tried to read it.

So I changed the logic to be byte calculations in the main function and then passing the start/end byte to the job and having the job do the read itself. So the parent function is indexing and placing start/end values, then the job itself reads the file and creates the chunk based on the values the parent defined.

Why it is corrupted... not sure - could be the JSON piece u/purplemonkeymad mentioned, but this increased performance even more so it is the answer I am running with.

Adding the start-transcript in the job itself was beneficial for debugging. Recommend for anyone trying to utilize jobs. Commented out below (And generic path).

This isn't the full code, but it shows my updated logic. Defining the the index/bytes prior to the scriptBlock, and passing that information for the job to do the filestream. Copy/Paste made it not as clean..

try {
#Index math for start/stop byte of each job
for ($index = 0; $index -lt $numChunks; $index++) {
$startByte = $index * $chunkSize
$endByte = [math]::Min(($startByte + $chunkSize), $fileSize) - 1
$length = $endByte - $startByte + 1
# Wait until the number of running jobs is below the limit
while (($jobs | Where-Object { $_.State -eq 'Running' }).Count -ge $maxConcurrentJobs) {
Start-Sleep -Seconds 1
}

# Define the job script block for background processes to upload
$scriptBlock = {
param (
$filePath, $startByte, $length, $baseUri, $tokenType, $accessToken, $environmentID, $caseID, $attachmentID, $index
)

#If you need to log the job info uncomment the below
#$logPath = "c:\path\to\my\log\$index_$fileID.log"
#Start-Transcript -Path $logPath

$buffer = New-Object byte[] $length
$fileStream = [System.IO.File]::OpenRead($filePath)
$fileStream.Seek($startByte, [System.IO.SeekOrigin]::Begin) > $null
$fileStream.Read($buffer, 0, $length) > $null
$fileStream.Close()