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
Treiber	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
OSAktivierung	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.

Anmerkung: 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.

Erste Schritte

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 eine Demo buchen to walk through your specific deployment requirements with the team.

Explore XOAP

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

How to create PSADT v4 packages with the XOAP Package Wizard

Mario — Wed, 20 May 2026 12:33:10 +0000

PSADT packages are only as consistent as the person who built them. One engineer structures the install phase one way, another handles process closing differently, a third skips the repair phase entirely. Each package works until it doesn’t and debugging it means deciphering someone else’s conventions first.

The lack of a standard compounds across every package in your library.

XOAP Package Wizard for PSADT v4 fixes that at the source. Every package built with it follows the same structure, uses the same phase layout and produces the same output format, regardless of who’s doing the packaging. Installer in, deployment-ready package out in under 10 minutes, without coding.

This tutorial walks through the full process, from dropping in your installer to exporting a zip you can hand straight to Intune, SCCM or any PowerShell-capable tool.

What is XOAP Package Wizard?

The Package Wizard is a free, standalone tool from XOAP that generates production-ready PowerShell App Deployment Toolkit (PSADT) v4 packages through a guided, no-code interface.

It handles the Invoke-AppDeployToolkit.ps1 structure, the $adtSession block, install and uninstall phases, and every parameter declaration, without you typing a single line of PowerShell.

The exported package is a standard ZIP file: PSADT toolkit, your installer files and the generated script, all in one folder. It works with any endpoint management tool like Intune, SCCM or anything else you deploy with, with no proprietary wrappers.

You can download the free Wizard edition hier without creating an account or providing credit card information.

How to create a package

XOAP Package Wizard handles packaging through seven guided steps.

To begin, open the Wizard and click Start New Package. You’ll land on the package setup screen with a drag-and-drop zone waiting for your installer.

For this walkthrough, we’ll package 7-Zip.

Step 1: Drop in your installer

Add or drag your installer file onto the drop zone. The Wizard accepts MSI files, EXE installers and any other format your deployment requires.

For MSI files, the Wizard reads the embedded metadata (product name, version, architecture and more) and offers to pre-fill the package details automatically. That’s around 12 fields you won’t have to type in manually.

Step 2: Configuration

Die Konfiguration screen maps directly to the $adtSession block of your generated Invoke-AppDeployToolkit.ps1. Most fields are already populated from the MSI metadata.

A few things worth setting here:

- RequireAdmin — set this to true for anything that installs to Program Files. It requires elevation and prevents silent failures on standard user accounts.
- ProcessesToClose — list any processes that should be closed before installation begins. For 7-Zip, that’s 7zFM (the 7-Zip File Manager). If a user has it open when the package runs, PSADT will close it cleanly before proceeding.

Everything you configure here ends up in the session block of the generated script, exactly where PSADT expects it.

Step 3: Parameters

The default PSADT v4 parameters like DeploymentType, DeployMode and the rest are always present and don’t need to be added manually. This step is for custom parameters specific to your package.

If you need an -Environment parameter with a fixed set of allowed values (e.g. Test, Staging, Production), you define it here.

For a straightforward application deployment like 7-Zip, you can skip ahead.

Step 4: Build your install phase

This is the core of the Wizard. The Installieren Sie screen gives you three editors: pre-install, install und post-install. These cover everything that runs before, during and after the main installation.

Autocomplete for every PSADT v4 cmdlet

Start typing a PSADT cmdlet name and the editor provides autocomplete across the full v4 toolkit. Accept a suggestion and it drops in a code snippet with placeholder values for each required parameter. Press space and a dash to trigger inline parameter hints (types, descriptions and valid values), all without leaving the editor.

Function Builder

If you’d rather not memorize cmdlet names at all, open the Function Builder. It’s a visual catalog of every PSADT v4 function, organised by category: Process, MSI, Files, Registry, UI and more. Pick a function, fill in the form, see the generated code update in real time, then click Insert to drop it directly into your script.

In the free version of the Wizard, the Process and MSI categories are fully enabled. Other categories are visible with lock indicators so you can see what’s available in the full version.

For the 7-Zip install itself, the MSI category handles Execute-MSI cleanly. Select it in the Function Builder, set the action to Install and point it at your installer file.

Steps 5 & 6: Uninstall and repair phases

Die Uninstall phase is handled the same way as the previous Install phase. Same three editors (pre-uninstall, uninstall, post-uninstall), same autocomplete, same Function Builder.

Step 6 is the Repair phase. Many packages leave this empty, which is fine, as PSADT simply runs an empty function. If your application supports repair operations, you can define them here using the same tools.

Step 7: Preview and test run

Click Next to see the fully generated Invoke-AppDeployToolkit.ps1. The exact script that will be included in your export.

From here you can run a live test before exporting:

1. Select a deployment type and mode
2. Enable Run as Admin
3. Click Test Run

The script executes on the local machine. Output streams into the terminal below the editor in real time. There’s a 120-second timeout for hung processes. The Wizard will do exactly what it says: test this on a dev box, not a production machine.

Step 8: Export

Back on the dashboard, click Export on the package card. The Wizard produces a standard ZIP archive containing:

• The generated Invoke-AppDeployToolkit.ps1
• The full PSADT v4 toolkit
• Your installer file(s)

This is what you hand to Intune, SCCM or whichever tool you use.

The ZIP contains nothing proprietary. If you switch deployment platforms tomorrow, the package still works.

Two features that save hours

Installed Apps

Before writing an uninstall phase from scratch, open Installed Apps. The Wizard scans the machine’s registry and surfaces every installed application with its uninstall command. Select the app and the Wizard generates the correct removal command. Paste it straight into your uninstall phase.

Import Local

Already have a library of existing PSADT packages? Import Local pulls any v3 or v4 package into your workspace. For v3 packages, it automatically translates the syntax to v4. Function names, parameter structures and session variables are updated to match the new framework. The result lands in your Packages Workspace, ready to edit or export.

Get the free Wizard

The XOAP Package Wizard for PSADT v4 is free to download. Fill in the form below and you’ll receive the download link via email. You can also check the full feature list and available plans hier.

Enjoy clean, standard PSADT v4 packages that work wherever you deploy.

Request
download link

Use a business email address to make sure you receive the XOAP Package Wizard in your inbox.

The post How to create PSADT v4 packages with the XOAP Package Wizard 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.

Explore XOAP

The post How to: Bare metal OS deployment with XOAP appeared first on XOAP.

The reality of application delivery in 2026

Dora — Fri, 08 May 2026 13:45:37 +0000

All events

Automation talks

The reality of application delivery in 2026

Ep. 07 with Jens Miltenberger (Ceterion)

About the episode

Cloud trifft auf Hybrid | Automatisierungsgespräche, hosted by Mario Istuk, is a podcast by XOAP, exploring IT infrastructure and automation topics.

Tune in for deep dives with expert guests and short updates on current IT topics.

Watch on YouTube & Apple Podcasts
Listen on Spotify

Have a question, suggestion or comment? Let us know at hello@xoap.io.

Application delivery. One of the most underestimated disciplines in IT.

In this episode, our guest is Jens Miltenberger, Consulting Services Director at Ceterion. We cover the evolution of packaging formats, the tool landscape from SCCM to Intune, hybrid environments and why application delivery is ultimately a process and organizational challenge, not a tooling one.

Bitte beachten: This episode is available in German only. For an English translation, watch it on YouTube with the subtitles on.

Watch now!
Available on YouTube, Apple Podcasts and Spotify.

Meet our host

XOAP

Mario Istuk

Mario Istuk, a co-founder of XOAP, oversees sales, marketing and corporate partnerships. With over 15 years of experience in IT infrastructure and automation, he helps organizations optimize complex hybrid IT environments. Mario hosts XOAP’s Gespräche über Automatisierung podcast, leads online events and speaks at conferences across Europe.

Kommende und vergangene Veranstaltungen

The reality of application delivery in 2026

Ep. 07 with Jens Miltenberger (Ceterion) | Watch now

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

Podcast episode | Hosted by DOAG

Bluecue event: Automated security compliance for IT infrastructure

April 1, 2026 | Online event | Hosted by blucue

Bluecue event: Automated KHZG security compliance for hospital IT

March 25, 2026 | Online event | Hosted by bluecue

BLINK 2025 | How XOAP simplifies hybrid IT automation

November 28, 2025 | Bielefeld, DE | Hosted by blucue

The AWS European Sovereign Cloud

Ep. 06 with Tobias Tomandl (Ingram Micro) | Watch now

The post The reality of application delivery in 2026 appeared first on XOAP.

AWS Systems Manager vs XOAP: Guide for MSPs

Stella — Mon, 13 Apr 2026 11:50:46 +0000

AWS Systems Manager and XOAP both help organizations manage infrastructure at scale. On the surface they overlap, but they were built for different situations. Knowing which one fits depends less on a feature comparison and more on understanding what each tool was originally designed to do.

What AWS Systems Manager does well

Built into the AWS platform, Systems Manager provides patch management, remote command execution, session management, secrets storage via Parameter Store and configuration enforcement through State Manager. Within a single AWS account running primarily EC2-based workloads, it is a natural fit, and many of its core features are included as part of standard AWS usage.

The product works best when the environment is largely AWS-native. The further an organization moves from that scenario, the more its limitations become relevant.

Where the two products differ:

Managing multiple clients

SSM is built around a single AWS organization. Keeping multiple clients properly separated typically means setting up separate AWS accounts with their own IAM policies. That works, but it adds setup time and ongoing maintenance overhead for every new client added.

Multi-tenancy is central to how XOAP is built, not something that needs to be configured around. Each client gets its own isolated space within the platform, with access controls and policies available by default. MSPs handling many clients will find this removes a significant amount of repetitive infrastructure work.

Hybrid and mixed environments

Through its hybrid activation feature, SSM can manage on-premises and non-AWS machines alongside cloud workloads. Its primary design target is still AWS, though, so managing infrastructure outside EC2 tends to require extra configuration steps that cloud-native workloads would not need.

XOAP treats cloud and on-premises infrastructure as equal from the outset. A server in a data center is handled the same way as a cloud instance, through the same interface and automation logic. Teams with a significant portion of infrastructure outside AWS will find day-to-day management considerably more consistent as a result.

Image management

AWS provides EC2 Image Builder for creating and maintaining machine images within AWS, with output in AMI format for EC2 workloads. XOAP’s Image Management is designed to work across both cloud and on-premises environments. Organizations that require consistent images across a mixed estate, rather than only within AWS, can benefit from the broader scope.

Cost

Many SSM features come at no additional cost within AWS. Getting it to work well across multiple clients or in hybrid environments, though, often requires building custom tooling to fill the gaps. That engineering time is a real cost, even if the software licence is not.

XOAP runs on a subscription model. The premise is that in multi-client or complex environments, the reduction in engineering overhead justifies the cost relative to building equivalent capabilities on top of native AWS tooling.

A real-world example

Consider an MSP onboarding a new client. The client has 40 Windows machines split between on-premises servers and AWS instances, and needs to prove patching compliance ahead of an upcoming audit.

With SSM, the team would need to configure hybrid activations for the on-premises machines, set up account-level separation to keep this client isolated from others and pull together a compliance report from multiple sources. None of this is impossible, but each step requires deliberate work outside the core tool.

The intended XOAP process is to create a new tenant, deploy the agent across all machines regardless of where they sit, apply the relevant policies and export a compliance report, with tenant isolation handled at the platform level throughout.
Both routes reach the same result. The difference is in how much surrounding work is needed to get there.

Which one?

SSM suits organizations running primarily on AWS, with teams comfortable in the AWS console and no significant need for multi-client isolation or cross-platform management.

XOAP is better positioned for MSPs and infrastructure teams managing multiple clients with strict separation requirements, working across a mix of cloud and on-premises environments, or wanting to reduce the manual effort involved in keeping automation consistent at scale.

Different tools, different contexts

AWS Systems Manager (SSM) and XOAP are designed for different priorities and operational realities, rather than serving the same need. XOAP’s focus is on supporting how organizations actually operate across diverse environments, so the right approach is one that aligns with real workflows and infrastructure requirements.

This distinction is worth considering carefully when evaluating either platform, particularly in multi-client or hybrid environments.

To see how XOAP handles these scenarios in practice, book a demo.

Explore XOAP

Disclaimer:
This article is provided for informational and comparative purposes only. All product names, trademarks and registered trademarks mentioned are the property of their respective owners. The information presented reflects publicly available documentation and general product capabilities at the time of writing.

This comparison does not constitute legal, financial or procurement advice. Readers are encouraged to independently evaluate each platform based on official documentation and vendor guidance. Any references to pricing models reflect publicly available pricing information and are not legal or financial interpretations.

The analysis is intended to provide an objective overview of architectural differences and intended use cases, not to assert superiority, deficiency or competitive claims.

The post AWS Systems Manager vs XOAP: Guide for MSPs appeared first on XOAP.

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

Dora — Tue, 07 Apr 2026 09:59:35 +0000

All events

PODCAST

DOAG Voices:
Cloud transformation reality check with XOAP's Christian Reineke

Hosted by: DOAG | Language: German

Automation, costs & cultural change

On paper, the value of cloud is undeniable. In reality, many organizations are discovering that cloud transformation is far more complex, costly and organizationally demanding than expected.

In a DOAG Voices episode, hosted by David Koenig, XOAP’s CEO, Christian Reineke, shares practical insights from years of working with enterprises navigating this journey.

The biggest challenges in cloud transformation are structural. The disconnect between traditional IT und DevOps teams cannot be fixed by one tool alone. Automation tools are often treated as the solution, but they often introduce complexity.

What’s missing is a unifying layer, a way to standardize and operationalize automation across teams and skill levels. This is exactly where a platform approach becomes critical.

Listen to the episode on your podcast platform of choice

Kommende und vergangene Veranstaltungen

The reality of application delivery in 2026

Ep. 07 with Jens Miltenberger (Ceterion) | Watch now

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

Podcast episode | Hosted by DOAG

Bluecue event: Automated security compliance for IT infrastructure

April 1, 2026 | Online event | Hosted by blucue

Bluecue event: Automated KHZG security compliance for hospital IT

March 25, 2026 | Online event | Hosted by bluecue

BLINK 2025 | How XOAP simplifies hybrid IT automation

November 28, 2025 | Bielefeld, DE | Hosted by blucue

The AWS European Sovereign Cloud

Ep. 06 with Tobias Tomandl (Ingram Micro) | Watch now

The post DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP) appeared first on XOAP.

From legacy to scalable: Rethinking AVD management for MSPs

Stella — Wed, 01 Apr 2026 08:44:54 +0000

Modern IT service providers are in the middle of a major transition: customers are rapidly moving workloads to the cloud, especially to Azure Virtual Desktop (AVD). But while infrastructure has evolved, management tooling often hasn’t. That gap is where inefficiencies, risk and operational complexity start to grow.

The truth about “good enough” tooling

For years, tools like Microsoft SCCM, Microsoft Deployment Toolkit, and Baramundi Management Suite formed the backbone of endpoint and system management. They were reliable. Familiar. Proven.

But they were also built for a different era:

On-premises infrastructure
Static environments
Single-tenant operations

Fast forward to today’s reality:

Multi-tenant Azure environments
Elastic infrastructure
Rapid deployment cycles
Distributed endpoints

Legacy tools weren’t designed for this.

Where legacy tools break in AVD environments

When MSPs attempt to extend traditional tooling into AVD, several friction points emerge:

1. Image management becomes slow and fragile

Golden image creation is still largely manual, time-consuming, often taking days, and difficult to standardize across tenants. As a result, environments are prone to drift, inconsistencies, and frequent rebuilds.

2. Application packaging lacks consistency

Even with frameworks like PSAppDeployToolkit, application packaging often varies between teams, deployment methods differ across environments, and reusability remains limited, leading to duplicated effort and higher failure rates.

3. No unified visibility across tenants

MSPs frequently operate across multiple dashboards, manage separate tenant logins, and rely on inconsistent reporting tools to monitor their environments. This fragmented approach results in the absence of a single source of truth, slower troubleshooting processes, and reduced confidence in consistently meeting SLAs.

4. Tool sprawl increases operational cost

Instead of working from a single platform, teams often rely on a combination of SCCM for device management, custom scripts for automation, Azure-native tools for cloud operations, and various third-party solutions for monitoring. This fragmented toolchain increases training overhead, creates specialist silos, and raises the risk of misconfiguration across environments.

What modern AVD management should look like

To operate efficiently at scale, MSPs need a cloud-first, multi-tenant-aware approach. This means:

Automated image lifecycle management

Version-controlled images
Repeatable builds
Rapid updates across environments

Standardized application delivery

One packaging method
Cross-platform compatibility
Centralized deployment logic

Centralized configuration and visibility

Unified dashboards
Cross-tenant insights
Real-time compliance tracking

Platform consolidation

Fewer tools
Less context switching
Lower operational overhead

How XOAP enables a unified approach

This is exactly the gap XOAP is designed to address, without forcing MSPs to abandon what already works. Instead, it connects and standardizes across environments.

1. Image Management: From manual to automated

XOAP enables:

Automated image creation for AVD, Azure, VMware, and more
Standardized, versioned images
Continuous lifecycle management

No more rebuilding images from scratch or tracking undocumented changes.

2. Application Management: Built on what teams already trust

XOAP leverages PSAppDeployToolkit as a foundation and extends it:

Centralized application catalog
Plattformübergreifender Einsatz
Consistent packaging standards

3. Configuration Management: One view across all tenants

XOAP provides:

Unified policy management
Software inventory across environments
Compliance monitoring

No more logging into separate tenants to piece together insights.

The real opportunity for MSPs

The biggest advantage is the service differentiation. XOAP introduces a layering model:

XOAP handles automation and orchestration
MSPs build services on top

This allows you to:

Define your own service tiers
Package AVD management as a premium offering
Deliver consistent, scalable outcomes

Instead of selling tools, you’re delivering managed experience.

Practical example: Before vs after

Before (legacy stack):

SCCM + scripts + Azure tools
Manual image pipelines
Fragmented visibility
High operational overhead

After (unified with XOAP):

Single platform for lifecycle management
Automated image + application workflows
Zentralisierte Überwachung
Scalable across tenants

Abschließende Überlegungen

Azure Virtual Desktop is not the problem, outdated management approaches are. If your team is still stitching together Microsoft SCCM, Microsoft Deployment Toolkit, and custom scripts to manage modern cloud environments, you’re carrying unnecessary complexity.

Start exploring a better way to manage Azure environments with XOAP. Erstellen Sie Ihr kostenloses Konto and see how unified automation changes your operational model.

Easily manage Azure environments

The post From legacy to scalable: Rethinking AVD management for MSPs appeared first on XOAP.

Make AWS WorkSpace management easy with XOAP

Stella — Fri, 20 Mar 2026 13:05:17 +0000

Managing AWS WorkSpaces can be a bit of a maze, but with XOAP’s automation and configuration tools, you can simplify the process, from system configuration to application delivery.

Common challenges like automating bundle creation for Windows 11, scaling WorkSpaces in a pool, and overseeing the entire system add to the difficulty. This post will walk you through how to make these and many other tasks easier, helping you take control of your AWS WorkSpaces without unnecessary complexity.

Before we begin: Define your AWS WorkSpaces

When working with Amazon WorkSpaces, clear planning is key. Start by defining the critical components needed for each workspace.

Select the Operating System (OS)

Start by choosing the appropriate OS for each workspace. AWS currently supports:

Windows 10 and Windows 11
Linux distributions such as Amazon Linux 2 and Ubuntu (20.04 / 22.04 LTS)

With XOAP, the choice of OS can be standardized across environments and automated for consistency.

Define security and hardening standards

Next, define your security parameters so each workspace is hardened according to your organization’s requirements. These settings can be automatically applied, including compliance policies.

Regarding compliance, organizations should align with frameworks like:

Center for Internet Security (CIS benchmarks)
Security Technical Implementation Guides (STIGs)

These help protect sensitive information and meet regulatory requirements.

Decide which applications you want to deploy

Once security components have been defined, choose the software you want to install, such as Office, Adobe Reader, or compression tools. This will be important for defining packaging standards later.

Know how many tenants you'll manage

Do you plan to manage only one AWS tenant or multiple? Many organizations and MSPs manage multiple environments (DEV, QA, PROD) or customers. XOAP enables centralized management of all these AWS WorkSpaces environments from a single interface.

How to manage your AWS WorkSpaces with XOAP

1. Configure systems with Configuration Management

Once your AWS WorkSpaces definitions are set, it’s time to standardize configurations using Configuration Management.

It ensures consistency across all workspaces—eliminating configuration drift and reducing errors. Instead of manually configuring each workspace:

Define configurations once
Apply them across all environments
Automatically deploy updates, patches, and policy changes

You can also validate configurations using testing tools. When scaling up, AWS’s on-demand infrastructure allows you to expand seamlessly.

2. Deliver applications with Application Management

Managing applications in AWS WorkSpaces can be complex due to:

Security and compliance requirements
Performance considerations
Dependency management
Connectivity challenges

With Application Management, you can:

Package applications once
Deploy them across all workspaces
Group software by roles
Define dependencies and installation order

This eliminates common issues like inconsistent installs, poor performance, or integration conflicts.

3. Automate everything with Platform Management

Manual processes don’t scale—and they increase the risk of errors.

Platform Management allows you to automate and schedule tasks using:

PowerShell scripts
Command-line interfaces (CLI)

With it, you can:

Create, modify, or delete workspaces automatically
Schedule routine operations
Monitor execution logs and task history

This provides full visibility into your environment and helps quickly troubleshoot issues.

Automation scripts

Sie können use prebuilt scripts as a starting point for automating AWS WorkSpaces. Customize them based on your environment and operational needs.

Start managing AWS WorkSpaces for free

How much longer can you afford to manage AWS WorkSpaces without unified visibility and control?

XOAP simplifies the entire lifecycle:

Configuration Management → define reusable system configurations
Application Management → automate consistent software delivery
Platform Management → automate operations via scripts and CLI

By combining these, you can standardize and automate every step of managing your AWS WorkSpaces.

AWS WorkSpace management made easy

The post Make AWS WorkSpace management easy with XOAP appeared first on XOAP.

Choosing the right infrastructure: Cloud, on-premises or hybrid

Stella — Mon, 16 Mar 2026 14:01:51 +0000

Whether you’re launching a startup, modernizing enterprise systems, or running mission-critical workloads, the debate around cloud providers and traditional infrastructure continues to evolve.

In this discussion, we’ll compare Amazon Web Services, Microsoft Azure, and Google Cloud Platform with on-premises infrastructure and hybrid environments, and explore where each approach makes the most sense.

Choosing an infrastructure strategy isn’t just a technical decision — it’s a financial and operational one. The wrong choice can lead to unexpected cloud costs or the quieter but equally costly problem of innovation stagnation in on-premises environments.

The rise of cloud computing

Over the past decade, cloud computing has changed how companies build and scale software. Instead of buying servers and setting up physical data centers, teams can deploy infrastructure globally in minutes. You can scale up during peak demand and scale down when traffic drops. That flexibility has lowered the barrier to innovation.

But cloud is not automatically the best answer for every workload. Some systems require strict control, consistent latency or regulatory isolation. The right decision depends on what you are running and why.

Amazon Web Services (AWS)

AWS is the most mature and widely adopted cloud provider. It offers an enormous range of services, from compute and storage to AI, analytics and serverless tools. For startups and fast growing SaaS companies, AWS often becomes the default choice because it makes rapid scaling straightforward.

Its global footprint is a major advantage for products with users across different regions. You can deploy close to customers without building physical infrastructure yourself.

The tradeoff is complexity. With so many services and pricing options, costs can become difficult to manage without strong governance. Teams need clear architecture standards and active monitoring. When managed well, AWS delivers unmatched flexibility.

Microsoft Azure

Azure is especially strong in enterprise environments. Organizations that already rely on Windows Server, Active Directory or Microsoft 365 often find Azure a natural extension of their existing setup.

One of Azure’s biggest strengths is hybrid capability. Many enterprises are not starting from scratch. They have legacy systems, internal applications and compliance requirements that cannot simply be moved overnight. Azure allows businesses to connect on-prem systems with cloud services in a structured way.

While some niche services may not feel as deep as AWS, Azure works extremely well for companies modernizing existing infrastructure rather than building entirely cloud-native platforms from day one.

Google Cloud Platform (GCP)

GCP stands out for its strength in data, analytics and containers. It reflects Google’s background in running large scale distributed systems. For companies building analytics heavy platforms or AI driven applications, GCP can be very attractive.

Its Kubernetes capabilities are widely respected and its global network performance is strong. Engineering focused teams often appreciate the simplicity and performance orientation of its services.

GCP has traditionally had a smaller footprint in large legacy enterprises compared to AWS and Azure. But for modern, data centric architectures, it is a serious contender.

Traditional on premises infrastructure

On-premises infrastructure means you own and manage your own servers, storage and networking equipment. You control the hardware, the security policies and the physical access.

For highly regulated industries or systems that require strict data residency, this level of control can be critical. It can also make sense for stable workloads that do not fluctuate much over time.

The downside is limited elasticity. Scaling requires buying and installing new hardware. There is also ongoing maintenance, refresh cycles and operational overhead. It demands long term planning and capital investment.

Hybrid infrastructure as a practical option

Hybrid infrastructure combines on-prem systems with one or more cloud providers. Instead of choosing one side, companies design around workload needs.

For example, sensitive databases may remain on-prem to meet compliance and governance standards, while customer-facing applications run in the cloud to benefit from elasticity and global reach. Analytics workloads can scale into the cloud during peak processing periods and scale back when demand drops.

XOAP follows this kind of hybrid approach. It helps organizations standardize, secure and automate infrastructure across on-prem and cloud environments. Rather than treating each platform separately, the focus is on creating consistent processes, governance and operational controls across the entire environment. This approach improves visibility and maintains security standards while allowing workloads to run in the environment that best fits their requirements.

Cost considerations

Cloud platforms operate on a pay as you go model. This reduces upfront investment and allows faster experimentation. However, without monitoring and discipline, operational costs can grow quickly.

On-prem infrastructure requires capital investment upfront. Over time, that can lead to predictable cost structures for steady workloads, but it reduces flexibility when demand changes. Hybrid models blend both approaches. Some costs remain fixed and predictable, while others scale with usage.

Choosing infrastructure that works for you

There is no single winner in the AWS vs Azure vs GCP vs on-prem discussion. Each model reflects a different balance between control and scalability.

AWS offers unmatched breadth and global reach. Azure aligns well with Microsoft centric enterprises and hybrid environments. GCP excels in data intensive and cloud native architectures. On-prem remains relevant where compliance, latency and control are non negotiable. Hybrid infrastructure brings these worlds together in a practical way.

The real advantage comes from workload driven decisions. When infrastructure is aligned with business goals rather than trends, it becomes a competitive strength rather than just a technical choice.

Explore XOAP

The post Choosing the right infrastructure: Cloud, on-premises or hybrid appeared first on XOAP.

Bluecue event: Automated security compliance for IT infrastructure

Dora — Wed, 25 Feb 2026 14:49:30 +0000

All events

ONLINE EVENT

Security compliance automation for
IT infrastructures

APRIL 1, 2026
10:00 AM

About the event

Security compliance audits stressing you out? Automation helps you reach basic compliance rate of up to 98% immediately and takes care of complex setups easily.

On April 1, XOAP is speaking at bluecue’s free online event aimed at organizations seeking a fast and reliable approach to security compliance.

We’ll show you how to automate security across entire environments, stay compliant and audit-ready at all times, and do all this without manual work or highly specialized expertise.

Reduce risk and avoid regulatory fines. From CIS and STIG standards to German BSI, get fully compliant in days (not months).

Click to register now and meet IT security regulations fast.

Meet the speaker

XOAP

Mario Istuk

Mario Istuk is the Director Global Business Development at XOAP. With over 15 years of experience in IT infrastructure and automation, he helps organizations optimize complex hybrid IT environments. Mario hosts XOAP’s Gespräche über Automatisierung podcast, leads online events and speaks at conferences across Europe.

The post Bluecue event: Automated security compliance for IT infrastructure appeared first on XOAP.

XOAP

Windows OS (re)deployment with XOAP and OSDCloud

Inhaltsübersicht

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

Erste Schritte

How to create PSADT v4 packages with the XOAP Package Wizard

Inhaltsübersicht

What is XOAP Package Wizard?

How to create a package

Step 1: Drop in your installer

Step 2: Configuration

Step 3: Parameters

Step 4: Build your install phase

Autocomplete for every PSADT v4 cmdlet

Function Builder

Steps 5 & 6: Uninstall and repair phases

Step 7: Preview and test run

Step 8: Export

Two features that save hours

Installed Apps

Import Local

Get the free Wizard

Request download link

How to: Bare metal OS deployment with XOAP

Inhaltsübersicht

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?

The reality of application delivery in 2026

The reality of application delivery in 2026

About the episode

Meet our host

Mario Istuk

Kommende und vergangene Veranstaltungen

AWS Systems Manager vs XOAP: Guide for MSPs

Inhaltsübersicht

What AWS Systems Manager does well

Where the two products differ:

Managing multiple clients

Hybrid and mixed environments

Image management

Cost

A real-world example

Which one?

Different tools, different contexts

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

DOAG Voices: Cloud transformation reality check with XOAP's Christian Reineke

Automation, costs & cultural change

Kommende und vergangene Veranstaltungen

From legacy to scalable: Rethinking AVD management for MSPs

Inhaltsübersicht

The truth about “good enough” tooling

Where legacy tools break in AVD environments

1. Image management becomes slow and fragile

2. Application packaging lacks consistency

3. No unified visibility across tenants

4. Tool sprawl increases operational cost

What modern AVD management should look like

Automated image lifecycle management

Standardized application delivery

Centralized configuration and visibility

Platform consolidation

How XOAP enables a unified approach

1. Image Management: From manual to automated

2. Application Management: Built on what teams already trust

Request
download link

DOAG Voices:
Cloud transformation reality check with XOAP's Christian Reineke

Security compliance automation for
IT infrastructures