windows Archives | XOAP

Windows OS (re)deployment with XOAP and OSDCloud

Perica — Fri, 22 May 2026 11:34:27 +0000

<\/path><\/svg>"},"no_headings_message":"No headings were found on this page.","minimize_box":"yes","minimized_on":"tablet","hierarchical_view":"yes","min_height":{"unit":"px","size":"","sizes":[]},"min_height_tablet":{"unit":"px","size":"","sizes":[]},"min_height_mobile":{"unit":"px","size":"","sizes":[]}}" data-widget_type="table-of-contents.default">

Managing large-scale Windows deployments is one of the more demanding responsibilities in IT operations. Between inconsistent hardware configurations, compliance requirements and the ongoing need to keep devices registered and managed after installation, the process is rarely as straightforward as it should be.

This article outlines how XOAP and OSDCloud work together to address these challenges and covers the three deployment approaches the integration supports, each differing in boot image type and Windows image source, so you can select the option that fits your infrastructure.

Challenges of Windows OS deployment

Deploying Windows at scale consistently surfaces the same set of problems:

Configuration difficulty: Different device groups require different driver sets, OS editions, language packs and activation types. Managing these variations manually introduces errors and does not scale effectively across large fleets.
Hardware consistency: Devices from different manufacturers behave differently during deployment. Without a controlled, repeatable process, the result is a fleet that starts its lifecycle in an inconsistent state.
Security and compliance from day one: OS deployment is the point at which security baselines should be enforced. Organizations that rely on post-deployment remediation are taking on unnecessary risk and audit exposure.
Post-deployment management continuity. Installing an operating system is only the first step. Registering devices for ongoing management, applying configurations and deploying standard applications still need to happen — ideally without any manual intervention.

Traditional solutions such as MDT, SCCM and WDS address these problems but require significant infrastructure investment and ongoing maintenance. XOAP combined with OSDCloud provides an alternative that requires no dedicated imaging infrastructure beyond a single virtual machine for ISO creation and, for Scenario 3, a network share or other storage location for the ISO file.

Three deployment scenarios

XOAP and OSDCloud integration supports three distinct scenarios. Each is designed for a different infrastructure context, and the choice between them depends on the type of boot image required, where the Windows image is sourced from and how deployment is triggered.

Scenario 1: OS downloaded from the internet

This scenario requires no local image hosting. The target device boots into WinPE, downloads the Windows image directly from Microsoft Update, completes installation and registers automatically with the designated XOAP Workspace.

Infrastructure required:
• 1 Windows 11 24h2 virtual machine (for ISO creation)
• Internet access on the ISO creator VM and on target devices

Preparing the ISO:
On the ISO creator VM, install the OSDCloud tooling either through XOAP by applying the OSDCloud Workspace Internet OS Application Role, or manually by running the following PSADT packages in order:

1. APP_Microsoft_WindowsAssessmentDeploymentKit_101261002454_Any_x64_EN
2. APP_Microsoft_WindowsPEforADK_101261002454_Any_x64_EN
3. APP_DavidSegura_OSDCloudISOCreator_121_Any_Any_EN
Before starting the installation, run the following command to set the execution policy:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine -Force

During setup, configure the parameters that define the deployment image:

Parameter description:

Parameter	Description
Driver	Drivers to include in boot.wim — use * for all or None to skip
OSVersion	Windows 10 or Windows 11
OSBuild	Target build (e.g. 22h2, 24h2) — Windows 10 supports 21h2 and 22h2 only
OSEdition	Home, Pro, Enterprise, etc.
OSLanguage	Language of the deployed OS
OSActivation	Volume or Retail
XOAPWorkspaceID	The Workspace ID found on the XOAP dashboard
XOAPConfigurationGroup	The configuration group newly deployed devices will join

Once complete, OSDCloud_NoPrompt.iso is generated in C:\OSDCloudWorkspace.

Uploading and configuring in XOAP:
Add the generated ISO into the Files subfolder of the SYS_XOAP_OSDcloudRElocal_100_Any_Any_Any PSADT package, zip the package and upload it to XOAP via Application Management > Applications. Once uploaded, create an Application Role and a Configuration Group for the application. When that Configuration Group is deployed to a target device, re-deployment begins automatically.

The device extracts the ISO to a newly created Windows Recovery (WinRE) partition. After a reboot, the device boots from that partition into the OSDCloud WinPE environment, wipes and repartitions the disk and downloads the Windows image from Microsoft Update for installation.

After OS installation, OSDCloud sets up SetupComplete scripts that register the device with the XOAP Workspace on first startup, provided internet access is available. In parallel, a scheduled task is configured to run at user logon and check XOAP connectivity — if the device is already registered the task removes itself, and if not it will attempt registration whenever an internet connection is present.

Scenario 2: WinPE boot with OS downloaded from the internet

This scenario follows the same end-to-end flow as Scenario 1. The Windows OS is downloaded from the internet during the WinPE phase, but uses a Recovery Full boot image. The difference lies in the boot.wim: rather than a minimal WinPE environment, the boot image includes the full install.wim file, which is used to construct the WinPE environment itself.

Use the OSDCloud Workspace Recovery Full Application Role or the APP_DavidSegura_OSDCloudISOCreatorRecoveryFull_121_Any_Any_EN package in place of the standard ISO creator. The setup process, required parameters and XOAP upload steps are otherwise identical to Scenario 1.

Note: This scenario is not currently supported for re-deployment on Hyper-V virtual machines. The partition containing the install.wim file does not get mapped correctly in that environment and has not been tested on other virtualisation platforms.

Scenario 3: OS re-deployment from a network share, local source or other

This scenario covers OS re-deployment using the OSDcloud_RE_from_localISO.ps1 script rather than a XOAP-managed PSADT package. It supports two options for sourcing the Windows image during WinPE – internet download or retrieval from a network share or local source, and is suited to environments where more control over the deployment trigger is required.

Scenario 3 supports two options for where the Windows image is sourced during WinPE:

• OS downloaded from the internet — use the OSDCloud Workspace Internet OS Application Role or the APP_DavidSegura_OSDCloudISOCreator_121_Any_Any_EN package, with the standard parameters as described in Scenario 1
• OS retrieved from a network share — use the OSDCloud Workspace local OS Application Role or the APP_DavidSegura_OSDCloudISOCreatorLocalShare_121_Any_Any_EN package, with the following additional parameters:

Parameter description:

ShareUser	A user account with read access to the network share
ShareUserPassword	The password for that account
UncSharePath	The UNC path to the share, e.g. \\srv1\xoap

When using a network share, it must follow a specific folder structure for OSDCloud to locate the image:
\\shareserver\sharename\OSDcloud\OS.

Triggering deployment:
Rather than packaging the ISO within a PSADT application, deployment is triggered using the OSDcloud_RE_from_localISO.ps1 script with the -LocalISOPath parameter:
OSDcloud_RE_from_localISO.ps1 -LocalISOPath “\\srv1\xoap\OSDCloud_NoPrompt.iso”

This script manages the complete OSDCloudRE setup process: creating the WinPE partition, mounting the ISO, copying boot content, configuring Boot Manager entries and initiating a reboot into the recovery environment. It can be called directly via a XOAP connector, or embedded within a DSC configuration module to allow additional steps such as ISO integrity hash checks, prerequisite validation and file backups before the wipe begins.

The script has been tested with ISOs located on local devices and network shares. For other storage types such as Azure Blob Storage, GitHub or OneDrive, the script would need to be extended to handle the download step before invoking the local ISO logic.

Deploying to multiple workspaces or configuration groups? This applies to all three scenarios. Run the ISO creation process again with the required parameters for each target workspace or configuration group. Rename or move the OSDCloud_NoPrompt.iso file from C:\OSDCloudWorkspace between runs, as each new run overwrites the previous file.

The deployment process on the target device

Regardless of which scenario is used, the process on the target device follows the same sequence:

1. The Configuration Group deploys the PSADT package to the target device, which extracts the ISO, creates the WinRE partition and triggers a reboot or for Scenario 3, the OSDcloud_RE_from_localISO.ps1 script is executed directly
2. The device boots from the OSDCloudRE WinPE partition
3. If connected via Ethernet, deployment proceeds without interaction; if not, a wireless network selection prompt is displayed (keyboard layout is en-us at this stage)
4. The operator confirms disk wipe; this is the only interactive step in the process
5. Windows is installed and SetupComplete scripts run, registering the device with the XOAP Workspace on first startup if internet access is available; a scheduled task also runs at each subsequent user logon to verify and retry XOAP registration if needed
6. The device reboots into the newly installed, managed Windows environment

Ongoing management after deployment

Once registered in the XOAP Workspace, devices are immediately subject to the policies and configurations defined in their assigned Configuration Group. Standard applications can be deployed and system and user configurations enforced without any further manual steps. The result is a consistent, compliant endpoint from the point of first boot.

Getting started

All three scenarios require a Windows 11 24h2 virtual machine and a XOAP account for ISO creation. Internet access is required on the ISO creator VM and on target devices for Scenarios 1 and 2.

For Scenario 3 with a network share image source, internet access is required on the ISO creator VM but target devices can operate without it during the WinPE phase.

Create your free XOAP account or book a demo to walk through your specific deployment requirements with the team.

Also read:
→ Master the BIOS management
→ 30-day guaranteed IT automation delivery with XOAP
→ From cryptic SIDs to clear names: The end of Entra identity confusion
→ How XOAP modernizes Citrix MCS and PVS
→ How to automate AWS without using Terraform

Explore XOAP

The post Windows OS (re)deployment with XOAP and OSDCloud appeared first on XOAP.

Secure your Windows environment with XOAP Windows LAPS DSC

Perica — Mon, 17 Jun 2024 12:55:30 +0000

In today’s digital landscape, maintaining the security of your Windows infrastructure is paramount. One of the critical aspects of this security is managing local administrator passwords, which, if mishandled, can become a significant vulnerability.

Say hello to XOAP Windows LAPS DSC a robust solution designed to enhance your security posture by automating the management of local administrator passwords across your Windows environment.

What is XOAP Windows LAPS DSC?

XOAP Windows LAPS DSC is a powerful Desired State Configuration (DSC) module that leverages the capabilities of the Local Administrator Password Solution (LAPS) to manage and securely store local administrator passwords on domain-joined machines. By integrating with the DSC framework, XOAP Windows LAPS DSC allows for the automated deployment and configuration of LAPS policies, ensuring that local administrator passwords are unique, randomly generated and periodically updated.

Key features

1. Automated password management: XOAP Windows LAPS DSC automates the generation, storage, and updating of local administrator passwords, significantly reducing the risk of password-related breaches.

2. Centralized control: Manage and monitor password policies centrally using DSC, ensuring consistent security practices across your organization.

3. Seamless integration: Easily integrate with existing Active Directory infrastructures, making deployment straightforward and hassle-free.

4. Compliance and auditing: Meet compliance requirements with detailed auditing capabilities, ensuring password policies are enforced and tracked.

Why use XOAP Windows LAPS DSC?

Enhanced security

Local administrator accounts are often targeted by attackers looking to gain privileged access. By using XOAP Windows LAPS DSC, you make sure that each local administrator password is unique and regularly updated, drastically reducing the attack surface.

Operational efficiency

Manual password management is not only time-consuming but also prone to errors. Automating this process with XOAP Windows LAPS DSC frees up IT resources and ensures that password policies are consistently applied across all machines.

Compliance and auditing

Regulatory frameworks often require strict password management practices. XOAP Windows LAPS DSC helps organizations meet these requirements by providing detailed logs and reports on password policy enforcement and changes.

Simplified management

With DSC, administrators can define the desired state of their infrastructure using configuration files. XOAP Windows LAPS DSC extends this capability to local administrator passwords, allowing for easy deployment and management through familiar DSC tools.

Getting started with XOAP Windows LAPS DSC

Prerequisites

Windows PowerShell: Make sure you have Windows PowerShell 5.1 or later installed.

DSC: Familiarity with the Desired State Configuration is beneficial.

Active Directory:

Active Directory environment to manage domain-joined machines
- - - Update AD schema
    - Grant permissions
    - Check Domain Functional Level (DFL) prerequisites
    - Get started with Windows LAPS and Windows Server Active Directory

Entra ID (Azure AD ) environment to manage -joined machines
- - - Enable Local Administrator Password Solution (LAPS) setting
    - Windows Local Administrator Password Solution in Microsoft Entra ID

Installation

To install the XOAP Windows LAPS DSC module, you can navigate to our Github repo. As with all other DSC modules that we provide, this one is free to use in and outside of the XOAP universe.

Download the files in the releases section and extract the contents into one of your locations that are used for searching modules. The list of locations can be shown by checking the value of the “$env:PSModulePath” variable.

An example of the standard path is: $Env:programfiles/WindowsPowerShell/Modules.

When you’re extracting the files, please use the correct folder structure:

Configuration

For easier understanding how to use XOAPWinowsLAPSDSC module, below is documentation of used resources:

⭢ AzureADWindowsLAPSSettings

				
					 AzureADWindowsLAPSSettings [String] #ResourceName
	    {
	        [DependsOn = [String[]]]
	        [PsDscRunAsCredential = [PSCredential]]
	        [AdministratorAccountName = [String]]
	        [PasswordAgeDays = [Int32]]
	        [PasswordLength = [Int32]]
	        [PasswordComplexity = [Int32]]
	        [PostAuthenticationResetDelay = [Int32]]
	        [PostAuthenticationActions = [Int32]]
	    }

⭢ LocalADWindowsLAPSSettings

				
					LocalADWindowsLAPSSettings [String] #ResourceName
    {   
        [DependsOn = [String[]]]
        [PsDscRunAsCredential = [PSCredential]]
        [AdministratorAccountName = [String]]
        [PasswordAgeDays = [Int32]]
        [PasswordLength = [Int32]]
        [PasswordComplexity = [Int32]]
        [PasswordExpirationProtectionEnabled = [Boolean]]
        [ADPasswordEncryptionEnabled = [Boolean]]
        [ADPasswordEncryptionPrincipal = [String]]
        [ADEncryptedPasswordHistorySize = [Int32]]
        [ADBackupDSRMPassword = [Boolean]]
        [PostAuthenticationResetDelay = [Int32]]
        [PostAuthenticationActions = [Int32]]
    }

⭢ WindowsLAPSEmulationMode

				
					 WindowsLAPSEmulationMode [String] #ResourceName
 {
	[DependsOn = [String[]]]
	[PsDscRunAsCredential = [PSCredential]]
	[AdministratorAccountName = [String]]
	[PasswordAgeDays = [Int32]]
	[PasswordLength = [Int32]]
	[PasswordComplexity = [Int32]]
	[PasswordExpirationProtectionEnabled = [Boolean]]
	[AdministratorPasswordEnabled = [Boolean]]
 }

Example

This is an example of a configuration that uses AzureADWindowsLAPSSettings:

				
						configuration 'TestConfigAzureAD_
	{
	    Import-DscResource -ModuleName 'XOAPWindowsLAPSDSC' -ModuleVersion '0.0.2'
	    
	    AzureADWindowsLAPSSettings 'TEST'
	    {
	        AdministratorAccountName = 'TestAdmin'
	        PasswordAgeDays = '14'
	        PasswordLength = '16'
	        PasswordComplexity = '4'
	        PostAuthenticationResetDelay = '2'
	        PostAuthenticationActions = '1'
	    }
	}
	TestConfigAzureAD

Instead of writing this configuration in a code editor locally, you can also use XOAP. Using our DSC configuration wizard, you can create a LAPS configuration by using our simple-to-use frontend, create different versions of the configuration every time you save a change and prepare everything to deploy LAPS to multiple customers and groups.

To create a new LAPS config you need to follow a few steps:

1. Navigate to the Configuration Management area, go to Configurations and click the + button to create a new configuration.

2. Define general settings like Name, Description and Tags and click “Add Resources”.

3. Select the “XOAPWindowsLAPSDSC” module, Version and Resource and configure the settings.

4. Once when all resources are configured, you can save the configuration and use it in Configuration Management groups to apply the settings to your nodes.

The good thing is, you don’t need to think about DSC syntax when you use XOAP to deploy LAPS configurations. The configuration wizard will guide you and it will allow you to input only valid types for parameters. Also, versioning of configurations allows you to easily change and deploy possible future changes of your LAPS configurations.

If you need more information about the Configuration Wizard, or how to apply configurations to your environments, please check our documentation.

Your next step

In a time where cybersecurity threats are ever-evolving, taking proactive steps to secure your Windows environment is crucial. XOAP Windows LAPS DSC offers a comprehensive solution for automating local administrator password management, enhancing security and ensuring compliance.

By integrating this module into your infrastructure, you can streamline password management processes, reduce risks and focus on other critical aspects of your IT operations.

Explore more about XOAP Windows LAPS DSC on its GitHub repository and take the first step towards a more secure Windows environment!

Deploy LAPS to multiple accounts or customers

The post Secure your Windows environment with XOAP Windows LAPS DSC appeared first on XOAP.