Windows
View all Worklets
WindowsWindows

Windows - Maintenance Tasks - Windows 10 to Windows 11 Upgrade via ISO

Upgrades Windows 10 endpoints to Windows 11 in place using a Windows 11 ISO hosted on a network share

Worklet Details

What the Windows 11 ISO upgrade Worklet does

This Automox Worklet™ performs an unattended, in-place upgrade from Windows 10 to Windows 11 using an ISO file you host on an internal network share. The Worklet copies the ISO from the share to a local cache directory, mounts it with Mount-DiskImage, extracts the setup files, and runs setup.exe with quiet upgrade arguments under the SYSTEM account. There is no USB drive, no console operator, and no end user prompt during the install.

Before any of that happens, the evaluation script checks whether the endpoint is already on Windows 11 (build 22000 or higher) and short-circuits if so. If the endpoint is still on Windows 10, the script calls Get-Win11Eligibility to confirm TPM 2.0 presence and activation, a primary disk of at least 64 GB, and at least 4 GB of RAM. Endpoints that fail any check exit cleanly and are not flagged for remediation.

Three policy parameters drive the run. isoPath is the UNC path to the Windows 11 ISO on your share (for example, \\server01\share\Win11_Enterprise_22H2_en-US.iso). argumentList controls how setup.exe runs and defaults to /auto upgrade /quiet /dynamicupdate disable /eula accept with an automatic reboot at the end. setupDir defaults to C:\WindowsSetup and is where the ISO is staged and extracted on each endpoint.

Why move Windows 10 endpoints to Windows 11 now

Windows 10 reached end of support on October 14, 2025. After that date, Windows 10 endpoints stop receiving monthly security updates from Microsoft, and any new vulnerability disclosed against the OS sits unpatched on every host you have not migrated. The longer the Windows 10 tail lingers, the more out-of-band exceptions your IT and security teams have to track. Examples include unsupported-OS findings in CIS Benchmark reports, PCI-DSS scope expansions, and vendor agents that drop Windows 10 support in their next release.

Manual upgrades do not scale to that deadline. Sending a technician to every desk, shipping bootable USB media, or asking users to run setup.exe themselves consumes weeks of labor and produces inconsistent results. This Worklet mounts the same ISO from the same UNC share on every Windows 10 endpoint the Automox agent can reach, runs setup.exe with the consistent /auto upgrade /quiet /noreboot arguments you specify, and reports the upgrade exit code back to the console for triage.

How the in-place Windows 11 upgrade works

  1. Evaluation phase: The Worklet reads [System.Environment]::OSVersion.Version and exits 0 if the endpoint is already on Windows 11 (major 10, minor 0, build ≥ 22000). Otherwise it calls Get-Win11Eligibility, which uses Get-CimInstance against root\cimv2\security\microsofttpm\win32_tpm to confirm a TPM is present, IsEnabled_InitialValue and IsActivated_InitialValue are True, and SpecVersion starts at 2 or higher. The same function checks (Get-Disk -Number 0).Size for at least 64 GB and Get-CimInstance CIM_PhysicalMemory for at least 4 GB of RAM. If every check passes, the endpoint exits 2 and is queued for remediation.

  2. Remediation phase: The script re-runs Get-Win11Eligibility, then Test-Path against isoPath to confirm the SYSTEM account can read the share. It creates setupDir (C:\WindowsSetup by default) and copies the ISO to $setupDir\Windows11.iso. The script then mounts the image with Mount-DiskImage, copies the contents to the setup directory with Copy-Item -Recurse, dismounts the image, and deletes the copied ISO to reclaim space. It then runs Start-Process on C:\WindowsSetup\setup.exe with the configured arguments (default: /auto upgrade /quiet /dynamicupdate disable /eula accept) and waits. Exit codes 0, 1641, and 3010 are treated as success; anything else throws and exits 1003. The endpoint shows Pending Update in the Automox console while Windows builds the ~30 GB cache under C:\$WINDOWS.~BT\ and reboots to finalize.

Windows 11 ISO upgrade requirements

  • Source endpoint running Windows 10 x64, version 1909 or later, with PowerShell 5.0 or later

  • TPM 2.0 present, enabled, and activated in firmware; Secure Boot capable and enabled in UEFI

  • Primary disk (Disk 0) of at least 64 GB with roughly 30 GB free for the C:\$WINDOWS.~BT\ cache

  • Minimum 4 GB RAM (the script reads CIM_PhysicalMemory.Capacity)

  • A UNC network share (\\server\share\Win11_*.iso) reachable from each endpoint, with Read permissions granted to the SYSTEM account because the Automox agent runs as SYSTEM

  • A Windows 11 ISO whose System Default UI Language matches the target endpoint; cross-language upgrades (en-US to en-GB) are blocked starting with Windows 11 version 22H2

  • Three policy parameters configured: isoPath (UNC path), argumentList (setup.exe switches), setupDir (default C:\WindowsSetup)

  • To defer the reboot, append /noreboot to argumentList and coordinate the final restart with Automox Restart Notifications

Expected state after the Windows 11 upgrade

After the upgrade completes, the endpoint boots into Windows 11 and reports a build of 22000 or higher to [System.Environment]::OSVersion.Version. The next Automox policy evaluation finds the endpoint on Windows 11, logs the Device is already on Windows 11 and compliant message, and exits 0 without re-running the upgrade. The previous Windows 10 installation is preserved at C:\Windows.old for 10 days. That is the supported window to roll back through Settings → System → Recovery if the upgrade introduces an application or driver regression.

If a run fails, the Automox activity log captures the exit code and stderr from setup.exe. Setup also writes detailed logs under C:\$WINDOWS.~BT\Sources\Panther – setupact.log for every action and setuperr.log for installation errors. For a structured failure summary, run SetupDiag.exe (downloadable from Microsoft) against the endpoint after a failed attempt; it parses the Panther logs and identifies the failing component, blocking driver, or compatibility hold. Endpoints clear the Pending Update status in the Automox console once the upgrade finishes and the endpoint reboots, restoring normal policy cadence across the fleet.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets