Parallels hat Parallels RAS Core v21.2.1-27306 am 30. Juli 2026 veröffentlicht. Offiziell ein Wartungsrelease, hat es tatsächlich ein sehr eigenes Profil: Von neun Changelog-Einträgen betreffen drei Hyper-V und drei den Druck. Der Rest dreht sich um Identität (Enrollment Server, Web Authentication) und Lastverteilung.
Hier ist, was sich in der Praxis ändert und wer zuerst patchen sollte.
Die neue Funktion: Druckeinstellungen im User Portal
Druckeinstellungen für Dokumente, die in einer Remotesitzung festgelegt werden — einschließlich der Wahl des Papierfachs —, werden jetzt beim Drucken über den RAS Universal Printer in User-Portal-Sitzungen an Clients und Erweiterungen von Drittanbietern weitergegeben.
Konkret: Wählte ein User-Portal-Benutzer bisher in einer veröffentlichten Anwendung ein bestimmtes Fach, wurde diese Wahl ignoriert oder uneinheitlich an den lokalen Drucker weitergereicht. Das ist das klassische Szenario in Umgebungen mit Briefpapier in Fach 1 und Normalpapier in Fach 2 — Steuerkanzleien, Anwaltskanzleien, Personalabteilungen. Jetzt kommt die Auswahl an.
Bemerkenswert: Diese Weitergabe richtet sich ausdrücklich an Clients und Erweiterungen von Drittanbietern, also an Integrationen auf Basis des User Portal und nicht an den nativen Parallels Client.
Der kritische Fix: Absturz des Provider Agent
Das ist der einzige Eintrag dieses Builds, der als Critical Fix gekennzeichnet ist. Der Provider Agent konnte in drei Situationen abstürzen: bei der Hyper-V-Verwaltung, beim Klonen von VDI oder beim Bereinigen aktiver Gastsitzungen während des Herunterfahrens eines Hosts. Als Ursachen werden sporadische Zugriffsfehler und Verbindungsabbrüche genannt.
Warum das wichtig ist: Der Provider Agent ist die Komponente, die mit dem Hypervisor spricht. Fällt er aus, verliert der Broker die Sicht auf den VDI-Pool — keine Provisionierung, keine Energieverwaltung, und Hosts bleiben in inkonsistenten Zuständen zurück. In Infrastrukturen, die während der Arbeitszeit klonen, um Last abzufangen, ist das ein sofortiger Funktionsausfall.
Das Wort sporadisch ist hier entscheidend: Diese Art von Absturz lässt sich nicht auf Knopfdruck reproduzieren, sondern tritt unter Last oder in Wartungsfenstern auf. Wenn Ihre Ereignisprotokolle unerklärliche Neustarts des Dienstes RAS Provider zeigen, haben Sie wahrscheinlich gerade die Erklärung gefunden.
Hyper-V-Cluster: zwei Fixes, die manuelles Aufräumen ersparen
Zwei getrennte Korrekturen, die dieselbe Geschichte erzählen: Die Behandlung von Hyper-V-Clustern hatte Verbesserungspotenzial.
Gelöschte Hosts hinterlassen verwaiste Ressourcen
Das Löschen von Hosts aus einem Hyper-V-Cluster konnte sporadisch fehlschlagen und verwaiste virtuelle Maschinen oder Datenträgerressourcen im Hypervisor zurücklassen. Genau die Art von Bug, die unbemerkt bleibt: Die RAS-Konsole zeigt den Host als entfernt an, der Administrator macht weiter, und die VHDX-Dateien belegen monatelang Platz auf dem CSV. Bei einem VDI-Pool, der regelmäßig neu erstellt wird, sammelt sich das schnell an.
Wenn Sie eine ältere Version einsetzen, lohnt sich vor dem Patchen eine Prüfung Ihrer CSVs: Vergleichen Sie die Maschinen, die der Broker kennt, mit dem, was tatsächlich im Cluster liegt.
Klonen auf nicht verfügbare Knoten
Das Klonen von VDI-Hosts in einem Hyper-V-Cluster konnte fehlschlagen, wenn das System versuchte, neue Hosts auf Knoten zu platzieren, die angehalten, isoliert oder unter Quarantäne standen.
Ein Lehrbuchszenario aus der Wartung: Sie halten einen Knoten an, um Patches einzuspielen, RAS betrachtet ihn weiterhin als gültiges Platzierungsziel, und die Provisionierung bricht ab. Der Fix berücksichtigt jetzt den tatsächlichen Zustand des Knotens. Praktisch heißt das: Einen Knoten für die Wartung zu leeren, muss nicht mehr mit dem Aussetzen der Provisionierung auf RAS-Seite abgestimmt werden.
Universal Printing: korrekte Fächer und wiederhergestellte AVD-Unterstützung
Fachnamen, die endlich etwas bedeuten
Die Druckeinstellungen konnten generische oder unpassende Fachnamen anzeigen, wenn für einen umgeleiteten Drucker keine spezifischen Einstellungen auf Client-Seite vorlagen. Aus Sicht des Benutzers: Bezeichnungen, die zu nichts Physischem passen, und jedes Mal ein Support-Ticket.
Die Optionen Paper Source, Paper Form und Print Quality entsprechen jetzt korrekt den Einstellungen des lokalen Druckers.
Universal Printing unter AVD
Drastischer: Das RAS Universal Printing funktionierte auf Azure-Virtual-Desktop-Ressourcen schlicht nicht. Für hybride Infrastrukturen, die sowohl lokale RDSH als auch AVD veröffentlichen, bedeutete das ein Druckerlebnis zweiter Klasse, je nachdem, woher die Ressource kam. Jetzt behoben.
Identität: Enrollment Server und Web Authentication
Enrollment Server: stille Verschmutzung des Verzeichnisses
Der heikelste Fix des Builds. Ist die Zertifizierungsstelle beim Start des Enrollment Server nicht erreichbar, konnte der Server eine übermäßige Anzahl von Zertifikaten im Active Directory erzeugen und die zugehörigen privaten Schlüssel nicht bereinigen.
Das sind zwei Probleme in einem. Erstens wuchern Zertifikatsobjekte im Verzeichnis und blähen die Benutzerobjekte auf. Zweitens bleiben private Schlüssel ohne nutzbares Zertifikat auf dem Server zurück — eine Ansammlung, die dort nichts zu suchen hat, und das auf einer per Definition sensiblen Komponente.
Das auslösende Szenario ist banal: ein Neustart des Enrollment Server, während die CA nicht verfügbar ist — Wartung, ein gesammelter Neustart nach dem Patch Tuesday, ein Netzwerkausfall zwischen beiden. Wer Smartcard-Anmeldung oder Web Authentication einsetzt, für den rechtfertigt allein dieser Fix das Upgrade.
Web Authentication: der Fehler, der keiner ist
Web Authentication konnte mit neu ausgestellten Zertifikaten eine Fehlermeldung zu falschem Benutzernamen oder Passwort anzeigen, obwohl die Anmeldung nach dem Schließen der Meldung erfolgreich war.
Technisch harmlos, im Betrieb ärgerlich: Genau so ein Verhalten erzeugt Support-Anrufe und untergräbt das Vertrauen der Benutzer in die Plattform. Wer gelernt hat, einen Fehler zu ignorieren, ignoriert auch den nächsten — einschließlich des einen, der wirklich zählt.
Lastverteilung: Mehrfachzuweisung bei leerem Puffer
Benutzern konnten beim Start einer Anwendung fälschlicherweise mehrere Hosts innerhalb desselben Host-Pools zugewiesen werden, wenn im Puffer keine Hosts verfügbar waren.
Das Szenario: Der Puffer ist leer — morgendliche Anmeldespitze, nachhinkende Provisionierung oder ein zu knapp bemessener Pool —, und der Zuweisungsmechanismus gibt demselben Benutzer mehrere Maschinen statt einer. Ergebnis: Hosts werden umsonst verbraucht, was genau den Engpass verschärft, der das Problem ausgelöst hat. Ein klassischer Schneeballeffekt.
Wenn Sie Ihre Puffer knapp dimensionieren, um die Kosten im Griff zu behalten — typischerweise auf Azure —, ist dieser Fix relevant.
Die vollständigen Release Notes finden Sie in KB 131037.
