Perica, Author at 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.

How to: Bare metal OS deployment with XOAP

Perica — Fri, 15 May 2026 12:28:59 +0000

When a new hardware batch arrives, the expectation is straightforward: devices should be provisioned, configured and enrolled in the management platform with minimal delay. In practice, however, bare metal deployment is often one of the most labour-intensive stages of the device lifecycle.

XOAP addresses this through an automated, repeatable deployment pipeline that provisions a device from bare metal and connects it to the correct XOAP workspace without requiring manual intervention at the device level.

This article describes how the process works and outlines both supported deployment methods: PXE boot and USB.

How XOAP approaches bare metal deployment

The deployment pipeline is built on OSDCloud, a PowerShell-based framework for OS installation via Windows PE. XOAP extends this with a preconfigured set of PSADT packages that handle environment setup, image creation and post-installation enrollment – producing a deployment artefact that is repeatable, parameterised and tied to a specific XOAP workspace and configuration group.

The critical mechanism is what occurs at the end of each installation. Once the operating system has been applied, OSDCloud executes SetupComplete scripts that register the device with XOAP automatically. If internet connectivity is unavailable at first boot, a scheduled task is created that checks for connectivity on every user logon and initiates enrollment as soon as a connection is established. Once the device is registered, the task deregisters itself.

The result is a device that enters the managed environment without requiring any post-installation steps from the engineer.

Deployment methods

XOAP supports two distinct paths for bare metal OS deployment, each suited to a different infrastructure context.

Method 1: PXE boot (network deployment)

PXE boot is appropriate for large-scale deployments within environments that have Active Directory, DHCP and DNS in place. Devices boot from the network and receive a custom Windows PE environment that drives the full installation without a physical boot medium.

Infrastructure requirements

Active Directory, DHCP and DNS environment
One Windows Server VM (2019, 2022 or 2025) for the WDS/PXE role
One Windows 11 24H2 VM for building the OSDCloud ISO
Internet access for the build VM and for newly staged devices

Setup process

The process begins on the ISO creator VM. Using XOAP application roles or locally installed PSADT packages, Windows ADK and Windows PE for ADK are deployed first, followed by the OSDCloud ISO Creator package. This package accepts the required deployment parameters – OS version, build, edition, language, activation method, target XOAP Workspace ID and Configuration Group – and produces a custom OSDCloud_NoPrompt.iso in C:\OSDCloudWorkspace. The resulting ISO contains the XOAP enrollment configuration, ensuring that every device deployed from it connects to the correct workspace and configuration group.

The boot.wim file is extracted from the ISO and imported into Windows Deployment Services on the WDS server. The install.wim from a standard Windows ISO is placed in the XOAP share at C:\RemoteInstall\Images\XOAP\OSDcloud\OS. Where bandwidth is constrained or internet access is unavailable during staging, the Windows image can alternatively be sourced from a local network share – a separate ISO Creator package and additional parameters (ShareUser, ShareUserPassword and UncSharePath) are required for this variant.

DHCP scope options complete the server-side configuration: option 066 (Boot Server Host Name) pointing to the WDS server and option 067 (Bootfile Name) pointing to the UEFI boot file. Any device that PXE boots on the configured network segment is then served the Windows PE environment automatically.

Device-side experience

The technician connects the device to the deployment network and initiates PXE boot, typically via F12 on startup. The WDS Boot Manager presents the available WinPE images, the correct image is selected, and the operator chooses the target Windows image and edition. After confirming disk cleanup, the installation completes without further interaction. The device reboots into a freshly installed, XOAP-managed Windows environment.

A notable capability of the PXE approach is that multiple boot.wim files can be imported into WDS, each configured with a different XOAP Workspace ID or Configuration Group. A single WDS server can therefore serve deployments across multiple clients or environments, with the operator selecting the appropriate boot image at startup. For MSPs managing multiple tenants, this provides multi-tenant isolation at the image level.

Method 2: USB stick (standalone deployment)

The USB method is suited to deployments where no PXE or DHCP infrastructure exists – at a new client site, in a remote office or for smaller ad hoc rollouts. The underlying process is the same but the boot environment is delivered from a USB drive rather than a network server.

Infrastructure requirements

One Windows 11 24H2 VM to build the OSDCloud ISO
One physical workstation to create the bootable USB
Internet access for the build VM and staged devices

Setup process

ISO creation follows the same procedure as the PXE method: deploy Windows ADK, Windows PE for ADK and the OSDCloud ISO Creator via XOAP or PSADT packages with the appropriate parameters. The resulting OSDCloud_NoPrompt.iso contains the customised boot environment with XOAP enrollment embedded.

The ISO is transferred to a physical machine, where the OSD PowerShell module is used to write it to a USB drive:

Install-Module -Name OSD
New-OSDCloudUSB -fromIsoFile “C:\Path\To\OSDCloud_NoPrompt.iso”

The command prompts for the target USB drive and confirmation of the wipe. Where deployment from a local Windows image is preferred over an internet download, an install.wim file can be copied to OSDCloudUSB:\OSDcloud\OS\ on the USB after creation.

Device-side experience

The technician connects the USB, boots from it and the OSDCloud WinPE environment initialises. Where the device has no wired network connection, a wireless network selection prompt appears automatically – WLAN support is provided via WinRE integration in the boot environment. The operator selects the Windows image and edition, confirms the disk wipe, and the installation proceeds. Post-installation enrollment via SetupComplete follows the same process as the PXE method.

The OSDCloud XOAP package stack

Both deployment methods rely on the same three-package stack. Windows Assessment and Deployment Kit (ADK) – version 10.1.26100.2454: the foundational requirement for building custom WinPE environments. Windows PE for ADK – version 10.1.26100.2454: extends ADK with the Windows PE add-on, enabling bootable pre-installation environments. OSDCloud ISO Creator: the package that contains the XOAP-specific logic. It installs the OSD PowerShell module, creates the OSDCloud template with WinRE (required for WLAN support in WinPE), configures the OSDCloud workspace and embeds the SetupComplete and StartNet scripts responsible for XOAP enrollment. Hardware drivers are injected into the boot.wim at this stage. The output is OSDCloud_NoPrompt.iso.

The parameters required at install time are: driver set, OS activation method, OS build (e.g. 24H2 or 25H2), OS edition, OS language, OS version, target XOAP Configuration Group and XOAP Workspace ID.

To generate images for multiple XOAP workspaces, the package is run again with different parameters. The ISO must be renamed or moved between runs, as each execution overwrites the previous output at the same path.

Ready to see it in action?

XOAP’s bare metal deployment capability is one component of a broader infrastructure automation platform that takes devices from zero to fully managed with minimal manual touchpoints at every stage.

Book a demo to see how XOAP handles OS deployment, endpoint management and configuration delivery across your entire device fleet.

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 How to: Bare metal OS deployment with XOAP appeared first on XOAP.

XOAPChangeBIOSsettingDSC: Master the BIOS management

Perica — Fri, 30 Jan 2026 09:09:46 +0000

Managing BIOS settings across a diverse fleet of devices has historically been a headache for IT administrators. Different vendors, different tools, and varying security requirements often lead to fragmented workflows.

To streamline this process, we are excited to share a new PowerShell DSC (Desired State Configuration) module: XOAPChangeBIOSsettingDSC. This module provides a unified way to manage BIOS configurations on both Dell and Lenovo devices using infrastructure-as-code principles.

Key features

Multi-vendor support: Works seamlessly across Dell and Lenovo hardware.
Security minded: Fully tested to work with or without BIOS passwords.
Granular control: Allows for precise setting definitions (e.g., Secure Boot, Wake-on-LAN, etc.).

Important usage notes

To ensure successful deployment, keep these two technical details in mind:

Case sensitivity: The module is case-sensitive regarding setting names. For example, you must use SecureBoot exactly as defined by the vendor; using secureboot will result in an error.
Discovery: If you are unsure of the exact naming or possible values for a setting, you can refer to the scripts within the TestScript portion of the DSC Resources. These can be used to read all available values directly from the hardware.

Why DSC for BIOS?

By using DSC, you ensure that your hardware configuration remains in the “Desired State”. If a user or an update manually changes a BIOS setting, DSC will automatically detect the drift and pull the setting back to your defined corporate standard.

Installation and usage

There are no special prerequisites for this module.

To install the module in XOAP:

Upload the zipped DSC module to Configuration Management → Modules.
Once uploaded, the module can be referenced and used in your DSC configuration as needed.

Get the XOAPChangeBIOSsettingDSC module

Simplify BIOS management across your devices. Get free access to the module now and replace manual, error-prone processes with a unified approach.

Download the free module

The post XOAPChangeBIOSsettingDSC: Master the BIOS management appeared first on XOAP.

Migrate to Windows 11 with PSADT

Perica — Fri, 25 Apr 2025 11:11:25 +0000

In our previous blog posts, we explored different approaches to migrating to Windows 11: using SCCM, through XOAP, via GPOs and registry keys and Windows Update in Settings . In this post, we’ll walk you through yet another method – deploying the Windows 11 upgrade package using PowerShell App Deployment Toolkit (download XOAP Package Wizard for PSADT v4 for free).

Watch:
XOAP Package Wizard PSADT v4 walk-through

Use PSADT to migrate from Windows 10 to Windows 11

To get started, extract the contents of your Windows 11 ISO file and include them in your PSADT package. Then, you’ll use the setup.exe file from the extracted ISO along with specific command-line parameters to upgrade from Windows 10 to Windows 11.

Once you’ve got your source file ready, it’s time to modify the “Deploy-Application.ps1” script. In the pre-installation part, it will check if a scheduled task exists and delete it (in case of failures/reruns).

				
					#### (Pre-Install) Delete Scheduled Task -------------------------------------------->
$DELTaskName = 'Win11Upgrade'
# Check if the task exists
$DELTaskExists = Get-ScheduledTask -TaskName $DELTaskName -ErrorAction SilentlyContinue
if ($DELTaskExists) {
    # Delete the task
    Unregister-ScheduledTask -TaskName $DELTaskName -Confirm:$false
    Write-Output "(Pre-Install) Task '$DELTaskName' has been deleted."
} else {
    Write-Output "(Pre-Install) Task '$DELTaskName' does not exist.  Moving on to Installation"
}

In the installation part, a scheduled task will be created and started. While loop is used to check if the task is still running after it was started.

				
					 ###># CREATE SCHEDULED TASK -------------------------------------------------------->
    $STExecutable = "$dirfiles\ISO\Setup.exe"
    $STArguments = "/Auto Upgrade /EULA accept /NoReboot"
    $STTaskName = "Win11Upgrade"
    $STTriggerTime = (Get-Date).AddSeconds(15)
    $STPriority = 4
    $STTrigger = New-ScheduledTaskTrigger -Once -At $STTriggerTime
    $STSettings = New-ScheduledTaskSettingsSet -StartWhenAvailable -Priority $STPriority -RunOnlyIfNetworkAvailable -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
    # Create a new scheduled task action
    $STAction = New-ScheduledTaskAction -Execute $STExecutable -Argument $STArguments -WorkingDirectory (Split-Path $STExecutable)
    # Create a new scheduled task principal for the SYSTEM account
    $STPrincipal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest
    # Create and register the new scheduled task
    $STTask = New-ScheduledTask -Action $STAction -Trigger $STTrigger -Settings $STSettings -Principal $STPrincipal
    Register-ScheduledTask -TaskName $STTaskName -InputObject $STTask

    #### KICK OFF SCHEDULED TASK ------------------------------------------------------>
    Start-Sleep 10
    Start-ScheduledTask -TaskName "Win11Upgrade"
    #### MONITOR SCHEDULED TASK ------------------------------------------------------->
    $STTaskName = "Win11Upgrade"
    # Loop until the task is no longer running
    while ((Get-ScheduledTask -TaskName $STTaskName).State -eq "Running")
    {
        # Get task information
        $taskInfo = Get-ScheduledTaskInfo -TaskName $STTaskName
        # Verify if the task is being run by SYSTEM
        if ((Get-ScheduledTask -TaskName $STTaskName).Principal.UserId -eq "SYSTEM")
        {
            # Write to the output
            Write-Output "$STTaskName is still running as SYSTEM"
        }
        else
        {
            Write-Output "$STTaskName is still running, but not as SYSTEM"
        }
        # Wait for 10 seconds before checking again
        Start-Sleep -Seconds 10
    }
    Write-Output "$STTaskName has finished running"

In the post-installation part, created scheduled task is deleted.

				
					#### (Post-Install) Delete Scheduled Task -------------------------------------------->
    $DELTaskName = "Win11Upgrade"
    # Check if the task exists
    $DELTaskExists = Get-ScheduledTask -TaskName $DELTaskName -ErrorAction SilentlyContinue
    if ($DELTaskExists) {
        # Delete the task
        Unregister-ScheduledTask -TaskName $DELTaskName -Confirm:$false
        Write-Output "(Post-Install) Task '$DELTaskName' has been deleted."
    } else {
        Write-Output "(Post-Install) Task '$DELTaskName' does not exist."
    }

There are a couple of options to consider if you want to expand on this package:

Add Windows 11 prerequisites check
Expand it with PSADT functions like:
– Show-InstallationWelcome
– Show-InstallationProgress
– Show-InstallationRestartPrompt
Adjust available scheduled task options:
– RunOnlyIfNetworkAvailable
– AllowStartIfOnBatteries
– DontStopIfGoingOnBatteries
Add other parameters to setup.exe run (for example “/Product Server” as a workaround for the prerequisites check)

You're good to go!

Upgrading to Windows 11 with PSADT is a flexible option if you want more control over the process. With a few script tweaks, you can handle the upgrade from start to finish.

You may also like:
→Windows 11 migration via SCCM
→Step-by-step: Windows 11 migration using GPOs and registry keys
→Windows 11 migration made easy with XOAP
→How to migrate to Windows 11 via Windows Update in Settings

The post Migrate to Windows 11 with PSADT appeared first on XOAP.

Windows 11 migration made easy with XOAP

Perica — Wed, 23 Apr 2025 12:27:04 +0000

This quick guide shows how to upgrade Windows 10 devices to Windows 11 using XOAP. The example uses Lenovo T490s and walks through setting up driver and application groups, then deploying them through XOAP. You can apply the same approach to your own device type. If you need assistance, contact us here. Let’s get started!

Upgrade to Windows 11 with XOAP: Simple steps

In this example, we are going to configure the migration for Lenovo T490s devices.

Inside XOAP’s Application Management, we have created 2 Application Groups from our Applications:

Lenovo T490s (installs Windows 11 drivers for Lenovo T490s)
Migration to Windows 11 24H2 (installs Windows 11 24H2 as an in-place upgrade)

To create an application group for driver installation, you need to:

- Download the corresponding driver package for your device from a manufacturer’s web page (for our example: Lenovo PC Support – ThinkPad T490s).
- Extract and package those drivers using PSADT. For the installation part, you can use the following command inside PSADT: pnputil /add-driver $dirFiles\tp_t490s_x390_w11_22_202210\*.inf /install /subdirs
- Import the created PSADT Package in XOAP: Application Management > Applications > New Application.

After that, you can navigate to Application Groups and create an Application Group using the imported application. Application Management > Application Groups > New Group.

WATCH VIDEO
2-minute overview of the migration processTutorial continues below

This video may not load due to your cookie preferences. Adjust your cookie settings or watch it directly on YouTube.

In the New group window, set the name for the application group and search for your imported application. Once you find the correct application, go to Add Group and choose your installation settings for that package.

When creating an Application group from Windows 11 24H2 Application, there area a couple of options to choose from:

- AllowStartIfOnBatteries
- DontStopIfGoingOnBatteries
- RunOnlyIfNetworkAvailable
- SkipPrereqCheck (skips all prerequisite checks for Windows 11)

After that, we create an Application Role from those 2 Application Groups.

After the Application Role is created, we have to create a Configuration Group, inside of XOAP’s Configuration Management, by choosing our Application Role and XOAP_Applications_and_Monitoring configuration.

Then, download the registration script and deploy it to clients. Once the configuration is started on clients, both of our packages (Drivers and Win11) are going to prompt for user confirmation before installing and for a restart after installation.

All set!

That wraps it up. Once everything’s in place, XOAP takes care of the upgrade. Just adjust the steps for your own devices and you’re good to go.

You may also like:

→Complete Windows 11 migration guide for enterprise IT
→How to migrate to Windows 11 via Windows Update in Settings
→Windows 11 migration via SCCM
→Step-by-step: Windows 11 migration using GPOs and registry keys

Migrate to Windows 11 with XOAP

The post Windows 11 migration made easy with XOAP appeared first on XOAP.

Step-by-step: Windows 11 migration using GPOs and registry keys

Perica — Wed, 16 Apr 2025 11:55:10 +0000

If you’re planning to upgrade your devices to Windows 11, there are several ways to go about it. In our previous blog post, we showed how to use the Windows Update settings to start the upgrade.

In this post, we’ll focus on using Group Policy Objects (GPOs) and registry keys to manage the migration. Even if you’re using Windows Update to deploy updates, you can still control how and when Windows 11 is offered to eligible devices.

By setting the right policies, you can make sure the upgrade process fits your organization’s needs.

Guide: Windows 11 migration using GPOs/registry keys

If you are deploying updates using Windows Update, there is still a possibillity to control their delivery using different GPOs. And if you set/change proper policy, Windows 11 will be deployed on your devices if they are eligible to upgrade.

How to specify target Feature Update version in Windows 10

A new TargetReleaseVersion policy available in Windows 10 version 1803 and higher allows you to specify which feature update version of Windows 10/11 you would like your computer to move to and/or stay on until the version reaches the end of service or you reconfigure this policy.

If you don’t update this policy before the device reaches end of service, the device will automatically be updated once it is 60 days past end of service for its version.

If you specify a TargetReleaseVersion the same as the current version, Windows 10 will stay on this version until it reaches the end of service. This can also be useful to block an automatic upgrade to Windows 11.

If you specify a TargetReleaseVersion higher than the current version, Windows 10/11 will directly update only to the specified version, even if a higher version is available.

Specify target Feature Update version in Local Group Policy Editor

Open the Local Group Policy Editor.
Navigate to the location below in the left pane of Local Group Policy Editor (see screenshot below);
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update.

In the right pane of Windows Update for Business in Local Group Policy Editor, double click/tap on the Select the target Feature Update version policy to edit it (see screenshot above).
Select (dot) Enabled (see screenshot below).
Perform the following steps under Options:
Type which Windows product version would you like to receive feature updates for? E.g, Windows 10: Windows 11.
Type the version (e.g, “21H1”) you want to specify in the Target Version for Feature Updates: 24H2.
Click/tap on OK.

If you want to set the same options via registry keys, use the following key and values:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
“ProductVersion”=”Windows 11”
“TargetReleaseVersion”=dword:00000001
“TargetReleaseVersionInfo”=”24H2”

You can see a list of Windows 10 versions to use as a value in the Windows 11 release information table.

And you're done!

That’s it, your Windows 11 migration using GPOs and registry keys is complete. With these steps in place, your devices should upgrade smoothly and stay on track. Keep testing, keep things backed up and you’ll be good to go.

You may also like:
→How to migrate to Windows 11 via Windows Update in Settings
→Windows 11 migration via SCCM
→Windows 11 migration made easy with XOAP

The post Step-by-step: Windows 11 migration using GPOs and registry keys appeared first on XOAP.

How to migrate to Windows 11 via Windows Update in Settings

Perica — Tue, 15 Apr 2025 09:20:50 +0000

Upgrading to Windows 11 is easier than you might think. If your device is eligible, you can start the process right from the Windows Update section in Settings. Follow this quick guide to check availability and begin your upgrade with just a few clicks.

Windows 11 migration via Windows Update in Settings

If upgrading from Windows 10 to Windows 11, Microsoft recommends waiting until Windows Update notifies that the upgrade is ready for the device. To check if Windows 11 is ready for a device using Windows Update, follow these steps:

Right-click on the Start menu and then select Settings > Update & Security > Windows Update.
In the Windows Update window that opens, select the Check for updates button.
Note: If there are updates available for the current version of Windows, the Windows 11 upgrade might not be made available until those updates are installed. Install any updates for the current version of Windows, restart the device, and then try checking for the Windows 11 upgrade again.
If Windows 11 is ready to be installed on the device, a message is displayed in the Windows Update window showing that Windows 11 is ready. Select the Download and Install button to start the Windows 11 upgrade.
In the Software License Terms window that opens, select the Accept and install button.
The Windows Update window refreshes, and the Status shows the progress of the Windows 11 upgrade downloading and installing.
Once the installation portion of the Windows 11 upgrade is done in Windows 10:
The Windows Update window refreshes and changes to Restart required. The Status: also updates to Pending restart.
A Windows Update notification is displayed in the notification area with the message Restart to install the newest Windows feature update.
To continue the Windows 11 upgrade, restart the device by selecting the Restart now button in the Windows Update window or Restart now in the Windows Update notification.
The device restarts and the Windows 11 upgrade process continues. The device restarts automatically a few more times to finish installing Windows 11.
The Windows sign-on screen is displayed once the Windows 11 upgrade is done. Sign in to the device to complete the upgrade.

If Windows 11 isn’t shown in Windows Update

If a message isn’t displayed in the Windows Update window that Windows 11 is ready, it could be for one of the following reasons:

The device meets the hardware requirements for Windows 11, but the Windows 11 upgrade isn’t ready to install yet.
The device meets the hardware requirements for Windows 11, but there might be a known compatibility issue with the device and Windows 11. The Windows 11 upgrade will eventually be offered if the compatibility issue is resolved. For more information, see the notification “What needs your attention” displayed during a Windows upgrade.
The device doesn’t meet the hardware requirements for Windows 11.

That's it!

And that’s all it takes to migrate to Windows 11 via Windows Update! The process is simple, and you’ll be up and running with the new OS in no time.

You may also like:
→Windows 11 migration via SCCM
→Step-by-step: Windows 11 migration using GPOs and registry keys
→Windows 11 migration made easy with XOAP

The post How to migrate to Windows 11 via Windows Update in Settings appeared first on XOAP.

Tutorial: Windows 11 migration via SCCM

Perica — Mon, 14 Apr 2025 11:07:51 +0000

Thinking about moving your organization to Windows 11? With SCCM (System Center Configuration Manager), there are two ways to get it done: Windows servicing and Task sequence. In this tutorial, we’ll walk you through both methods so you can choose the best fit for your environment.

Windows servicing

Configuration Manager requires only minimal configuration before deploying feature updates to computers. If you’ve previously deployed feature updates, most prerequisites are likely already in place. However, for new SCCM setups, some initial configuration may be necessary.

Prerequisites for the Windows 11 23H2 upgrade using SCCM

Configure Software Update Point by enabling the upgrades for Windows 10 and Windows 11.
Ensure the service connection point is online before you sync the updates.
Enable dynamic updates for feature updates in Configuration Manager Client Settings.
The product category “Windows 11” must be enabled under Software Update Point > Products.

First, you need to download the Windows 11 23H2 enablement package update using SCCM.It is recommended first to downloadthe enablement package, then distributing the content to distribution points, and finally deploying it.

Steps to get Windows 11, Version 23H2 update in SCCM

In the SCCM console, go to Software Library > Windows Servicing > All Windows Feature Updates. Then, in the search box, type “23H2” and click Search. This will filter the updates and display only 23H2 updates. Right-click on Windows 11, version 23H2 x64 2023-10B and select Download.

On the Deployment Package window, you must specify the deployment package for Windows 11 23H2 upgrade files. This deployment package that you create will contain the software update files that will be deployed to the clients.

Select “Create a new deployment package” and specify the package name as “Windows 11 23H2 Deployment Package.” Specify the package source, which is a shared folder where you want to download the updates. Enabling the binary differential replication is optional. Click Next.

On the Distribution Points page, click on the Add button and choose the distribution point servers to which you would like to distribute the Windows 11 23H2 upgrade files. Click Next.

Then, on the Distribution Settings page, configure the general distribution settings for the deployment package. Click Next.

Select an option to specify from where you want to download the updates. In the example below, we have selected the option Download software updates from the internet. Click Next.

On the Summary window, review the settings for the deployment package and click Next. Now, on the Progress tab, we see the Windows 11 23H2 Enablement Package updates being downloaded.

Steps to deploy Windows 11 23H2 feature update using SCCM

In the ConfigMgr console, navigate to Software Library\Overview\Windows Servicing\All Windows Feature Updates. Right-click Windows 11, version 23H2 x64 2023-10B update, and select Deploy.

On the General page, enter the details for the Windows 11 23H2 feature update deployment.

- Deployment name: Enter the deployment name, for example, Windows 11 23H2 upgrade.
- Description: Add a brief description about the deployment.
- Software Update Group: This is created automatically and is visible under Software Update Groups in the Configuration Manager console.
- Collection: Click Browse and select a device collection consisting of a few pilot devices selected for testing the Windows 11 2023 upgrade. After that, click Next to continue.

Accept the license terms for the Windows 11 23H2 update. Click Next.

On the Deployment Settings page, specify the type of deployment. Choose whether you want to make the Windows 11 23H2 upgrade available for users in the Software Center or deploy it as required.

The Scheduling page lets you configure schedule details for the deployment. If you want to make the Windows 11 23H2 upgrade available at a specific date and time, select Specific Time and define it. Define the deadline for installation to ensure the upgrade happens within the defined period. Click next to continue.

Specify the following user experience settings for the 23H2 update deployment:

- User notifications: Display in Software Center and show all notifications
- Commit changes at the deadline or during a maintenance window (requires restarts): Yes
- If any update in this deployment requires a system restart, run updates deployment evaluation cycle after restart: No.

Click Next.

On the Download Settings tab, specify the download settings for the current deployment:

- Client Computers can use distribution points from neighbor boundary: Yes
- Download and install software updates from the fallback content source location: Yes

Click Next to continue.

Review the deployment settings of Windows 11 23H2 on the Summary page and click Next. On the completion window, click Close.

Test the upgrade installation

After you have deployed the Windows 11 23H2 enablement package update using Windows Servicing, it’s time to test the upgrade installation on Windows computers. The end-user experience is similar to other feature upgrades.

On the client’s computer, launch the Software Center. Once the Software Center has been opened, select Windows 11, version 23H2 x64 2023-10B update by clicking the Updates tab. Click on the Install button.

Confirm that you want to upgrade this computer’s operating system. Note that this is an in-place upgrade to version 23H2, and the setup automatically migrates your apps, data, and settings. Click on the Install button to begin the Windows 11 23H2 upgrade.

Restart, and now the computer reboots. After it has rebooted, the operating system version is Windows 11 23H2.

Task sequence

To do an in-place upgrade of Windows 10 to Windows 11 via SCCM Task sequence, you must import the Windows 11 upgrade package into SCCM.

Steps to add or import Windows 11 upgrade package into SCCM

Launch the SCCM console.
Navigate to Software Library > Operating Systems > Operating System Upgrade Packages.
Right-click Operating System Upgrade Packages and click Add Operating System Upgrade Package.

On the Data Source page, click Browse and specify the folder path that contains the Windows 11 setup files. This is the folder that contains the extracted Windows 11 ISO file.

Select the option: By checking this box, you agree that when applying this operating system to the device, the applicable Windows license was purchased through volume licensing. Or that you are authorized to bind your company and agree to the Microsoft license terms on its behalf.

Check the box – extract a specific image index from install.wim file of the selected upgrade package. Select the image index appropriately and click Next.

On the General window, specify the upgrade package name as Windows 11 upgrade. You may add more details in the comment box and click Next. Click Next on the Summary window.
On the Completion window, click Close. We have successfully imported the Windows 11 upgrade package in SCCM.

Create task sequence

To create a Windows 11 In-place upgrade SCCM Task Sequence, do the following:

• Launch the Configuration Manager console.
• Go to Software Library\Overview\Operating Systems\Task Sequences.
• Right-click Task Sequences and select Create Task Sequence.

On the Create a new task sequence page, select Upgrade an operating system from an upgrade package. Click Next.

On the Task Sequence Information page, specify the task sequence name, such as in-place upgrade of Windows 10 to Windows 11 or something meaningful. Add an optional description. Click Next.

On the Upgrade Windows operating system page, select an upgrade package, click Browse and select Windows 11 upgrade package. The edition index is automatically populated. Click Next.

On the next page, select Do not install any software updates. Click Next. If you have any applications that you need to install along with this upgrade, you can define them on the Install Applications page. Otherwise, click Next.

Review the settings on the Summary page and click Next.

Finally, on the Completion page, click Close. This completes the steps for creating a Windows 11 in-place upgrade task sequence.

Deploy task sequence

After the task sequence is created, you need to distribute the content to your distribution points and deploy the task sequence to the desired SCCM Collection:

In the ConfigMgr console, go to Software Library\Overview\Operating Systems\Task Sequences.
Right-click Windows 11 upgrade task sequence and click Distribute Content to distribute content to distribution points.
Right-click Windows 11 upgrade task sequence and click Deploy to deploy the task sequence to the desired SCCM collection.

Once the task sequence is deployed and becomes available on the client, it will pop up in the client Software Center under Operating Systems.

The user will be asked to confirm if they want to upgrade the operating system on this computer. Select Install.

The task sequence progresses now and the Windows 11 upgrade files will be downloaded to the computer. The task sequence displays the Windows 11 upgrade progress percentage.

When the in-place task sequence is running, you can monitor the deployment by reviewing the smsts.log file. During the Windows 11 upgrade, the smsts.log file is located in C:\Windows\CCM\Logs\SMSTSLog folder on the client machine. The task sequence restarts the computer to complete the upgrade.

Of course, there is a possibility to adjust the task sequence to do a couple of extra steps.

For example, in the task sequence below.

Before upgrading to Windows 11:

Extra checks are performed before upgrade
InstallLanguage registry key is corrected if needed
BitLocker is suspended

After Windows 11 upgrade:

CU is installed (needed if you have an extra language pack injected in your wim file)
Inbox/Store Apps are installed with the proper language
Unwanted Inbox/Store Apps are removed
Outlook New is removed and blocked
IPU Successfull flag is written to registry

Need help?

Whether you go with Windows servicing for a simpler in-place upgrade or a Task sequence for more control and customization, SCCM makes it easy either way.

Questions? We’re just a message away!

You may also like:
→How to migrate to Windows 11 via Windows Update in Settings
→Step-by-step: Windows 11 migration using GPOs and registry keys
→Windows 11 migration made easy with XOAP

The post Tutorial: Windows 11 migration via SCCM 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.

Offline Domain Join using XOAP and Azure Blob storage

Perica — Thu, 29 Feb 2024 12:27:02 +0000

Our module allows you to Domain Join a device that doesn’t have access to the Domain Controller (through the company network or via VPN). It’s an alternative to using Azure Hybrid Join.

While Azure Hybrid Join adds a device to Azure AD (Entra) and local AD, this option allows joining a device to local AD only. Meanwhile, Hybrid Join is limited regarding naming convention and only allows the defining of the prefix.

With this solution, it’s possible to define a prefix and to use a serial number of computers for the computer name.

Who is this for?

You can benefit from using this module whether you’re a XOAP user or not. Here’s how:

a) If you’re a XOAP user, simply set up Windows clients for use of Offline Domain Join via Azure Blob Storage using this module and XOAP console.

b) If you’re not a XOAP user, use this module in your own DSC environment, or use PowerShell scripts inside this module to create their own automation alternative for Offline Domain Join.

Want to experience everything XOAP has to offer? Create your free account here!

What does this module do?

To explain further, this module will rename the computer using the serial number and defined prefix. Afterwards, it’ll make an Offline Domain Join of the device via Azure Blob storage; if wanted.

The computer creates a request and posts it on a defined location on Azure Blob. Then, the Domain Controller will take that request and post a response on Azure Blob. This response file is then read by a computer – and the computer makes Offline Domain Join. Furthermore, the certificate will be imported from Azure Blob.

What do I need to know before I start?

To understand how to use it, knowledge of PowerShell, Active Directory and Azure Storage is needed along with these 3 components:

Server-side: modify Domain Controller to allow for Offline Domain Join
Azure Blob Storage: storage to host files needed for Offline Domain Join
XOAPOfflineDomainJoinViaBlobDSC: to set up Windows client to create request and fetch the answer for Offline Domain Join

List of prerequisites:

AzureAZ PowerShell Module (if not installed ‘Az.Accounts’ and ‘Az.Storage’ submodules are going to be installed while running this DSC module);
ComputerManagementDsc in version 8.5.0;
Azure Blob storage;
Local Active Directory;
PowerShell script that reads the request from Azure Blob Storage and sets response file and machine certificate to Azure Blob storage (example below).

				
					$WarningPreference = "SilentlyContinue" 
$Domain = "test.local.com" 
$OU = "OU=Notebooks,OU=Koeln,DC=test,DC=local,DC=com" 
 
$Tenant_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$Subscription_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$ResUsername = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$SAccountname = 'xoapdeployments' 
$ContainerName = "adjoin" 
 
$FExt = ".blb" 
$BlobFolder ="adblob" 
$RequestFolder = "request" 
$JoinName ="" 
 
Set-Location C:\Scripts 
 
#SecPass.exe generetes password for Azure access 
$SecPassStr = cmd /c .\SecPass.exe $args 2`>`&1    
$cred = New-Object System.Management.Automation.Pscredential($ResUsername, (ConvertTo-SecureString -String $SecPassStr)) 
 
$ARMA = Add-AzureRmAccount -ServicePrincipal -Credential $cred -TenantId $Tenant_ID -Subscription $Subscription_ID 
$ARMA 
 
$storageContainer = Get-AzureRmStorageAccount | where {$_.StorageAccountName -eq $SAccountname} | Get-AzureStorageContainer 
 
$ComputerFiles = $storageContainer | Get-AzureStorageBlob | where {$_.Name.Contains($RequestFolder) -and !($_.Name.Contains("flag.flg"))}  | Select-Object "Name" ,"LastModified" 
 
# $ComputerFiles 
 
if($ComputerFiles) { 
    foreach($Computerfile in $ComputerFiles) { 
        $JoinName = $ComputerFile.Name.Replace("/","\") 
        # $JoinName 
        $storageContainer | Remove-AzureStorageBlob -Container $ContainerName -Blob ($JoinName) -Force 
        $JoinName = $JoinName.SubString(8) 
        $ADblobfile = $Computername + ".blob" -f $computer 
        $BlobName = ".\" + $JoinName + $FExt 
        # $BlobName 
        $run = "djoin.exe /provision /domain {0} /MachineOU {1} /machine {2} /savefile {3} /reuse /rootcacerts" -f $Domain, $OU, $JoinName, $BlobName 
        # $run 
        Invoke-Expression $run 
        $StorageBlob = $BlobFolder + "\" + $JoinName + $FExt 
        # $Storage 
        $storageContainer | Set-AzureStorageBlobContent –File $BlobName -Blob $StorageBlob -Properties @{"ContentType" = "text/plain"} 
        $storageContainer | Remove-AzureStorageBlob -Blob ($RequestFolder + "\" + $JoinName) -Force 
        Remove-Item -Path $BlobName 
    } 
} 
Remove-AzureRmAccount -Username $ResUsername

Available resources and syntax

				
					OfflineDomainJoinViaBlob [String] #ResourceName 
{ 
    [DependsOn = [String[]]] 
    [PsDscRunAsCredential = [PSCredential]] 
    Tenant_ID = [String] 
    Subscription_ID = [String] 
    Username = [String] 
    Password = [String] 
    SAccountname = [String] 
    ContainerName = [String] 
    RequestFolder = [String] 
    BlobFolder = [String] 
    CertFolder = [String] 
    [TimeoutInMinutes = [Int32]] 
    [RenameComputerUsingSerial = [Boolean]] 
    [ComputerNamePrefix = [String]] 
    [RebootAfterDomainJoin = [Boolean]] 
}

Saccountname = Storage Account Name

Ready to get started? Download this module below!

Download Offline Domain Join

The post Offline Domain Join using XOAP and Azure Blob storage appeared first on XOAP.

Perica, Author at XOAP

Windows OS (re)deployment with XOAP and OSDCloud

Table of contents

Challenges of Windows OS deployment

Three deployment scenarios

Scenario 1: OS downloaded from the internet

Scenario 2: WinPE boot with OS downloaded from the internet

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

The deployment process on the target device

Ongoing management after deployment

Getting started

Explore XOAP

How to: Bare metal OS deployment with XOAP

Table of contents

How XOAP approaches bare metal deployment

Deployment methods

Method 1: PXE boot (network deployment)

Infrastructure requirements

Setup process

Device-side experience

Method 2: USB stick (standalone deployment)

Infrastructure requirements

Setup process

Device-side experience

The OSDCloud XOAP package stack

Ready to see it in action?

Explore XOAP

XOAPChangeBIOSsettingDSC: Master the BIOS management

Key features

Important usage notes

Why DSC for BIOS?

Installation and usage

Get the XOAPChangeBIOSsettingDSC module

Download the free module

Migrate to Windows 11 with PSADT

Use PSADT to migrate from Windows 10 to Windows 11

You're good to go!

Windows 11 migration made easy with XOAP

Upgrade to Windows 11 with XOAP: Simple steps

All set!

Migrate to Windows 11 with XOAP

Step-by-step: Windows 11 migration using GPOs and registry keys

Table of contents

Guide: Windows 11 migration using GPOs/registry keys

How to specify target Feature Update version in Windows 10

Specify target Feature Update version in Local Group Policy Editor

And you're done!

How to migrate to Windows 11 via Windows Update in Settings

Table of contents

Windows 11 migration via Windows Update in Settings

If Windows 11 isn’t shown in Windows Update

That's it!

Tutorial: Windows 11 migration via SCCM

Table of contents

Windows servicing

Prerequisites for the Windows 11 23H2 upgrade using SCCM

Steps to get Windows 11, Version 23H2 update in SCCM

Steps to deploy Windows 11 23H2 feature update using SCCM

Test the upgrade installation

Task sequence

Steps to add or import Windows 11 upgrade package into SCCM

Create task sequence

Deploy task sequence

Need help?

Secure your Windows environment with XOAP Windows LAPS DSC

Table of contents

What is XOAP Windows LAPS DSC?

Key features

Why use XOAP Windows LAPS DSC?

Enhanced security

Operational efficiency

Compliance and auditing

Simplified management

Getting started with XOAP Windows LAPS DSC

Prerequisites

Installation

Configuration

⭢ AzureADWindowsLAPSSettings

⭢ LocalADWindowsLAPSSettings

⭢ WindowsLAPSEmulationMode