Manual Boot ISOs
A Manual Boot ISO is a boot image wrapped in bootable media. Attach it to a virtual machine, burn it to a disc, or write it to a USB stick with a tool that lays out the stick for you (see below), and the agent starts exactly as it would after a network boot - no PXE, no ProxyDHCP, nothing added to the network.
It exists because of where the servers live. Core usually sits on a server VLAN, and switching on network boot there to try a single deployment is a large ask: it touches DHCP for everything else on that segment, and it usually needs somebody else's approval. Booting an ISO asks nothing of the network and proves the same things - that the machine reaches the server, that certificate pinning matches, that the recipe is found, and that imaging starts.
Attaching it, burning it, or putting it on a USB stick
Attaching the .iso to a virtual machine's DVD drive, or burning it to a physical disc, needs
nothing further: that is exactly the medium the file describes.
A USB stick needs a tool that converts the image - copying the raw bytes onto the stick does not
boot. The file is an ISO9660 image with an El Torito boot catalog, and firmware only reads that
catalog on optical media; a USB device has 512-byte sectors and is expected to carry a partition
table, which a raw image does not have. Use Rufus (choose the image, leave it in ISO mode) or
copy the file onto a Ventoy stick; both put a real partition and boot loader on the device and
extract the image's files into it. dd, Win32DiskImager and "copy the ISO to the stick" all
produce a device the firmware skips, usually with no message at all.
Pick the server, then download
Boot Images > Actions > Manual Boot ISO lists one entry per server, not one download:
| Entry | What it is |
|---|---|
core.contoso.local (this server) |
Built with the Windows ADK when the boot image was built |
relay-leeds.contoso.local (Leeds) |
Made by the Leeds relay, from its own boot.wim, as you download |
relay-bristol.contoso.local (Bristol) |
Made by the Bristol relay, the same way |
Each row leads with the host that ISO connects to, because that is the only thing that decides whether it works. Pick the row for the server the machine you are testing will talk to.
An ISO only ever reaches one server
The server address and its certificate thumbprint are written into the boot image when it is built. They are not discovered at boot, and there is no fallback. An ISO built for Core does not work against a relay, and an ISO made by one relay does not work against another:
- it dials the address it was built with, which at a different site is usually not listening at all, and
- if something does answer, certificate pinning rejects it.
Neither failure explains itself on the boot screen, which is why the product states the target
everywhere the file is offered: the menu row names the host, and the download is named
FluxDeploy-Boot-<image>-<site>-<server>.iso. A file sitting in somebody's Downloads folder still
identifies itself weeks later, and two sites' ISOs cannot be confused for one another.
Where a site's ISO comes from
Nowhere. It does not exist until you ask for it.
A relay already stores a boot.wim because PXE needs one. An ISO is that same file plus about
40 MB of boot scaffolding, so storing one would keep a second copy of the largest file in the
system - on Core, on the relay, or both. Instead the relay builds the image while you download
it and keeps nothing. A site's ISO therefore costs no disk anywhere, and it is never stale: it is
made from whatever boot image that site is serving at that moment.
And it is the one you asked for. Because the relay holds a single boot.wim, Core sends the
SHA-256 of the image it believes is at that site along with the request, and the relay compares it to
what it actually holds before producing a byte. If they differ - a sync in flight, say - the download
is refused and says so. A refusal costs you a retry; a disc that boots the wrong WinPE tells you
nothing at all.
The download always comes from Core's address. Core fetches from the relay and passes the bytes through, because an administrator sitting at Core often has no route to a branch office at all - and "test it without going to the site" is the whole point.
This works on Linux relays as well as Windows ones. The ISO is written by FluxDeploy itself rather
than by the Windows ADK's oscdimg, which a relay does not have.
The one file the relay cannot make
A boot configuration store (BCD) is a Windows registry hive, and only bcdedit can author one - a
Linux relay has no such tool. Core therefore builds a small ISO-shaped BCD (about 24 KB) and ships
it to relays over the same channel that already carries the PXE boot configuration they depend on.
A relay that has not received it yet falls back to its PXE copy, which differs only in two settings
that have no meaning on a disc.
When a site cannot produce one
The reason appears on the page, in red under the site that cannot produce one, and again if you click it anyway. It is not a failed download in the browser's download list.
| What you see | What it means |
|---|---|
| The site is not listed | Its boot image has not been built or has not reached it yet. Per-site builds are queued when a boot image is activated for PXE. |
| "cannot produce a Manual Boot ISO because its boot image is still building" | Wait for the Jobs page to finish. Network boot at that site is unaffected. |
| "is not the boot image active for PXE" | A relay holds one boot.wim - the active image's. A disc for any other image would contain the active one instead, so only the active image's ISO is offered. Activate the image you want first. |
| "This relay is holding a different boot image than the one this ISO was asked for" | The relay and Core disagree about what is at the site, usually because a new boot image is mid-sync. Wait for the site to report Synced and download again. The relay checks this before it produces a byte, so you never receive the wrong disc. |
| "Relay ... is Unreachable and cannot be asked for a boot ISO right now" | The relay is offline or unreachable from Core. The ISO is made by the relay on demand, so it has to be reachable. |
| "Relay ... rejected this server's credential" | Regenerate the site's key from Sites, which reissues both halves, then let the relay check in once. |
| "ISO9660 cannot hold a single file of 4 GiB or more" | See Limits, below. |
A download that is interrupted fails outright rather than leaving a short file: the size is declared before the first byte is sent, so a browser can tell a truncated transfer from a finished one. That covers a link that drops cleanly. A link that simply goes silent - a branch-office VPN dropping without either end noticing - is given two minutes with nothing arriving and is then abandoned the same way, with the reason in this server's log. A slow transfer is never cut off: only a stalled one is, and any byte arriving resets the clock.
Limits
No single file on the disc may reach 4 GiB. That is a limit of the ISO9660 format, not of
FluxDeploy, and in practice it means the boot image's boot.wim. A WinPE image is normally a few
hundred megabytes; if yours is over 4 GiB, reduce the WinPE drivers or optional packages in the boot
image. Network boot has no such limit and is unaffected.
Who can download one
Any signed-in user, including Read Only, and for every site's ISO as much as for this server's. The ISO contains the same agent configuration that PXE already serves unauthenticated over TFTP to anything on the deployment VLAN, so restricting the download would not protect it - it would only make it harder to test.