Overview

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

What Are Standardized on-premises OS Images? 

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

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

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

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

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

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

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

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

High‑Level Architecture – How It Works 

At a high level, the process looks like this: 

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

Key design principles: 

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

Short Overview of the End‑to‑End Flow 

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

Prerequisites

Before you start, ensure the following prerequisites are met: 

General

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

Cloud‑Specific 

vSphere  

Required privileges at vCenter level (minimum set): 

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

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

Nutanix 

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

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

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

XenServer

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

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

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

Connector Deployment Flow 

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

Create an API Key 

Text

Note your Workspace ID 

Text

Install Connector on Windows 

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

Install Connector on Linux 

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

Verify Registration 

Text

Add a Connection 

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

Steps:

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

Add connection Cloud-specific 

Nutanix

Text

vSphere

Text

XenServer

Text

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

Add Operating Systems 

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

Examples: 

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

Add Builder Configuration 

Builders define how an image is created. 

A Builder configuration typically includes: 

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

Builders abstract provider differences while keeping builds transparent and auditable. 

Add a builder configuration Cloud specific

Nutanix

Text

vSphere

Text

XenServer

Text

Add Image Definition 

An Image Definition ties everything together. 

It references: 

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

Run Image Definition 

Once defined, you can start an image build: 

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

Each run results in a new, versioned image artifact. 

Summary 

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

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

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

Next steps

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

Troubleshooting 

If a build fails: 

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

Most issues are related to: 

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

Add Your Own Scripts, Applications and Configurations 

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

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

Reuse existing Roles in the cloud 

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

Build Higher‑Level Automation 

• Application packaging 
• Stacks and roles 
• Continuous image updates 

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

Image Management

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

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

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

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

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

AWS

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

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

#Codeblock

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

#EndOfCodeblock

Read more about the required permissions here.

Azure

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

Command format

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

Command example

#Codeblock

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

#EndOfCodeblock

Command output

#Codeblock

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

#EndOfCodeblock

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

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

Read more about the required permissions here.

Google

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

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

Required IAM Roles for Packer to build Images

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

Read more about the required permissions here.

vSphere

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

Required privileges

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

Configuration Management

PowerShell

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

Remote management

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

Communication with our backend

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

Proxy configuration for nodes

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

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

You should find the file in these locations:

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

Firewalls

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

DEP

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

TLS

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

Set it via PowerShell:

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

Application Management

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

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

• Applications
• Application Groups
• Application Roles

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

Creating packages

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

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

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

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

Platform Management

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

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

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

This means you can start automating immediately using existing templates.

Supported formats

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

Establishing connections

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

You can easily set this up from your XOAP workspace:

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

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

The post Prerequisites appeared first on XOAP.

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).
• Click 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.
• Click Upgrade Plan.
• Select the modules you need and adjust the number of units based on your usage.
• Click Next to continue.
• Enter (or update) your payment method and billing details.
• Click Next 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. Contact us here 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 Users tab.
• Click Add user.
• Assign the user to specific modules or to all modules. Optionally, you can grant admin rights.
• Click 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 Next.
• Enter your payment and billing information, then click Next.
• Review your setup and click Confirm.
• 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 Connections.
• Click the + New Connection 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 Confirm.

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: 

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

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

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

For 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 or Download registration script.

Note: 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 Nodes section. Click on Details to view system information.

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