Topics created by Tyler

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

If it's the only database that's running on there, then it really doesn't matter.

I had the thought, right now Process_File_Copy() is downloading the archives via curl, via the com server API, and I use SMB Direct so there's no reason to do it that way.

I thought maybe the 404 is happening because I don't have any of the files replicated onto the com server, I tried copying <storage>\software_uploads to C:\toems_local_storage\, this didn't work but I don't think the server config knows about this file location anymore. I would have to dive into the api code and I can't do that right now.

Since it should be using SMB for this anyway, I implemented that, and now it seems to be working

I can provide the code, but I'm not quite happy with some rough edges it has, I've made a lot of other tweaks along the way, and ultimately this solution is derived from existing code; also the codeblocks here don't know about powershell and make a visual mess of it.

One additional note, the call to Expand-Archive doesn't use -force, which means it can't overwrite. I didn't locate the overwrite value so I just hard-forced it, which won't matter for my case. It should probably be something like -force:$file.Overwrite

Been going through requests trying to figure what to work on next and I think this makes the most sense. This will be a focus of the next release.

At this point I've been reliably deploying these and several other models of surface for a couple days. It's safe to say the problem is fixed, but I'm not confident I know why.

My best guess is I had enabled Randomize GUIDs in Admin Settings -> Image Profile Templates, for the LinuxBlock.

I first tried Standard Partitions while this was enabled, and it's the only thing I can remember that was consistent between when deploy didn't work, and when it did. Everything else I tried didn't correlate, as in, I was having failures and successes with the setting in all states.

I'd still love to understand what was going wrong, if that is possible to discern from the existing evidence, so that I can avoid or fix it in the future.