This serves as an introduction to Image Management, outlining its purpose, advantages and important features.

Le Image Management module is an extended implementation of Hashicorp’s Packer. It enables administrators to create standardized and consistent images across multiple platforms. With Image Management, you don’t need to write JSON-based configurations for multiple infrastructure images.

: Watch our YouTube video for a visual walkthrough

Caractéristiques principales

Image Management lets you use your custom installation scripts and extends the Packer implementation through the following features:

• Create Provisioner Groups
• Create Provisioner Roles
• Use PowerShell DSC configurations during image build (hosted and standalone with Configuration Management)
• Use PowerShell AppDeployment Toolkit packages, groups and roles (with Application Mnagament)

Use cases

• Continuous Delivery
• DEV/ACC/PRD alignment
• Demo creation
• Golden images

Top benefits

Our Image Management module:

• Allows you to launch completely provisioned and configured machines in minutes, on repeat and consistently – create different images for development, acceptance or production environments or use one for all stages
• Defines pre-baked developer images or is usable in Citrix environments to create golden images – because it creates identical images for multiple platforms, you can run production in AWS, staging/QA in a private cloud like OpenStack and development in desktop virtualization solutions such as VMware or VirtualBox
• Installs and configures all the software for a machine at the time the image is built – if there are bugs in these scripts, they will be caught early rather than in production
• Implements Pester scripts (or similar) to test your machines against a defined state

The post About Image Management 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:

The post Prerequisites appeared first on XOAP.

Quick guide

This is the final step of creating images. If you have not yet configured your Connection, Systèmes d'exploitation, Builder Configuration ou Provisioner Role, please do so before proceeding.

Create a new Image Definition

1. In the upper-right corner, click + Nouvelle image.
2. Enter all required parameters and click Économiser.
3. Right-click the newly created Image Definition and select Exécuter to create the images.

Update an existing Image Definition

1. Right-click the Image Definition and select Details.
2. Adjust the parameters as needed and click Économiser.
3. Run the Image Definition to create a new image version with the updated configuration.

Delete an Image Definition

1. To delete an Image Definition, right-click it and select Supprimer.
2. This removes the Image Definition from XOAP, but all previously created image versions remain in your environment.

Additional useful information

Connector requirement:

Le Connector in an Image Definition is required for secure deployments in both cloud and on-premises environments. See our documentation for instructions on how to deploy the XOAP Connector on your machine.

Templates:

We provide example Builder Configurations, Systèmes d'exploitation, and Provisioner Roles in your Workspace as quick-start templates. They may not fully match your environment, so feel free to modify them or create your own.

Logs and Runs:

To view the log for the last run, click on the Statut badge. Live logging and stopping an image run can be done from the Courses view.

Temporary runs:

If a run is stopped, the temporary files created during that run are not deleted from your environment. For Failed ou Succeeded runs, temporary files are removed automatically.

Technical documentation

The image definition is the final and most crucial step in the image creation process. This is where you bring together all previously configured components—Provisioner Role, Operating System, and Builder Configuration—into a single, unified blueprint.

By combining these elements, you define exactly how the virtual machine image will be built, what operating system it will use, how it will be configured, and in which environment it will be deployed (e.g., AWS, Azure, etc.).

In XOAP, this step ensures that your image is consistently created according to your selected setup and ready for deployment or automation.

The interface allows you to:

• Assign a name and description to the image definition
• Select tags for categorization or filtering
• Choose the builder provider and specific builder configuration
• 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 or secure cloud environments
• Schedule Image Definition Run

Run or schedule image builds

By runing an Image Definition you will start the image build process. You can track the progress by clicking the Courses button in the upper right corner. This opens a side panel showing active runs.

By clicking Toggle Logs, you can follow live build logs and monitor progress in real time.

There are several possible statuses for an image definition run:

No Runs – The image definition has not been executed yet
En attente – The run is waiting in line and will start when resources are available
La course à pied – The image build process is currently in progress
Succeeded – The image was successfully built and completed without errors
Failed – The image build process encountered an error and did not complete
Stopped – The image build was successfully stopped by a user and did not complete

The Image Definition run can take anywhere from a few minutes to a few hours.

This mainly depends on the number of provisioners being used and the selected base operating system. If you want to see more details about a specific image definition, click Details in the Action menu.

For Windows Image Definitions in cloud environments the sysprep command is executed automatically at the end of the image definition run. For on-premises environments you need to add it manually inside your Provisioner Role.

Sysprep provisioners which we are running as PowerShell script automatically on cloud can be found on our GitHub repo: https://github.com/xoap-io/xoap-packer-templates.

And below is example of script which you can use for sysprep on on-premises image definitions. To use it, upload a script to resource area, then assign script provisioner on last place in your definition.

Script

<#
.SYNOPSIS
    Performs final cleanup and prepares Windows Server 2025 for sysprep

.DESCRIPTION
    This script performs final cleanup tasks and prepares the system for sysprep and imaging on Windows Server 2025.
    Developed and optimized for use with the XOAP Image Management module, but can be used independently.
    No liability is assumed for the function, use, or consequences of this freely available script.
    PowerShell is a product of Microsoft Corporation. XOAP is a product of RIS AG. © RIS AG

.COMPONENT
    PowerShell

.LINK
    https://github.com/xoap-io/xoap-packer-templates

#>

Set-StrictMode -Version Latest
$ProgressPreference = 'SilentlyContinue'
$ErrorActionPreference = 'Stop'

# Setup local file logging to C:\xoap-logs
try {
    $LogDir = 'C:\xoap-logs'
    if (-not (Test-Path $LogDir)) {
        New-Item -Path $LogDir -ItemType Directory -Force | Out-Null
    }
    
    $scriptName = [IO.Path]::GetFileNameWithoutExtension($PSCommandPath)
    $timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
    $LogFile = Join-Path $LogDir "$scriptName-$timestamp.log"
    
    Start-Transcript -Path $LogFile -Append | Out-Null
    Write-Host "Logging to: $LogFile"
} catch {
    Write-Warning "Failed to start transcript logging to C:\xoap-logs: $($_.Exception.Message)"
}

# Simple logging function
function Write-Log {
    param($Message)
    $timestamp = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
    Write-Host "[$timestamp] $Message"
}

trap {
    Write-Log "ERROR: $_"
    Write-Log "ERROR: $($_.ScriptStackTrace)"
    Write-Log "ERROR EXCEPTION: $($_.Exception.ToString())"
    try { Stop-Transcript | Out-Null } catch {}
    Exit 1
}

try {
    Write-Log 'Starting final cleanup and sysprep'
     
    # Defragment system drive
    Write-Log 'Optimizing system drive...'
    try {
        Optimize-Volume -DriveLetter C -Defrag -Verbose:$false
        Write-Log 'System drive optimization completed'
    } catch {
        Write-Log "Warning: Could not optimize system drive: $($_.Exception.Message)"
    }
    
    Write-Log 'Final cleanup completed, preparing for sysprep...'
      
    # Stop transcript before sysprep
    try { Stop-Transcript | Out-Null } catch {}
    
    # Prepare sysprep command
    $sysprepPath = Join-Path $env:WINDIR "System32\Sysprep\sysprep.exe"
    $sysprepArgs = @('/generalize', '/oobe')
    
    Write-Log "Running sysprep with arguments: $($sysprepArgs -join ' ')"
    Write-Log "This will shutdown the system when complete"
    
        # Check if sysprep.exe exists
        if (Test-Path $sysprepPath) {
            # Run sysprep using Start-Process for better error handling
            $process = Start-Process -FilePath $sysprepPath -ArgumentList $sysprepArgs -Wait -PassThru
            $exitCode = $process.ExitCode
            if ($null -eq $exitCode) {
                # Fallback to $LASTEXITCODE if ExitCode is not set
                $exitCode = $LASTEXITCODE
            }
            if ($exitCode -ne 0) {
                Write-Log "Sysprep failed with exit code: $exitCode"
                exit $exitCode
            }
        } else {
            Write-Log "Sysprep executable not found at $sysprepPath"
            exit 1
        }
    
} catch {
    Write-Log "Critical error in final cleanup: $($_.Exception.Message)"
    try { Stop-Transcript | Out-Null } catch {}
    throw
}

Scheduling Image Definition runs provides several operational and strategic advantages. By automating the execution of image builds at defined intervals, you eliminate the need for manual intervention and reduce the risk of human error.

Scheduled runs help maintain consistency across environments by ensuring that the latest configurations and software updates are regularly incorporated into your images. This is especially important for compliance and security, as it guarantees that patched and up-to-date images are always available.

Additionally, scheduling builds during off-peak hours can optimize resource usage and avoid impacting other workloads. Finally, regularly scheduled images improve preparedness for disaster recovery scenarios by ensuring that clean and current machine images are readily accessible.

There are two ways to schedule image definition runs:

1. By creating a new schedule
2. By editing an existing schedule

To manage either option, navigate to the Horaires section.
If you want to create a new schedule, click the New Schedule button in the upper right corner. In the first step, provide a name and define schedule parameters (e.g., frequency, start time). In the second step, select the image definitions you want to assign to this schedule. One image definition can be linked to multiple schedules.

If you wish to assign an image definition to an existing schedule, select the desired schedule from the list, click the three-dot menu, and then choose Details. In the details view, select the image definitions you want to include and click Économiser.

Locate your created image on your hypervisior or hyperscaler

Once a run finishes successfully, the created image is available in your environment. Images use the name defined in the Image Definition, with a version suffix added for each run. For example, if your Image Definition is named Windows11-BaseImage, the runs will create images such as Windows11-BaseImage-v1, Windows11-BaseImage-v2, and so on. If the image build fails, no image is created. The exact method for locating the image depends on your target environment.

Microsoft Azure

The location of images created in Azure using XOAP Image Management depends on the selected Builder Type during builder creation. In the builder configuration, you can choose between Azure Managed et Azure Gallery.

1. Azure Managed (Managed Images)
   If the selected builder type is Azure Managed, the image will be created as a standard Managed Image.
   - Location:
   Azure Portal → Images
   - Behavior:
   The image is stored regionally and is only available in the region it was created.
   - Use Case:
   This approach is recommended for simple deployments, testing, or proof-of-concept scenarios.
2. Azure Gallery (Shared Image Gallery)
   If the selected builder type is Azure Gallery, the image will be stored in a Shared Image Gallery (SIG).
   - Location:
   Azure Portal → Shared Image Gallery
   - Behavior:
   The image supports versioning, can be replicated across multiple regions, and is scalable for enterprise scenarios.
   - Use Case:
   Best suited for production workloads or environments requiring regional redundancy and image lifecycle management.

Amazon Web Services (AWS)

Images created via XOAP are stored as AMIs (Amazon Machine Images).

To locate:

1. Go to the AWS Console.
2. Naviguez jusqu'à EC2 → AMIs (under Images in the left menu).
3. Make sure to change the filter from Owned by Amazon to Owned by me.
4. Search using the AMI ID or name returned by the XOAP image definition run (e.g., ami-xxxxxxxxxxxxxxxxx).

By default, AMIs are private — they are only visible to the account that created them.
To make an AMI accessible from a different AWS account, you need to share it explicitly.
Follow these steps on the account where the AMI was created:

1. Open EC2 → AMIs (in the region where the AMI was created, e.g., eu-central-1).
2. Locate the AMI (e.g., ami-0839804dea557cd2b).
3. Select the AMI and click Actions → Modify Image Permissions.
4. Add the AWS Account ID of the recipient account.
5. Cliquez sur Économiser.

Once shared, the AMI will be visible under the “Private Images” filter in the recipient’s EC2 dashboard.

Google Cloud Platform (GCP)

XOAP images on GCP are stored under Compute Engine → Images.

To locate:

1. Go to the Google Cloud Console.
2. Naviguez jusqu'à Compute Engine → Images.
3. Filter by project or use the search bar to locate the image name generated by XOAP.
4. Custom images may be grouped by image families ou individual entries depending on how the build was configured

Troubleshoot image builds or run failures

When creating an image using XOAP Image Management, issues can typically arise from one of the following three areas:

1. Connexions – Incorrectly configured cloud connection (e.g., invalid credentials or missing permissions).
2. Provisionneurs – Wrongly selected or misconfigured provisioners, such as scripts or tools that fail during execution.
3. Builder Configuration – Misconfigured builder parameters (e.g., invalid region, missing image settings).

All three types of issues are reflected in the logs of the image definition run.

To quickly identify the problem:

• Navigate to the Image Definitions table.
• Click on Status (Latest Run) for the corresponding image definition.
• A side panel will appear, showing the log of the latest run.
• Review the log to locate the error line and take the necessary corrective action.

Reviewing these logs is the most efficient way to debug failures and ensure your image builds succeed.

For logs from previous runs, click the three-dot menu next to the image definition and select Details. Scroll down to the Past Runs section and click the status of the desired run to view its log.

During the image build process, it’s possible to identify and troubleshoot issues in real time. Active image builds are visible in the Runs section, located in the upper-right corner of the Image Definitions page.

To monitor the ongoing process:

• Click on the log icon beside the image build to open the live log view.
• Logs are streamed in real time, with the latest entries appearing at the top.

This allows you to:

• Track provisioning steps as they occur.
• Quickly identify long-running provisioners that may cause timeouts.
• Take corrective actions early, potentially saving significant time during debugging and validation.

This view is especially useful for diagnosing failures without waiting for the entire build to complete.

On on-prem image build VMs, logs are typically stored locally in these common locations:

• Temporary folders: C:\Windows\Temp and %TEMP% (e.g., C:\Users\\AppData\Local\Temp)
• Windows troubleshooting logs (useful for install/update/sysprep issues):
• Event Viewer: Application and System
• C:\Windows\Logs\DISM\dism.log and C:\Windows\Logs\CBS\CBS.log
• Sysprep: C:\Windows\System32\Sysprep\Panther\setupact.log and setuperr.log

If you can’t find them, the most common reason is that the build VM is automatically cleaned up after the run (including on failure), so the local logs are deleted with it.

Tip: If you stop the run, the temporary build VM is not deleted, so you can connect to it and collect the logs for troubleshooting. After you finish investigating, remember to delete the temporary build VM to avoid leaving unused resources behind.

Common image build issues and how to resolve them

1. Incompatible Provisioners – Using Linux provisioners on a Windows-based image (or vice versa) will cause failures. Resolution: Check the Provisioner Groups assigned to the selected role and remove any that are not relevant to the operating system of the image.
2. Invalid Credentials or Connection Settings – Connection issues may occur if the credentials are incorrect or the user lacks sufficient permissions. Resolution: Review your connection configuration under the Connections section. Ensure credentials are valid and have appropriate access rights.
3. Incorrect Builder Configuration – Errors may arise if the builder configuration references non-existent resources such as a virtual network or resource group. Resolution: Verify all values in the builder settings, especially network and resource group names.
4. Deprecated Operating System Definition – Older image definitions may reference deprecated or outdated operating systems. Resolution: Navigate to Operating Systems and add the latest version. Then, in the Image Definition details, update the OS selection from the dropdown to the newest version.

The post Image Definitions appeared first on XOAP.

Quick guide

The builder definition 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.

Create a new Builder Configuration

1. In the upper-right corner, click + New Builder Configuration.
2. Select Create builder configuration for cloud images, or choose a specific On-premises builder configuration.
3. Enter all required parameters and click Confirmer.

Edit a Builder Configuration

1. Right-click the builder configuration and select Details.
2. Update the required parameters and click Économiser

Delete a Builder Configuration

1. Right-click the builder configuration and select Supprimer.
2. Confirm the deletion.

Additional useful information

Connector requirement:

If you have not yet configured your Connection, you can do this during builder creation by clicking + Add Connection.

General details:

Dans le cadre de la General details accordion, all mandatory parameters are displayed. For additional parameters, expand the other accordions.

Technical documentation

Le builder definition defines where (which platform or cloud provider) and how (which configuration and instance type) an image is created. It represents the infrastructure layer of the image creation process and is responsible for launching the base virtual machine that will later be customized by provisioners.

In XOAP, when creating a builder configuration, you specify:

• Provider – for example AWS, Azure, or VMware
• Connection – the credentials and endpoint used to access the platform
• Region – the target cloud location
• Instance Type – which defines compute resources such as CPU and RAM

Together, these settings tell XOAP how to provision the underlying infrastructure required to build the image.

More information about additional settings you can configure in the Builder Configuration can be found at the following links:

• L'azur
• AWS
• Google Cloud
• VMware
• Nutanix

The post Builder Configuration appeared first on XOAP.

Quick guide

In XOAP, the Operating System represents the base image that will be used as the foundation for your custom virtual machine image.

Add a new Cloud Operating System

1. Cliquez sur + Add Base Image et sélectionnez Cloud.
2. Specify the Provider, Region, and Plate-forme details.
3. Select one or more operating systems and click Add.

Add a new On-Premises Operating System

1. Cliquez sur + Add Base Image et sélectionnez On-Premises.
2. Define the ISO-related parameters.
3. Select the Autounattend file and setup files for your OS, then click Add.

Edit an Operating System

1. Right-click the Operating System and select Details.
2. Update the configurable parameters and click Économiser.

Delete an Operating System

1. Right-click the Operating System and select Supprimer.
2. Confirm the deletion.

Additional useful information

OS updated list:

XOAP retrieves updated OS lists from supported cloud providers on a weekly basis.

Operating systems:

Operating systems can be deprecated and removed by cloud providers, which may cause Image Definition runs to fail. To avoid this, keep your Operating Systems up to date by adding the latest versions and updating your Image Definitions accordingly.

Technical documentation

In XOAP, the Operating System represents the base image that will be used as the foundation for your custom virtual machine image. You can select one or more OS versions from your cloud provider (e.g., Azure, AWS, GCP) to match your infrastructure requirements.This step is essential because all provisioning, customization, and image building will be performed on top of this base OS.

When adding an Cloud Operating System in XOAP, you define:

• Provider – Select the cloud or platform provider (e.g., Azure, AWS, Google Cloud)
• Region – Specify the region where the base image is available
• Platform Details – Choose the OS version, architecture (x64/ARM), hypervisor generation, and SKU
• Tags – Optionally add tags to help organize or categorize the OS for future reference

When adding an On-Premisses 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
• ISO Path – full location to the your ISO file
• ISO Checksum – checksum of your ISO as additional security feature
• Autounattend – file which is used to modify windows settings during Setup. This file must be uploaded to XOAP resource area.
• Setup Files – defines which extra files XOAP mounts into the virtual machine during operating system installation.

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

On-premisses tips

Pour on-premises operating systems, XOAP does not upload/store the ISO itself. Instead, you register the ISO by providing its path et checksum, and the build infrastructure (hypervisor / storage) must be able to access that ISO at runtime.

What this means in practice:

• The ISO is stored in your hypervisor storage (e.g., vSphere datastore / Hyper-V library) or on afile share (e.g., SMB/UNC path).
• XOAP stores metadata about the ISO (name, path, checksum) and uses that information during image builds.
• Ensure the build components (e.g., the host running the on-prem builder) have network access and permissions to read the ISO from the specified path.

Use Get-FileHash 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.

Use unique filenames if you plan to upload multiple autounattend files for the same OS (e.g., different languages, environments, driver sets).

Example naming convention:

• Autounattend_W11_23H2_EN.xml
• Autounattend_W11_23H2_DE.xml
• Autounattend_W11_23H2_WithDrivers.xml

Important : Autounattend resources are renamed during the deployment/build process (as part of how XOAP stages resources into the temporary VM).Because of that, having distinct filenames in XOAP Resources is essential to keep them manageable and avoid confusion when selecting the correct file.

Ensure the Autounattend file matches the target OS (edition/SKU, architecture, expected install flow) and references any setup files/drivers using paths that are valid in your setup process.

The post Operating Systems appeared first on XOAP.

Quick guide

A Provisioner Role in XOAP is a higher-level construct that allows you to group together multiple Provisioner Groups into a single unit.

Add a new Provisioner Role

1. Cliquez sur + Create Provisioner Role.
2. Enter the required parameters, such as Nom et Description.
3. Assign Provisioner Groups by clicking + Assign Provisioner Groups.
4. Click Save to create the new Provisioner Role.

Edit a Provisioner Role

1. Right-click the Provisioner Role and select Details.
2. Update the parameters or change the assigned groups.
3. Click Save to apply the changes.

Delete a Provisioner Role

1. Right-click the Provisioner Role and select Supprimer.
2. Confirm the deletion.

Additional useful information

Provisioner Role:

Only one Provisioner Role can be used in an Image Definition. The Provisioner Role is therefore the highest-level construct for running provisioners during image creation. You cannot delete a Provisioner Role if it is currently used in an Image Definition.

Provisioner Group:

Each Provisioner Group can only be added once to a given Provisioner Role.

Order of execution:

During image creation, provisioners are executed in order from top to bottom within the role: all provisioners in the first group run first, followed by the second group, third group, and so on.

Order of groups:

You can change the order of groups in a Provisioner Role by dragging and dropping them in the Provisioner Role details view.

Technical documentation

A Provisioner Role in XOAP is a higher-level construct that allows you to group together multiple Provisioner Groups into a single unit. It defines which provisioner groups will be executed during the image build process and in what order.

Provisioner Roles are especially useful when:

• You want to reuse predefined group sets across different image definitions
• You need to combine complex sequences of provisioning steps into a manageable unit

When creating a Provisioner Role, you define:

• Role name – a unique identifier for the role
• Description – a short explanation of the role’s purpose (e.g., “Join domain and apply baseline”)
• Tags – optional labels to help categorize or search roles
• Selected Provisioner Groups – choose the groups that should run during the build

Provisioner Groups within a role are executed in the order they are listed, and the entire role can then be reused across multiple image definitions.

A single Provisioner Role can be used in multiple Image Definitions, just like provisioner groups and provisioners themselves. This promotes reusability and consistency across builds.

The post Provisioner Roles appeared first on XOAP.

Quick guide

A Provisioner Group in XOAP allows you to organize multiple provisioners into a single, logical unit.

Add a new Provisioner Group

1. Cliquez sur + Create Provisioner Group.
2. Enter the required parameters, such as Nom et Description.
3. Assign provisioners by clicking + Assign Provisioners.
4. Cliquez sur Économiser to create the new Provisioner Group.

Edit a Provisioner Group

1. Right-click the Provisioner Group and select Details.
2. Update the parameters or change the assigned provisioners.
3. Cliquez sur Économiser to apply the changes.

Delete a Provisioner Group

1. Right-click the Provisioner Group and select Supprimer.
2. Confirm the deletion.

Additional useful information

Group rules:

A provisioner can be added to the same group only once, but the same provisioner can belong to multiple groups.

Execution:

Provisioners in a group are executed from top to bottom.

Order of provisioners:

You can change the order of provisioners within a Provisioner Group by dragging and dropping them in the Provisioner Group details view.

Technical documentation

A Provisioner Group in XOAP allows you to organize multiple provisioners into a single, logical unit. This is useful for grouping related configuration tasks or setup steps that should be applied together during the image build process.

Provisioners within the group are executed in the exact order they are listed, which gives you full control over the execution flow. For example, you can ensure that a file is copied before a script is executed, or that Windows Updates run before a reboot.

When creating a provisioner group, you define:

• Group name – a unique name for easy identification
• Description – optional text explaining the purpose of the group
• Tags – to help organize and filter groups in large environments
• Selected Provisioners – choose one or more provisioners to include from the available list

Provisioners within a Provisioner Group are executed in the order they are listed, and the entire group can then be reused across multiple Provisioner Roles. This promotes reusability and consistency across builds.

The post Provisioner Groups appeared first on XOAP.

Quick guide

A provisioner is a key component in the image build process used to customize the virtual machine after it has been created by the builder.

Add a new Provisioner

1. Cliquez sur + Create Provisioner.
2. Enter the required parameters, such as Nom et Description.
3. Select the Provisioner Type and fill in all required parameters.
4. Cliquez sur Économiser to create the new Provisioner.

Edit a Provisioner

1. Right-click the Provisioner and select Details.
2. Update the Provisioner parameters as needed.
3. Cliquez sur Économiser to apply the changes.

Delete a Provisioner

1. Right-click the Provisioner and select Supprimer.
2. Confirm the deletion.

Additional useful information

Multi-group assignment:

When creating a Provisioner, you can automatically add it to multiple Provisioner Groups.

Combined management:

Provisioners is the place where you combine the XOAP Application Management et Configuration Management modules with Image Management.

OS-specific provisioners:

Some Provisioners are Linux-only or Windows-only. Be careful when assigning them to Provisioner Groups.

Technical documentation

A provisioner is a key component in the image build process used to customize the virtual machine after it has been created by the Builder Configuration. Provisioners allow you to automate tasks inside the VM to prepare it for your specific use case.

Provisioners operate inside the guest operating system and are responsible for modifying the system state before the image is finalized.

Provisioners can be used to:

• Install software (e.g., Chrome, Office, .NET Framework)
• Copy files to specific locations on the VM
• Configure system settings (e.g., registry, services, network)
• Apply hardening or compliance baselines (e.g., STIG, CIS)
• Run PowerShell, Bash, CMD, or other scripts
• Apply DSC configurations or join the machine to a domain (in enterprise builds)
• Install Windows Updates
• Reboot Windows instances

In XOAP, provisioners are modular and reusable, meaning a single provisioner can be referenced in multiple Image Definitions. This allows for consistent configuration across builds and reduces duplication when maintaining your image pipeline.

XOAP supports multiple types of provisioners, each designed to automate a specific type of task during image creation:

• Application Group Installer – Installs applications from the selected Application Group.
• Application Role Installer – Installs applications from the selected Application Role.
• DSC Local Configuration – Copies local DSC (Desired State Configuration) configuration files into the image to be applied during or after provisioning.The configuration can be uploaded to the resource area and selected from the dropdown menu.
• DSC Pullserver Configuration – Applies a configuration from the XOAP Configuration Management module.
• File – Copies files from the XOAP workspace into the image — for example, configuration files, scripts, or assets.
• Linux Shell Command – Executes a single inline shell command (e.g., apt install, chmod, etc.) on a Linux machine.
• Linux Shell Script – Runs a full shell script (.sh) to configure Linux-based images with more complex logic. You can select the script from the Resources area.
• PowerShell Command – Executes a one-liner PowerShell command on Windows-based machines — useful for setting registry keys, services, etc.
• Script PowerShell – Runs a complete PowerShell script to perform advanced setup tasks in the Windows OS. You can select the script from the Resources area.
• Windows Restart – Triggers a system reboot during image provisioning — useful when configuration changes require a restart to take effect.
• Mise à jour de Windows – Applies the latest Windows Updates during the provisioning process to ensure the image is up to date.

Provisioners can have multiple configurable settings.

Source files for the DSC Local Configuration, File, Linux Shell Command, and PowerShell Script provisioner types must be uploaded to the Resources area in XOAP before you can assign them to the corresponding Provisioner.

The post Provisioners appeared first on XOAP.

If you define provisioners, you should always define a timeout. This is important to avoid a situation where a provisioner runs forever and blocks the image creation process. Some provisioners have default timeouts, but you should always define a timeout that fits your use case.

The post Best practices appeared first on XOAP.