XOAP

How to build a custom Windows 365 Cloud PC image with XOAP

Mario — Fri, 10 Jul 2026 15:10:08 +0000

<\/path><\/svg>"},"no_headings_message":"No headings were found on this page.","minimize_box":"yes","minimized_on":"tablet","hierarchical_view":"yes","min_height":{"unit":"px","size":"","sizes":[]},"min_height_tablet":{"unit":"px","size":"","sizes":[]},"min_height_mobile":{"unit":"px","size":"","sizes":[]}}" data-widget_type="table-of-contents.default">

Building a custom image for Windows 365 has traditionally been a manual, multi-step job. Spinning up a reference VM, installing and configuring applications by hand, handing the image off to Intune… One missed step usually means starting over, and repeated a few times a year, this approach to golden images becomes difficult to reproduce.

XOAP's Image Management module replaces the manual custom image sequence with a defined, repeatable pipeline. The operating system, the build location and what gets installed on top are each defined once, then the image is built on demand, with no capture scripting and no hand-assembly.

In this blog, we’ll guide you through building a custom Windows image for Windows 365 Cloud PC provisioning and handing the finished image off to Windows 365 for use in a provisioning policy – done, automated and simplified with XOAP.

Before you start: Connect your Azure subscription

XOAP needs a working connection to your Azure subscription before it can build anything. If you don’t use XOAP yet, create a free account to test it.

Aller à Connections > Add new connection and use a Service Principal avec Contributor role access.

You can create one with the Azure CLI:
az ad sp create-for-rbac –name xoap-image-principal –role Contributor –scopes /subscriptions/ –years 1

Take the resulting ID de l'abonnement, ID du locataire, ID client et Client Secret and enter them into the connection details in XOAP.

The build at a glance

The full pipeline is five steps in XOAP, plus one hand-off in Intune:

1. Under Image Management > Operating Systems, add the Windows base image you want to build from.

2. Under Image Management > Builder Configuration, define where and how the image will be built.

3. Under Image Management > Provisioners / Provisioner Groups / Provisioner Roles, define what gets installed and configured.

4. Under Image Management > Définitions des images, cliquer + New Image and combine the operating system, builder configuration and provisioner role into one definition.

5. Save, then right-click the image definition and select Exécuter.

Once the run succeeds, locate the finished image in Azure and upload it to Windows 365 as a custom image.

Now, let’s dive deeper into each step.

Step 1: Choose the operating system

Sous Systèmes d'exploitation, sélectionner Cloud, then choose the L'azur provider, region and platform details.

Pour Windows 365, use the Enterprise Cloud PC image family: offer windows-ent-cpc, SKU win11-25h2-ent-cpc (or the latest available release and version).

This is Microsoft’s dedicated Cloud PC edition: Enterprise, single-session, and already optimised for Windows 365 scenarios.

Starting from the right base saves you fighting the image into shape later.

Step 2: Define the builder configuration

The builder configuration tells XOAP where the image is built and what it produces.

Create a new configuration with the following settings:

• Type: Azure Managed. This creates a standard managed image in the Azure Portal, the simplest and most direct option for Windows 365 custom images.
• Connection: your Azure connection from the setup step.
• Region: your target region, for example West Europe.
• Instance Type: the size of the temporary build VM used only during the build itself, for example Standard_D2s_v3. This VM is created and torn down automatically and has no effect on the final Cloud PC’s performance, so there is no need to oversize it.
• Storage Account Type: Standard_LRS.

Step 3: Define what goes on the image

This layer is where the image stops being a stock OS and becomes yours.

Provisionneurs define what gets installed and configured on top of the base operating system: applications, settings, PowerShell scripts, DSC configurations or PSADT packages.

XOAP provides example provisioners as quick-start templates, but you are not limited to them. Fully custom provisioners are equally supported. Any script or package you create yourself can be added and used exactly like the built-in ones.

Group the provisioners you need into a Provisioner Group, then attach that group to a Provisioner Role.

One practical rule worth following:
Always define a timeout on each provisioner, so a long-running script can’t stall the entire build.

Step 4: Combine it into an image definition

The image definition is where the three layers come together. Under Définitions d'images, cliquer + New Image and fill in:

• Name and description
• Builder: the builder configuration created above
• Operating system: the Cloud PC image selected above
• Role: the provisioner role created above

Save the definition, then right-click it and select Exécuter.

You can track progress from the Runs panel in the upper-right corner, with live log streaming available via Toggle Logs. A run moves through these statuses: Queued, Running, Succeeded, Failed and Stopped.

The live logs are where you’ll catch a misbehaving provisioner early rather than after a failed build.

Step 5: Locate the finished image

Because the builder configuration used Azure Managed, the resulting image appears in Azure Portal > Images, named after the image definition with a version suffix, for example CloudPC-v1.

If you had used an Azure Gallery builder instead, the image would land in Azure Portal > Shared Image Gallery, with support for versioning and multi-region replication.

For a single Windows 365 custom image, the managed image is the simpler route.

Step 6: Hand off to Windows 365

XOAP builds the Azure image, but Windows 365 provisioning is managed separately, so the final step happens in Intune:

1. Go to Intune admin center > Devices > Provision Cloud PCs > Custom images > Add > Managed image.
2. Select the subscription and the image built by XOAP.
3. Provide an image name and version, for example 1.0.0.
4. Windows 365 validates the image, confirming it boots and provisions successfully as a Cloud PC, before it becomes available.
5. Once validated, select it as the source image when creating a Provisioning Policy.

That validation step is your safety net. A custom image only becomes selectable once Windows 365 has confirmed it actually provisions, so a broken build never reaches your users.

Why the pipeline matters

Next quarter, when you need the same image with one more application or an updated base OS, you change one layer and run it again. Two admins running the same definition get the same result. The manual golden-image ritual, and the drift that came with it, is gone.

That is the point of building images with XOAP’s Image Management: reproducibility you don’t have to think about, across as many image versions as your Cloud PC estate needs.

Also running Azure Virtual Desktop?

The same Image Management workflow builds the golden images for AVD host pools too. From there, XOAP’s AVD Manager handles the operational side: rolling image rollout with one-click rollback, autoscaling, per-pool cost tracking and patching across the fleet. AVD Manager is part of the XOAP platform by default – no need for additional accounts, installs or any extra steps. En savoir plus

Build your custom images with XOAP

The post How to build a custom Windows 365 Cloud PC image with XOAP appeared first on XOAP.

Windows OS (re)deployment with XOAP and OSDCloud

Perica — ven., 22 mai 2026 11:34:27 +0000

La gestion des déploiements de Windows à grande échelle est l'une des responsabilités les plus exigeantes en matière d'exploitation informatique. Entre les configurations matérielles incohérentes, les exigences de conformité et le besoin constant de maintenir les appareils enregistrés et gérés après l'installation, le processus est rarement aussi simple qu'il le devrait.

Cet article explique comment XOAP et OSDCloud travaillent ensemble pour relever ces défis et couvre les trois approches de déploiement prises en charge par l'intégration, chacune différant par le type d'image de démarrage et la source de l'image Windows, afin que vous puissiez sélectionner l'option qui convient à votre infrastructure.

Défis du déploiement du système d'exploitation Windows

Déployer Windows à grande échelle fait systématiquement apparaître le même ensemble de problèmes:

Configuration deDifficulté : Différents groupes d'appareils nécessitent des ensembles de pilotes, des éditions de système d'exploitation, des modules linguistiques et des types d'activation distincts. La gestion manuelle de ces variations introduit des erreurs et ne permet pas une mise à l'échelle efficace sur de grandes flottes.
Cohérence matérielle: Les appareils de différents fabricants se comportent différemment lors du déploiement. Sans un processus contrôlé et reproductible, le résultat est un parc qui commence son cycle de vie dans un état incohérent.
Sécurité et conformité dès le premier jour: Le déploiement du système d'exploitation est le moment où les bases de référence de sécurité doivent être appliquées. Les organisations qui s'appuient sur la remédiation post-déploiement assument des risques et des expositions d'audit inutiles.
Gestion continue post-déploiement. L'installation d'un système d'exploitation n'est que la première étape. L'enregistrement des appareils pour une gestion continue, l'application de configurations et le déploiement d'applications standard doivent encore être effectués — idéalement sans aucune intervention manuelle.

Les solutions traditionnelles telles que MDT, SCCM et WDS résolvent ces problèmes, mais nécessitent des investissements d'infrastructure importants et une maintenance continue. XOAP associé à OSDCloud offre une alternative ne nécessitant aucune infrastructure d'imagerie dédiée au-delà d'une seule machine virtuelle pour la création d'ISO et, pour le scénario 3, un partage réseau ou un autre emplacement de stockage pour le fichier ISO.

Trois scénarios de déploiement

L'intégration de XOAP et OSDCloud prend en charge trois scénarios distincts. Chacun est conçu pour un contexte d'infrastructure différent, et le choix entre eux dépend du type d'image de démarrage requis, de la source de l'image Windows et de la manière dont le déploiement est déclenché.

Scénario 1 : OS téléchargé depuis Internet

Ce scénario ne nécessite aucun hébergement d'image local. L'appareil cible démarre sous WinPE, télécharge l'image Windows directement depuis Microsoft Update, achève l'installation et s'enregistre automatiquement auprès de l'espace de travail XOAP désigné.

Infrastructure requise :
• 1 machine virtuelle Windows 11 24h2 (pour la création d'ISO)
• Accès à Internet sur la machine virtuelle de création ISO et sur les appareils cibles

Préparation de l'ISO :
Sur la VM du créateur ISO, installez l'outil OSDCloud soit via XOAP en appliquant le rôle d'application OSDCloud Workspace Internet OS, soit manuellement en exécutant les paquets PSADT suivants dans l'ordre :

1. APP_Microsoft_WindowsAssessmentDeploymentKit_101261002454_Any_x64_FR
2. APP_Microsoft_WindowsPEforADK_101261002454_Any_x64_EN
3. APP_DavidSegura_OSDCloudISOCreator_121_Any_Any_FR
Avant de commencer l'installation, exécutez la commande suivante pour définir la stratégie d'exécution :
Définir la stratégie d'exécution -Stratégie d'exécution Contourner -Portée Machine locale -Forcer

Lors de la configuration, configurez les paramètres qui définissent l'image de déploiement :

Description du paramètre :

Paramètre	Description
Conducteur	Pilotes à inclure dans boot.wim — utiliser * pour tout ou Aucun sauter
OSVersion	Windows 10 ou Windows 11
OSBuild	Cible de build (par exemple 22h2, 24h2) — Windows 10 prend en charge uniquement 21h2 et 22h2
OSEdition	Accueil, Pro, Entreprise, etc.
OSLanguage	Langue du système d'exploitation déployé
OSActivation	Volume ou Vente au Détail
XOAPWorkspaceID	L'ID de l'espace de travail trouvé sur le tableau de bord XOAP
XOAPConfigurationGroup	Le groupe de configuration rejoint par les nouveaux appareils déployés

Une fois terminé, OSDCloud_NoPrompt.iso est généré dans C:\OSDCloudWorkspace.

Téléchargement et configuration dans XOAP :
Ajoutez l'image ISO générée dans le sous-dossier « Files » du package PSADT « SYS_XOAP_OSDcloudRElocal_100_Any_Any_Any », compressez le package au format ZIP et téléchargez-le sur XOAP via Application Management > Applications. Une fois le téléchargement terminé, créez un rôle d'application et un groupe de configuration pour l'application. Lorsque ce groupe de configuration est déployé sur un appareil cible, le redéploiement démarre automatiquement.

L'appareil extrait l'ISO vers une partition de récupération Windows (WinRE) nouvellement créée. Après un redémarrage, l'appareil démarre à partir de cette partition dans l'environnement WinPE OSDCloud, efface et redivise le disque, puis télécharge l'image Windows depuis Microsoft Update pour l'installation.

Après l'installation du système d'exploitation, OSDCloud configure des scripts SetupComplete qui enregistrent l'appareil auprès de l'espace de travail XOAP au premier démarrage, à condition qu'un accès à Internet soit disponible. Parallèlement, une tâche planifiée est configurée pour s'exécuter à l'ouverture de session de l'utilisateur et vérifier la connectivité XOAP — si l'appareil est déjà enregistré, la tâche se supprime elle-même, et sinon, elle tentera l'enregistrement dès qu'une connexion Internet sera présente.

Scénario 2 : Démarrage WinPE avec un OS téléchargé depuis Internet

Ce scénario suit le même flux de bout en bout que le Scénario 1. TLe système d'exploitation Windows est téléchargé depuis Internet pendant la phase WinPE, mais utilise une image de démarrage de récupération complète. La différence réside dans le fichier boot.wim : plutôt qu'un environnement WinPE minimal, l'image de démarrage inclut le ensemble install.wim fichier, qui est utilisé pour construire l'environnement WinPE lui-même.

Utiliser le OSDCloud Récupération d'espace de travail Complète Rôle de l'application ou le APP_DavidSegura_OSDCloudISOCreatorRecoveryFull_121_Any_Any_FR package à la place du créateur ISO standard. Le processus d'installation, les paramètres requis et les étapes de téléchargement XOAP sont par ailleurs identiques au scénario 1.

Remarque : Ce scénario n'est actuellement pas pris en charge pour le redéploiement sur les machines virtuelles Hyper-V. La partition contenant le install.wim le fichier n'est pas mappé correctement dans cet environnement et n'a pas été testé sur d'autres plateformes de virtualisation.

Scénario 3 : Redéploiement du système d'exploitation depuis un partage réseau, une source locale ou autre

Ce scénario couvre le redéploiement de l'OS à l'aide du script OSDcloud_RE_from_localISO.ps1 plutôt qu'un package PSADT géré par XOAP. Il prend en charge deux options pour l'approvisionnement de l'image Windows pendant WinPE : le téléchargement par Internet ou la récupération à partir d'un partage réseau ou d'une source locale, et convient aux environnements où un plus grand contrôle sur le déclencheur de déploiement est requis.

Le scénario 3 prend en charge deux options pour la provenance de l'image Windows pendant WinPE :

• Système d'exploitation téléchargé sur Internet — utilisez le rôle d'application OSDCloud Workspace Internet OS ou le package APP_DavidSegura_OSDCloudISOCreator_121_Any_Any_EN, avec les paramètres standard décrits dans le scénario 1
• Système d'exploitation récupéré à partir d'un partage réseau — utilisez le rôle d'application de système d'exploitation local OSDCloud Workspace ou le package APP_DavidSegura_OSDCloudISOCreatorLocalShare_121_Any_Any_EN, avec les paramètres supplémentaires suivants :

Description du paramètre :

PartagerUtilisateur	Un compte utilisateur avec un accès en lecture au partage réseau
PartagerMotDePasseUtilisateur	Le mot de passe de ce compte
CheminDePartageNonSécurisé	Le chemin UNC vers le partage, par exemple. \\srv1\xoap

Lorsque vous utilisez un partage réseau, il doit suivre une structure de dossiers spécifique pour que OSDCloud puisse localiser l'image :
\\serveurpartage\nompartage\OSDcloud\OS.

Déclenchement du déploiement :
Plutôt que d'empaqueter l'ISO dans une application PSADT, le déploiement est déclenché à l'aide du script OSDcloud_RE_from_localISO.ps1 avec le paramètre -LocalISOPath :
OSDcloud_RE_from_localISO.ps1 -LocalISOPath “\\srv1\xoap\OSDCloud_NoPrompt.iso”

Ce script gère le processus complet de configuration d'OSDCloudRE : création de la partition WinPE, montage de l'ISO, copie du contenu de démarrage, configuration des entrées du gestionnaire de démarrage et initialisation d'un redémarrage dans l'environnement de récupération. Il peut être appelé directement via un connecteur XOAP, ou intégré dans un module de configuration DSC pour permettre des étapes supplémentaires telles que les vérifications de hachage d'intégrité de l'ISO, la validation des prérequis et les sauvegardes de fichiers avant le début de l'effacement.

Le script a été testé avec des ISOs situés sur des appareils locaux et des partages réseau. Pour d'autres types de stockage tels que le stockage Blob Azure, GitHub ou OneDrive, le script devrait être étendu pour gérer l'étape de téléchargement avant d'invoquer la logique ISO locale.

Déploiement dans plusieurs espaces de travail ou groupes de configuration ? Ceci s'applique aux trois scénarios. Lancez à nouveau le processus de création de l'ISO avec les paramètres requis pour chaque espace de travail ou groupe de configuration cible. Renommez ou déplacez le fichier OSDCloud_NoPrompt.iso depuis C:\OSDCloudWorkspace entre les exécutions, car chaque nouvelle exécution écrase le fichier précédent.

Le déploiement sur l'appareil cible

Quel que soit le scénario utilisé, le processus sur l'appareil cible suit la même séquence :

1. Le Groupe de Configuration déploie le package PSADT sur l’appareil cible, ce qui extrait l’ISO, crée la partition WinRE et déclenche un redémarrage, ou pour le Scénario 3, le script OSDcloud_RE_from_localISO.ps1 est exécuté directement.
2. L'appareil démarre à partir de la partition OSDCloudRE WinPE
3. Si connecté via Ethernet, le déploiement se déroule sans interaction ; sinon, une invite de sélection de réseau sans fil s'affiche (la disposition du clavier est en-us à ce stade).
4. L'opérateur confirme l'effacement du disque ; c'est la seule étape interactive du processus
5. Windows est installé et les scripts de SetupComplete s'exécutent, enregistrant l'appareil auprès de XOAP Workspace au premier démarrage si l'accès à Internet est disponible ; une tâche planifiée s'exécute également à chaque connexion utilisateur ultérieure pour vérifier et retenter l'enregistrement XOAP si nécessaire
6. L'appareil redémarre dans le nouvel environnement Windows installé et géré.

Gestion continue après le déploiement

Une fois enregistrés dans l'espace de travail XOAP, les appareils sont immédiatement soumis aux politiques et configurations définies dans leur groupe de configuration assigné. Les applications standard peuvent être déployées et les configurations système et utilisateur appliquées sans aucune autre étape manuelle. Le résultat est un point de terminaison cohérent et conforme dès le premier démarrage.

Pour commencer

Les trois scénarios nécessitent une machine virtuelle Windows 11 24h2 et un compte XOAP pour la création d'ISO. Un accès à Internet est requis sur la VM créant l'ISO et sur les appareils cibles pour les scénarios 1 et 2.

Pour le scénario 3 avec une source d'image de partage réseau, un accès Internet est requis sur la VM créatrice d'ISO, mais les appareils cibles peuvent fonctionner sans celui-ci pendant la phase WinPE.

Créez votre compte XOAP gratuit or réserver une démonstration pour discuter de vos exigences de déploiement spécifiques avec l'équipe.

Explorer XOAP

The post Windows OS (re)deployment with XOAP and OSDCloud appeared first on XOAP.

How to create PSADT v4 packages with the XOAP Package Wizard

Mario — Mer., 20 mai 2026 12:33:10 +0000

Les packages PSADT ne sont aussi cohérents que la personne qui les a créés. Un ingénieur structure la phase d'installation d'une manière, un autre gère la fermeture des processus différemment, un troisième ignore complètement la phase de réparation. Chaque package fonctionne jusqu'à ce qu'il ne fonctionne plus et le débogage implique d'abord de déchiffrer les conventions de quelqu'un d'autre.

Le manque d'un composé standard dans chaque package de votre bibliothèque.

Assistant de package XOAP pour PSADT v4, cela corrige le problème à la source. Chaque paquet construit avec cela suit la même structure, utilise la même disposition des phases et produit le même format de sortie, quel que soit celui qui s'occupe de l'emballage. Solution prête à déployer en moins de 10 minutes, sans codage.

Ce tutoriel détaille le processus complet, depuis le dépôt de votre programme d'installation jusqu'à l'exportation d'une archive zip que vous pouvez remettre directement à Intune, SCCM ou à tout outil capable de PowerShell.

Qu'est-ce que le Sorcier de Packages XOAP ?

L'Assistant de package est un outil gratuit et autonome de XOAP qui génère des paquets PowerShell App Deployment Toolkit (PSADT) v4 prêts à être déployés en production via un interface guidée sans code.

Il gère la structure du script Invoke-AppDeployToolkit.ps1, le bloc $adtSession, les phases d'installation et de désinstallation, ainsi que toutes les déclarations de paramètres, sans que vous ayez à taper la moindre ligne de PowerShell.

Le progiciel exporté est un fichier ZIP standard: le kit PSADT, vos fichiers d'installation et le script généré, le tout dans un seul dossier. Il fonctionne avec n'importe quel outil de gestion des points de terminaison comme Intune, SCCM ou tout autre moyen que vous utilisez pour le déploiement, sans aucun wrapper propriétaire.

Vous pouvez télécharger l'édition Wizard gratuite ici sans créer de compte ni fournir d'informations de carte de crédit.

Comment créer un package

Le Sorcier de Packages XOAP gère le packaging à travers sept étapes guidées.

Pour commencer, ouvrez l'assistant et cliquez sur Démarrer Nouveau Paquet. Vous arriverez à l'écran de configuration du package avec une zone de glisser-déposer attendant votre installateur.

Pour ce tutoriel, nous allons empaqueter 7-Zip.

Étape 1 : Insérez votre programme d'installation

Ajoutez ou faites glisser votre fichier d'installation dans la zone de dépôt. L'Assistant accepte Fichiers MSI, installateurs EXE et tout autre format votre déploiement requiert.

Pour les fichiers MSI, l'Assistant lit les métadonnées intégrées (nom du produit, version, architecture et plus) et propose de pré-remplir automatiquement les détails du colis. Cela représente environ 12 champs que vous n'aurez pas à saisir manuellement.

Étape 2 : Configuration

Le Configuration L'écran est directement mappé au bloc $adtSession de votre fichier Invoke-AppDeployToolkit.ps1 généré. La plupart des champs sont déjà renseignés à partir des métadonnées du fichier MSI.

Quelques points à définir ici :

- ExigerAdmin — définissez ceci sur true pour tout ce qui s'installe dans Program Files. Cela nécessite une élévation et empêche les échecs silencieux sur les comptes d'utilisateurs standards.
- ProcessusÀFermer — liste les processus qui doivent être fermés avant le début de l'installation. Pour 7-Zip, il s'agit de 7zFM (le gestionnaire de fichiers 7-Zip). Si un utilisateur l'a ouvert lorsque le package s'exécute, PSADT le fermera proprement avant de continuer.

Tout ce que vous configurez ici se retrouve dans le bloc "session" du script généré, exactement là où PSADT s'y attend.

Étape 3 : Paramètres

Les paramètres par défaut de PSADT v4 comme TypeDeDéploiement, ModeDéploiement et les autres sont toujours présents et n’ont pas besoin d’être ajoutés manuellement. Cette étape est destinée aux paramètres personnalisés spécifiques à votre package.

Si vous avez besoin d'un Environnement paramètre avec un ensemble fixe de valeurs autorisées (par exemple, Test, Staging, Production), vous le définissez ici.

Pour un déploiement d'application simple comme 7-Zip, vous pouvez passer directement à la suite.

Étape 4 : Construire votre phase d'installation

C'est le cœur du Sorcier. Le Installer screen vous offre trois éditeurs : pré-installer, installer et post-installation. Ceux-ci couvrent tout ce qui précède, se déroule pendant et suit l'installation principale.

Remplissage automatique pour chaque cmdlet PSADT v4

Commencez à taper un nom de cmdlet PSADT et l'éditeur fournit une complétion automatique dans toute la boîte à outils v4. Acceptez une suggestion et elle insère un extrait de code avec des valeurs d'espace réservé pour chaque paramètre requis. Appuyez sur Espace et un tiret pour déclencher des indices de paramètres en ligne (types, descriptions et valeurs valides), le tout sans quitter l'éditeur.

Constructeur de fonctions

Si vous préférez ne pas mémoriser du tout les noms des cmdlets, ouvrez Constructeur de fonctions. C'est un catalogue visuel de toutes les fonctions PSADT v4, organisé par catégorie : Process, MSI, Files, Registry, UI et plus encore. Choisissez une fonction, remplissez le formulaire, voyez le code généré se mettre à jour en temps réel, puis cliquez sur Insérer pour l'insérer directement dans votre script.

Dans la version gratuite de Wizard, les catégories Processus et MSI sont entièrement activées. Les autres catégories sont visibles avec des indicateurs de verrouillage afin que vous puissiez voir ce qui est disponible dans la version complète.

Pour l'installation de 7-Zip elle-même, la catégorie MSI gère proprement Execute-MSI. Sélectionnez-la dans le Function Builder, définissez l'action sur Installer et pointez vers votre fichier d'installation.

Étapes 5 et 6 : Phases de désinstallation et de réparation

Le Désinstaller La phase est traitée de la même manière que la phase d'installation précédente. Mêmes trois éditeurs (pré-désinstallation, désinstallation, post-désinstallation), mêmes complétions automatiques, même constructeur de fonctions.

Étape 6 est la Réparation phase. De nombreux packages laissent cela vide, ce qui est tout à fait normal, car PSADT exécute simplement une fonction vide. Si votre application prend en charge les opérations de réparation, vous pouvez les définir ici en utilisant les mêmes outils.

Étape 7 : Aperçu et exécution de test

Cliquez sur Suivant pour voir la commande Invoke-AppDeployToolkit.ps1 entièrement générée. Le script exact qui sera inclus dans votre exportation.

D'ici, vous pouvez exécuter un test en direct avant d'exporter :

1. Sélectionnez un type et un mode de déploiement
2. Activer l'exécution en tant qu'administrateur
3. Cliquez sur Test Run

Le script s'exécute sur la machine locale. La sortie est dirigée vers le terminal sous l'éditeur en temps réel. Il y a un délai d'expiration de 120 secondes pour les processus bloqués. L'Assistant fera exactement ce qu'il dit : testez ceci sur une machine de développement, pas sur une machine de production.

Étape 8 : Exporter

Retour sur le tableau de bord, cliquez Exporter sur la carte du package. L'Assistant produit une archive ZIP standard contenant :

• Le script Invoke-AppDeployToolkit.ps1 généré
• La trousse complète PSADT v4
• Vos fichiers d'installation

C'est ce que vous donnez à Intune, SCCM ou tout autre outil que vous utilisez.

Le ZIP ne contient rien de propriétaire. Si vous changez de plateforme de déploiement demain, le paquet fonctionnera toujours.

Deux fonctionnalités qui font gagner des heures

Applications installées

Avant d'écrire une phase de désinstallation à partir de zéro, ouvrez Applications installées. L'assistant analyse le registre de la machine et affiche chaque application installée avec son commande de désinstallation. Sélectionnez l'application et l'assistant générera la commande de suppression correcte. Collez-la directement dans votre phase de désinstallation.

Importer Local

Vous avez déjà une bibliothèque de packages PSADT existants ? Importer Local importe n'importe quel paquet v3 ou v4 dans votre espace de travail. Pour les paquets v3, il traduit automatiquement la syntaxe en v4. Les noms de fonctions, les structures de paramètres et les variables de session sont mis à jour pour correspondre au nouveau framework. Le résultat arrive dans votre espace de travail Packages, prêt à être modifié ou exporté.

Obtenez le sorcier gratuit

L'assistant de configuration de package XOAP pour PSADT v4 est gratuit à télécharger. Remplissez le formulaire ci-dessous et vous recevrez le lien de téléchargement par e-mail. Vous pouvez également consulter la liste complète des fonctionnalités et les plans disponibles. ici.

Profitez de packages PSADT v4 propres et standards qui fonctionnent où que vous déployiez.

Demande
lien de téléchargement

Utilisez une adresse e-mail professionnelle pour vous assurer de recevoir l'assistant de package XOAP dans votre boîte de réception.

The post How to create PSADT v4 packages with the XOAP Package Wizard appeared first on XOAP.

How to: Bare metal OS deployment with XOAP

Perica — Ven, 15 mai 2026 12:28:59 +0000

Lorsqu'un nouveau lot de matériel arrive, l'attente est simple : les appareils doivent être provisionnés, configurés et inscrits dans la plateforme de gestion dans les plus brefs délais. En pratique, cependant, le déploiement de serveurs nus est souvent l'une des étapes les plus exigeantes en main-d'œuvre du cycle de vie des appareils.

XOAP résout ce problème grâce à un pipeline de déploiement automatisé et répétable qui provisionne un appareil à partir de zéro et le connecte à l'espace de travail XOAP correct sans intervention manuelle au niveau de l'appareil.

Cet article décrit le fonctionnement du processus et présente les deux méthodes de déploiement prises en charge : le démarrage PXE et l'USB.

Comment XOAP aborde le déploiement bare metal

Le pipeline de déploiement est construit sur OSDCloud, un framework basé sur PowerShell pour l'installation de systèmes d'exploitation via Windows PE. XOAP étend cela avec un ensemble préconfiguré de packages PSADT qui gèrent la configuration de l'environnement, la création d'images et l'enrôlement après l'installation – produisant un artefact de déploiement répétable, paramétrable et lié à un espace de travail et un groupe de configuration XOAP spécifiques.

Le mécanisme critique est ce qui se passe à la fin de chaque installation. Une fois le système d'exploitation appliqué, OSDCloud exécute les scripts SetupComplete qui enregistrent automatiquement l'appareil auprès de XOAP. Si la connectivité Internet n'est pas disponible au premier démarrage, une tâche planifiée est créée pour vérifier la connectivité à chaque connexion utilisateur et initier l'inscription dès qu'une connexion est établie. Une fois l'appareil enregistré, la tâche se désinscrit elle-même.

Le résultat est un appareil qui entre dans l'environnement géré sans nécessiter d'étapes post-installation de la part de l'ingénieur.

Méthodes de déploiement

XOAP offre deux voies distinctes pour le déploiement de systèmes d'exploitation sur bare-metal, chacune étant adaptée à un contexte d'infrastructure différent.

Méthode 1 : Démarrage PXE (déploiement réseau)

Le démarrage PXE est approprié pour les déploiements à grande échelle dans des environnements disposant d'Active Directory, de DHCP et de DNS. Les appareils démarrent à partir du réseau et reçoivent un environnement Windows PE personnalisé qui pilote l'installation complète sans support de démarrage physique.

Exigences en matière d'infrastructure

Environnement Active Directory, DHCP et DNS
Un serveur Windows VM (2019, 2022 ou 2025) pour le rôle WDS/PXE
Une machine virtuelle Windows 11 24H2 pour créer l'ISO OSDCloud
Accès à Internet pour la VM de build et pour les appareils nouvellement mis en scène

Processus d'installation

Le processus commence sur la VM créatrice d'ISO. En utilisant les rôles d'application XOAP ou les packages PSADT installés localement, ADK Windows et PE Windows pour ADK sont déployés en premier, suivis du package créateur d'ISO OSDCloud. Ce package accepte les paramètres de déploiement requis – version du système d'exploitation, build, édition, langue, méthode d'activation, ID de l'espace de travail XOAP cible et groupe de configuration – et produit un OSDCloud_NoPrompt.iso dans C:\OSDCloudWorkspace. L'ISO résultant contient la configuration d'inscription XOAP, garantissant que chaque appareil déployé à partir de celle-ci se connecte à l'espace de travail et au groupe de configuration corrects.

Le fichier boot.wim est extrait de l'ISO et importé dans les services de déploiement Windows sur le serveur WDS. Le fichier install.wim d'une ISO Windows standard est placé dans le partage XOAP à C:\RemoteInstall\Images\XOAP\OSDcloud\OS. Lorsque la bande passante est limitée ou que l'accès à Internet est indisponible pendant la phase de préparation, l'image Windows peut également provenir d'un partage réseau local – un package ISO Creator distinct et des paramètres supplémentaires (ShareUser, ShareUserPassword et UncSharePath) sont requis pour cette variante.

Les options de l'étendue DHCP complètent la configuration côté serveur : l'option 066 (Nom d'hôte du serveur de démarrage) pointant vers le serveur WDS et l'option 067 (Nom du fichier de démarrage) pointant vers le fichier de démarrage UEFI. Tout appareil qui démarre en PXE sur le segment réseau configuré se voit alors automatiquement servir l'environnement Windows PE.

Expérience côté appareil

Le technicien connecte l'appareil au réseau de déploiement et lance le démarrage PXE, généralement via F12 au démarrage. Le gestionnaire de démarrage WDS présente les images WinPE disponibles, l'image correcte est sélectionnée, et l'opérateur choisit l'image Windows cible ainsi que son édition. Après avoir confirmé le nettoyage du disque, l'installation se termine sans autre intervention. L'appareil redémarre dans un environnement Windows fraîchement installé et géré par XOAP.

Une capacité notable de l'approche PXE est que plusieurs boot.wim les fichiers peuvent être importés dans WDS, chacun configuré avec un ID d'espace de travail XOAP ou un groupe de configuration différent. Un seul serveur WDS peut donc prendre en charge des déploiements sur plusieurs clients ou environnements, l'opérateur sélectionnant l'image de démarrage appropriée au démarrage. Pour les MSP gérant plusieurs locataires, cela offre une isolation multi-locataires au niveau de l'image.

Méthode 2 : Clé USB (déploiement autonome)

La méthode USB convient aux déploiements où aucune infrastructure PXE ou DHCP n'existe – sur un nouveau site client, dans un bureau distant ou pour des déploiements ponctuels plus petits. Le processus sous-jacent est le même, mais l'environnement de démarrage est livré à partir d'une clé USB plutôt que d'un serveur réseau.

Exigences en matière d'infrastructure

Une VM Windows 11 24H2 pour construire l'ISO OSDCloud
Une station de travail physique pour créer la clé USB bootable
Accès Internet pour la machine virtuelle de build et les appareils mis en scène

Processus d'installation

La création d'ISO suit la même procédure que la méthode PXE : déployez Windows ADK, Windows PE pour ADK et l'outil OSDCloud ISO Creator via des packages XOAP ou PSADT avec les paramètres appropriés. Le résultat OSDCloud_NoPrompt.iso contient l'environnement de démarrage personnalisé avec l'enrôlement XOAP intégré.

L'ISO est transférée sur une machine physique, où le module PowerShell OSD est utilisé pour l'écrire sur une clé USB :

Installer-Module -Nom OSD
New-OSDCloudUSB -fromIsoFile “C:\Chemin\Vers\OSDCloud_NoPrompt.iso”

L'invite de commande demande le lecteur USB cible et la confirmation de l'effacement. Lorsque le déploiement à partir d'une image Windows locale est préféré au téléchargement par Internet, un install.wim fichier peut être copié à OSDCloudUSB:\OSDcloud\OS\ sur l'USB après la création.

Expérience côté appareil

Le technicien branche l'USB, démarre dessus et l'environnement OSDCloud WinPE s'initialise. Lorsque l'appareil n'a pas de connexion réseau filaire, une invite de sélection du réseau sans fil apparaît automatiquement – la prise en charge du WLAN est assurée via l'intégration de WinRE dans l'environnement de démarrage. L'opérateur sélectionne l'image et l'édition Windows, confirme l'effacement du disque, et l'installation continue. L'inscription post-installation via SetupComplete suit le même processus que la méthode PXE.

La pile de packages OSDCloud XOAP

Les deux méthodes de déploiement reposent sur la même pile de trois packages. Kit de déploiement et d'évaluation Windows (ADK) – version 10.1.26100.2454: tL'exigence fondamentale pour construire des environnements WinPE personnalisés. Windows PE pour ADK – version 10.1.26100.2454eétend le kit de développement ADK avec le module complémentaire Windows PE, permettant des environnements de préinstallation démarrables. Créateur d'ISO OSDCloud: tLe package qui contient la logique spécifique à XOAP. Il installe le module PowerShell OSD, crée le modèle OSDCloud avec WinRE (requis pour le support WLAN dans WinPE), configure l'espace de travail OSDCloud et incorpore les scripts SetupComplete et StartNet responsables de l'enrôlement XOAP. Les pilotes matériels sont injectés dans boot.wim à ce stade. La sortie est OSDCloud_NoPrompt.iso.

Les paramètres requis au moment de l'installation sont : ensemble de pilotes, méthode d'activation du système d'exploitation, version du système d'exploitation (par exemple 24H2 ou 25H2), édition du système d'exploitation, langue du système d'exploitation, version du système d'exploitation, groupe de configuration XOAP cible et ID de l'espace de travail XOAP.

Pour générer des images pour plusieurs espaces de travail XOAP, le package est relancé avec des paramètres différents. L'ISO doit être renommée ou déplacée entre les exécutions, car chaque exécution écrase la sortie précédente au même chemin.

Prêt à le voir en action ?

La capacité de déploiement bare metal de XOAP est un composant d'une plateforme d'automatisation d'infrastructure plus large qui gère les appareils de zéro à une gestion complète avec un minimum d'intervention manuelle à chaque étape.

Book a demo pour voir comment XOAP gère le déploiement de systèmes d'exploitation, la gestion des points de terminaison et la livraison de configurations sur l'ensemble de votre flotte d'appareils.

Explorer XOAP

The post How to: Bare metal OS deployment with XOAP appeared first on XOAP.

The reality of application delivery in 2026

Dora — ven. 08 mai 2026 13:45:37 +0000

Tous les événements

L'automatisation parle

La réalité de la livraison d'applications en 2026

Ép. 07 avec Jens Miltenberger (Ceterion)

À propos de l'épisode

L'informatique en nuage et l'informatique hybride - conférences sur l'automatisation, animé par Mario Istuk, est un podcast de XOAP, explorant les sujets d'infrastructure informatique et d'automatisation.

Restez à l'écoute pour des discussions approfondies avec des experts invités et de courtes mises à jour sur les sujets informatiques actuels.

Regarder sur YouTube & Apple Podcasts
Écoute sur Spotify

Vous avez une question, une suggestion ou un commentaire ? Faites-le nous savoir à hello@xoap.io.

La livraison d'applications. L'une des disciplines les plus sous-estimées en informatique.

Dans cet épisode, notre invité est Jens Miltenberger, Directeur des Services de Conseil chez Ceterion. Nous couvrons l'évolution des formats d'emballage, le paysage des outils de SCCM à Intune, les environnements hybrides et pourquoi la distribution des applications est finalement un défi de processus et d'organisation, pas un défi d'outillage.

A noter : Cet épisode n'est disponible qu'en allemand. Pour une traduction en anglais, regardez-le sur YouTube avec les sous-titres.

Regardez maintenant !
Disponible sur YouTube, Apple Podcasts et Spotify.

Rencontrez notre hôte

XOAP

Mario Istuk

Mario Istuk, cofondateur de XOAP, supervise les ventes, le marketing et les partenariats d'entreprise. Fort de plus de 15 ans d'expérience dans l'infrastructure informatique et l'automatisation, il aide les organisations à optimiser des environnements informatiques hybrides complexes. Mario anime les Entretiens sur l'automatisation podcasts, génère des prospects lors d'événements en ligne et intervient lors de conférences à travers l'Europe.

Événements à venir et passés

La réalité de la livraison d'applications en 2026

Ép. 07 avec Jens Miltenberger (Ceterion) | Regardez maintenant

DOAG Voices : La réalité de la transformation du cloud avec Christian Reineke (XOAP)

Épisode de podcast | Animé par DOAG

Bluecue event : conformité de sécurité automatisée pour les infrastructures informatiques

1er avril 2026 | Événement en ligne | Hébergé par blucue

Événement Bluecue : Conformité de sécurité automatisée KHZG pour l'informatique hospitalière

25 mars 2026 | Événement en ligne | Organisé par bluecue

BLINK 2025 | Comment XOAP simplifie l'automatisation du cloud hybride

28 novembre 2025 | Bielefeld, DE | Organisé par blucue

Le cloud souverain européen AWS

Ép. 06 avec Tobias Tomandl (Ingram Micro) | Regardez maintenant

The post The reality of application delivery in 2026 appeared first on XOAP.

AWS Systems Manager vs XOAP: Guide for MSPs

Stella — lun, 13 avr. 2026 11:50:46 +0000

AWS Systems Manager et XOAP aident tous deux les organisations à gérer leur infrastructure à grande échelle. En apparence, ils se recoupent, mais ils ont été conçus pour des situations différentes. Savoir lequel convient le mieux dépend moins d'une comparaison de fonctionnalités que de la compréhension de ce que chaque outil a été initialement conçu pour faire.

Ce que AWS Systems Manager fait bien

Intégré à la plateforme AWS, Systems Manager propose la gestion des correctifs, l'exécution de commandes à distance, la gestion de sessions, le stockage sécurisé des informations sensibles via Parameter Store et le contrôle de la configuration par le biais de State Manager. Au sein d'un seul compte AWS exécutant principalement des charges de travail basées sur EC2, il s'intègre naturellement et bon nombre de ses fonctionnalités principales sont incluses dans l'utilisation standard d'AWS.

Le produit fonctionne au mieux lorsque l'environnement est très largement natif d'AWS. Plus une organisation s'éloigne de ce scénario, plus ses limites deviennent pertinentes.

Où les deux produits diffèrent :

Gérer plusieurs clients

SSM est construit autour d'une seule organisation AWS. Maintenir plusieurs clients correctement séparés signifie généralement la mise en place de comptes AWS séparés avec leurs propres politiques IAM. Cela fonctionne, mais cela ajoute du temps de configuration et de la surcharge de maintenance continue pour chaque nouveau client ajouté.

La multi-location est au cœur de la conception de XOAP, ce n'est pas quelque chose qui nécessite une configuration supplémentaire. Chaque client dispose de son propre espace isolé au sein de la plateforme, avec des contrôles d'accès et des politiques disponibles par défaut. Les MSP gérant de nombreux clients trouveront que cela élimine une quantité importante de travail d'infrastructure répétitif..

Environnements hybrides et mixtes

Grâce à sa fonctionnalité d'activation hybride, SSM peut gérer des machines locales et non AWS aux côtés de charges de travail cloud. Sa cible de conception principale reste néanmoins AWS, de sorte que la gestion de l'infrastructure en dehors d'EC2 a tendance à nécessiter des étapes de configuration supplémentaires qui ne seraient pas nécessaires pour les charges de travail natives du cloud.

XOAP traite l'infrastructure cloud et l'infrastructure locale de manière égale dès le départ. Un serveur dans un centre de données est géré de la même manière qu'une instance cloud, via la même interface et la même logique d'automatisation. Les équipes disposant d'une part importante de leur infrastructure en dehors d'AWS trouveront par conséquent une gestion quotidienne considérablement plus cohérente.

Gestion des images

AWS propose EC2 Image Builder pour créer et gérer des images de machines au sein d'AWS, avec une sortie au format AMI pour les charges de travail EC2. La solution Image Management de XOAP est conçue pour fonctionner aussi bien dans des environnements cloud que sur site. Les entreprises qui ont besoin d’images cohérentes sur l’ensemble d’un parc informatique mixte, et non pas uniquement au sein d’AWS, peuvent tirer parti de cette portée élargie.

Coût

De nombreuses fonctionnalités de SSM sont incluses sans frais supplémentaires dans AWS. Cependant, pour qu'il fonctionne bien sur plusieurs clients ou dans des environnements hybrides, il faut souvent créer des outils personnalisés pour combler les lacunes. Ce temps d'ingénierie représente un coût réel, même si la licence logicielle n'en a pas.

XOAP fonctionne sur un modèle d'abonnement. L'idée est que dans les environnements multi-clients ou complexes, la réduction des frais d'ingénierie justifie le coût par rapport à la création de capacités équivalentes sur les outils natifs d'AWS.

Un exemple concret

Considérez un MSP intégrant un nouveau client. Le client dispose de 40 machines Windows réparties entre des serveurs sur site et des instances AWS, et doit prouver sa conformité en matière de correctifs avant un audit à venir.

Avec SSM, l'équipe devrait configurer des activations hybrides pour les machines locales, mettre en place une séparation au niveau du compte pour isoler ce client des autres et rassembler un rapport de conformité provenant de plusieurs sources. Rien de tout cela n'est impossible, mais chaque étape nécessite un travail délibéré en dehors de l'outil principal.

Le processus XOAP prévu est de créer un nouveau locataire, de déployer l'agent sur toutes les machines, où qu'elles se trouvent, d'appliquer les stratégies pertinentes et d'exporter un rapport de conformité, l'isolement du locataire étant géré au niveau de la plateforme tout au long du processus.
Les deux routes mènent au même résultat. La différence réside dans la quantité de travail périphérique nécessaire pour y parvenir.

Lequel ?

Le SSM convient aux organisations qui fonctionnent principalement sur AWS, avec des équipes à l'aise dans la console AWS et sans besoin significatif d'isolation multi-clients ou de gestion multiplateforme.

XOAP est mieux positionné pour les MSP et les équipes d'infrastructure qui gèrent plusieurs clients avec des exigences de séparation strictes, qui travaillent dans des environnements mixtes (cloud et sur site), ou qui souhaitent réduire l'effort manuel nécessaire pour maintenir la cohérence de l'automatisation à grande échelle.

Outils différents, contextes différents

AWS Systems Manager (SSM) et XOAP sont conçus pour des priorités et des réalités opérationnelles différentes, plutôt que pour répondre au même besoin. Le XOAP se concentre sur le soutien du fonctionnement réel des organisations dans des environnements diversifiés, de sorte que la bonne approche est celle qui s'aligne sur les flux de travail réels et les exigences d'infrastructure.

Cette distinction mérite une attention particulière lors de l'évaluation de l'une ou l'autre plateforme, notamment dans les environnements multi-clients ou hybrides.

Pour voir comment XOAP gère ces scénarios en pratique, réserver une démo.

Explorer XOAP

Avis de non-responsabilité :
Cet article est fourni à titre informatif et comparatif uniquement. Tous les noms de produits, marques commerciales et marques déposées mentionnés sont la propriété de leurs propriétaires respectifs. Les informations présentées reflètent la documentation publiquement disponible et les capacités générales des produits au moment de la rédaction.

Cette comparaison ne constitue pas un conseil juridique, financier ou d'approvisionnement. Il est conseillé aux lecteurs d'évaluer indépendamment chaque plateforme en fonction de la documentation officielle et des directives du vendeur. Toute référence aux modèles de tarification reflète les informations de prix publiquement disponibles et ne constitue pas des interprétations juridiques ou financières.

L'analyse vise à fournir un aperçu objectif des différences architecturales et des cas d'utilisation prévus, et non à affirmer une supériorité, une insuffisance ou des revendications concurrentielles.

The post AWS Systems Manager vs XOAP: Guide for MSPs appeared first on XOAP.

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

Dora — mar. 07 avr. 2026 09:59:35 +0000

Tous les événements

Baladodiffusion

Voix DOAG :
Bilan de la transformation cloud avec Christian Reineke de XOAP

Hébergé par : DOAG | Langue : Allemand

Automatisation, coûts et changement culturel

Sur le papier, la valeur du cloud est indéniable. En réalité, de nombreuses organisations découvrent que la transformation vers le cloud est beaucoup plus complexe, coûteuse et exigeante sur le plan organisationnel que prévu.

Dans un où DOAG Voices épisode, animé par David Koenig, PDG de XOAP, Christian Reineke, partage des aperçus pratiques tirés de ses années d'expérience à accompagner les entreprises dans cette démarche.

Les plus grands défis de la transformation cloud sont structurels. La déconnexion entre informatique traditionnelle et Équipes DevOps ne peut être résolu par un seul outil. Les outils d'automatisation sont souvent considérés comme la solution, mais ils introduisent souvent de la complexité.

Ce qui manque, c'est un couche unificatrice, une façon de standardiser et d'opérationnaliser l'automatisation entre les équipes et les niveaux de compétence. C'est exactement là que a approche plateforme devient critique.

Écoutez l'épisode sur votre plateforme de podcast de prédilection

Événements à venir et passés

La réalité de la livraison d'applications en 2026

Ép. 07 avec Jens Miltenberger (Ceterion) | Regardez maintenant

DOAG Voices : La réalité de la transformation du cloud avec Christian Reineke (XOAP)

Épisode de podcast | Animé par DOAG

Bluecue event : conformité de sécurité automatisée pour les infrastructures informatiques

1er avril 2026 | Événement en ligne | Hébergé par blucue

Événement Bluecue : Conformité de sécurité automatisée KHZG pour l'informatique hospitalière

25 mars 2026 | Événement en ligne | Organisé par bluecue

BLINK 2025 | Comment XOAP simplifie l'automatisation du cloud hybride

28 novembre 2025 | Bielefeld, DE | Organisé par blucue

Le cloud souverain européen AWS

Ép. 06 avec Tobias Tomandl (Ingram Micro) | Regardez maintenant

The post DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP) appeared first on XOAP.

From legacy to scalable: Rethinking AVD management for MSPs

Stella — Mer, 01 Avr 2026 08:44:54 +0000

Les fournisseurs de services informatiques modernes sont en pleine transition : les clients transfèrent rapidement leurs charges de travail vers le cloud, en particulier vers Azure Virtual Desktop (AVD). Mais alors que l'infrastructure a évolué, les outils de gestion, eux, sont souvent restés au point mort. C'est dans cet écart que naissent les inefficacités, les risques et la complexité opérationnelle.

La vérité sur les outils “ suffisamment bons ”

Pendant des années, des outils comme Microsoft SCCM, Microsoft Deployment Toolkit et Baramundi Management Suite ont constitué l'épine dorsale de la gestion des terminaux et des systèmes. Ils étaient fiables. Familier. Éprouvé.

Mais ils ont aussi été construits pour une époque différente :

Infrastructure sur site
Environnements statiques
Opérations mono-locataire

Plongeons dans la réalité d'aujourd'hui :

Environnements Azure multi-locataires
Infrastructure élastique
Cycles de déploiement rapides
Points de terminaison distribués

Les outils hérités n'ont pas été conçus pour cela.

Où les outils hérités échouent dans les environnements AVD

Lorsque les MSP tentent d'étendre les outils traditionnels à AVD, plusieurs points de friction apparaissent :

1. La gestion des images devient lente et fragile

La création d'images de référence est encore largement manuelle et prend beaucoup de temps., souvent prenant des jours, et difficile à standardiser entre les locataires. En conséquence, les environnements sont sujets à la dérive, aux incohérences et aux reconstructions fréquentes.

2. L'empaquetage des applications manque de cohérence

Même avec des frameworks tels que PSAppDeployToolkit, le packaging des applications varie souvent d'une équipe à l'autre, les méthodes de déploiement diffèrent selon les environnements et la réutilisabilité reste limitée, ce qui entraîne une duplication des efforts et des taux d'échec plus élevés.

3. Pas de visibilité unifiée entre les locataires

Les MSP opèrent fréquemment sur plusieurs tableaux de bord, gèrent des connexions locataire distinctes et s'appuient sur des outils de reporting incohérents pour surveiller leurs environnements. Cette approche fragmentée entraîne l'absence d'une source unique de vérité, ralentit les processus de dépannage et réduit la confiance dans le respect constant des SLA.

4. La prolifération des outils augmente les coûts opérationnels

Au lieu de travailler à partir d'une plateforme unique, les équipes s'appuient souvent sur une combinaison de SCCM pour la gestion des appareils, de scripts personnalisés pour l'automatisation, d'outils natifs d'Azure pour les opérations cloud et de diverses solutions tierces pour la surveillance. Cette chaîne d'outils fragmentée augmente les coûts de formation, crée des silos de spécialistes et augmente le risque de mauvaise configuration entre les environnements.

Ce à quoi devrait ressembler la gestion moderne des AVD

Pour fonctionner efficacement à grande échelle, les MSP ont besoin d'une approche orientée cloud et consciente du multi-locataire. Cela signifie :

Gestion automatisée du cycle de vie des images

Images versionnées
Constructions reproductibles
Mises à jour rapides entre les environnements

Livraison d'applications standardisée

Une méthode d'emballage
Compatibilité multiplateforme
Logique de déploiement centralisée

Configuration centralisée et visibilité

Tableaux de bord unifiés
Informations inter-locataires
Suivi de conformité en temps réel

Consolidation de plateforme

Moins d'outils
Moins de changement de contexte
Réduction des frais d'exploitation

Comment XOAP permet une approche unifiée

C'est exactement le vide que XOAP est conçu pour combler, sans obliger les MSP à abandonner ce qui fonctionne déjà. Au lieu de cela, il connecte et standardise dans tous les environnements.

1. Image Management : Du manuel à l'automatisé

XOAP permet :

Création automatisée d'images pour AVD, Azure, VMware et plus encore
Images standardisées et versionnées
Gestion continue du cycle de vie

Fini de reconstruire les images à partir de zéro ou de suivre les modifications non documentées.

2. Application Management : S'appuie sur ce en quoi les équipes ont déjà confiance

XOAP s'appuie sur PSAppDeployToolkit comme base et l'étend :

Catalogue d'applications centralisé
Déploiement multiplateforme
Normes d'emballage cohérentes

3. Configuration Management : une vue d'ensemble de tous les locataires

XOAP fournit :

Gestion unifiée des politiques
Inventaire logiciel dans tous les environnements
Surveillance de la conformité

Fini les connexions à des locataires distincts pour assembler des informations.

La véritable opportunité pour les MSP

Le plus grand avantage est la différenciation du service. XOAP introduit un modèle en couches :

XOAP gère l'automatisation et l'orchestration
Les MSP construisent des services sur mesure

Cela vous permet de :

Définissez vos propres niveaux de service
Intégrer la gestion AVD comme une offre premium
Fournir des résultats cohérents et évolutifs

Au lieu de vendre des outils, vous livrez une expérience gérée.

Exemple concret : Avant vs après

Avant (pile héritée) :

SCCM + scripts + outils Azure
Pipelines d'images manuelles
Visibilité fragmentée
Frais d'exploitation élevés

Après (unifié avec XOAP) :

Plateforme unique pour la gestion du cycle de vie
Image + application automatiséesdemande flux de travail
Surveillance centralisée
Évolutif entre les locataires

Dernières réflexions

Le problème ne vient pas du principe « Azure Virtual Desktop », mais des approches de gestion obsolètes. Si votre équipe continue à combiner Microsoft SCCM, Microsoft Deployment Toolkit et des scripts personnalisés pour gérer des environnements cloud modernes, vous vous imposez une complexité inutile.

Commencez à explorer un meilleure façon de gérer les environnements Azure avec XOAP. Créez votre compte gratuit et voyez comment l'automatisation unifiée change votre modèle opérationnel.

Gérez facilement les environnements Azure

The post From legacy to scalable: Rethinking AVD management for MSPs appeared first on XOAP.

Make AWS WorkSpace management easy with XOAP

Stella — ven. 20 mars 2026 13:05:17 +0000

La gestion des AWS WorkSpaces peut s'avérer complexe, mais avec les outils d'automatisation et de configuration de XOAP, vous pouvez simplifier le processus, de la configuration du système à la livraison des applications.

Les défis courants tels que l'automatisation de la création de bundles pour Windows 11, la mise à l'échelle de WorkSpaces dans un pool et la supervision de l'ensemble du système ajoutent à la difficulté. Cet article vous guidera pour simplifier ces tâches et bien d'autres, vous aidant ainsi à prendre le contrôle de vos AWS WorkSpaces sans complexité inutile.

Avant de commencer : Définissez vos WorkSpaces AWS

Lorsque vous travaillez avec Amazon WorkSpaces, une planification claire est essentielle. Commencez par définir les composants critiques nécessaires pour chaque espace de travail.

Sélectionnez le système d'exploitation (SE)

Commencez par choisir le système d'exploitation approprié pour chaque espace de travail. AWS prend actuellement en charge :

Windows 10 et Windows 11
Distributions Linux telles qu'Amazon Linux 2 et Ubuntu (20.04 / 22.04 LTS)

Avec XOAP, le choix du système d'exploitation peut être standardisé entre les environnements et automatisé pour assurer la cohérence.

Définir les normes de sécurité et de renforcement

Ensuite, définissez vos paramètres de sécurité afin que chaque espace de travail soit renforcé conformément aux exigences de votre organisation. Ces paramètres peuvent être appliqués automatiquement, y compris les politiques de conformité.

En matière de conformité, les organisations devraient s'aligner sur des cadres tels que :

Center for Internet Security (benchmarks CIS)
Guides de mise en œuvre technique de sécurité (STIG)

Celles-ci aident à protéger les informations sensibles et à satisfaire aux exigences réglementaires.

Décidez quelles applications vous souhaitez déployer

Une fois les composants de sécurité définis, choisissez les logiciels que vous souhaitez installer, tels que Office, Adobe Reader ou des outils de compression. Ceci sera important pour définir les normes de packaging ultérieurement.

Sachez combien de locataires vous gérerez

Envisagez-vous de gérer un seul locataire AWS ou plusieurs ? De nombreuses organisations et MSP gèrent plusieurs environnements (DEV, QA, PROD) ou clients. XOAP permet la gestion centralisée de tous ces environnements AWS WorkSpaces à partir d'une seule interface.

Comment gérer vos AWS WorkSpaces avec XOAP

1. Configurer les systèmes avec Configuration Management

Une fois vos définitions AWS WorkSpaces configurées, il est temps d'uniformiser les configurations à l'aide de Configuration Management.

Il assure la cohérence entre tous les espaces de travail, éliminant la dérive de configuration et réduisant les erreurs. Au lieu de configurer manuellement chaque espace de travail :

Définir les configurations une seule fois
Appliquez-les à tous les environnements
Déployer automatiquement les mises à jour, les correctifs et les changements de politique

Vous pouvez également valider des configurations à l'aide d'outils de test. Lors d'une montée en puissance, l'infrastructure à la demande d'AWS vous permet de vous étendre de manière transparente.

2. Déployer des applications avec Application Management

La gestion des applications dans AWS WorkSpaces peut être complexe en raison de :

Exigences de sécurité et de conformité
Considérations de performance
Gestion des dépendances
Défis de connectivité

Avec Application Management, vous pouvez :

Empaqueter les applications une fois
Déployez-les dans tous les espaces de travail
Grouper le logiciel par rôles
Définir les dépendances et l'ordre d'installation

Cela élimine les problèmes courants tels que les installations incohérentes, les performances médiocres ou les conflits d'intégration.

3. Tout automatiser avec Platform Management

Les processus manuels ne sont pas évolutifs et augmentent le risque d'erreurs.

Platform Management vous permet d'automatiser et de planifier des tâches à l'aide des éléments suivants :

Scripts PowerShell
Interfaces en ligne de commande (CLI)

Avec lui, vous pouvez :

Créer, modifier ou supprimer automatiquement des espaces de travail
Planifier les opérations de routine
Surveiller les journaux d'exécution et l'historique des tâches

Cela offre une visibilité complète de votre environnement et permet de résoudre rapidement les problèmes.

Scripts d'automatisation

Vous pouvez utiliser des scripts pré-construits comme point de départ pour automatiser AWS WorkSpaces. Personnalisez-les en fonction de votre environnement et de vos besoins opérationnels.

Commencez à gérer AWS WorkSpaces gratuitement

Combien de temps encore pouvez-vous vous permettre de gérer AWS WorkSpaces sans visibilité et contrôle unifiés ?

XOAP simplifie l'ensemble du cycle de vie :

Configuration Management → définir des configurations système réutilisables
Application Management → automatiser la mise à disposition cohérente des logiciels
Platform Management → automatisation des opérations via des scripts et l'interface en ligne de commande (CLI)

En combinant ces éléments, vous pouvez standardiser et automatiser chaque étape de la gestion de vos AWS WorkSpaces.

Gestion facile d'AWS WorkSpaces

The post Make AWS WorkSpace management easy with XOAP appeared first on XOAP.

Choosing the right infrastructure: Cloud, on-premises or hybrid

Stella — lun, 16 mars 2026 14:01:51 +0000

Que vous lanciez une startup, modernisiez des systèmes d'entreprise ou exécutiez des charges de travail critiques, le débat autour des fournisseurs de cloud et de l'infrastructure traditionnelle continue d'évoluer.

Dans cette analyse, nous comparerons Amazon Web Services, Microsoft Azure et la plateforme Google Cloud à une infrastructure sur site et à des environnements hybrides, et nous examinerons dans quels cas chaque approche s'avère la plus pertinente.

Choisir une stratégie d'infrastructure n'est pas seulement une décision technique, c'est une décision financière et opérationnelle. Un mauvais choix peut entraîner des coûts cloud imprévus ou le problème plus discret mais tout aussi coûteux de la stagnation de l'innovation dans les environnements sur site.

L'essor du cloud computing

Au cours de la dernière décennie, le cloud computing a transformé la manière dont les entreprises développent et adaptent leurs logiciels. Au lieu d'acheter des serveurs et de mettre en place des centres de données physiques, les équipes peuvent déployer une infrastructure à l'échelle mondiale en quelques minutes. Vous pouvez augmenter la capacité lors des pics de demande et la réduire lorsque le trafic diminue. Cette flexibilité a abaissé la barrière à l'innovation.

Mais le cloud n'est pas automatiquement la meilleure réponse pour chaque charge de travail. Certains systèmes nécessitent un contrôle strict, une latence constante ou un isolement réglementaire. La bonne décision dépend de ce que vous exécutez et pourquoi.

Amazon Web Services (AWS)

AWS est le fournisseur de cloud le plus mature et le plus largement adopté. Il offre une gamme énorme de services, du calcul et du stockage aux outils d'IA, d'analytique et sans serveur. Pour les startups et les entreprises SaaS en forte croissance, AWS devient souvent le choix par défaut car il permet une mise à l'échelle rapide et simple.

Son empreinte mondiale est un avantage majeur pour les produits ayant des utilisateurs dans différentes régions. Vous pouvez déployer à proximité des clients sans avoir à construire vous-même d'infrastructure physique.

Le compromis est la complexité. Avec autant de services et d'options de tarification, les coûts peuvent devenir difficiles à gérer sans une gouvernance solide. Les équipes ont besoin de normes architecturales claires et d'une surveillance active. Lorsqu'elle est bien gérée, AWS offre une flexibilité inégalée.

Microsoft Azure

Azure est particulièrement performant dans les environnements d'entreprise. Les organisations qui dépendent déjà de Windows Server, d'Active Directory ou de Microsoft 365 trouvent souvent qu'Azure constitue une extension naturelle de leur configuration existante.

L'une des plus grandes forces d'Azure est sa capacité hybride. De nombreuses entreprises ne repartent pas de zéro. Elles ont des systèmes existants, des applications internes et des exigences de conformité qui ne peuvent pas simplement être déplacés du jour au lendemain. Azure permet aux entreprises de connecter leurs systèmes sur site à des services cloud de manière structurée.

Bien que certains services de niche puissent sembler moins complets qu'AWS, Azure fonctionne extrêmement bien pour les entreprises qui modernisent leur infrastructure existante plutôt que de construire des plateformes entièrement natives dans le cloud dès le départ.

Plateforme Google Cloud (GCP)

GCP se distingue par sa puissance dans les domaines des données, de l'analyse et des conteneurs. Il reflète l'expérience de Google dans l'exploitation de systèmes distribués à grande échelle. Pour les entreprises qui développent des plateformes axées sur l'analyse ou des applications pilotées par l'IA, GCP peut être très attractif.

Ses capacités Kubernetes sont largement respectées et ses performances réseau mondiales sont solides. Les équipes axées sur l'ingénierie apprécient souvent la simplicité et l'orientation performance de ses services.

GCP a traditionnellement eu une présence plus faible dans les grandes entreprises traditionnelles par rapport à AWS et Azure. Mais pour les architectures modernes axées sur les données, c'est un concurrent sérieux.

Infrastructure locale traditionnelle

L'infrastructure sur site signifie que vous possédez et gérez vos propres serveurs, votre équipement de stockage et de réseau. Vous contrôlez le matériel, les politiques de sécurité et l'accès physique.

Pour les industries hautement réglementées ou les systèmes qui exigent une résidence stricte des données, ce niveau de contrôle peut être essentiel. Cela peut également être judicieux pour des charges de travail stables qui ne fluctuent pas beaucoup au fil du temps.

Le revers de la médaille est une élasticité limitée. La mise à l'échelle nécessite l'achat et l'installation de nouveau matériel. Il y a également la maintenance continue, les cycles de renouvellement et les frais d'exploitation. Cela exige une planification à long terme et des investissements en capital.

Infrastructure hybride comme option pratique

L'infrastructure hybride combine les systèmes sur site avec un ou plusieurs fournisseurs de cloud. Au lieu de choisir un camp, les entreprises conçoivent en fonction des besoins de charge de travail.

Par exemple, des bases de données sensibles peuvent rester sur site pour répondre aux normes de conformité et de gouvernance, tandis que les applications orientées client s'exécutent dans le cloud pour bénéficier de l'élasticité et de la portée mondiale. Les charges de travail analytiques peuvent s'étendre dans le cloud pendant les périodes de pics de traitement et se réduire lorsque la demande diminue.

XOAP adopte cette approche hybride. Elle aide les organisations à standardiser, sécuriser et automatiser l'infrastructure entre les environnements locaux et cloud. Plutôt que de traiter chaque plateforme séparément, l'accent est mis sur la création de processus cohérents, d'une gouvernance et de contrôles opérationnels sur l'ensemble de l'environnement. Cette approche améliore la visibilité et maintient les normes de sécurité tout en permettant aux charges de travail de s'exécuter dans l'environnement qui correspond le mieux à leurs besoins.

Considérations relatives aux coûts

Les plateformes cloud fonctionnent sur un modèle de paiement à l'usage. Cela réduit les investissements initiaux et permet une expérimentation plus rapide. Cependant, sans surveillance et discipline, les coûts opérationnels peuvent augmenter rapidement.

L'infrastructure sur site nécessite un investissement en capital initial. Avec le temps, cela peut conduire à des structures de coûts prévisibles pour des charges de travail stables, mais cela réduit la flexibilité lorsque la demande change. Les modèles hybrides combinent les deux approches. Certains coûts restent fixes et prévisibles, tandis que d'autres s'adaptent à l'utilisation.

Choisir une infrastructure qui vous convient

Il n'y a pas de vainqueur unique dans la discussion AWS vs Azure vs GCP vs on-prem. Chaque modèle reflète un équilibre différent entre contrôle et évolutivité.

AWS offre une largeur et une portée mondiale inégalées. Azure s'aligne bien avec les entreprises centrées sur Microsoft et les environnements hybrides. GCP excelle dans les architectures intensives en données et natives dans le cloud. L'on-premise reste pertinent lorsque la conformité, la latence et le contrôle sont non négociables. L'infrastructure hybride rassemble ces mondes de manière pratique.

Le véritable avantage vient des décisions basées sur la charge de travail. Lorsque l'infrastructure est alignée sur les objectifs commerciaux plutôt que sur les tendances, elle devient une force concurrentielle plutôt qu'un simple choix technique.

Explorer XOAP

The post Choosing the right infrastructure: Cloud, on-premises or hybrid appeared first on XOAP.

XOAP

How to build a custom Windows 365 Cloud PC image with XOAP

Table des matières

Before you start: Connect your Azure subscription

The build at a glance

Step 1: Choose the operating system

Step 2: Define the builder configuration

Step 3: Define what goes on the image

Step 4: Combine it into an image definition

Step 5: Locate the finished image

Step 6: Hand off to Windows 365

Why the pipeline matters

Also running Azure Virtual Desktop?

Windows OS (re)deployment with XOAP and OSDCloud

Table des matières

Défis du déploiement du système d'exploitation Windows

Trois scénarios de déploiement

Scénario 1 : OS téléchargé depuis Internet

Scénario 2 : Démarrage WinPE avec un OS téléchargé depuis Internet

Scénario 3 : Redéploiement du système d'exploitation depuis un partage réseau, une source locale ou autre

Le déploiement sur l'appareil cible

Gestion continue après le déploiement

Pour commencer

How to create PSADT v4 packages with the XOAP Package Wizard

Table des matières

Qu'est-ce que le Sorcier de Packages XOAP ?

Comment créer un package

Étape 1 : Insérez votre programme d'installation

Étape 2 : Configuration

Étape 3 : Paramètres

Étape 4 : Construire votre phase d'installation

Remplissage automatique pour chaque cmdlet PSADT v4

Constructeur de fonctions

Étapes 5 et 6 : Phases de désinstallation et de réparation

Étape 7 : Aperçu et exécution de test

Étape 8 : Exporter

Deux fonctionnalités qui font gagner des heures

Applications installées

Importer Local

Obtenez le sorcier gratuit

Demande lien de téléchargement

How to: Bare metal OS deployment with XOAP

Table des matières

Comment XOAP aborde le déploiement bare metal

Méthodes de déploiement

Méthode 1 : Démarrage PXE (déploiement réseau)

Exigences en matière d'infrastructure

Processus d'installation

Expérience côté appareil

Méthode 2 : Clé USB (déploiement autonome)

Exigences en matière d'infrastructure

Processus d'installation

Expérience côté appareil

La pile de packages OSDCloud XOAP

Prêt à le voir en action ?

The reality of application delivery in 2026

La réalité de la livraison d'applications en 2026

À propos de l'épisode

Rencontrez notre hôte

Mario Istuk

Événements à venir et passés

AWS Systems Manager vs XOAP: Guide for MSPs

Table des matières

Ce que AWS Systems Manager fait bien

Où les deux produits diffèrent :

Gérer plusieurs clients

Environnements hybrides et mixtes

Gestion des images

Coût

Un exemple concret

Lequel ?

Outils différents, contextes différents

DOAG Voices: Cloud transformation reality check with Christian Reineke (XOAP)

Voix DOAG : Bilan de la transformation cloud avec Christian Reineke de XOAP

Automatisation, coûts et changement culturel

Événements à venir et passés

From legacy to scalable: Rethinking AVD management for MSPs

Table des matières

La vérité sur les outils “ suffisamment bons ”

Où les outils hérités échouent dans les environnements AVD

Demande
lien de téléchargement

Voix DOAG :
Bilan de la transformation cloud avec Christian Reineke de XOAP