I had to step away from this for a little while but I just ran into a small snag on it.
When a system is using Storage Spaces to pool drives, the drives do not appear in PS> Get-Disk, and this messes up the disk numbers. In wie_global_functions.ps1 : Get-Hard-Drives() we get an array of the valid disks
$script:HardDrives=$(get-disk | where-object {$_.NumberOfPartitions -gt 0 -and $_.BusType -ne "USB"} | Sort-Object Number)
In wie_deploy.ps1 : Process-Hard-Drives() we foreach through that array with an external index to get the schema
$currentHdNumber = -1
foreach ($hardDrive in $script:HardDrives) {
log " ** Processing Hard Drive $($hardDrive.Number)" -display -timeStamp
$currentHdNumber++
[...]
$script:hdSchema = $(curl.exe $script:curlOptions -H Authorization:$script:userTokenEncoded --data "profileId=$profile_id&clientHdNumber=$currentHdNumber&newHdSize=$($hardDrive.Size)&schemaHds=$script:imaged_schema_drives&clientLbs=$($hardDrive.LogicalSectorSize)" ${script:web}CheckHdRequirements --connect-timeout 10 --stderr -)
So now we have 3 numbers, $script:hardDrive.Number, $currentHdNumber, and $script:hdSchema.SchemaHdNumber. Under normal circumstances these are all the same number, but in Storage Spaces, and who knows maybe other RAID setups, hardDrive.Number is the system's index for that disk, while currentHdNumber and SchemaHdNumber are the position of the disk in an unordered array.
That's all good and fine, great actually, because this disjoint allows the wie to ignore this problem.
currentHdNumber is used to request the schema so it will always request 0 first, and on most systems there's only one drive. Any time we want to get something from the server, we want this number.
hardDrive.Number then reflects any modification to the disk order. As long as we use hardDrive.Number to direct disk operations it'll work out.
In wie_deploy.ps1 : Download-Image(), the line used to stream the .wim onto the partition is
$udpProc=$(Start-Process cmd "/c curl.exe $script:curlOptions -H Authorization:$script:userTokenEncoded --data ""profileId=$profile_id&hdNumber=$($hardDrive.Number)&fileName=part$wimSource.winpe.wim"" ${script:web}GetImagingFile | wimapply - 1 C: 2>>$clientLog > x:\wim.progress" -NoNewWindow -PassThru)
Which uses hardDrive.Number to ask the server to send the image over. The server doesn't know about disk 3, so the request errors out. Changing this to currentHdNumber or SchemaHdNumber fixes it, and now the wie is able to deploy images to storage spaces
There is actually a secret 4th number, $script:imageHdToUse, which is just SchemaHdNumber