Parallels a publié le 30 juillet 2026 la build Parallels RAS Core v21.2.1-27306. Présentée comme une release de maintenance, elle a en réalité une identité très marquée : sur les neuf entrées du changelog, trois concernent Hyper-V et trois l’impression. Le reste touche l’identité (Enrollment Server, Web Authentication) et le load balancing.
Voici ce que ça change concrètement sur le terrain, et qui doit patcher en priorité.
La nouveauté : les préférences d’impression exposées dans le User Portal
Les préférences de document définies dans une session distante — y compris la sélection du bac papier — sont désormais exposées lors d’une impression via l’Imprimante Universelle RAS dans les sessions User Portal, pour les clients tiers et les extensions.
Concrètement : jusqu’ici, un utilisateur du User Portal qui sélectionnait un bac spécifique depuis son application publiée voyait ce choix ignoré ou remonté de façon incohérente vers l’imprimante locale. C’est le scénario classique des environnements avec papier à en-tête dans le bac 1 et papier standard dans le bac 2 — cabinets comptables, cabinets juridiques, services RH. Le choix est maintenant transmis.
À noter : cette exposition vise explicitement les clients tiers et les extensions, donc les intégrations construites au-dessus du User Portal plutôt que le Parallels Client natif.
Le correctif critique : crash du Provider Agent
C’est le seul item classé Critical Fix de la build. Le Provider Agent pouvait crasher dans trois situations : pendant la gestion Hyper-V, pendant le clonage VDI, ou lors du nettoyage des sessions invitées actives pendant l’arrêt d’un hôte. Les causes remontées sont des erreurs d’accès intermittentes et des réinitialisations de connexion.
Pourquoi c’est critique : le Provider Agent est le composant qui dialogue avec l’hyperviseur. Quand il tombe, le broker perd sa visibilité sur le pool VDI — plus de provisioning, plus de power management, et des hôtes qui restent dans des états incohérents. Sur une infrastructure qui clone en journée pour absorber la charge, c’est une panne fonctionnelle immédiate.
Le mot intermittent est important : ce type de crash ne se reproduit pas à la demande, il se manifeste sous charge ou pendant les fenêtres de maintenance. Si vous avez des redémarrages inexpliqués du service RAS Provider dans vos journaux d’événements, vous tenez probablement votre explication.
Hyper-V Cluster : deux fixes qui évitent le nettoyage manuel
Deux correctifs distincts, mais qui racontent la même histoire — la gestion des clusters Hyper-V était perfectible.
Suppression de hosts laissant des ressources orphelines
La suppression de hosts Hyper-V Cluster pouvait échouer de façon sporadique, laissant des machines virtuelles ou des ressources disque orphelines dans l’hyperviseur. C’est le genre de bug qu’on ne voit pas passer : la console RAS affiche le host comme supprimé, l’administrateur passe à autre chose, et les VHDX continuent d’occuper le CSV pendant des mois. Sur un pool VDI qui tourne avec du recreate régulier, l’accumulation est rapide.
Si vous êtes sur une version antérieure, il vaut la peine d’auditer vos CSV avant de patcher : comparez la liste des machines connues du broker avec celle du cluster.
Clonage vers des nœuds indisponibles
Le clonage de hosts VDI dans un cluster Hyper-V pouvait échouer lorsque le système tentait de placer les nouveaux hosts sur des nœuds en état paused, isolated ou quarantined.
C’est un scénario de maintenance typique : on met un nœud en pause pour appliquer des correctifs, RAS continue à le considérer comme une cible de placement valide, et le provisioning se casse. Le correctif consiste à tenir compte de l’état réel du nœud. Concrètement, le drain d’un nœud pour maintenance n’a plus besoin d’être synchronisé avec une suspension du provisioning côté RAS.
Universal Printing : des bacs corrects et le support AVD rétabli
Des noms de bacs enfin réels
Les préférences d’impression pouvaient afficher des noms de bacs génériques ou sans rapport lorsqu’une imprimante redirigée ne disposait pas de préférences spécifiques côté client. Résultat côté utilisateur : des libellés qui ne correspondaient à rien de physique, et un ticket de support à chaque fois.
Les options Paper Source, Paper Form et Print Quality correspondent maintenant correctement aux réglages de l’imprimante locale.
L’impression universelle sur AVD
Plus radical : RAS Universal Printing échouait purement et simplement sur les ressources Azure Virtual Desktop. Pour les infrastructures hybrides qui publient à la fois du RDSH on-premise et de l’AVD, cela signifiait une expérience d’impression à deux vitesses selon l’origine de la ressource. C’est corrigé.
Identité : Enrollment Server et Web Authentication
Enrollment Server : la pollution silencieuse de l’annuaire
Le correctif le plus vicieux de la build. Si l’autorité de certification est indisponible au démarrage de l’Enrollment Server, celui-ci pouvait générer un nombre excessif de certificats dans l’Active Directory, et échouer à nettoyer les clés privées associées.
Deux problèmes en un. D’abord la prolifération d’objets certificats dans l’annuaire, qui alourdit les objets utilisateurs. Ensuite des clés privées qui restent en place sur le serveur sans être associées à un certificat exploitable — de l’accumulation qui n’a rien à faire là, sur un composant sensible par définition.
Le scénario déclencheur est banal : un redémarrage de l’Enrollment Server pendant que la CA est indisponible — maintenance, reboot groupé après Patch Tuesday, coupure réseau entre les deux. Si vous faites du logon par carte à puce ou de la Web Authentication, ce correctif justifie à lui seul la montée de version.
Web Authentication : l’erreur qui n’en est pas une
La Web Authentication pouvait afficher une erreur de nom d’utilisateur ou de mot de passe incorrect avec des certificats nouvellement émis, alors que la connexion aboutissait malgré tout après fermeture du message.
Techniquement mineur, opérationnellement pénible : c’est exactement le genre de comportement qui génère des appels au support et qui érode la confiance des utilisateurs dans la plateforme. Un utilisateur à qui on apprend à ignorer une erreur ne fera pas non plus confiance à la suivante, celle qui compte.
Load balancing : l’assignation multiple quand le buffer est vide
Les utilisateurs pouvaient être assignés à tort à plusieurs hosts d’un même host pool lors du lancement d’une application, si aucun host n’était disponible dans le buffer.
Le scénario : le buffer est à sec — pic de connexions matinal, provisioning en retard, ou pool sous-dimensionné — et le mécanisme d’assignation attribue plusieurs machines au même utilisateur au lieu d’une seule. Résultat, des hosts consommés pour rien, ce qui aggrave la pénurie à l’origine du problème. Effet boule de neige classique.
Si vous dimensionnez vos buffers au plus juste pour maîtriser les coûts — typiquement sur Azure — c’est un correctif qui compte.
Les notes de version complètes sont disponibles dans la KB 131037.
