@typotony That’s Great to hear!
Glad you got it working and that it was as easy as intended.

@r-pawlowski I would be happy to help in anyway I can. Personally, I deploy a bootmanager (grub2win) and the ipxe.efi file to each machines efi partition. Then I can just change the boot managers default to boot straight to fog. It takes a bit of time to get setup, but I found it to be the most reliable as I then didn’t have to worry as much about the bios settings. Theoretically you can use bcdedit commands to change the boot order to boot to network, but that also differs on different hardware.

I digress though, the easy bit for queueing an image to deploy

Follow the setup instructions for the fog API (involves installing the module from powershell gallery and then inputting your API keys and fog server address) Then make sure the host you’re imaging is assigned the correct image, this can be changed in the API if you need that, but for this quick example, we’ll pretend it’s set correct. For an example, we’ll say the hostname of a computer in fog is ‘test-computer’, so this will find the host in fog, then queue an image to deploy on it right now $hostID = (Get-FogHost -hostname 'Test-Computer').id #create a quick json string, this can also be done in a powershell object and converted, but this is just a quick example. #tasktypeID of 1 is a deploy task, if no runtime/schedule time is specified, it defaults to instant deploy # shutdown = 0 is not scheduling with shutdown # I believe other2 = 0 means not a debug # other4 = 1 means to enable wol # isactive =1 means the task is active $jsonData = "{`"taskTypeID`": 1,`"shutdown`":`"0`",`"other2`":`"0`",`"other4`":`"1`",`"isActive`":`"1`" }"; # make the API call to create the new task for your host New-FogObject -type objecttasktype -coreTaskObject host -jsonData $jsonData -IDofObject $hostId;

Once you have this all setup in a powershell module or script internally, you can get things automated pretty smoothly. It’s meant to be modular so it can be applied to any infrastructure or workflow and built upon.

If you need more help let me know and I’ll see what I can do.

This is where computer imaging isn’t exactly a smooth process. Unfortunately, machines implement displaying a drive however they see fit, even across the same model of different machines. Typically the channels that an HDD is connected to (SATA 0, SATA 1, etc…) are followed to some level, but sometimes this isn’t the case (as I imagine you’re seeing now).

It is possible to tell FOG which drive to use, though it doesn’t know if the drive is ssd or hybrid or spinner. This is completely dependent on the machine, and if you can’t rely on which will be populated as what letter (my guess is your machines were setup in RAID mode of sorts?) that isn’t really going to help you much.

One way you could do this though, is to swap out the /usr/share/fog/lib/funcs.sh file and change the getHardDisk function to detect your drive sizes. (You can do the swap out using postinit scripts.) But then it’s implicit that all machines will follow the same method.

The steps I would take, albeit more time consuming initially:

Install the SSD to the 1st SATA Channel (if that’s how your machines are setup – I can’t help much in the case of NVMe/MMC builtin controllers as I have nothing to base them on yet).

Move the 1TB to the second SATA Channel.

Ensure the machine’s firmware is updated to the latest and greatest.

Ensure the machine’s SATA operation mode is AHCI.

If these don’t make your SSD display as /dev/sda then I don’t know else to tell you to try.

@JJ-Fullmer this is awesome thank you for sharing your knowledge and scripts.