The post Use case: B3S/BSI Technical control mapping appeared first on XOAP.

Overview

This guide walks you through the end‑to‑end process of standardizing on-premises operating system images with XOAP. The goal is to help you build repeatable, compliant, and provider‑agnostic base images that can be used consistently across on-premises deployments on either VMware vSphere, Nutanix or XenServer. 

What Are Standardized on-premises OS Images? 

Standardized Cloud OS Images are centrally defined, versioned, and automated operating system images that: 

• Follow a common baseline (security, hardening, tooling) 
• Are built in a reproducible way 
• Can be reused across multiple environments and providers 
• Serve as the foundation for higher‑level automation (platform management) 

XOAP acts as the control plane that defines what an image should look like and how it is built, while the actual build execution happens inside the target environment. 

What is the difference between images being created in the cloud and on-premises

Creating images in the cloud and on-premises follows the same high-level goal—producing a reusable, standardized machine image—but differs significantly in implementation details.  

In on-premises environments, image creation typically relies on full OS installers and requires an explicit autounattend.xml for Windows to automate setup steps such as disk partitioning, locale, users, and initial configuration; additional scripts are needed to configure WinRM, open or adjust the Windows Firewall, and install the appropriate hypervisor tools (for example, VMware Tools or XenServer guest tools) to ensure manageability and performance.  

In cloud environments, many of these steps are partially abstracted by the platform through metadata services and pre-configured base images, but customization scripts are still required to align with enterprise standards.

For Linux, both cloud and on-premises image builds require unattended installation mechanisms (for example Kickstart, Preseed, or Cloud-Init) along with post-install scripts to configure SSH access, firewall rules, networking, time synchronization, and to install the relevant hypervisor or cloud-agent packages, ensuring the image integrates cleanly with the target runtime platform. 

High‑Level Architecture – How It Works 

At a high level, the process looks like this: 

1. XOAP defines operating systems, builders, and image definitions 
2. An on‑premises Connector executes builds locally 
3. Images are created using native provider tooling 
4. Results are tracked, versioned, and reused 

Key design principles: 

• No public inbound access required for XOAP 
• Least‑privilege access using native identity concepts 
• Separation of control plane and execution plane 

Short Overview of the End‑to‑End Flow 

• Prepare prerequisites 
• Deploy a Connector 
• Add an on-premises Connection 
• Add and manage Operating Systems 
• Configure Builders 
• Create Image Definitions 
• Run Image Builds 
• Validate the created images 
• Troubleshoot if required 
• Next steps and extensions 

Prerequisites

Before you start, ensure the following prerequisites are met: 

General

• An active XOAP Workspace 
• Access to at least one supported on-premises virtualization platform 
• Permissions to create images and identities in the target environment (solution specific) 
• An Linux or Windows VM, to install the XOAP Connector which acts a s a proxy 
• If a proxy is used for internet connection, proxy credentials are needed for the Connector 
• Connector has access to the created images with required ports (WinRM 8595, 8596) 
• An ISO on the datastore of the desired platform 
• The SHA256 hash of the iso 

Cloud‑Specific 

vSphere  

Required privileges at vCenter level (minimum set): 

    •   Datastore 
    •   Allocate space 
    •   Browse datastore 
    •   Low level file operations 
    •   Network 
    •   Assign network 
    •   Resource 
    •   Assign virtual machine to resource pool 
    •   Virtual Machine → Inventory 
    •   Create new 
    •   Register 
    •   Remove 
    •   Virtual Machine → Configuration 
    •   Add new disk 
    •   Add or remove device 
    •   Change CPU count 
    •   Change memory 
    •   Settings 
    •   Virtual Machine → Interaction 
    •   Power on 
    •   Power off 
    •   Reset 
    •   Virtual Machine → Provisioning 
    •   Allow disk access 
    •   Allow read-only disk access 
    •   vApp 
    •   Import 

Best practices: 
    •   Create a dedicated vCenter role for Packer/XOAP 
    •   Assign the role at Datacenter or Folder level 
    •   Use a service account, not a personal user 

Nutanix 

Required roles / permissions: 
    •   Ability to create, update, and delete VMs 
    •   Image upload and management permissions 
    •   Network assignment permissions 
    •   Disk attach/detach permissions 

Recommended built-in roles: 
    •   Infrastructure Admin (broad, easiest) 
    •   Or a custom role with: 
    •   VM Create / Delete 
    •   Image Create / Update 
    •   Network View / Attach 

Best practices: 
    •   Use a service account in Prism Central 
    •   Scope permissions to a specific project if possible

XenServer

Required permissions: 
    •   Pool‑admin or equivalent custom role with: 
    •   VM create / destroy 
    •   Attach / detach disks 
    •   Power operations 
    •   ISO SR access 

Key requirements: 
    •   Access to an ISO SR containing the installation media 
    •   Permission to create templates or base VMs 

Best practices: 
    •   Use a dedicated automation user
    •   Avoid using the built‑in root account 

Connector Deployment Flow 

For most scenarios, XOAP uses a Connector that runs inside the target environment. 

Create an API Key 

Text

Note your Workspace ID 

Text

Install Connector on Windows 

• Deploy the Connector VM or service in the target environment 
• Outbound‑only communication to XOAP (api.dev.xoap.io) via 443 
• No inbound firewall rules required 

Install Connector on Linux 

• Deploy the Connector VM or service in the target environment 
• Outbound‑only communication to XOAP (api.dev.xoap.io) via 443 
• No inbound firewall rules required 

Verify Registration 

Text

Add a Connection 

The Connection represents the logical link between XOAP and a target environment. 

Steps:

• Navigate to Connections in XOAP 
• Select the target provider (Nutanix, vSphere or XenServer 
• Insert necessary Connection information 
• Assign the Connector that should be used for communication 
• Save the connection 

Add connection Cloud-specific 

Nutanix

Text

vSphere

Text

XenServer

Text

At this stage, no workloads are executed yet—you are only defining where builds will later run. 

Add Operating Systems 

Operating Systems define what base OS versions are supported for image creation. On-premises operating systems are generic for all types of on-premises hypervisors. 

Examples: 

• Windows 11 Enterprise 
• Windows Server 2025 
• Ubuntu LTS 
• RHEL 

Add Builder Configuration 

Builders define how an image is created. 

A Builder configuration typically includes: 

• Target platform (Nutanix, vSphere or XenServer.) 
• CPU and RAM configuration 
• Networking and storage configuration 
• Temporary build resources 

Builders abstract provider differences while keeping builds transparent and auditable. 

Add a builder configuration Cloud specific

Nutanix

Text

vSphere

Text

XenServer

Text

Add Image Definition 

An Image Definition ties everything together. 

It references: 

• Platform 
• Builder Configuration 
• Operating System 
• Provisioning steps (scripts, actions, hardening), we call it Provisioner Role. 

Run Image Definition 

Once defined, you can start an image build: 

1. Select the Image Definition 
2. Trigger a run manually or via schedule 
3. XOAP hands off execution to the Connector 
4. Build progress and logs are tracked centrally 

Each run results in a new, versioned image artifact. 

Summary 

By following this flow, you establish a clean, auditable, and scalable image pipeline: 

• One control plane (XOAP) 
• Multiple execution environments 
• Consistent OS baselines 
• Cloud and on‑prem parity 

This forms the foundation for enterprise‑grade automation and compliance‑driven infrastructure. 

Next steps

Once your first standardized image is working, typical next steps include: 

Troubleshooting 

If a build fails: 

• Review build logs in XOAP 
• Check Connector health and permissions 
• Validate cloud quotas and limits 
• Confirm network reachability inside the target environment 

Most issues are related to: 

• Missing permissions 
• Network misconfiguration or port restrictions 
• Provider‑side quota limits 

Add Your Own Scripts, Applications and Configurations 

• Extend provisioners with custom scripts 
• Integrate security baselines 
• Install enterprise tooling 

Check our repo at https://dev.xoap.io/image-management-templates 

Reuse existing Roles in the cloud 

• Apply the same provisioning roles to cloud images 
• Achieve consistency across hybrid environments 

Build Higher‑Level Automation 

• Application packaging 
• Stacks and roles 
• Continuous image updates 

The post Standardizing on premises OS images appeared first on XOAP.

This release focuses on improving efficiency, scalability, and operational clarity across the platform.

Key highlights include enhanced bulk operations, extended Azure integration using Managed Identities, a clearer Provisioner integration, and significant improvements to the XOAP Connector installation and lifecycle management.

General

This section introduces usability and productivity improvements that apply across multiple areas of the platform, with a strong focus on working with larger datasets.

Data tables

Data tables have been enhanced to better support bulk operations and day-to-day administrative workflows.

Bulk Tag Editing

You can now edit tags for multiple resources in a single operation, reducing repetitive manual effort.

Bulk Downloads

Multiple resources can now be downloaded at once.

Note: Ensure that your browser allows multiple simultaneous downloads.

Bulk Exports

Export data for all or selected resources to .csv or .xlsx formats for further processing or reporting.

Bulk Delete

Multiple resources can now be deleted in a single action, simplifying cleanup and lifecycle management.

Image Management

This release significantly improves Azure-based image workflows by removing networking constraints and strengthening security.

Azure Managed Identity Support

The XOAP Connector can now be used with Azure Managed Images and Azure Gallery Image Definition runs.

This eliminates the need for Public IPs on provisioned VMs. Instead, the XOAP Connector VM uses an Azure Managed Identity within the subscription to:

• Create all required Azure resources
• Securely communicate with the XOAP backend
• Align image builds with enterprise security and compliance requirements

NEW – Provisioners overview and details

Gain visibility into configured provisioners and inspect their configuration and status.

NEW – Provisioners Groups overview and details

Organize provisioners into logical groups to better reflect environments or responsibilities.

NEW – Provisioners Roles overview and details

Clearly define and review provisioning roles to support structured and secure execution models.

NEW – Operating Systems overview and details

Centralized visibility and management of supported operating systems used across image and provisioning workflows.

Documentation slide-outs

The documentation experience has been redesigned to improve accessibility and usability.

Documentation is now structured into:

• Quick Guide – for fast, task-oriented help
• Technical Documentation – for deeper, implementation-focused guidance

This allows users to quickly find the level of detail they need.

Tags

Tag handling has been refined to make metadata management faster and more intuitive.

Inline Tag removal

Tags can now be removed directly within tag input fields without additional actions.

Inventory

Inventory management has been extended to support more flexible onboarding scenarios.

Add Device

Devices can now be manually added to the inventory, enabling better alignment with existing environments.

XOAP Connector

Installer and Connector

The XOAP Connector has been split into two components to:

• Improve update handling
• Clearly separate installation and runtime responsibilities

Default installation path on Windows:

C:\Program Files\XOAP

Command-line parameters

The installer now provides a built-in help function to discover supported command-line parameters.

PS C:\Program Files\XOAP\Installer> .\XOAP.Connector.Installer.exe --help

Windows Service

The XOAP Connector for Windows now runs as a native Windows Service, improving reliability and manageability.

Event log integration

The XOAP Connector for Windows now writes operational logs directly to the Windows Event Log, enabling easier troubleshooting and monitoring.

Additional log files and temporary files for Image Definition runs are stored in:

C:\ProgramData\XOAP

Updating the Connector

The XOAP Connector can now be updated in place using the installer.

PS C:\Program Files\XOAP\Installer> .\XOAP.Connector.Installer.exe --update

This updates the installer and connector components to the latest available version.

Proxy configuration

Proxy settings for the XOAP Connector can be centrally configured using the following file:

C:\Program Files\XOAP\Connector\config.yml

The post 2026 January updates appeared first on XOAP.

Quick guide

Commands Library is a centralized repository for reusable commands that can be executed on managed devices. It lets you standardize common operational tasks (e.g., troubleshooting, data collection, quick checks) by storing commands in one place and reusing them across the environment. Commands can be created for different runtimes such as PowerShell, PowerShell Core, Bash/Shell, or CMD.

Add a new Command

1. Click + Add Command.
2. Enter a Command name.
3. Select the Type (e.g., PowerShell Core, PowerShell, Bash/Shell, CMD).
4. (Optional) Add Tags and a Description.
5. Paste or write the Command content.
6. Click Add to create the command.

Edit a Command

1. Open the command (e.g., via the Details / eye icon).
2. In the Current version panel, click Edit.
3. Update the command content and/or metadata as needed.
4. Save the changes (a new version is created).

Delete a Command

1. Click the Delete (trash) icon next to the command.
2. Confirm deletion.

Additional useful information

OS compatibility

Some command types are OS-specific. Use Tags (e.g., windows, linux) and/or naming conventions to clearly indicate the target platform.

Prefer non-interactive commands

Avoid prompts and UI interactions; commands should run unattended.

Keep output readable

Return clear, structured output (and include error handling) to simplify troubleshooting and auditing.

Technical documentation

The Commands Library is XOAP’s centralized store for versioned and reusable commands that can be executed on managed devices through the XOAP Inventory/Connector execution layer. It is designed for operational tasks such as troubleshooting, validation checks, log collection, and lightweight remediation actions.

A command in the library is defined by:

• Metadata (name, description, tags)
• Runtime type (PowerShell, PowerShell Core, Bash/Shell, CMD)
• Command body (the actual script/command text)
• Version information (version number and message)

Commands are executed on devices that have the XOAP Connector installed.

Command Types (Runtime)

When you create a command, you select a Type that defines the interpreter/runtime used on the device:

• PowerShell
  Runs using Windows PowerShell (typically 5.1 on Windows).
• PowerShell Core
  Runs using PowerShell 7+ (cross-platform when available).
• Bash/Shell
  Runs using a shell on Linux/macOS (typically /bin/bash or /bin/sh, depending on the device).
• CMD
  Runs using Windows Command Prompt (cmd.exe).

Versioning behavior

Commands are versioned artifacts. Any change to the command definition (especially the command body) should be treated as a new version so you can:

• Track who changed what and why
• Roll forward safely
• Keep operational actions reproducible across environments

Best practice: Use short, meaningful version messages (e.g., “Add service filter”, “Fix path quoting”, “Support PS7”).

Fields and what they mean

In the Add Command dialog:

• Command name
  Unique, human-readable identifier. Use a consistent naming scheme like:
  windows-check-service-status / linux-journalctl-last-50
• Type
  The runtime/interpreter used to execute the command on the target device.
• Tags
  Used for filtering and organization (OS, purpose, team, environment).
• Description (optional)
  Short explanation of intent, expected output, and any prerequisites.
• Command
  The script/command content. This should be non-interactive and safe to run repeatedly.

Execution model and output

Commands are  executed remotely and return:

• Exit code (success/failure)
• Standard output (results)
• Standard error (errors)

Recommended patterns

• Return human-readable output plus simple structured output where possible (key/value lines).
• Use explicit exit codes:
  • 0 = success
  • non-zero = failure or partial failure
• Write errors to stderr and keep stdout for normal results.

Operational and security considerations

Non-interactive only

• Avoid prompts (Read-Host, pause, interactive confirmation).
• Assume the command runs unattended.

Idempotency

• Prefer commands that can be run multiple times without harmful side effects.
• For remediation-type commands, check current state before changing it.

Logging

• For troubleshooting commands, include contextual details (hostname, timestamp, relevant versions).

Best practices for building a maintainable library

• Naming convention: os-purpose-action (e.g., windows-inventory-installed-software)
• Tagging: OS + team + category (e.g., windows, security, troubleshooting)
• Small scope: One command = one purpose. Avoid “do everything” scripts.
• Document prerequisites: Required tools, modules, permissions, or paths.
• Test on pilots: Validate on a small set of devices before broad use.
• Prefer PowerShell Core for cross-platform: If your fleet supports it, it simplifies reuse.

Examples (simple, safe commands)

PowerShell (Windows) – list a service state

Get-Service -Name “WinRM” | Select-Object Name, Status, StartType

PowerShell (Windows) – last 50 event log errors (System)

Get-WinEvent -LogName System -MaxEvents 50 |
  Where-Object { $_.LevelDisplayName -in “Error”,”Critical” } |
  Select-Object TimeCreated, Id, ProviderName, Message

CMD (Windows) – basic network info

ipconfig /all

Bash (Linux) – disk usage summary

df -h

Troubleshooting

If a command fails to run or returns unexpected output, the most common causes are:

• Wrong Type selected (e.g., Bash command on Windows)
• Runtime not installed (e.g., PowerShell 7 missing for “PowerShell Core” commands)
• OS differences (paths, tools, service managers)
• Command is interactive or expects a TTY

Recommendation: Start with read-only diagnostics commands, then add remediation actions only after validation and clear approvals.

The post Commands library appeared first on XOAP.

Image Management

To get started with Image Management, there is only one prerequisite: a working connection to your environment. Configure your connection by navigating to Connections, then clicking the Add new connection button in the upper-right corner.

In the slide-out panel, select the connection Type and Provider. Fill in the remaining required information and click Confirm to save your connection.

If you need assistance with configuring your access credentials, please refer to the Connect your infrastructure documentation.

In the following sections, you will find more information about the required permissions for your infrastructure. Please note that these are the minimum permissions needed to create Image Definitions.

If you plan to use the same connection for Scripted Actions, the required permissions may vary depending on the specific use case.

AWS

To create a customized image, a default VPC must be available in the AWS account you’re using.

Additionally, you need to assign appropriate IAM permissions to the user specified in the connection. At a minimum, the following permissions are required:

#Codeblock

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CopyImage",
        "ec2:CreateImage",
        "ec2:CreateKeyPair",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSnapshot",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:DeleteKeyPair",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSnapshot",
        "ec2:DeleteVolume",
        "ec2:DeregisterImage",
        "ec2:DescribeImageAttribute",
        "ec2:DescribeImages",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeRegions",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSnapshots",
        "ec2:DescribeSubnets",
        "ec2:DescribeTags",
        "ec2:DescribeVolumes",
        "ec2:DetachVolume",
        "ec2:GetPasswordData",
        "ec2:ModifyImageAttribute",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifySnapshotAttribute",
        "ec2:RegisterImage",
        "ec2:RunInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Resource": "*"
    }
  ]
}

#EndOfCodeblock

Read more about the required permissions here.

Azure

To create images on Azure, ensure the following prerequisite is met: you must create a Service Principal with Contributor role access to your Azure subscription. Use the Azure CLI to generate the Service Principal.

Command format

#Codeblock
az ad sp create-for-rbac \
  --name [ServicePrincipalName] \
  --role Contributor \
  --scopes /subscriptions/[SubscriptionId] \
  --years 1
#EndOfCodeblock

Command example

#Codeblock

az ad sp create-for-rbac \
  --name xoap-image-principal \
  --role Contributor \
  --scopes /subscriptions/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --years 1

#EndOfCodeblock

Command output

#Codeblock

{
  "appId": "[ClientId (Guid)]",
  "displayName": "xoap-image-principal",
  "name": "http://xoap-image-principal",
  "password": "[ClientSecret]",
  "tenant": "[TenantId (Guid)]"
}

#EndOfCodeblock

Using this output, you can now configure your connection in XOAP:

• Subscription ID: xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
• Tenant ID: [TenantId (GUID)]
• Client ID: [appId]
• Client Secret: [password]

Read more about the required permissions here.

Google

The file you’re required to upload is a Google Cloud Service Account key file in JSON format. You can generate and download it like this:

1. Open Google Cloud Console: https://console.cloud.google.com/iam-admin/serviceaccounts.
2. Select your project from the top-left dropdown.
3. Create or select a service account: If you don’t have one yet, click “Create Service Account” under “IAM&Admin” menu. Give it a name and optional description.
4. Assign the required roles (see below for full list).
5. After creating or selecting a service account:
   • Click the ⋮ (three dots) next to the service account name → Manage Keys
   • Under the “Keys” section, click Add Key → Create new key
   • Choose JSON, then click Create
6. The file will download automatically – this is the file you need to upload into XOAP to authenticate with Google Cloud.

Required IAM Roles for Packer to build Images

To allow the service account to build custom images with Packer, you need to assign at least these roles:

Read more about the required permissions here.

vSphere

To integrate XOAP with VMware vSphere for image builds, create a custom vSphere role that includes only the privileges required for XOAP to perform its operations. Assign this role to a dedicated service account to ensure XOAP has least-privilege access to the vSphere infrastructure.

Required privileges

Clone the default Read-Only vSphere role and add the following privileges:

Configuration Management

PowerShell

All nodes that will be used to author or receive configurations are running WMF version 5.1 or later. Authoring nodes that are used to write configurations locally need to have internet connectivity to download new DSC-related resources.

Remote management

WS-Management (WS-MAN) traffic is permitted on the network. It will be enabled by default on nodes that have PowerShell version 5 installed, but you must ensure it’s not being blocked by firewalls or other network elements. Read further for more information.

Communication with our backend

In order to communicate with our backend, the following ports need to be open: https://api.dev.xoap.io on port 443.

Proxy configuration for nodes

To force PowerShell DSC nodes to use a proxy server to communicate with the cloud-hosted backend, some adjustments to the node configuration must be made before registering the node. DSC does not communicate in a user context and therefore uses the SYSTEM context.

For DSC to connect successfully and register the node, adjust the following lines inside the machine.config in your .NET installation directory.

You should find the file in these locations:

32-bit
**%windir%\Microsoft.NET\Framework\[version]\config\machine.config**
64-bit
**%windir%\Microsoft.NET\Framework64\[version]\config\machine.config**
[version] should be equal to v1.0.3705, v1.1.4322, v2.0.50727 or v4.0.30319. v3.0 and v3.5 just contain additional assemblies to v2.0.50727 so there should be no config\machine.config. v4.5.x and v4.6.x are stored inside v4.0.30319.
Then add the following lines:
<defaultProxy>  <proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" /> </defaultProxy></system.net>

Firewalls

SSL decryption can get you into trouble when clients inside your corporate network try to communicate with the cloud backend.

DEP

We’ve seen some Virus Scanners with DEP enabled to prevent users from logging into the cloud backend successfully.

TLS

Enable TLS 1.2 wherever possible. Not doing so will keep Configurations Management from working successfully.

Set it via PowerShell:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWordSet-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWordSet-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v2.0.50727' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

Application Management

To use Application Management you need to have network access to api.dev.xoap.io over port 443 and custom packages must be provided as a ZIP archive prior to upload.

Within your XOAP workspace, you can already find a wide selection of:

• Applications
• Application Groups
• Application Roles

This means you’re ready to begin installing applications immediately.

Creating packages

XOAP’s Application Management supports PSADT packages in both v3 and v4 formats. Our current Package Wizard supports package creation in v3 format. If you plan to create your own application packages, we recommend installing it on your packaging machine. The easiest way to do this is directly from your XOAP Workspace.

1. Navigate to Application Management → Application Roles
2. Locate the Role: PSADT Packaging Baseline
3. Open the three-dot menu next to the role and choose Copy installation command
4. On the machine where you want to install the wizard, open PowerShell as Administrator. Paste and execute the copied command.

Alternatively, you can download the installation script or copy the installation command, copy it manually to the target system, and then run it through PowerShell as Administrator.

Once completed, the Package Wizard will be fully installed and configured. You can find the shortcut on your desktop.

Platform Management

There are no deployed agents required to use Platform Management — the logic runs directly on XOAP’s cloud runners or through your established infrastructure connections.

Within the Scripted Actions library, you can already find a selection of:

• Template scripts: pre-built scripts for common tasks (like AVD management or Azure automation)
• Resources: a library where your custom scripts are stored

This means you can start automating immediately using existing templates.

Supported formats

Platform Management supports standard PowerShell (.ps1), Azure CLI, Google CLI and AWS CLI scripts. The only prerequisite for using your own automation is that the script file must be uploaded to the Resources area or imported directly during action creation.

Establishing connections

To execute any script, the platform requires a valid Connection to your infrastructure. It is recommended setting up your Connections to cloud providers (Azure, AWS, Google) or on-premises systems (VMware, Nutanix) before creating complex workflows.

You can easily set this up from your XOAP workspace:

• Navigate to Connections (in the main menu)
• Click + New connection
• Select your provider (Azure, AWS, Google, or other) and follow the authentication prompts

Note: The Scripted Action wizard also allows you to add a new connection during the Target selection step.

The post Prerequisites appeared first on XOAP.

This release delivers a range of improvements and new capabilities across XOAP, with a strong focus on usability, extensibility, and operational efficiency.

Key highlights include enhanced version transparency, the introduction of the new Inventory as a central management hub for devices, expanded command and application management features, and significant updates to the XOAP Connector.

General

Version descriptions

We added version descriptions to all version drop-downs for better identification specific version changes.

Inventory

Our new Inventory is the new home for all Devices registered with an XOAP Connector. It enables running operational tasks from a central management interface, independent of the location your Devices are located.

Commands Library

You can store commands for later use and edit them the same way we support editing resources, including versioning, access to previous versions and download of the commands.

Running a saved command:

Application Management

PSADT v4 Support

We added support for the latest PSADT v4 packages. You can now upload and deploy your v4 packages in the same way as you did with v3.

Extended support for BYO PSADT packages (v3 and v4)

As XOAP is using some custom functions to identify correct installation on nodes with PSADT script extensions, we are now adding those extensions automatically during PSADT upload. The same applies to some of the parameters we are using for extended functionality.

This enables customers to upload almost all of their previously created PSADT v3 and v4 packages without prior adjustments, as long as they comply with the PSADT standards.

Extension scripts

We are adding two functions as extensions during application upload:

Post-installation

Register-Installation

Writes the application parameters into the registry (SOFTWARE/PSADT) to identify applications that were installed.

Post-uninstallation

UnRegister-Installation

Adds specific registry information to the packages which gives XOAP the opportunity to identify if the package was uninstalled.

Adding parameters

We are using some special parameters for additional functionality inside of XOAP. Therefore we are adding some specific parameters to the installation scripts during upload, if they are not present inside the packages:

PackageType = ‘Application’

TargetOS = ‘Any’

PackageName = ‘APP_IgorPavlov_7ZipZS_2501_Any_x86_EN’

The PackageName parameter is dynamically created based on the application parameters inside the package.

The currently available XOAP PSADT Package Wizard is not supporting v4 packages and we are not planning to implement it there.

Group details page

Added additional information in Group details page: Deploy Type and Deploy mode.

Connections

We added a test connection capability for Azure, AWS and Google which makes verification of added connections an easy step.

XOAP Connector

Automatic Connector update during installation

We added a switch to the installation of the Connector, which automatically fetches the latest version from our GitHub repository located at: https://github.com/xoap-io/xoap-connector.

Installation sources and command line parameters

We added more information regarding the direct installation of the XOAP Connector from GitHub.

XOAP Connector command line parameters

This is a list of currently available command line parameters:

Mandatory

-i (–install), installs the Connector

-a (–apiKey), specifies the APIKey to connect to the XOAP Workspace

-w (–workspace), specifies the XOAP Workspace ID, the Connector should connect to

Optional

-m (–imageManagement), additionally installs packer on Windows and supported Linux distributions

-u (–update), fetches the latest available Connector binaries from GitHub

-p (–path), default value “C:Program FilesXOAPConnector”, “/opt/XOAP/Connector” on Linux and Mac

-?,  Shows available parameters

Preview of Linux Agent

List of tested distributions:

• Ubuntu 24.04, 22.04
• Rocky 10 Linux
• Alma Linux
• Fedora 43 Linux

The post 2025 November updates appeared first on XOAP.

Get a list of all applications installed on your nodes

The following GraphQL query returns a list of all applications installed across all nodes (systems) in your environment:

query NodesWithSoftware($skip: Int = 0, $take: Int = 500) {
  configMngt_Nodes(skip: $skip, take: $take) {
    totalCount
    pageInfo { hasNextPage }
    items {
      id
      nodeName
      lastSystem {
        software {
          displayName
          displayVersion
          publisher
        }
      }
    }
  }}

Notes:
• If you are managing more than 500 nodes, increase the value of $take accordingly.
• Pagination is supported using skip and hasNextPage.

Get a list of all applications available in XOAP’s Application Management module

This is useful for reporting, validation, or automation tasks involving application definitions. You can use the following GraphQL query for this:

query ListAllApplications($skip: Int = 0, $take: Int = 100) {
  appMngt_Applications(skip: $skip, take: $take) {
    totalCount
    pageInfo { hasNextPage }
    items {
      id
      name
      vendor
      version
      packageName
      operatingSystem
      architecture
      language
      createdAt
      updatedAt
    }
  }
}

This query also returns the metadata for all applications, including details like vendor, version, target OS, and architecture.

Notes:
• You can increase the $take value if more than 100 applications are expected.
• Use the hasNextPage field to implement pagination if needed.

Get a list of all systems from a specific hardware manufacturer

This query allows you to retrieve all nodes from a specific manufacturer (e.g., Lenovo) registered within your XOAP workspace.

This can be useful for inventory audits, hardware lifecycle management, or vendor-specific patching and compliance activities. Use the following GraphQL query:

query LenovoFlatNodes($skip: Int = 0, $take: Int = 5) {
  configMngt_FlatNodes(
    skip: $skip
    take: $take
    where: { csManufacturer: { eq: "LENOVO" } }
    order: [{ nodeName: ASC }]
  ) {
    totalCount
    pageInfo { hasNextPage }
    items {
      id
      nodeName
      csManufacturer
      csModel
      osName
      osVersion
    }
  }
}

Notes:
• Manufacturer Name is case-sensitive.
• To filter for a different vendor (e.g., HP, DELL), change the value of csManufacturer: { eq: "..." } accordingly.
• Increase the $take value to retrieve more records or implement pagination using the hasNextPage field.
• This example sorts results by nodeName in ascending order.

How to know what you can query

XOAP collects a vast amount of data from your nodes, along with additional metadata from your workspace. With such a large data set, it can be difficult to determine which fields are available for querying.

The most effective way to explore available query options is by reviewing the SDL (Schema Definition Language). The SDL provides a complete overview of all objects, fields, and types that can be queried via GraphQL.

By inspecting the SDL, you can:

• Discover all available data structures
• Identify relationships between entities
• Understand the full potential of GraphQL queries within XOAP

This approach ensures you’re not limited by predefined queries and can fully leverage the data collected in your environment.

Need more queries or want to add your own?

The github.com/xoap-io/queries repository is your go‑to collection of reusable GraphQL queries tailored for hardware and application management within XOAP and related platforms.

How to use it:

1. Navigate to the applications/ or hardware/ folders.
2. Copy the relevant .graphql file into your API or GraphQL client.
3. Adjust parameters as needed to fit your environment.

Under the MIT License and with zero stars or forks so far, this project is still blossoming. We highly welcome your contributions—whether it’s by submitting issues, enhancing queries, or opening pull requests to enrich this shared resource. Let’s grow together!

The post What you can do with GraphQL appeared first on XOAP.

Once you have enabled the Connector by connecting your on-premises environment with XOAP and adding an operating system (see First steps for detailed instructions), you can create a machine image for vSphere or Nutanix. To do that, follow the steps below.

Create Builder Configuration

Builder Configuration creates machine images for a specific platform by launching temporary resources, provisioning them and producing the final image artifact. Builder Configurations are specific to each environment type.

To create a Builder Configuration:

1. In your XOAP Workspace, go to Image Management → Builder Configurations.

2. Click New Builder Configuration and select either vSphere or Nutanix builder from the drop-down menu.

3. Fill in General Details and click Add.

Image Definition

Now, you will create the Image Definition and run it in your environment.

1. In Image Management → Image definition table, click New Image.

2. Provide the Image Definition Name and select the desired Builder provider type.

3. Select the created Builder Configuration, Connector, Operating System and Provisioner Role.

4. When everything is selected, click Save.

Run the image definition by clicking Run from the action menu. This will create the image in your environment.

The post Creating an image appeared first on XOAP.

XOAP Connector is an agent designed for secure system automation. The Connector enables centralized management of distributed systems and simplifies the operation of hybrid IT infrastructures.

It runs on Windows, macOS and Linux, and connects directly to your XOAP backend. Currently, supported on-premises environments include vSphere and Nutanix.

Below, you will find the initial steps to get started with the Connector.

Add Connection

The Connections area in your XOAP Workspace is where you define credentials to link your on-premises environment with the XOAP platform.

To create a new connection:

1. Go to Connections and click New Connection.

2. Select one of the on-premises environments and fill in the required fields.

3. Click Confirm to save the connection.

Add API key

Adding an API key to your XOAP environment enables a secure connection between XOAP and your Connector device.

To create a new API key:

1. In your XOAP workspace, go to Connections and click New Connection.

2. Select API Key as the connection type.

3. Provide a Connection Name and select the API Token Type called “XOAP Connector”.

4. Click Confirm to create a new API key.

You can now copy the key to the clipboard, as you will need it in the next step.

Connect your device

To run images in your on-premises environment, you need to install the XOAP Connector on a machine that has access to your on-premises infrastructure.

1. In Application Management, go to Application Groups.

2. Find the group XOAP Connector – Base Group and open Details.

3. On the Details page, under Assigned applications, click the Connector application eye icon to view details.

4. Set the apiKey and workspace values and click Update to save the new values to the application group.

5. Now, go to Configuration Management → Configuration Groups.

6. Find the XOAP Connector group, click the action menu and select Copy registration command.

7. Run this command on your device in a PowerShell administrator session.

Once complete, your device will appear under Inventory → Devices in the left-side menu in your XOAP Workspace.

Add operating system

In the XOAP workspace, Operating Systems is where you define the OS that will serve as the base for deploying your image. For cloud providers, all Marketplace images are available directly in XOAP and you can simply select the one that best fits your needs. For on-premises environments, you must provide the path to the ISO.

To add a new operating system:

1. Go to Image Management → Operating Systems and click New Operating System.

2. In the New Operating System window, select the On-premises type and fill in the required fields.

3. Click Save to add the new operating system.

If you are missing Setup Files like autonunattend.xml or hypervisor-specific adjustments, upload them to the Resources area, take a look at our GitHub repository or contact us for examples.

Next: Creating an image

Once your environment, API key, device and operating system are configured, you can create your first machine image. For detailed instructions, you can find the documentation here.

The post First steps appeared first on XOAP.

This release introduces a wide range of improvements across the XOAP platform, focusing on security, usability, performance, and hybrid deployment scenarios. From refined dashboards and inline help to deeper on-premises support and enhanced automation workflows – XOAP is now more powerful and easier to use than ever.

my.dev.xoap.io

Enhanced login and workspace access experience with MFA and adjusted password requirements.

MFA

Introduced Multi-Factor Authentication (MFA) to improve account security.

Adjusted password requirements

Adjusted and strengthened password policies to meet current security best practices. We re-adjusted the password requirements. Passwords now have a minimum length of 8 characters (instead of 12) and there is no need for special characters anymore.

General

• Performance optimizations across all modules for faster load times and smoother user experience
• Fixed sorting issues in data tables to ensure consistent and accurate ordering

Notifications area

The notifications area has been redesigned, including a new Notifications overview.

New Tasks and Processes overview providing better visibility into running and completed operations.

API & GraphQL

Swagger documentation is now available here:

• Swagger UI
• API Access

GraphQL Endpoints now include a full explorer and documentation:

• GraphQL UI
• GraphQL documentation

Inline help

Inline help has been added throughout the platform to assist users directly where they work.

Dashboard

We introduced a new main dashboard providing more insights and data visibility.

Old module dashboards have been removed to streamline navigation and focus on the new unified view.

Activity Log

We reduced the number of logged items for improved usability, making it easier to focus on important events.

Application Management

Roles details

We added the Roles details view and new options for Continue on Error and Reboot after installation.

Installation package caching on Nodes

Installation package caching on Nodes – packages are now cached and only updated on version changes, significantly reducing data transfer.

New Baseline Module 0.19.0

Released Baseline Module v0.19.0 for specific security-related scenarios where applications couldn’t be installed because of specific PowerShell execution policy settings.

View the application deployment script

You can now view application deployment scripts directly inside your workspace.

Image Management

Added On-Premises support for vSphere and Nutanix.

Image Definitions

Enhanced Image Definitions capabilities to support the new on-premises hypervisors.

Builders

New Builders for vSphere and Nutanix.

vSphere

Nutanix

Operating systems

Expanded Operating Systems support to support adding local ISO images from Nutanix and vSphere clusters.

Schedules

Added Schedules for automated image operations.

Inventory

Our new Inventory is the new home for all Devices registered with an XOAP Connector. It enables running operational tasks from a central management interface, independent of the location your Devices are located.

Devices

Improved Devices management with the capabilities to run:

• PowerShell, PowerShell Core, Cmd, Bash and Shell scripts or commands
• SQL queries against registered Devices
• Application installations based on Roles and Groups from Application Management
• File transfers to and from Devices

Queries

You can store queries for later use and edit them the same way we support editing resources, including versioning, access to previous versions and download of the queries.

Scripted Actions

Schedules

Introduced Schedules for automating scripted executions. Now configurable directly inside the Scripted Actions details.

Connections

On-premises support added for vSphere and Nutanix environments.

Added enhanced API Key management, enabling secure integrations and automation.

The post 2025 September updates appeared first on XOAP.