ℹ️ À savoir · En bref
MCS crée et maintient les machines d'un catalogue à partir d'une image maître : un seul système à patcher, des dizaines de VM identiques.
En non persistant, chaque redémarrage remet la machine dans l'état de l'image : les modifications locales disparaissent, ce qui garantit des machines propres et uniformes.
Objectifs de la fiche
- Comprendre ce que fait MCS sur l'hyperviseur ou le cloud.
- Choisir le type de catalogue et les options de cache.
- Mettre à jour une image, et revenir en arrière.
- Éviter les pièges de préparation d'image.
Comment ça marche
| Élément | Rôle |
|---|---|
| Image maître | VM de référence : Windows ou Linux, VDA installé en mode « image maître », applications |
| Snapshot | Version figée de l'image ; c'est elle que MCS consomme |
| Préparation de l'image | MCS démarre une copie pour la préparer (réarmement, licences, nettoyage) puis la publie comme disque de base |
| Disque d'identité | Petit disque propre à chaque VM : nom, compte machine AD, identité Citrix |
| Disque de différence | Reçoit les écritures de la VM ; remis à zéro au redémarrage en non persistant |
Types de catalogues
| Type | Comportement | Usage |
|---|---|---|
| Multisession (serveur) | Non persistant, réinitialisé au redémarrage | Applications publiées, bureaux partagés |
| Mono-session aléatoire | Non persistant, n'importe quelle machine du groupe | Bureaux standard |
| Mono-session statique, modifications jetées | Machine attribuée mais réinitialisée | Besoin d'une machine dédiée (nom, licences) sans persistance |
| Mono-session statique, persistant | Clone complet qui garde ses modifications | Développeurs, applications installées par l'utilisateur |
⚠️ Piège
Une machine persistante ne reçoit pas la nouvelle image lors d'une mise à jour du catalogue (seules les nouvelles machines l'utilisent) : elle se patche comme un poste classique (WSUS, Intune, ConfigMgr).
MCS I/O : le cache d’écriture
- Les écritures vont d'abord en mémoire, puis débordent sur un disque de cache dédié : moins d'IOPS sur le stockage partagé et des performances plus stables.
- Option du catalogue (taille mémoire et disque de cache) ; le composant MCS I/O doit être installé avec le VDA.
- Dimensionner la mémoire du cache en plus de la mémoire nécessaire aux sessions ; un cache trop petit déborde sur disque, un disque de cache plein bloque la VM.
Spécificités Azure
| Fonction | Intérêt |
|---|---|
| Profil de machine | Une VM modèle (ou une spec de modèle ARM) fournit taille, réseau, sécurité (Trusted Launch), balises Azure |
| Azure Compute Gallery | Réplique l'image pour créer beaucoup de machines plus vite |
| Disque OS éphémère | Disque sur le stockage local de l'hôte : pas de coût de disque géré, réinitialisation rapide (tailles de VM compatibles) |
| Type de disque à l'arrêt | Basculer le disque en HDD standard quand la VM est éteinte pour réduire le coût |
| Hibernation | Pour les bureaux mono-session : reprise rapide de la session (selon tailles et images compatibles) |
Gestion des images préparées
Citrix sépare désormais la préparation de l'image de la création du catalogue : une définition d'image regroupe des versions ; chaque version préparée peut servir à plusieurs catalogues, et la préparation se fait à l'avance.
- Création et mise à jour de catalogues beaucoup plus rapides, historique des versions, partage entre unités d'hébergement.
- Prérequis Windows : VDA 2311 ou plus récent avec le composant MCS I/O installé.
- Plateformes : Azure, AWS, VMware, XenServer, Nutanix, OpenShift… Limites : pas de cartes réseau multiples dans Azure ni de disques de données persistants.
Mettre à jour et revenir en arrière
PowerShell (SDK Citrix)
# Mise à jour d'un catalogue vers un nouveau snapshot (vSphere, exemple)
$img = "XDHyp:\HostingUnits\HU-Lille\W25-MASTER.vm\2026-11 W25.snapshot"
Publish-ProvMasterVMImage -ProvisioningSchemeName "CAT-W25-MS" -MasterImageVM $img
# Redémarrer progressivement les machines du groupe de mise à disposition
Start-BrokerRebootCycle -InputObject (Get-BrokerCatalog -Name "CAT-W25-MS") `
-RebootDuration 240 -WarningDuration 15 -WarningMessage "Redémarrage de maintenance"
💡 Astuce
Nomme les snapshots avec la date et le contenu (« 2026-11 W25 KB + VDA 2607 ») et garde les deux précédents : le retour arrière se fait en mettant à jour le catalogue vers l'ancien snapshot.
Teste chaque nouvelle image sur un catalogue de recette avant la production.
Identités des machines
| Type | Remarque |
|---|---|
| Active Directory | Classique : comptes machine créés par MCS dans une OU |
| Joint hybride Entra | Compte AD + enregistrement Entra ; attention aux délais de synchronisation |
| Joint à Entra ID | Sans AD ; compatible Rendezvous V2 sans Cloud Connector |
| Hors domaine | Ni AD ni Entra : kiosques, cas particuliers |
Pièges de préparation d’image
| Symptôme | Cause | Parade |
|---|---|---|
| Échec de préparation de l'image | Image non éteinte proprement, VDA mal installé, agent qui bloque | Journaux de préparation, arrêt propre, VDA en mode image maître |
| Machines non enregistrées après mise à jour | Image laissée dans un état de domaine incohérent, horloge | Ne pas faire de sysprep, image jointe au domaine et à l'heure |
| Démarrage lent de toutes les VM | Mises à jour, antivirus ou indexation au démarrage | Optimiser l'image (Citrix Optimizer), scans planifiés, exclusions |
| Stockage saturé | Disques de base multipliés (snapshots, stockages) | Supprimer les anciens snapshots, suivre l'espace par stockage |
| Agents en double dans les consoles | Identifiant unique d'agent figé dans l'image (sécurité, supervision) | Procédure « image maître » de chaque éditeur avant le snapshot |
🔷 En contexte Citrix
Pour Windows Server 2025 dans Azure sans accès Internet, prépare les mises à jour cumulatives hors ligne (MSU vérifiés, bon ordre) avant de figer le snapshot, puis valide l'ouverture de session en compte non administrateur sur le catalogue de recette.
Pour les VDA Linux, l'état de jonction AD de l'image et mcs.conf sont les deux points critiques (voir CTX-10).
À retenir
- Image maître → snapshot → préparation → disque de base → identité + différence par VM.
- Non persistant = propre à chaque redémarrage ; persistant = ne reçoit pas les nouvelles images.
- MCS I/O : cache mémoire + disque, à dimensionner.
- Images préparées : préparation à l'avance, réutilisable, versionnée.
- Retour arrière = mise à jour vers le snapshot précédent.
Auto-évaluation
Q1. Que contient le disque d'identité ?
→ Les informations propres à la VM : nom, compte machine AD et identité Citrix.
Q2. Tu mets à jour un catalogue persistant. Les machines existantes reçoivent-elles l'image ?
→ Non : seules les nouvelles machines l'utilisent. Les existantes se patchent comme des postes classiques.
Q3. Comment revenir à l'image précédente après un problème ?
→ Mettre à jour le catalogue vers le snapshot précédent puis redémarrer les machines.
Q4. Pourquoi installer MCS I/O ?
→ Pour le cache d'écriture en mémoire et sur disque dédié (moins d'IOPS sur le stockage) et pour la gestion des images préparées.