Always use configured letters in build VMs. On deployed devices, preserve opted-in letters and assign unchecked partitions from D: upward, relocating recognized FFU USB volumes while protecting unrelated volumes.
Update UI guidance, logs, and documentation.
Keep the Windows Fill Remaining option available when fixed-size data
partitions are configured, and enforce a single fill-remaining partition
across UI and CLI validation.
Reserve fixed data partition capacity by safely shrinking the maximum-size
Windows partition before creating Recovery and data partitions. Update the
Hyper-V settings and parameter documentation for the supported layouts.
When no explicit OptimizeFFUPartitionNumber or FillRemaining data
partition is configured, avoid passing /PartitionNumber for the resolved
Windows partition. This keeps DISM on its default OS partition path and
avoids FFU provider failures after resizing partition 3 in layouts with
Recovery after Windows.
Update BuildFFUVM.ps1 so Recovery partition creation fails clearly when
the disk cannot provide enough usable free extent. Align the calculated
Recovery size, reserve extra shrink slack for partition metadata, verify
supported shrink sizes, and require Storage cmdlets to throw terminating
errors so failures are logged instead of continuing with a blank drive
letter.
Use the selected FFU count in New-DeploymentUSB so one-item arrays log as single-file copies while multi-FFU copies keep the existing multiple-file message.
For FillRemaining data partitions, select the target from the mounted VHDX data-partition order and reassign the configured drive letter when it is free.
Throw when the configured drive letter is already occupied instead of falling back to data volume label/name matching.
Fall back to the Fill Remaining data partition's volume label or name when the mounted VHDX no longer uses the configured build-time drive letter. Log the resolved drive letter and preserve manual OptimizeFFUPartitionNumber overrides.
Consolidate disk size, required partition drive letters, Recovery, and data partition settings into the Hyper-V Disk Layout UI. Add capacity validation, Fill Remaining handling, Recovery remove/restore, data partition reorder/remove controls, and persist CreateRecoveryPartition through config and VHDX cache checks.
Update FFU optimization so automatic partition selection targets the Fill Remaining partition, falling back to Windows when none is selected. Refresh sample config and docs for the new Disk Layout parameters.
Support configurable data partitions after Recovery, including UI/config persistence, VHDX cache layout signatures, fixed-size-before-fill-remaining creation, and safer Windows/Recovery partition detection during capture and apply.
Replace hard-coded D:\ Apps ISO assumptions with FFUAppsRoot discovery, token expansion, legacy D:\ BYO app path remapping, and a logged audit-mode orchestration bootstrap.
Update BYO apps, Hyper-V settings, and parameter documentation.
Add System, Windows, and Recovery partition drive-letter settings to the Hyper-V Settings UI, config save/load, BuildFFUVM parameters, and sample/docs. Defaults remain S, W, and R.
Validate selected letters early, log validation failures for the UI, include drive-letter metadata in VHDX cache matching, and normalize legacy malformed cache values. This only affects FFU build-time partitioning; ApplyFFU deployment letters remain unchanged.
Treat WinGetWin32Apps.json as generated app orchestration output so failed or cancelled builds do not restore stale install metadata. Reuse Apps.iso when app inputs have not changed, and refresh it only when current app content or orchestration inputs are newer.
Introduces a new `SerialComputerNames` device naming mode that allows automated device naming during deployment based on the BIOS serial number. The mapping is provided via a CSV file with `SerialNumber` and `ComputerName` columns.
This feature requires `CopyUnattend` and writes a `SerialComputerNames.csv` file to the USB deployment media, replacing the need for manual prompts or prefix selection when device serial numbers are known in advance. The UI has been updated to support creating, loading, and saving the CSV mapping content.
Replaces the direct invocation of DISM via cmd with the native Windows PowerShell cmdlet to streamline and simplify the package installation process during WinPE media creation.
Replaces the native PowerShell command for adding Windows packages with direct command-line invocations of the Deployment Image Servicing and Management (DISM) tool. This fixes an issue introduced by the March 31, 2026 OOB update that persists in the April 2026 2B update where Add-WindowsPackage fails due to issues with CBS. Using native dism fixes the issue.
Adds parameters for x64 and arm64 unattend XML file paths.
Updates the BuildFFUVM_UI to let the user pick specific XML files to copy or inject instead of requiring them to exist in the `unattend` folder.
Adds validation to ensure the selected unattend XML files are not empty.
Updates documentation to reflect the new functionality.
Replaces the strict validation for an existing ComputerName element with dynamic XML initialization. Automatically creates the specialize settings block, the Microsoft-Windows-Shell-Setup component, and the ComputerName element if they are missing from the provided Unattend XML file. This improves script robustness and simplifies the requirements for custom unattended setup templates by patching in the necessary device naming structure on the fly.
Introduces an explicit "Prompt" option for device naming to allow technicians to enter the device name during deployment. This replaces the implicit legacy behavior, providing clear UI controls and validation to ensure that Unattend.xml is copied, which is required for prompt-based naming. Relevant documentation is updated to reflect this new workflow capability.
Comments out the restriction that previously prevented Microsoft 365 Apps and Office from installing on ARM64 virtual machines. This enables users to attempt or perform Office installations on ARM64 architectures where it was previously blocked.
Introduces new parameters and UI controls to give users more choice over device naming when applying an Unattend.xml file.
Users can now specify a device name, use a static or template-based name with the `%serial%` variable, or continue using a list of prefixes.
The UI is updated with a new Device Naming expander to guide the user through the options and clearly indicate the requirements for each mode, ensuring that mutually exclusive options like Copy Unattend and Inject Unattend are not selected together.
Documentation is updated to reflect the new functionality.
The Hyper-V switch selection in the UI previously did not connect the build VM to the network during provisioning. Since internet-connected Sysprep and capture flows are still experimental, this introduces an explicit "Enable VM Networking" checkbox to the Hyper-V Settings page that defaults to off.
- Adds the `-EnableVMNetworking` parameter to BuildFFUVM.ps1 to conditionally attach the Hyper-V network adapter during VM creation.
- Persists the setting through FFU config files and blocks UI execution if enabled without a valid switch.
- Refactors WPF event handlers in FFUUI.Core to fix dropdown scoping errors.
- Updates documentation and the sample configuration file to reflect the new behavior.
Replace the Get-WindowsVersionInfo registry-interrogation step in the VHDX capture path with parameter-driven naming via Get-FFUCaptureNamingInfo. This eliminates the registry load/unload commands and two full minutes of registry sleep time during capture.
By deriving default file and DISM image names from already-resolved target state (WindowsRelease, WindowsVersion, and installationType), capture naming now naturally matches the rest of the script. This also unifies CustomFFUNameTemplate evaluation between live image servicing and cached VHDX reuse instances.
Previously, when a requested Windows SKU was not found in the provided ISO/ESD and the user manually selected a fallback image, the script kept the original (stale) `$WindowsSKU`. This caused downstream features like FFU file naming, VHDX cache metadata, and cumulative update planning to enforce logic against the wrong edition.
- Refactored `Get-Index` into `Get-WindowsImageSelection` to return rich image metadata (including EditionId and InstallationType) instead of just the image index.
- Added `Get-ResolvedWindowsSKUFromImage` to resolve raw image metadata back into the repository's native friendly SKU vocabulary.
- Added `Get-WindowsTargetRuntimeState` to centralize and recalculate dependent variables (`installationType`, `WindowsVersion`, LTSC flags) after the SKU updates mid-flight.
By optimizing and mounting the VHDX directly on the host for image capture, the build process no longer needs to boot the VM into WinPE, create SMB network shares, generate temporary local accounts, or rely on complex Hyper-V switch IP configurations. This streamlines the workflow and eliminates multiple networking and permission-related points of failure.
This change also removes the need to generate and attach WinPE capture media. All related parameters (`ShareName`, `Username`, `VMHostIPAddress`, `CreateCaptureMedia`, `CleanupCaptureISO`), UI controls, capture scripts, and documentation references have been removed or updated to reflect the simplified architecture.
Switches back to utilizing the static cookie for Lenovo PSREF requests, as the token has remained unchanged for months. The dynamic retrieval function call is bypassed to streamline the process but remains in the codebase as a fallback in case the token expires or changes in the future.
Transitions the Microsoft Surface driver model list retrieval to use a centralized Learn-based index. This change unifies the scraping logic between the CLI and UI components, ensuring consistency and simplified maintenance. Cached model lists now serve both interfaces efficiently, reducing unnecessary network requests while retaining fallback mechanisms.
Updates the FFU UI and orchestration scripts to allow users to specify custom file paths for their Bring Your Own (BYO) app lists, rather than forcing the use of `UserAppList.json` in a specific directory.
Also modifies the orchestration to sync this custom path via `AppInstallConfig.json` so that the runtime orchestration phase resolves the correct file name and path during installation. Refreshes the Apps ISO if the custom BYO app list is updated.
Ensures build and cleanup processes run from the expected project location.
Prevents temporary state files from being created or removed in the wrong folder, which avoids stale markers and cleanup failures when launched from the UI or another directory.
Always requests the amd64 products catalog regardless of the target architecture, as it already contains media entries for both x64 and arm64. This removes unnecessary architecture-specific branching.
Improves the current-run cleanup mechanism by tracking file downloads explicitly. This ensures that files downloaded via BITS or preserving older timestamps are correctly identified and removed during cleanup. Extends the run manifest schema to support file backups, allowing for safe restoration of pre-existing scripts and configuration files modified during a run. Additional cleanup logic now correctly prunes residual empty directories after tracked files are removed.
Prevents reusing cached images when the requested disk size changes. Ensures the disk size property is properly saved and verified against existing cache items to maintain configuration accuracy.
Extends the volume optimization helper to safely handle already mounted drives, resolve partition letters, and optionally execute a volume retrim. Replaces inline defragmentation steps with the updated helper prior to caching to ensure a fully compacted and optimized image is stored.
Adds a new configuration parameter and UI toggle to control whether downloaded Windows ESD files are removed after application. Updates the download process to check for and reuse existing ESD files that match the latest metadata filename, saving bandwidth and time on subsequent executions. Integrates the conditional deletion logic into the shared cleanup module.
Adds logic to normalize LTSC/LTSB release years (such as 2016, 2019, 2021, and 2024) to their corresponding base Windows client versions (10 or 11). This ensures correct model retrieval and driver downloading, as OEM catalogs typically evaluate against base Windows versions rather than LTSC-specific release years.
Improves the reliability of locating Windows ADK and WinPE add-on installations.
Updates registry searches to locate installer executables in the bundle cache path instead of relying on display names, avoiding potential mismatches.
Expands the registry queries to check both the WOW6432Node and standard uninstall paths to better support different installation contexts.
Validates the Windows Deployment Tools feature by verifying the existence of expected script files rather than checking the registry.
Adds missing descriptions for cleanup, file copying, and download priority parameters to ensure complete help documentation.
Expands the documented supported values for Windows architectures, releases, and SKUs to accurately reflect expanded capabilities for ARM64, Windows Server, and LTSC deployments.
Corrects minor typos, updates default values to match the current implementation, and reorders parameters alphabetically to improve readability.
Since Windows 10 is out of support and only allows ESU updates, LTSB/LTSC builds are impacted by this and are unable to be offline serviced.
This commit fixes that by installing the CU in the VM, staging the update in a LTSCUpdate folder in the Apps folder.
Always stores .NET MSUs under a dedicated NET folder to keep cache structure consistent across OS variants
Migrates expected legacy root-stored .NET MSUs into the NET folder and prunes stale files from both locations to prevent buildup and mismatches
Prevents update packages for different Windows targets from mixing in a single cache, improving reuse across builds while avoiding DISM picking up stale MSUs.
Keeps pruning, download destinations, and update discovery confined to the OS/version-specific cache, including shared-branch handling for Windows 11 25H2/24H2 and LTSC mappings.
Removes older update packages from the local update cache so servicing tools don’t pick up multiple stale MSUs as sources.
Keeps only the MSUs expected for the current run across Windows, .NET (including LTSC folder layout), and Microcode updates, while logging failures and continuing.
rbalsleyMSFT