RASInsider
← Tous les articles
11 novembre 2026 / Guides pratiques / 5 min de lecture

Mise à jour Parallels RAS 21 vers 22 : la procédure complète sur une ferme multi-composants

Parallels RAS : mise a jour de la version 21 vers la 22

Le bouton « Check for Updates » de la console est pratique sur un lab, mais sur une ferme distribuée il met à jour les composants dans un ordre que vous ne maîtrisez pas — et c’est la porte ouverte aux mauvaises surprises. Voici la procédure manuelle et ordonnée que j’applique en production pour passer de la v21 à la v22, validée en lab au préalable. Et un conseil d’entrée : la 22 abandonne plusieurs systèmes et composants, donc on vérifie la compatibilité avant de lancer quoi que ce soit.

La v22 est sortie le 29 octobre 2026 (build 22.0.0.28160 ; appliance HALB 22.0.0.1-28161 depuis le 4 novembre).

Ce que vous gagnez en 22

Rien que sur la sécurité, la cuvée est costaude :

  • Device Posture avant connexion : on vérifie la conformité du poste (antivirus, OS, navigateur) avant d’ouvrir la session.
  • SAML comme second facteur (MFA) et filtrage par IP publique : des règles d’authentification différentes selon l’origine, interne ou externe.
  • Durcissement des Secure Gateways avec limitation de débit contre les rafales de connexions.
  • Vérification de ferme de confiance : un serveur non approuvé ne peut plus rejoindre le déploiement.
  • File Access : les partages SMB Windows directement dans le User Portal.
  • Côté plateforme : support des déploiements AVD hybrides, VMware vSphere 9 comme provider VDI, mises à jour d’agent en Drain Mode sur les RDSH, affichage de l’uptime des hôtes, et enregistrement de session (expérimental).

À vérifier avant tout : les OS et composants abandonnés

C’est le vrai piège de cette montée de version. Si l’un de ces éléments est encore chez vous, traitez-le avant l’upgrade :

  • Windows Server 2012 R2 n’est plus supporté pour l’agent RD Session Host.
  • SQL Server et SSRS 2016 ne sont plus supportés par le Reporting : il faut être en 2019 ou 2022.
  • Les anciennes appliances HALB et les anciennes versions de Reporting ne sont pas supportées avec la 22.
  • FSLogix 25.09 est retiré, 26.08 est ajouté.
  • Côté postes et clients : fin du support de Windows 10 32-bit (client et agents PC/Guest), macOS 13, iOS/iPadOS 17, Android 10 et 11, Debian 11, Fedora 40/41 et IGEL OS 11.

Au passage, la 22 ajoute le support de vSphere 9, macOS 27, iOS/iPadOS 27, Android 17, Ubuntu 26.04 et Azure Stack HCI Core Edition pour le provider Hyper-V.

L’architecture cible

On raisonne sur une ferme typique : un ou plusieurs Connection Brokers, des Secure Gateways, des HALB devant les gateways, et des hôtes RDSH ou VDI — le tout sur des serveurs séparés, avec éventuellement un Performance Monitor et un Reporting dédiés.

Avant de commencer

  • ⚠ Patchez entièrement Windows Server 2022 avant de lancer l’installeur. Sur un WS2022 pas à jour et du matériel avec CET (Control-flow Enforcement Technology), .NET peut ne pas s’initialiser : le service RAS Web Administration ne démarre pas et l’installation (ou l’upgrade) est annulée et revient en arrière. Visez au minimum le build 21H2, OS Build 20348.5622, redémarrez, puis relancez l’installeur en administrateur. Parallels n’installe pas les mises à jour Windows pour vous ; à défaut de pouvoir patcher, installez sur Windows Server 2025.
  • Vérifiez votre upgrade insurance : elle n’est pas incluse automatiquement avec un contrat de support.
  • Lisez les release notes v22 : nouveautés, prérequis logiciels, licences Microsoft, support des providers VDI.
  • Exportez la configuration de la ferme et rangez-la ailleurs.
  • Snapshots de tous les serveurs virtuels, en priorité le serveur de licence.
  • Sauvegardez la clé de licence (RAS Console → Licensing) et notez les détails d’installation (Help → About).
  • Assurez-vous que le serveur de la console a accès à Internet (installation et activation).
  • Planifiez hors activité, confirmez une ferme saine, identifiez le broker primaire, et téléchargez les installeurs depuis le site Parallels plutôt que via la console.

L’ordre de mise à jour

1. Le broker primaire d’abord

C’est le point le moins intuitif : on met à jour le primaire avant les secondaires. Si vous avez plusieurs Connection Brokers, arrêtez d’abord sur chaque broker secondaire le Redundancy Service, le Connection Broker Service et le Provider Agent Service — sous peine de perte de données. Lancez ensuite l’installeur sur le primaire, redémarrez si demandé. Si l’installeur échoue sur « Service RAS Web Administration failed to start » et fait un rollback, ce n’est ni les droits ni le firewall : c’est le combo WS2022 non patché + CET vu plus haut — mettez le serveur à jour et relancez.

2. Les brokers secondaires

Un par un. Mettez à jour, redémarrez les services que vous aviez arrêtés, et vérifiez que chaque broker est sain avant de passer au suivant.

3. Les Secure Gateways

⚠ La mise à jour d’une gateway coupe toutes ses sessions tunnelées. Planifiez hors-heures et mettez à jour une gateway à la fois pendant que l’autre continue de servir le trafic.

4. Les HALB

Retour de terrain : pendant la montée du broker puis des Secure Gateways, les HALB continuent de répartir le trafic. On peut donc remplacer les appliances une par une, sans coupure — toujours le nœud passif d’abord, on valide, on bascule, puis on fait l’autre. Attention : le HALB n’a pas d’upgrade in-place, et une appliance antérieure n’est pas supportée à terme avec une ferme 22. On déploie donc la nouvelle appliance 22.0 en reprenant la configuration réseau de l’ancienne, et on ne reste pas en version mixte une fois la migration finie. (Voir Inside HALB pour le détail de l’appliance.)

5. Les agents RDSH, Remote PC et VDI

Ils se mettent à jour depuis la console, sans couper les sessions en cours. ⚠ Mais tant qu’un hôte n’est pas à jour, aucune nouvelle session ne peut s’y ouvrir : priorisez les hôtes en haute disponibilité. Nouveauté bienvenue en 22 : les mises à jour d’agent en Drain Mode, qui préservent l’état de drain de l’hôte. Les pools basés sur template demandent une recréation des clones planifiée à part ; les host pools peuvent utiliser l’Auto-upgrade.

6. Les Enrollment Servers

On les traite comme des agents, un par un en haute disponibilité. Pendant les redémarrages, de nouvelles connexions SAML par carte à puce peuvent échouer brièvement.

7. Le Performance Monitor

Installez le nouveau MSI par-dessus l’existant : l’historique est conservé. Vérifiez le dashboard et le port 3000.

8. Le Reporting Service

⚠ Seule étape irréversible : l’historique des rapports est effacé. Vérifiez d’abord que vous êtes bien sur SQL Server / SSRS 2019 ou 2022 (2016 n’est plus supporté). Conservez le nom d’instance et faites le test de connexion.

Validation post-upgrade

  • Tous les composants verts et vérifiés dans la console.
  • Le compteur Concurrent UBL correspond à vos licences utilisateurs achetées.
  • Un test utilisateur réel (ouverture de session, appli publiée).
  • Le dashboard Performance Monitor répond.
  • Le test de connexion Reporting passe.
  • Redémarrez les serveurs qui le réclament encore.

Sources

Envie de voir RASInsider en priorité dans les actualités de Google ?Ajouter RASInsider comme source préférée sur Google

Cet article vous a été utile ?