> 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/task-sequences/continuation-methods.md). # Continuation methods Starting a bare-metal deployment with DeployR involves booting the device from PXE or from a boot ISO containing a pre-generated Windows PE image with the DeployR client. After a task sequence is selected, the individual steps are executed. These steps are customizable, but typically consist of formatting a disk, downloading and applying a Windows image, injecting any needed drivers, and then booting into the new OS to customize it by applying apps and other tweaks. A task sequence can continue in the new operating system in several ways. You can select these methods from the **Continuation method** drop-down list in the [**Apply operating system**](/deployr/reference/step-definitions/apply-operating-system.md) or [**Apply operating system from cloud**](/deployr/reference/step-definitions/apply-operating-system-from-cloud.md) step. The available options are: * Use SetupComplete.cmd (1). When choosing the SetupComplete.cmd option, the Out-of-Box Experience (OOBE) process will be completely automated using a provided unattend.xml template. The DeployR client will resume executing after OOBE completes by placing a SetupComplete.cmd file on the device that contains the necessary commands. Note that this is only supported with Windows volume license (VL) media. (This is similar to the mechanism used by Microsoft Configuration Manager.) * Use Specialize phase RunSynchronous command (2). When you select the Specialize option, an `unattend.xml` template runs the commands required to resume the task sequence with the DeployR client while Windows is still in the Specialize phase, before OOBE starts. Note that there may be some restrictions in this phase because Windows is still considered to be in "setup mode" at this point. For example, Windows Update processing will not work during the Specialization phase. * Use AutoAdminLogon and RunOnce (3). When choosing AutoAdminLogon, the local Administrator account will be enabled and its password will be set via the provided unattend.xml file, and the OOBE process will be automated. After OOBE completes, the local Administrator account will log on and the task sequence will resume via a Windows "RunOnce" registry entry. There are no restrictions on what can be done in this way. You can configure the password that is set on the local Administrator account via a task sequence variable (AdminPassword). (This is similar to the mechanism used by Microsoft Deployment Toolkit.) * Use OOBE (4). When specifying "Use OOBE," DeployR will complete the task sequence while in Windows PE; it will not resume in the new OS. This is designed primarily for Windows Autopilot scenarios where customizations in the new OS are to be performed through other means (e.g. Intune). The task sequence should complete while still in Windows PE. * Use Audit mode (5). When specifying to "Use Audit mode," Windows will start up and immediately boot into Audit mode, which was initially designed for OEMs and distributors to customize the OS before it goes through the OOBE process. In audit mode, Windows will automatically sign into the computer's Administrator account (even though that account has not been enabled and no password has been set); customizations such as installing apps and other tweaks can then be performed. Once the task sequence completes, the device will boot back to the full OS to go through the OOBE process. Because this OOBE process will not be automated, this is an ideal scenario for Windows Autopilot. Note that there may be some restrictions in this phase because Windows is still considered to be in "setup mode" at this point. For example, Windows Update processing will not work during the Audit mode. * Use provided unattend.xml (0). If you want, you can specify your own unattend.xml to use. Depending on how you choose to resume the task sequence, it is then your responsibility to run the needed command line to resume the DeployR client. ### Unattend.xml Behavior All continuation methods except audit mode generate an unattend.xml file, populating it with default information, or based on variables created before the step or steps. The following defaults from the Defaults.json file are applied: ```json "ComputerName": "PC-%RAND:10%", "HomePage": "about:blank", "InputLocale": "0409:00000409", "SystemLocale": "en-us", "UILanguage": "en-us", "UserLocale": "en-us", "AdminPassword": "%PWD:32%", "TimeZone": "Pacific Standard Time" ``` Steps like [Set Windows settings](/deployr/reference/step-definitions/set-windows-settings.md) set some of those items for you when added before the Apply OS step, such as TimeZone, InputLocale, SystemLocale, UILanguage, and UserLocale. Others can be set using custom scripts or **Set variable** steps. Additional modifications are made during the [Apply OS](/deployr/reference/step-definitions/apply-operating-system.md) step (or the other Apply OS steps) to ensure that the correct continuation method is triggered. For a look under the hood, check out the PowerShell scripts that run during those steps, for example Apply.ps1 and ApplyWU.ps1. --- # 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/task-sequences/continuation-methods.md?ask=&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.