La mise à jour de Parallels RAS sur un serveur unique est triviale — la console te propose une mise à jour automatique et ça marche. Mais sur une ferme distribuée avec des brokers séparés des Secure Gateways, des HALB, un Enrollment Server et un Reporting Service, laisser la console tout orchestrer d’un coup, c’est s’exposer à une ferme en état incohérent, des sessions coupées sans préavis et des composants incompatibles qui communiquent entre eux.
Cet article couvre la procédure complète de mise à jour de Parallels RAS v19 vers v21 sur une archi multi-composants, dans le bon ordre, avec les impacts réels sur les utilisateurs et les pièges à éviter. Elle est basée sur les KB officielles Parallels et validée en conditions réelles.
Pourquoi ne pas utiliser la console pour tout mettre à jour
La console RAS (Administration > Settings > Check now) interroge un repository Parallels pour vérifier les mises à jour disponibles. Ce repository peut avoir jusqu’à une semaine de retard par rapport à la page de téléchargement officielle. Tu risques donc de mettre à jour vers un build moins récent que celui disponible.
De plus, sur une ferme distribuée, l’ordre de mise à jour est critique. La console ne garantit pas cet ordre. Si elle met à jour un Secure Gateway avant que tous les brokers soient en v21, ou si elle relance des services sans respecter la séquence, tu te retrouves avec une ferme en état mixte que RAS ne sait plus gérer proprement.
La bonne approche : télécharger le package directement depuis la page officielle et mettre à jour composant par composant, dans l’ordre décrit ci-dessous.
Lien de téléchargement officiel : https://www.parallels.com/products/ras/download/links/
Prérequis avant de commencer
Avant de toucher quoi que ce soit :
Télécharger tous les installeurs depuis la page officielle Parallels : RASInstaller, RASAgentsInstaller, RASReporting, RASPerformanceMonitor, et la nouvelle appliance HALB v21. Les anciennes versions de HALB et de Reporting Service ne sont pas compatibles avec RAS v21.
Effectuer un snapshot de toutes les VMs concernées : les trois brokers, les deux Secure Gateways, les deux HALB, et la VM Reporting Service.
Exporter la configuration RAS depuis Console RAS > Administration > Export. C’est le filet de sécurité complémentaire aux snapshots.
Copier la clé de licence depuis Console RAS > Licensing, et noter la version actuelle depuis Help > About.
Identifier lequel des trois brokers est le broker primary. Il porte la licence — c’est visible dans Console RAS > Licensing. Il sera mis à jour en premier, contrairement à ce qu’on pourrait intuitivement penser.
Informer le client des impacts attendus : coupure des sessions tunnelisées lors de la mise à jour des Secure Gateways et du HALB actif, et perte de l’historique des rapports lors de la mise à jour du Reporting Service.
Planifier l’intervention en dehors des heures de pointe. Les coupures sont brèves mais réelles.
Ordre de mise à jour
1. Broker primary
Avant de lancer l’upgrade, stopper manuellement trois services sur chacun des brokers secondaires : Redundancy Service, Connection Broker Service et RAS Provider Service. Pour les retrouver rapidement dans services.msc, trier par la colonne Description — tous les services Parallels sont regroupés.
Lancer ensuite RASInstaller-21.1.26548.msi sur le broker primary. Un reboot est requis à la fin de l’installation. La Console RAS sera indisponible pendant le redémarrage — c’est normal, elle reconnecte automatiquement une fois le service remonté.
Note importante : si ton broker primary héberge également un Secure Gateway (archi typique d’un lab ou d’une petite ferme), la connexion des clients sera interrompue le temps du redémarrage puis reconnectée automatiquement. Sur une archi avec SG séparés, les clients ne verront rien pendant cette étape.
2 et 3. Brokers secondaires
Upgrader les brokers secondaires un par un. Après chaque upgrade, redémarrer les services qui avaient été stoppés à l’étape précédente. Vérifier que chaque broker est vert dans la Console RAS avant de passer au suivant.
4 et 5. Secure Gateways
C’est ici que la coupure est franche. Pendant la mise à jour d’un Secure Gateway, toutes les sessions tunnelisées passant par ce SG sont terminées. Pas une micro-interruption — une déconnexion réelle. Le SG restant continue à servir les nouvelles connexions pendant ce temps.
Mettre à jour le SG1, vérifier qu’il est remonté et vert, puis mettre à jour le SG2.
6 et 7. HALB
Commencer par le HALB passif. Le failover bascule automatiquement sur le HALB actif pendant la mise à jour. Vérifier que le failover s’est bien produit avant de toucher au HALB actif.
La mise à jour du HALB actif entraîne également une coupure franche le temps du basculement — même logique que les Secure Gateways. Prévoir ce moment en période creuse.
Ne jamais mettre les deux HALB à jour simultanément.
8. Agents RDSH et Remote PC
Les agents v19 communiquent correctement avec les brokers v21 — il n’y a pas de coupure de service tant que les agents ne sont pas mis à jour. En revanche la mise à jour reste obligatoire et doit être planifiée.
Depuis la Console RAS : Farm > Site > Tasks > Upgrade all Agents pour traiter tous les hôtes en lot. Sans coupure de service pour les utilisateurs connectés.
Sur les environnements avec templates et host pools, la mise à jour de l’agent sur le template nécessite ensuite de repasser le template en mode maintenance et de recréer les hôtes clonés. Sur une archi de prod avec de nombreux hôtes, cette recréation peut prendre du temps — la planifier séparément avec le client si nécessaire.
9. Enrollment Servers
Les Enrollment Servers sont des agents RAS à part entière — leur mise à jour se fait depuis la Console RAS, clic droit sur chaque Enrollment Server > Update Agent, ou via Tasks > Upgrade all Agents. Pendant le redémarrage de l’agent, les nouvelles authentifications SAML nécessitant l’émission d’un certificat smartcard seront en échec transitoire. Les sessions déjà établies ne sont pas impactées. Si tu disposes de deux Enrollment Servers en haute disponibilité, mettre à jour le premier, vérifier qu’il est vert, puis le second.
10. Performance Monitor
Lancer RASPerformanceMonitor-21.1.26542.msi directement par-dessus la version existante. Pas de désinstallation préalable, pas de reconfiguration. L’historique Grafana/InfluxDB est conservé.
Après redémarrage, vérifier que le dashboard est accessible dans la Console RAS depuis l’onglet Monitoring. Si rien n’apparaît, vérifier que le port TCP 3000 est accessible sur le serveur de monitoring.
11. Reporting Service
Avant tout : prévenir le client que la mise à jour efface l’historique des rapports. Les nouvelles sessions sont collectées immédiatement après réinstallation, mais les données historiques sont perdues.
Ne pas toucher à SQL Server Express 2022 ni à SSRS — ils sont pleinement compatibles avec RAS v21 et restent en place.
Se connecter sur la VM dédiée Reporting, lancer RASReporting-21.1.26542.msi, sélectionner Localhost comme emplacement de base de données et vérifier que l’instance SQL s’appelle bien RASREPORTING (la casse est importante).
Une fois installé, valider depuis Console RAS > Administration > Reporting > Test Connection.
Validation finale
Une fois tous les composants mis à jour, vérifier dans la Console RAS que tous les agents sont verts, que la licence affiche le bon nombre d’UBL concurrent, et tester une session utilisateur de bout en bout.
Sources officielles
- KB 131036 — Upgrading to Parallels Remote Application Server 21 : https://kb.parallels.com/131036
- KB 131037 — Parallels RAS v21 Release Notes : https://kb.parallels.com/131037
- KB 124973 — Performance Monitor installation : https://kb.parallels.com/en/124973
- KB 124323 — Performance Monitor troubleshooting : https://kb.parallels.com/124323
- Page de téléchargement officielle : https://www.parallels.com/products/ras/download/links/
