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

@ehutsonphr6

Cleaned up my statement, the sub query was enough to get the information that I wanted. I think I was originally going somewhere with a query with a subquery but I don't think it is necessary.

SELECT computer_name AS 'Computer Name',software_id AS 'Software ID',softinv.name AS 'Software Name', softinv.version AS 'Version', uninstall_string AS 'Uninstall String'
FROM computer_software csoft
JOIN computers comp ON csoft.computer_id = comp.computer_id
JOIN software_inventory softinv ON csoft.software_id = softinv.software_inventory_id
WHERE computer_name NOT REGEXP '#[0-9][0-9]-'

I created a super basic implementation of a self-service portal using the API, it works in a pinch but I wouldn't use it in production without heavy improvement. Mostly just curiosity about what's possible with the API
https://github.com/AidanRB/toem-store