Deploying Windows Server
FluxDeploy deploys Windows Server images the same way it deploys Windows 10 and Windows 11: you import the ISO, build an image, put it in a recipe, and PXE boot the machine. This page lists what is different for Server, and what is not supported.
Importing a Server ISO
A Windows Server install.wim lists every edition twice: once as Server Core (command line only, no desktop) and once as Desktop Experience (the full graphical desktop). In the Create Windows Image wizard each edition is labelled so you can tell them apart, and the wizard pre-selects a Standard (Desktop Experience) edition rather than the first image in the file, which on a Server ISO is Server Core. Choose Datacenter or Server Core explicitly if you want them.
Windows Server images are labelled by server release - for example Windows Server 2025 - and never as Windows 10 or Windows 11, even though Windows Server 2025 and Windows 11 24H2 share the same build number. The edition appears in brackets, for example Windows Server 2025 (ServerStandard).
Two options in the wizard behave differently for Server:
- Remove Bloatware (AppX Debloat) is disabled. Windows Server has no built-in AppX packages to remove.
- Apply Windows Updates works for Server 2016, 2019, 2022, 23H2 and 2025. FluxDeploy looks the image up under its own Server product in the Microsoft Update Catalog (Server 2025 shares a build number with Windows 11 24H2, but the catalog lists them as different products, and a Server image never receives a client update). It downloads the newest security cumulative update (the monthly Patch Tuesday release; preview and out-of-band releases are skipped on purpose), any checkpoint update the catalog says must go first, the newest .NET Framework cumulative update, and, for Server 2016 only, the servicing stack update, which is applied before the cumulative update. Every file is checked against the SHA-256 the catalog publishes. Server Core and Desktop Experience editions get the same updates. A .NET update that does not apply to the image is reported as "not applicable" in the job log and skipped. If the catalog cannot be reached, the image is still built, the job log says so, and only update files you placed in the updates folder are applied.
Optional features that do not exist on Windows Server (for example Windows Sandbox) are reported as failed in the job log and do not stop the job.
Autopilot is not available
Windows Autopilot is not available for Windows Server images. See Windows Autopilot for exactly where this is enforced, and what happens to a recipe that had Autopilot on before.
The answer file
The settings-driven answer file (Answer Files) is shaped for Server when the image is Windows Server:
| Windows 10 / 11 | Windows Server | |
|---|---|---|
| Product key | The Product Key setting is written | The separate Windows Server Product Key setting is written, and only when it is filled in and well formed. The Windows 10/11 key is never used for Server (a client key fails the Server specialize pass), and the Server key is never used for a client image. See Product key. |
| Hide online account / wireless / OEM screens, SkipMachineOOBE, SkipUserOOBE | Written when Skip OOBE is on | Not written. Server has no such pages. The EULA page is still hidden. |
| Local Administrator | The built-in account is enabled and a second Administrator account is created | The built-in Administrator is already enabled on Server, so only its password is set |
| Computer name, locales, domain join, auto-logon | Written | Written |
The local Administrator password must meet Windows Server's password complexity rules (the same as Settings requires: at least 8 characters with an upper case letter, a lower case letter and a digit).
Product key
Settings > Deployment > Unattend has two product key fields. Product Key is for Windows 10/11 images. Windows Server Product Key is used only for Windows Server images, and it is empty by default.
Leave the Server key empty when Server activates another way: a KMS host or Active Directory-based activation (the usual choice on a domain, and nothing is needed in the answer file), or when you enter a key after install. Fill it in with the key that matches your licence: a MAK or retail key, or an AVMA key for a Server virtual machine running on a licensed Hyper-V host. Microsoft publishes the generic KMS client setup keys and the AVMA keys in its Windows Server documentation on learn.microsoft.com (search for "KMS client setup keys" and "Automatic Virtual Machine Activation"); FluxDeploy does not ship that table, so copy the key for your edition from Microsoft's page.
The key must be five groups of five letters or digits (XXXXX-XXXXX-XXXXX-XXXXX-XXXXX). A key in any other shape is refused when you save, with a message on the page, and is never written to an answer file. The key is stored encrypted, is never shown to a Read Only user, is left out of a settings export unless you set a passphrase (then it is encrypted inside the export), and is synced to relays like the other unattend settings so a relay-served deployment behaves the same as a Core-served one.
Drivers
Auto driver matching normally compares only the machine's manufacturer and model. For a Windows Server image it also skips driver packs labelled for Windows 10 or Windows 11 only, because the OEM catalogs FluxDeploy browses are client catalogs. A pack with no Windows version recorded, or one that names a Windows Server release, is still a candidate. A manual driver list on the recipe is your explicit choice and is never filtered. Upload server hardware drivers on the Drivers page and tick the Windows Server versions they support.
First boot steps on a headless Server
On Windows 10 and 11, FirstBoot task steps start from a RunOnce entry, which Windows runs at the first interactive logon. A Server that nobody signs in to would never run them, so for a Windows Server image FluxDeploy starts them a different way:
- Windows Setup runs
SetupComplete.cmdas LocalSystem at the end of Setup, before any logon. FluxDeploy adds a block to it that registers a one-shot startup scheduled task (\FluxDeploy\FirstBoot, running as SYSTEM with the highest privileges) and starts it immediately. The task has a boot trigger as well, so a restart before it ran does not lose the sequence. - The task runs the same script, in the same order, with the same rules as on a client: a step that fails without "Continue on error" stops the remaining steps, a Restart step still reboots at the end, and the scripts (which may carry credentials) are deleted when it finishes. The task removes itself when it starts, so the sequence never runs twice.
- The output is written to
C:\FluxDeploy\firstboot-server.log(readable by administrators only). Check this file first if a Server's first boot steps did not do what you expected. - The
RunOnceentry is still registered as a fallback, for the case where Setup does not runSetupComplete.cmd(it skips it for some OEM-activated installs). A lock stops the two launchers from both running the sequence.
Steps that assume a signed-in user stay on RunOnce. A SYSTEM task has no signed-in user: a step that writes HKCU, uses %USERPROFILE%, %APPDATA%, $env:USERPROFILE and similar, names a path under C:\Users\<someone>, or is set to run as the current user would silently act on the wrong profile. If any FirstBoot step on a Server recipe looks like that, the whole sequence stays on RunOnce (so the order is preserved) and the deployment log says which step caused it. Turn on Auto-Logon (Settings > Unattend) for those recipes, or make the step machine-wide (HKLM, C:\Users\Public, C:\Users\Default).
Windows 10 and 11 images are not affected at all: their FirstBoot script and RunOnce entry are exactly what they have always been.
Task sequence templates
The recipe templates are written for client machines, and two of them are Autopilot templates. When the image you pick for a new recipe is Windows Server:
- Laptop with BitLocker: the Enable BitLocker step is not added, and the New Recipe form says so before you create the recipe.
Enable-BitLockerlives in the BitLocker feature, which Windows Server does not have installed by default, and installing it needs a restart; a FirstBoot sequence runs once with no resume point, so the step cannot install the feature and use it in the same run. To encrypt a Server, enable the BitLocker feature in the image first (for exampleDISM /Enable-Feature /FeatureName:BitLockerwhile customising it) and add your own step. - Autopilot Registration and Wipe & Redeploy (Autopilot): Autopilot is switched off (see above). The Wipe & Redeploy template normally skips the answer file so Autopilot can take over; on a Server image the answer file is kept, because without it Setup would stop at an interactive screen.
- Standard Workstation has nothing client-only and is unchanged.
If a recipe on a Server image already has a step that uses BitLocker cmdlets, OneDrive or the Microsoft Store, the Task Sequence tab shows a warning naming the step. The step is never changed or removed for you.
What has not been verified
Server deployment is covered by automated tests of the generated answer file, the recipe rules, driver matching and the generated first-boot script, startup task definition and SetupComplete.cmd block (the script is executed in the tests; the scheduled task itself is not). It has not yet been run end to end on a real Windows Server machine in the project's smoke environment, so treat the first Server deployment in your own lab as the real test.
Specifically, these need a real Windows Server boot to confirm: that Task Scheduler accepts the generated task definition, that Setup runs SetupComplete.cmd on your Server edition and the task then runs as SYSTEM with no one signed in, that a Restart step reboots as expected, and that activation behaves as you want with the Windows Server Product Key you entered.