This release focuses on expanding platform connectivity, strengthening the XOAP Connector lifecycle, and advancing configuration management and image workflows. Key highlights include Azure Managed Identity support for image builds, connector log streaming, a redesigned getting started experience, new pricing and bundle management, and significant backend refactoring for scalability.

Configuration Management

The configuration wizard has been refactored for improved usability and maintainability. Work is ongoing on styling, resource form handling, and navigation confirmation dialogs to deliver a more consistent experience.

A new search functionality has been added to the resource list within Configuration Management, making it easier to locate specific resources in larger environments.

Compilation statuses are now surfaced directly in configuration views, and the save dialog has been updated to reflect current state more clearly.

Configuration version assignment has been re-implemented, resolving issues with downloading specific configuration versions.

Custom version support has also been added to the configuration wizard.

Bug fixes:

• Fixed password field appearing in clear text in configuration forms
• Fixed failed installations not being recorded in compliance history
• Resolved configuration group performance issues

Connections

Azure Managed Identity Connection

A new Azure connection selector has been added, supporting Managed Identities, Service Providers and Application Registrations. This complements the Azure image build improvements and eliminates the need for Public IPs on provisioned VMs.

By specifying the Application Registration, you can run a Scripted Action against a connection using Microsoft Graph API scripts. No Azure subscription is needed here. Please note: This connection type does not support image management.

The Connections slide-out has been redesigned to include the Connector selector directly, streamlining the setup flow.

Bug fixes:

• Fixed frontend issues following API changes when creating and editing connections
• Adjusted run statuses to align with updated backend response format

Image Management

Azure Image Build support

The XOAP Connector now supports Azure image builds with Managed Identities, enabling full cloud-based image workflows. The connector uses an Azure Managed Identity within the subscription to create required resources and communicate securely with the XOAP backend, removing the requirement for Public IPs.

Operating system deprecation status

A deprecation status for Operating Systems has been implemented, providing clearer lifecycle visibility across image and provisioning workflows.

Details view with deprecation status, date and days left.

Bug fixes:

• Fixed graphQL query adjustment for image definitions in image management.
• Fixed OS details table alignment and layout issues
• Fixed OS autounattend version refresh behavior when files change

Connector

Log streaming

The XOAP Connector now supports real-time log streaming, providing immediate visibility into connector activity without requiring manual log retrieval.

Connector re-packaging

XOAP Connector packages inside the Workspaces and requirements have been re-packaged using PSADT 4.1.8, improving deployment reliability and compatibility.

Scripted Actions on Connector

Scripted actions can now be executed directly on the connector, extending automation capabilities at the connector level.

Installation Tasks & Agent Log Cleaner

Connector installation tasks have been refined, and an agent log cleaner job has been implemented to manage log retention and reduce disk usage automatically.

Bug Fixes:
• Fixed Scripted Action logs for Connector scripts in Platform Management
• Resolved active runs showing incorrect status (failed) in inventory

Inventory

PowerShell 7 support

The Inventory module has been updated to support PowerShell 7 (previously limited to PowerShell Core 5.1), aligning with current platform requirements.

Getting Started

A new central Getting Started area has been implemented in the platform shell, providing a guided onboarding experience for new users. The landing page has been redesigned and an initial layout has been defined with example flows to help users get up and running faster.

Getting Started guide for cloud images

Documentation

Documentation slide-outs

In-app documentation has been extended across additional areas. Documentation is structured into:
• Quick guide — for fast, task-oriented help
• Technical documentation — for deeper, implementation-focused guidance

The post 2026 March updates appeared first on XOAP.

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

1. 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 

2. 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 

2.1 Install XOAP Connector 

For on-premises scenarios XOAP uses a Connector that runs inside the target environment. 

Key requirements for the Connector to work with our backend: 

• Outbound‑only communication to XOAP (api.xoap.io) via 443 
• No inbound firewall rules required 
• For Windows systems, please run PowerShell as an Administrator. 
• For Linux systems, please execute the commands with sudo to ensure proper permissions. 

The Connector can be installed on Windows and Linux devices. The process can be started by clicking on “+  Add Device” button in the Inventory area of your XOAP Workspace. 

1. Download the correct installer to the device that has network access to your vCenter.  
2. Create a new API key by selecting + Create API key (or select existing). Under API token type select XOAP Connector 
3. On the device, navigate to the location where the installer was downloaded and run the command with the added flag –imageManagement  

Example:  .\XOAP.Connector.Installer.exe –install –apiKey PLEASE_SELECT_API_KEY –workspace YOUR_WORKSPACE_ID –imageManagement

2.2 Verify Registration 

Please note that following these steps will temporarily navigate you away from the Get Started module, but you can return at any time to pick up where you left off

After installing the XOAP Connector, you need to verify that it is successfully communicating with the XOAP platform.

Steps to verify: 

1. In the left-hand navigation menu, expand the Inventory module and click on Devices. 
2. Locate the machine where you installed the Connector by looking for its hostname in the Device Name column. 
3. Check the Is Online column next to your device. The status should display as Connected, confirming that the Connector is successfully installed and communicating with the platform. (Note: If it shows “Disconnected”, ensure the machine is powered on, has internet access, and the XOAP service is running). 

3. Add a Connection 

XOAP Connections store the credentials and endpoints XOAP needs to integrate with external systems (for example, cloud providers and on-prem virtualization platforms). These connections are then used by other XOAP features. 

Add connection Cloud-specific 

Nutanix

Fields you provide: 

  •   Connection name – Friendly name used in XOAP to reference this connection. 
  •   Connector - The device where the XOAP Connector is installed, acting as a bridge between the XOAP platform        and your environment. 
  •   Nutanix Username – The account XOAP uses to authenticate to Nutanix (typically Prism). 
  •   Nutanix Password - The password for the Nutanix account. 
  •   Endpoint – The Prism endpoint (hostname/IP + port if applicable) that XOAP connects to.  
  •   Cluster name - The Nutanix cluster identifier/name within Prism where operations will be performed.  
  •   Insecure (toggle) – Allows connecting without strict TLS validation (use only when required in lab/PoC scenarios). 
  •   Description (optional)  - Free-text note to document purpose/owner of the connection. 
  •   Tags (optional) - Labels to help you find, filter, and govern connections (max 5 per object).  

vCenter

Fields you provide: 

  •   Connection name – Friendly name used in XOAP to reference this connection. 
  •   Connector - The device where the XOAP Connector is installed, acting as a bridge between the XOAP platform and your environment. 
  •   vCenter Server – The vCenter hostname or IP address XOAP will connect to.  
  •   Username - The vCenter user (or SSO identity) used for authentication.  
  •   Password – The password for the specified vCenter user.   
  •   Datacenter - The vSphere Datacenter inventory object that contains the clusters/hosts/datastores you want to target.   
  •   Cluster – The vSphere cluster under the selected datacenter that groups hosts and provides shared resource management (DRS/HA if enabled).
  •   Host – A specific ESXi host to target (often used when selecting an exact host instead of scheduling via cluster/rules). 
  •   Resource pool – The resource pool within the cluster/host that defines CPU/RAM shares/limits/reservations for deployed VMs.  
  •   Datastore - The storage location where VM files (VMDKs/config) will be placed. 
  •   Folder - The vCenter VM folder used to organize where the VM object appears in the inventory.   
  •   Insecure (toggle) - Allows connecting without strict TLS validation (use only when required in lab/PoC scenarios). 
  •   Description (optional)  - Free-text note to document purpose/owner of the connection. 
  •   Tags (optional) - Labels to help you find, filter, and govern connections (max 5 per object).  

Important behavior: 

• Case-sensitive fields: vCenter inventory object names (Datacenter/Cluster/Host/Resource pool/Datastore/Folder) are case sensitive. Enter them exactly as defined in vCenter. 

XenServer

We're getting this ready for you

4. Add Operating Systems 

In XOAP, the Operating System represents the base image that will be used as the foundation for your custom virtual machine image.  
On-premises operating systems are generic for all types of on-premises hypervisors. 

Examples: 

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

You can add a New Operating System by clicking “+  Add Base Image” in right upper corner. 

When adding an On-Premises Operating System in XOAP you define: 

• Name – Name of your Operating System. You can define the name by your own naming convention 
• ISO File Name – provide the name of your ISO file which will be used as base Operating System for your Image Definition Example: SERVER_EVAL_x64FRE_en-us.iso 
• ISO Path – full location to the your ISO file Example: [datastore01] ISO/ 
• ISO Checksum – checksum of your ISO as additional security feature 

OS specific

For Windows 

  •   Autounattend – file which is used to modify windows settings during Setup. This file must be uploaded to XOAP resource area. You can select one from pre-uploaded autoanattend.xml files if they fit you 
  •   Setup Files - defines which extra files XOAP mounts into the virtual machine during operating system installation.

For Linux 

We're getting this ready for you

Important: 

• Use Get-FileHash in PowerShell to generate the checksum for the ISO file: Get-FileHash -Path “\fileserver\isos\Windows11_24H2.iso” -Algorithm SHA256. Copy the returned Hash value into the ISO Checksum field in XOAP. 
• Setup files files are typically used by the unattend.xml to install drivers, tools, or to run custom PowerShell scripts during or immediately after the first boot. For this use case, we provide some template files like:
  • windows-init.ps1 – Enables Windows Remote Management on Windows builds. Needed to sucesfully finish creation of template VM on your vCenter 

5. Add Builder Configuration 

The Builder Configuration defines where and how an image is created, based on the selected platform or cloud provider (for example, AWS, Azure, Google Cloud, or VMware). During builder configuration, you also choose the Connection used for your cloud or on-premises environment. 

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. 

To create new builder click on “+ Builder Configuration” and select wanted hypervisor .

Add a builder configuration Cloud specific

Nutanix

General Details: 

  •   Name – Friendly name used in XOAP to reference this builder configuration.  
  •   Select Type - The target platform for the builder (set to Nutanix in this context). 
  •   OS Type – The operating system type of the virtual machine being built.  
  •   Connection - The pre-configured Nutanix connection XOAP uses to authenticate and interact with your Nutanix cluster.  
  •   Subnet name – The name of the Nutanix network/subnet the virtual machine will connect to during the build process. 
  •   Description (optional) - Free-text note to document the purpose, owner, or specifics of this builder configuration.  
  •   Tags (optional) - Labels to help you find, filter, and govern builder configurations.   

Environment Configuration: 

  •   CPU – The number of virtual CPUs allocated to the virtual machine during the build.   
  •   Memory GB - The amount of memory allocated to the virtual machine, specified in gigabytes.  
  •   CD-files – A list of files to be uploaded and attached to the virtual machine as a CD-ROM. You can separate multiple files by pressing enter or using a comma.   
  •   Boot type - The firmware boot configuration used for the virtual machine (e.g., legacy or uefi). 
  •   Boot priority – The boot device order/priority (e.g., setting it to boot from CD-ROM first, then disk). 
  •   Disk size (GB) - The total capacity of the primary virtual hard disk to be created, specified in gigabytes. 
  •   GPU - Optional GPU configuration to attach a virtual graphics processing unit (vGPU) to the VM during the build. 

Output Configuration / All OS

  •   Image export (toggle) – When enabled, exports the resulting built virtual machine into a finalized Nutanix image.    
  •   Disable sysprep at the end (toggle) - When enabled, skips the standard Sysprep (System Preparation) process at the end of a Windows build. Use this only if you are handling generalization via custom scripts. 
  •   Shutdown command  – The specific command used to gracefully shut down the guest operating system once provisioning is complete.   
  •   Shutdown timeout  - The maximum amount of time to wait for the virtual machine to shut down gracefully before forcing a power off or failing the build.   

vSphere

Fields you provide:

General Details

  •   Name – Friendly name used in XOAP to reference this builder configuration.     
  •   Select Type - The target platform for the builder (set to vSphere in this context).  
  •   Connection – The pre-configured vSphere connection XOAP uses to authenticate and interact with your vCenter/ESXi environment.    
  •   Disk size (GB) - The total capacity of the primary virtual hard disk to be created, specified in gigabytes.   
  •   HW Version – The VMware hardware version for the virtual machine (e.g., 19, 20).     
  •   Guest OS Type - The VMware internal ID for the guest operating system (e.g., windows9Server64Guest, ubuntu64Guest). This ensures vSphere applies the correct default optimizations for the OS.  
  •   Network – The vSphere network or port group the virtual machine will connect to during the build process.     
  •   Network card - The type of virtual network adapter to attach to the VM (e.g., vmxnet3, e1000). 
  •   Export to Content library destination (toggle) – When enabled, exports the resulting built artifact directly into a specified vSphere Content Library. 
  •   Convert to template (toggle) - TWhen enabled, automatically converts the built virtual machine into a VMware template once the provisioning is complete. 
  •   Tags (optional) – Labels to help you find, filter, and govern builder configurations. 
  •   Description (optional) - Free-text note to document the purpose, owner, or specifics of this builder configuration.  
  •   Firmware - The firmware type used to boot the virtual machine (e.g., bios or efi). 
  •   CPUs – The number of virtual CPU cores allocated to the virtual machine during the build. 
  •   RAM (GB) - The amount of memory allocated to the virtual machine, specified in gigabytes.
  •   CD-ROM type – The virtual controller type used for the CD-ROM drive (e.g., sata, ide). 
  •   Disk controller type - The type of storage controller to use for the virtual disk (e.g., pvscsi, lsilogic, sata). 
  •   Disk thin provisioned (toggle) - When enabled, the virtual disk will be thin-provisioned, meaning it only consumes physical storage space as data is actually written to it. 
  •   Storage – The target vSphere datastore or datastore cluster where the virtual machine files and disks will be stored. 

Flag Configuration:

  •   VBS enabled (toggle) – Enables Virtualization-Based Security (VBS) on the virtual machine. Note: This typically requires EFI firmware, Secure Boot, and specific hardware versions.      
  •   VVTD enabled (toggle) - Enables VMware Virtual I/O Technology (Intel VT-d) on the virtual machine, allowing direct access to hardware devices.   

Content Library Configuration - (These fields appear when "Export to Content library destination" is enabled) 

  •   Library – The name of the target vSphere Content Library where the finalized image or template will be stored. 
  •   Cluster - The ESXi cluster associated with the Content Library export or where the temporary staging occurs.  
  •   Folder – The vCenter virtual machine folder where the temporary VM is placed during the build and export process. 
  •   Datastore - The specific vSphere datastore used for staging the export files or backing the Content Library item.
  •   Destroy (toggle) - When enabled, automatically deletes the original built virtual machine from your vCenter inventory after it has been successfully exported to the Content Library. 
  •   OVF (toggle) – When enabled, exports the artifact as an OVF (Open Virtualization Format) package. If disabled, it typically exports as an OVA (single-file) format. 
  •   Skip import (toggle) - When enabled, the build process runs but skips the final step of actually importing the artifact into the Content Library. This is primarily used for testing or debugging the build process without uploading the final image. 

XenServer

We're getting this ready for you

6. 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. 

You will have at least 2 Provisoner Roles in your workspace. One ready for Windows devices and 2nd for linux.

To create and run New Image Definition click on button in right upper corner “+ New Image Definition” and fill next form:

• Assign a name and description to the image definition 
• [optional] Select tags for categorization or filtering 
• Choose the builder provider and specific builder configuration 
• [optional] Pick a base operating system image 
• Link the appropriate provisioner role (which includes all scripts, tasks, and configurations) 
• Define a XOAP Connector device for on-premises Image definitions 
• [optional] Schedule Image Definition Run 

You can save Image definition and run it later from Image Definition area under Image Management module, or click Save & Run  to run it during creation. 

Each run results in a new, versioned image artifact. 

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

Each run results in a new, versioned image artifact. 

6.1 Verify the Created Image  

After a successful build: 

• Validate the image 
• Confirm naming and version metadata 

XOAP keeps a record of: 

• Logs 
• Resulting image IDs 

Validate Image Definition

Nutanix

To confirm your image was successfully created and finalized in your Nutanix environment (especially if you enabled the Image export toggle), you will need to check the Prism web console: 

Checking the Nutanix Image Service: 

  •   Log in to your Nutanix Prism console (Prism Element or Prism Central, depending on your target connection). 
  •  Navigate to the Images dashboard: 
     In Prism Central: Go to the hamburger menu > Compute & Storage > Images. 
     In Prism Element: Click the gear icon (Settings) and select Image Configuration, or use the main drop-down menu to go to Virtual Infrastructure > Images. 
  •  Search the list for the name you specified in your XOAP image definition. 
  •  Verify that the image state is active/active and that its type matches what you expect (e.g., Disk Image), making it ready for deploying new virtual machines. 

vSphere

After a successful build, you can verify the creation of your image or template directly within your VMware vCenter environment. The location depends on the specific settings you chose in the vSphere Builder Configuration: 

If exported to a Content Library: 

  •  Log in to your vSphere Client. 
  •  Navigate to the main menu and select Content Libraries. 
  •  Click on the specific Library you selected in your XOAP configuration. 
  •  Browse the OVF & OVA Templates tab to find your newly exported image. 

If converted to a standard vSphere Template: 

  •  Log in to your vSphere Client. 
  •  Navigate to the VMs and Templates inventory view. 
  •  Expand your vCenter tree to locate the specific Datacenter and Folder where the build took place. 
  •  Look for the name you assigned to the image. It should have the standard vSphere template icon (a virtual machine icon with a small paper symbol). 

XenServer

We're getting this ready for you

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. 

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 

Next steps

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

Add Your Own Scripts, Applications and Configurations 

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

Check our repo at https://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.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.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.