> For the complete documentation index, see [llms.txt](https://documentation.2pintsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.2pintsoftware.com/deployr/reference/step-definitions/upgrade-operating-system-from-cloud.md).

# Upgrade operating system from cloud

The **Upgrade operating system from cloud** step performs an in-place upgrade of the running Windows 10 or Windows 11 installation. It downloads the matching Windows media from Microsoft and runs Windows Setup, keeping the existing apps, settings, and user data. The target image uses the same edition, architecture, and language as the installed OS.

Run this step in the existing full OS. The [Windows in-place upgrade from cloud](/deployr/task-sequences/task-sequence-templates/windows-in-place-upgrade-from-cloud.md) template uses it.

### Options

| Option                   | Description                                                                                                                                                |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Operating system         | **Windows 10** or **Windows 11**. Default: **Windows 11**.                                                                                                 |
| Operating system version | Target version: 21H2, 22H2, 23H2, 24H2, 25H2, or 26H2. Default: **25H2**.                                                                                  |
| Upgrade method           | The Windows Setup `/auto` option. See below. Select a method when you add the step.                                                                        |
| Dynamic update option    | Whether Windows Setup downloads updates during the upgrade: **Enable**, **Disable**, **NoDrivers**, **NoLCU**, or **NoDriversNoLCU**. Default: **Enable**. |
| Disable Shift-F10        | Prevents opening a command prompt with Shift-F10 during setup. Default: `false`.                                                                           |

The upgrade methods are:

* **Upgrade**: keep apps, settings, and user data.
* **DataOnly**: keep user data, but not apps or settings.
* **Clean**: keep nothing.
* **CompatScanOnly**: run the Windows Setup compatibility check without upgrading. The step succeeds if no compatibility issues are found, and fails with the Setup return code otherwise.

### How it works

1. The step downloads the media to the device and runs `Setup.exe` with `/quiet`. BitLocker is always suspended during the upgrade.
2. When Setup finishes its first phase, the device restarts and Windows completes the upgrade.
3. After the upgrade (or a rollback), DeployR runs again and the step checks the result. It succeeds if the upgrade completed. It fails with return code `2201` if Windows rolled back to the previous version, or `2202` for any other unexpected result.

Because a failed upgrade returns an error, you can put recovery steps in a group with the condition `_LastActionSucceeded` equals `false`, as the template does.

After the step runs, details about the target image are available in task sequence variables such as `OSImageName`, `OSImageVersion`, `OSImageBuild`, and `OSImageEditionId`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://documentation.2pintsoftware.com/deployr/reference/step-definitions/upgrade-operating-system-from-cloud.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.