Tutorials Archives | XOAP

Windows OS (re)deployment with XOAP and OSDCloud

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

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

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

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

Challenges of Windows OS deployment

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

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

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

Three deployment scenarios

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

Scenario 1: OS downloaded from the internet

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

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

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

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

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

Parameter description:

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

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

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

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

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

Scenario 2: WinPE boot with OS downloaded from the internet

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

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

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

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

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

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

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

Parameter description:

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

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

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

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

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

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

The deployment process on the target device

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

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

Ongoing management after deployment

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

Getting started

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

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

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

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

Explore XOAP

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

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.

The tutorial is also available in video format. Watch it here

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 here 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

The Configuration 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 Install screen gives you three editors: pre-install, install and 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

The 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 here.

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.

Also read:
→ About XOAP Package Wizard
→ XOAP Package Wizard feature list & plans
→ About XOAP automation platform
→ XOAP’s Application Management module

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.

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.

How to automate AWS without using Terraform

Mario — Thu, 09 Oct 2025 10:52:34 +0000

If you’re managing AWS infrastructure, there’s a good chance Terraform is on your radar or already part of your pipeline.

However:
a) It’s not always necessary.
b) You might not need it at all.

The effort of writing HCL, managing state files and stitching together modules can slow things down, especially for operational tasks, account bootstrapping or cross-environment scripting.

If you want fast, simple and flexible AWS automation, XOAP can be a great option, with or without Terraform.

Is Terraform really necessary?

While Terraform is great for building infrastructure, not every task is about provisioning VPCs or load balancers.

Much of what DevOps and cloud teams do looks more like this:

• Applying security settings at scale.
• Running scripts across multiple accounts.
• Automating patching, updates or cleanup.
• Enforcing compliance across environments.
• Configuring operating systems or installing apps.

Read more about Securing AWS accounts automatically

Using XOAP

XOAP can provision infrastructure, not just manage existing environments. It does this through Scripted Actions and prebuilt automation templates that let you create and configure:

• EC2 instances.
• IAM roles and policies.
• VPCs and security groups.
• S3 buckets and encryption settings.
• GuardDuty, Config, CloudTrail and other AWS services.

Instead of declaring resources in HCL, you write scripts – or use ready-made ones available in your XOAP Workspace – that tell AWS exactly what to do, which gives you:

• More flexibility to define infrastructure your way.
• Easier cross-account and multi-region provisioning.
• The ability to use conditional logic, loops and dynamic inputs.
• Simpler onboarding with no need to learn Terraform internals.

XOAP can be your provisioning engine and your operations tool, especially if you prefer scripting over declarative IaC.

What this means in practice for AWS automation

By using your own scripts or XOAP’s pre-built templates, you can automate AWS tasks directly, across any number of accounts:

• Connect your AWS environments easily (via access key or role).
• Create production-ready Landing Zones fast.
• Run Scripted Actions using PowerShell, CLI or your preferred language.
• Apply changes instantly or schedule them across time zones and regions.
• Automate configuration, security, updates and more.

No IaC or state files. Just automation that works at scale.

Read more about Automating entire AWS operations

Example: Automating patching across all your EC2s

Let’s say you want to update EC2 instances with security patches across five AWS accounts.

With Terraform, that means modeling your EC2 fleet declaratively, managing dependencies and state updates, and possibly writing a custom provider or pulling in external data.

With XOAP, it’s a Scripted Action: you select a patching script, pick the accounts and hit run.

Scripted Actions can also be scheduled to keep it fully automated.

This way, you get:

➜ Secure access to each account.
➜ Parallel execution across regions.
➜ Logging, audit trails and notifications.

Read more about Automating Amazon DCV deployment

Already using Terraform? Even better!

If your team already uses Terraform for provisioning, keep going. XOAP isn’t here to replace it, but to complement it.

While Terraform covers infrastructure provisioning, XOAP handles:

• Day-2 operations like updates, restarts or application installations.
• Cross-account orchestration, particularly when it involves configuration that goes beyond the platform’s capabilities.
• Conditional flows based on runtime state, like remediation scripts.
• Orchestration of operational sequences.
• Central view of execution history and logs.

You can even trigger XOAP actions via API to keep your workflows clean and modular.

Try XOAP now

If you’re spending time on repetitive tasks, dealing with multi-account complexity or just want a simple path to automation, XOAP can help. And if you’re already deep into Terraform, XOAP goes a step beyond.

Read also:
→Automating entire AWS operations
→Securing AWS accounts instantly
→Automating Amazon DCV deployment

Terraform is a registered trademark of HashiCorp, Inc. XOAP is not affiliated with or endorsed by HashiCorp.
Results may vary depending on AWS account configuration, access permissions and workload complexity.

Simple and flexible automation

The post How to automate AWS without using Terraform appeared first on XOAP.

How to automate AWS CIS hardening

Stella — Tue, 30 Sep 2025 07:00:39 +0000

If you manage cloud environments, you already know that security is non-negotiable, but it can slow everything down – especially when you’re spinning up new AWS accounts.

Every time you add a new account, there’s a long list of things to do: configure logs, enable GuardDuty, tweak IAM policies, block public S3 access… and so on. It’s tedious, time-consuming, and easy to get wrong.

So we built a better way! With XOAP, your AWS accounts can be CIS compliant the moment you connect them.

Why the CIS AWS benchmark matters

The CIS AWS Foundations Benchmark is a set of best practices designed to help secure AWS environments. It covers things like:

Logging and monitoring
Identity and access management
Network protections
Encryption settings
Regional coverage

Following these guidelines helps reduce risk and improve your security posture. The problem? Actually applying all of this manually isn’t simple.

Read more about CIS compliance

The problem with manual hardening

Here’s how it usually works:

A new AWS account gets created.
Someone (usually a DevOps or security engineer) goes through a checklist.
They set up CloudTrail, enable Config, turn on GuardDuty, enforce MFA, etc.
Repeat for every region and every new account.

This process is not only repetitive, but it also introduces inconsistencies, especially as your environment grows.

The fix: XOAP’s automated AWS CIS hardening

Instead of doing all that manually, XOAP lets you automate the entire process in just a few clicks. Here’s how it works:

1. Connect your AWS account

Head to your XOAP Workspace, go to Connections and add your AWS account. The setup only takes a few minutes.

2. Choose the CIS hardening script

Open Scripted Actions, click New, and select the Resource: aws-ps-account-hardening.ps1. It’s pre-built and ready to go.

3. Run now or schedule it

Run the action immediately or schedule it to run automatically at the desired time (your choice).

4. Done! Start using your hardened AWS account

That’s it. The script applies all CIS-aligned settings behind the scenes. No extra tools needed.

What XOAP configures for you

When you run the CIS hardening script, XOAP automatically configures:

CloudTrail: Multi-region, KMS-encrypted, with log file validation
AWS Config: Recording and delivery set up across your regions
Security Hub: Enabled per region and subscribed to the CIS standard
GuardDuty: Turned on and actively managed
S3: Public access blocked; SSL-only enforced via bucket policies
EBS/EC2: Default encryption enabled with your customer-managed keys
VPC: Flow logs on; optional tightening of admin ports
IAM: Strong password policy; optional MFA enforcement for console access.

All of this happens automatically, in minutes.

Why this makes a difference

Cloud teams today are moving fast and security can’t be an afterthought. With XOAP:

New accounts are secured instantly – no lag, no risk.
You get consistency at scale – the same secure setup across all environments.
Compliance is easier – CIS-aligned settings are mapped and exportable.
You don’t need to write scripts – we’ve already done that part.

Whether you’re managing a few accounts or hundreds, this saves time and reduces mistakes significantly.

Read more about CIS-ready AWS accounts

Try it now

There’s no reason to spend hours manually securing every new AWS account. It’s repetitive and pulls your team away from more valuable work.

With XOAP, CIS hardening becomes automatic. The moment an account is connected, it’s configured with security best practices: no guesswork, no delays. You get consistent, reliable security at scale without slowing anything down.

It’s a straightforward fix to a real problem. If you’re managing cloud environments and care about getting security right from day one, this is how you do it.

Please note: The hardening script is automatically available for all new XOAP accounts. If you’re an existing XOAP user, please contact us to get the script.

We cover instant AWS account security in the Automation Talks podcast
If the video does not load, adjust your cookie preferences or watch it directly on YouTube.

Helpful info:
→How to connect your infrastructure
→Automate your entire AWS operations
→Centralized script automation

CIS-ready AWS accounts

The post How to automate AWS CIS hardening appeared first on XOAP.

How to migrate from VMware to Nutanix using XOAP

Stella — Thu, 18 Sep 2025 09:22:15 +0000

Across industries, organizations are reassessing their virtualization strategies. As licensing models evolve and support costs rise, many IT teams are looking for more flexible, cost-effective platforms, without compromising performance or security.

Nutanix AHV has become a popular choice for modern enterprises. It’s tightly integrated with the Nutanix ecosystem, and built for operational simplicity. However, making the transition from VMware ESXi to AHV is no small task.

This is exactly where XOAP helps.

XOAP offers a systematic, automated and consistent method for migrating workloads from VMware to Nutanix.

VMware to Nutanix: Migration guidelines

Step 1: Assess your current environment

A successful migration starts with a complete and accurate understanding of your existing VMware infrastructure. Assess the following:

VM inventory (including OS, CPU, memory, and storage)
Oversized VMs or workloads with specific resource constraints
Application dependencies and inter-VM communication
Network architecture, including VLANs and IP mappings
Storage performance requirements and capacity utilization

Step 2: Plan the migration strategically

Rather than treating all workloads the same, segment and prioritize based on:

Business criticality and downtime sensitivity
Migration complexity (e.g., shared storage, networking requirements)
Resource usage patterns
Organizational or compliance requirements
Application owner input and change windows

Step 3: Choose the easiest migration method (XOAP)

Create platform-independent VM images

XOAP allows you to build virtual machine images that work across different platforms, cloud or on-prem. You don’t have to rebuild your environment every time you switch providers; this saves time and keeps your infrastructure consistent.

Automate your setup and delivery

With XOAP, you can automate the entire setup – from provisioning servers to deploying applications. This reduces manual work, avoids human errors, and makes sure everything is repeatable.

Create a modular and reusable delivery pipeline

XOAP uses modular components you can reuse across different projects. Once you build a process, you can apply it anywhere; it also makes it easier to update parts of your pipeline without breaking everything.

Scale fast to other platforms

Need to move to another cloud or expand to multiple regions? XOAP supports fast, consistent scaling across providers – no need to redesign your pipeline; just connect a new platform and run.

No vendor lock-in

XOAP is cloud-agnostic. Whether you’re on AWS, Azure, Google Cloud, or on-premises infrastructure, you’re not tied down – you can switch platforms without starting from scratch.

Keep know-how internal

XOAP keeps the migration process in your hands. Instead of relying on outside consultants, your internal team owns the setup, delivery, and scaling; this protects your know-how and builds in-house expertise over time.

Why migrate with XOAP?

Migrating with XOAP takes the stress out of moving from VMware to Nutanix by making the process simple, consistent, and automated. It keeps your systems properly configured without needing extra agents, gives you instant visibility through ready-to-use dashboards, and makes it easy to deploy applications or build images at scale no matter where your systems live.

Make the switch without the stress

Moving from VMware to Nutanix AHV can feel like a challenge, but XOAP makes it very straightforward. It handles the tough parts behind the scenes, keeps your systems aligned, and lets you see exactly what’s happening along the way.

No complicated setups or manual fixes – just a clear, reliable process that helps you get the job done faster and with less stress. With XOAP, migrating becomes less of a project and more of a smooth step forward.

Migrate from VMware to Nutanix

The post How to migrate from VMware to Nutanix using XOAP appeared first on XOAP.

Automating Amazon DCV deployment with XOAP

Ante — Mon, 18 Aug 2025 13:05:47 +0000

Amazon DCV (formerly NICE DCV) offers a high-performance, secure solution for delivering remote desktops and 3D applications. However, setting up DCV infrastructure manually can be time-consuming and prone to errors.

This blog post walks you through the automation process using AWS tools and XOAP to simplify the deployment of Amazon DCV.

How does it work?

Using prebuilt scripts, XOAP’s Image Management module and the Scripted Actions feature, you’ll spin up a fully functional Amazon DCV environment efficiently, reducing setup time, ensuring consistency and enabling rapid scaling in the cloud.

You can test everything in this tutorial for free, as both Image Management and Scripted Actions are available in XOAP’s free plan. Just create your account first.

The Amazon DCV deployment will take five steps:

Download a script from AWS.
Change the username in the script and upload it to XOAP.
Create a connection to your AWS environment.
Prepare your image for DCV deployment with Image Management.
Spin up the DCV infrastructure with Scripted Actions.

Let’s go into the details now.

Step 1: Downloading script from AWS

Download the script from the official AWS GitHub repository here. You can find the documentation in the AWS Administrator Guide.

Step 2: Uploading script to XOAP

Now, let’s edit the script quickly before uploading it:

• Remove the first and last lines of code: and .

• Replace the placeholder “USERNAME” in line 51 with a valid username.

• Remove the comments from lines 49 to 52 (optional, but considered a good practice).

To upload the script, open your XOAP Workspace and go to the Resources area in the left-side menu. Click + New Resource, then simply drag and drop the script. Click Next and Save.

For more information on the script’s syntax, click here.
The DCV license is free on EC2, with a required S3 policy.

Follow the Amazon DCV automation video tutorial

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

Step 3: Creating a connection to your AWS environment

In XOAP, connections are used to deploy image definitions, as well as to provision and configure cloud and on-premises environments.

• Go to Connections in the left-side menu.
• Click + New Connection.
• Select AWS as the provider and choose the connection type.
• If you’re using the AWS-Access Key type, provide your Access Key ID, Secret Access Key and Account ID.
• Click Confirm to save the connection.

Step 4: Preparing image for DCV deployment

The next step is Image Management. It’s a custom image automation module that can be found in your XOAP Workspace.

First, create a provisioner:

• Click on Image Management, then click on Provisioners in the drop-down menu.
• In the Provisioners area, click + New Provisioner.
• Under Select Type, choose PowerShell Script.
• Under Source File, select Install-DCV.ps1, the script you uploaded to XOAP.
• Enter the mandatory information and click Confirm.

Adding a provisioner in XOAP

Now, add that provisioner to a group:

• Go to Image Management > Provisioner Groups.
• Click + New Provisioner Group and select the provisioner you’ve created from Available Provisioners.
• Enter the details and click Save.

Add the group to a provisioner role:

• Go to Image Management > Provisioner Roles.
• Click + New Role and select the group you created from Available Provisioner Groups.
• Enter the details and click Save.

Note:

Each XOAP Workspace is equipped with Operating Systems that can be used as templates for further customizations. Operating system availability depends on the region and may vary. If your region is not available and you would like to adjust the operating system, you can add additional ones as needed.

The same applies to Builders, which define the connection being used, the region, the size of the VM defined to build the image and additional optional settings. You can create them before the next step or add them while defining the Image Definition.

• Now go to Image Management > Image Definitions and click + New Image. Here you will create your image – see screenshot below as a reference. If you need help creating the image, watch this short video tutorial.

Creating an image

Once your image is created, it will appear in Image Definitions.

• Click the three dots on the right in the image’s row, then click Run.

You can track the progress of the Image Definition build by either clicking on the status badge or by clicking on Runs in the upper right corner.

Once the run is finished, in the Image ID field, you will see the ID as ami-xxxxxxxxxxxxxxxxx.
It’s good to save the image ID now, as you will need it to spin up you DCV infrastructure later.

Important:
• If you don’t have it in your XOAP Workspace already, download the EC2 provisioning script below and upload it to the Resources area, just like you did with the first AWS script.

Tutorial continues below

Download the EC2 provisioning script

Step 5: Spinning up DCV infrastructure

Now that you’ve uploaded the EC2 provisioning script to Resources, let’s move to Scripted Actions.

You will find this feature in your XOAP Workspace under the Platform Management module, which helps you automate hybrid infrastructures and cloud workflows.

• Go to Platform Management > Scripted Actions and click + New Scripted Action.
• Enter a Name for this scripted action.
• Under Choose a script from Resources, select the EC2 provisioning script.
• Click Next.

Creating a scripted action

• Edit script parameters as shown below.

Important:

Under AMI_ID, use the Image ID from your Image Definition run. Specify the region where you want the EC2 instance to be created, along with the SUBNET_ID of the VPC where you want the instance to be placed. Make sure you choose the same region that was specified in your Image Definition. Otherwise, the AMI won’t be found, as they are region-specific.

Editing script parameters

• When everything’s ready, click Next.

• Select AWS from the Connections table and click Next.

• In the final scripted action creation step, you can schedule your scripted actions. We can skip that for now, so just click Finish.

The scripted action is now created and you can run it the same way you ran your Image Definition. If you want to track the progress, click on the status badge right next to the scripted action. Once the run is finished, the DCV will be ready.

You can find all the information necessary for connecting to the DCV in the scripted action’s log. To access the log, click the three dots on the right side in the scripted action’s row and click View log.

Example of a scripted action’s log

To connect to the DCV, you can use web access or the Amazon DCV client, which is available for download from AWS. Be mindful of the required Security Group rules when connecting. Direct access to the instance will be required (for web access, you will need a public facing instance).

Alternatively, you can deploy the Amazon DCV client to your endpoints worldwide using XOAP’s Application Management module. Application Management automates and simplifies software packaging and delivery to any device. This way, you can easily create a remote access solution for your endpoints.

Did we miss something? If you need help using XOAP to automate Amazon DCV deployment, just book a call and our engineers will walk you through it.

More about XOAP:
→ More on Application Management
→ Automating your entire AWS operations
→ Standardized image automation across platforms
→ Scripted Actions for centralized script management

Start automating your cloud infrastructure with XOAP

The post Automating Amazon DCV deployment with XOAP appeared first on XOAP.

Set IGEL RDP collections on the latest OS12 RDP app: A workaround

Mario — Thu, 22 May 2025 08:33:14 +0000

In IGEL OS 12, the ability to configure RDP collections via the GUI is currently not available. This can be a limitation for users in terminal server environments where managing multiple RDP session collections is crucial. In particular, environments that do not rely on Citrix or other solutions may face difficulty when trying to use RDP collections.

While this feature is not yet supported in the GUI, there is a simple workaround to configure RDP collections manually.

The workaround

Although the OS12 RDP App does not offer a direct option for configuring RDP collections through the graphical interface, you can still achieve this configuration by modifying the registry.

To configure the RDP collection, you need to set the following registry key:

				
					app.rdp.sessions.rdp0.options.load-balance-info

This registry tweak allows you to specify the load-balance info string, which is essential for RDP collections to function properly.

Why this matters

For those working in Microsoft RDS environments, especially in thin client deployments, configuring RDP collections is often a key part of session management. By using this workaround, you can continue to deploy IGEL thin clients effectively, even without the GUI option for RDP collection configuration.

Although this feature is not yet available in the GUI, this workaround ensures that you can maintain an efficient terminal server environment while waiting for future updates.

A story from one of our customers:
>> Windows Remote Desktop Services infrastructure delivery and standardization

Automate Remote Desktop Services with XOAP

The post Set IGEL RDP collections on the latest OS12 RDP app: A workaround appeared first on XOAP.

Firewall setup for Intune AD Connector in legacy systems

Mario — Fri, 02 May 2025 11:54:21 +0000

Modern endpoint management with Microsoft Intune enables IT teams to automate device provisioning and management processes, including Windows Autopilot scenarios and Hybrid Azure AD Join.

However, not every organization operates in a greenfield environment.

Legacy infrastructures, often found in healthcare, public sector, education or manufacturing come with specific challenges:

No Application Control features in firewalls
No Host-based Ruleset automation
No wildcard support for FQDN-based rules
Manual IP address maintenance is required

This blog post outlines how to design a secure and operationally manageable firewall configuration for the Intune Connector for Active Directory, even in restricted and technically outdated environments.

The challenge

The Intune Connector for Active Directory requires outbound communication to various Microsoft cloud services to function properly. However, in legacy environments, this can present some challenges:

No wildcard support in the firewall (no *.microsoft.com)
No Application Control feature available
Only specific IP addresses or FQDNs can be configured
Firewall rules must be maintained manually

Recommended technical approach

Step 1: Identify required endpoints

Microsoft provides official documentation listing all required URLs and IP address ranges for Microsoft 365 services and Intune:

Focus Categories for Intune Connector:

Microsoft 365 Common & Office Online
Intune
Azure Active Directory

Optional for Automation: Microsoft’s Endpoint API provides a machine-readable JSON file for automated processing (more here).

Step 2: Firewall ruleset design

Define dedicated outbound rules for the Intune Connector server.

Note: If DNS resolution is restricted, IP addresses must be resolved manually and configured explicitly in the firewall.

Step 3: Operational process for IP maintenance

Since Microsoft services evolve continuously, it’s essential to establish a reliable process for maintaining firewall rules.

Recommended steps:

Monthly check of the official Microsoft documentation.
Optional: PowerShell script querying the Microsoft Endpoint API for changes.
Generate an automated notification or create a ticket for the firewall team.
Keep documentation updated with the current IP ranges and URLs.

Step 4: Automation pipeline flow

Update IP Addresses: Automated PowerShell script pulls the latest Microsoft Endpoint API data.
Update DSC Config: IP addresses are dynamically injected into the DSC configuration template.
XOAP Deploy: XOAP pulls the new configuration and applies it to the target firewall servers.
Compliance check: XOAP runs a configuration compliance scan to validate correct deployment.

Read more about automated firewall changes with XOAP below ↓

Best practices for firewall management in legacy environments

Long-term optimization options

Organizations should evaluate possible optimizations over time:

Upgrade firewall systems to support Application Control features.
Implement transparent or explicit proxy solutions.
Utilize Microsoft Azure Service Tags for dynamic IP management.
Consider Azure Firewall or modern next-generation firewalls for cloud-centric environments.

Automation use cases

Fully automated firewall changes with XOAP's Configuration Management

XOAP’s Configuration Management makes it easy to define, version and automatically deploy configuration settings across systems, including firewalls, servers, and other infrastructure components.

By using Config as Code principles alongside PowerShell Desired State Configuration (DSC), firewall rules can be fully automated, audited, and enforced across multiple environments.

XOAP integration provides:

Related: Automate firewall changes with XOAP

Final thoughts

Running Intune Connector for Active Directory in environments with strict firewall rules is possible. It just takes the right setup and processes. By creating clear firewall rules, managing IPs and keeping good documentation, even older systems can safely connect to Microsoft cloud services.

Use XOAP for automated firewall changes

The post Firewall setup for Intune AD Connector in legacy systems appeared first on XOAP.

Complete Windows 11 migration guide for enterprise IT

Mario — Mon, 28 Apr 2025 11:03:10 +0000

Migrating from Windows 10 to Windows 11 isn’t just about installing a new version. It involves checking your devices, making sure apps work, and managing the user experience. Without the right tools, this can be a tricky process.

XOAP gives you a platform to handle all of it. Whether you’re working with a handful of devices or thousands, XOAP provides the right tools for imaging app deployment and system configuration.

Check upgrade readiness

Before you begin, make sure your devices meet these basic requirements:

Devices need to be running a supported version of Windows 10.
They must meet the minimum hardware requirements for Windows 11.
Secure Boot should be turned on in the BIOS, and TPM 2.0 should be available.
Use the latest drivers for Windows 11 to avoid issues like Blue Screen errors.

Tools for checking device eligibility

Use these tools to check if your devices are ready for Windows 11:

PC Health Check app
WhyNotWin11
Windows Update in Settings

Windows 11 migration phases

We’ve outlined the migration process in three main phases below. For a quick guide on what it takes to migrate devices to Windows 11, check out this blog: Windows 11 migration made easy with XOAP.

1. Pre-migration

This phase is all about getting everything ready before upgrading. Check your hardware and drivers, test your apps for compatibility, prepare your Windows 11 images, and confirm that all system settings are correct. XOAP’s tools can help you run these checks automatically.

Start by checking hardware and drivers across all devices. XOAP’s reporting and scripting tools can help you automate these readiness checks and spot any issues early. Next, test application compatibility using the Application Management module to identify apps that may need updates or adjustments.

Prepare your Windows 11 images with Image Management, making sure they include the right settings and software. Review Group Policy settings and system configurations, and use Configuration Management to automate these checks. Finally, use the same tool to apply security baselines and hardening policies so that all systems meet your organization’s compliance standards.

2. Migration

Now it’s time to actually deploy Windows 11.

Pick a deployment method (Autopilot, SCCM, Intune, PSADT, or XOAP) and test it first. Then use XOAP to handle app installs and system settings across all your devices.

VIDEO TUTORIAL: Migrating to Windows 11 using XOAP
Blog article continues below

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

Read the full tutorial: How to migrate to Windows 11 with XOAP

3. Post-migration

Once Windows 11 is installed, it’s time to make sure everything works as it should.

Run clean-up tasks like removing temporary files, updating apps, and checking system settings. XOAP can automate these tasks to save time.

Custom actions let you run specific tasks like removing Windows.old folder, installing missing language packs, or managing app compliance using scripts in XOAP. This can greatly improve your migration strategy, especially when you’re not using SCCM task sequences.

You may also be interested in:
Windows 11 migration via SCCM
Step-by-step: Windows 11 migration using GPOs and registry keys
Migration to Windows 11 with PSADT
How to migrate to Windows 11 via Windows Update in Settings

What this means for your team

Migrating to Windows 11 is a good time to review how your systems are managed. It’s not just about getting to the latest OS – it’s a chance to clean up old processes, fix what’s slowing things down and set up a simpler way to handle future updates.

Look at what worked, what didn’t and where automation or better visibility could save time. A solid approach now will save you from scrambling later.

Our platform can help you simplify that process. By automating key tasks and providing better insights, it makes future updates easier to manage.

Make Windows 11 rollout simple with XOAP

The post Complete Windows 11 migration guide for enterprise IT appeared first on XOAP.

Tutorials Archives | 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

How to create PSADT v4 packages with the XOAP Package Wizard

Table of contents

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

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?

How to automate AWS without using Terraform

Table of contents

Is Terraform really necessary?

Using XOAP

What this means in practice for AWS automation

Example: Automating patching across all your EC2s

Already using Terraform? Even better!

Try XOAP now

How to automate AWS CIS hardening

Table of contents

Why the CIS AWS benchmark matters

The problem with manual hardening

The fix: XOAP’s automated AWS CIS hardening

1. Connect your AWS account

2. Choose the CIS hardening script

3. Run now or schedule it

4. Done! Start using your hardened AWS account

What XOAP configures for you

Why this makes a difference

Try it now

How to migrate from VMware to Nutanix using XOAP

Table of contents

VMware to Nutanix: Migration guidelines

Step 1: Assess your current environment

Step 2: Plan the migration strategically

Step 3: Choose the easiest migration method (XOAP)

Create platform-independent VM images

Automate your setup and delivery

Create a modular and reusable delivery pipeline

Scale fast to other platforms

No vendor lock-in

Keep know-how internal

Why migrate with XOAP?

Make the switch without the stress

Automating Amazon DCV deployment with XOAP

Table of contents

How does it work?

Request
download link