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.

Pour 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 Inventaire module and click on Dispositifs. 
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 Connexions 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. 

Exemples : 

• 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: 

• Nom – 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.  
  •   Sélectionner le 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

  •   Nom – Friendly name used in XOAP to reference this builder configuration.     
  •   Sélectionner le 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) 

  •   Bibliothèque – 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: 

• Plate-forme 
• 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.

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 Connexions, then clicking the Add new connection button in the upper-right corner.

In the slide-out panel, select the connection Type et Provider. Fill in the remaining required information and click Confirmer 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 Actions scénarisées, 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 ici.

L'azur

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

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 Créer
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 ici.

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 et AWS CLI scripts. The only prerequisite for using your own automation is that the script file must be uploaded to the Ressources 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:

• Naviguez jusqu'à Connexions (in the main menu)
• Cliquez sur + New connection
• Select your provider (Azure, AWS, Google, or other) and follow the authentication prompts

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

The post Prerequisites appeared first on XOAP.

Welcome to XOAP! This guide will help you set up your account, create your first Workspace and manage your subscription if you need more features.

Create a free account

• Go to the registration page and fill in your details (no credit card required to start).
• Cliquez sur Create an account.
• Check your email inbox and verify your email address to activate your free Workspace.

Please open the link in the same browser you used to create your account.

• You’ll briefly see a loading screen.
• Then, click Go to Workspace to access your new Workspace. Alternatively, click Back to Dashboard to manage other settings.

Subscribe for unlimited features (optional)

Want more features or extended capacity? Upgrade your plan anytime.

• If you’re currently in your Workspace, click Back to my.XOAP.io in the lower left corner. If not, proceed to the next step.
• From the Workspace Overview, click your Workspace name.
• Cliquez sur Upgrade Plan.
• Select the modules you need and adjust the number of units based on your usage.
• Cliquez sur Suivant to continue.
• Enter (or update) your payment method and billing details.
• Cliquez sur Suivant to continue.
• Review your plan and confirm by clicking Upgrade free plan Workspace.
• Your Workspace status will now show as Active with upgraded access.

We offer tailored deals for MSPs, as well as public sector and education organizations. Contactez nous ici for a custom quote.

The post Create an account appeared first on XOAP.

Need to work with others? You can easily invite teammates to your Workspace. If you’re running multiple projects or teams, you can also create extra Workspaces.

Invite users to your Workspace

• If you’re currently in your Workspace, click Back to my.XOAP.io in the lower left corner. If not, proceed to the next step.
• Click on the name of your Workspace.
• Go to the Utilisateurs tab.
• Cliquez sur Add user.
• Assign the user to specific modules or to all modules. Optionally, you can grant admin rights.
• Cliquez sur Send invite.

New users will receive an email to register and join the Workspace.

Existing users will get a link to access the Workspace directly.

Add an additional Workspace

Need a separate space for another project or team? You can create extra Workspaces – just note this is a paid feature.

• If you’re currently in your Workspace, click Back to my.XOAP.io in the lower left corner. If not, proceed to the next step.
• On the Workspaces page, click Add Workspace.
• Give your new Workspace a name.
• Select the modules you want to include, then click Suivant.
• Enter your payment and billing information, then click Suivant.
• Review your setup and click Confirmer.
• Once created, you can access your new Workspace using its Workspace URL.

The post Invite team members appeared first on XOAP.

Connecting your cloud infrastructure is the first step to building automations in XOAP. This guide covers how to add a new connection to AWS, Azure or Google Cloud.

If you want to use XOAP only to deliver configurations or install applications on your systems, this step is not mandatory. You can manage your on-prem or cloud systems even without connecting XOAP to your cloud infrastructure.

How to add a Connection

• Go to the Connexions.
• Click the + Nouvelle connexion button in the top-right corner.
• You can select from the following available connection types: AWS, Azure, Google Cloud (more details below).
• Select your chosen provider and configure other necessary settings accordingly.
• When you’re done, click Confirmer.

Supported cloud providers

AWS

You can choose from three connection types:

• AWS – Access Key
• AWS – Assume Role
• AWS – Assume Role (Cross-Account)

All AWS connection details are securely stored in a vault tied to your Workspace.

Learn more about setting up AWS – Access Key permissions:

• Managing access keys for IAM users
• Introduction to AWS IAM
• IAM tutorial: Delegate access across AWS accounts using IAM roles
• IAM identifiers and ARN format

Learn more about AWS – Assume Role permissions:

• STS API Reference: AssumeRole

Learn more about AWS – Assume Role (Cross-Account) with External ID:

• How to use External ID when granting access to your AWS resources (AWS Security Blog)
• IAM Trust Policies: Using conditions with sts: ExternalId

Microsoft Azure

XOAP supports connecting to Azure using Service Principals, providing secure access to your Azure subscriptions. To set this up, the following information is required: 

• Nom: a custom name for the connection as it will appear in your application (e.g., XOAP-Azure-Prod).
• Client ID: the Application (client) ID of your Azure AD application (also known as a Service Principal).
• Client Secret: the client secret you create under the “Certificates & secrets” section in the App Registration. Note that the value is shown only once at the time of creation.
• Subscription ID: a unique GUID representing the Azure subscription where your resources are located.
• Tenant ID: the Directory (tenant) ID of your Azure Active Directory instance.

As with AWS, all Azure credentials are stored securely in your Workspace vault.

Pour detailed guidance on configuring your XOAP connection and retrieving the necessary information, please refer to the following resources:

• Register an application in Microsoft Entra ID
• Register a Microsoft Entra app & create a client secret
• Subscription & Tenant ID

Google Cloud

To connect XOAP to Google Cloud, you need a Service Account with sufficient permissions and a downloaded JSON key file.

• Nom: a custom name for identifying the connection (e.g., XOAP-GCP-Prod).
• Project ID: the unique identifier of your Google Cloud project.
• File: the Service Account JSON key file that contains authentication credentials.

Make sure the service account has the required roles (e.g., Viewer, Editor, or a custom role depending on your needs).

As with AWS and Azure, all Google credentials are stored securely in your Workspace vault.

Pour more information on configuring your XOAP connection and retrieving the required details, please refer to the following links:

• Find your Project ID
• How to generate the Service Account JSON key file

The post Connect your infrastructure appeared first on XOAP.

Quickly learn how to connect your managed system to XOAP. It only takes a few clicks.

Locate the XOAP unassigned configuration group and from the action menu select Copy registration command ou Download registration script.

Remarque : Both do the same and can be integrated into any existing delivery process (GPO, deployment solution, image build and more).

To connect the system manually and test the connection, go to your target system, open PowerShell as Administrator, paste the command and run it.

Once completed, your machine will appear under the Nœuds section. Click on Details to view system information.

Remarque : This action (XOAP_unassigned) does not change anything in your system, it only connects it to XOAP.

The post Connect your managed system appeared first on XOAP.