Parallels publicó Parallels RAS Core v21.2.1-27306 el 30 de julio de 2026. Presentada como una versión de mantenimiento, tiene en realidad un perfil muy marcado: de nueve entradas en el changelog, tres tratan de Hyper-V y tres de impresión. El resto toca la identidad (Enrollment Server, Web Authentication) y el balanceo de carga.
Esto es lo que cambia sobre el terreno y quién debería parchear primero.
La novedad: preferencias de impresión expuestas en el User Portal
Las preferencias de impresión de documentos definidas dentro de una sesión remota —incluida la selección de bandeja— se exponen ahora al imprimir mediante la RAS Universal Printer en sesiones del User Portal, para clientes y extensiones de terceros.
En la práctica: hasta ahora, si un usuario del User Portal elegía una bandeja concreta desde una aplicación publicada, esa elección se ignoraba o llegaba de forma incoherente a la impresora local. Es el escenario clásico de los entornos con papel con membrete en la bandeja 1 y papel normal en la bandeja 2: asesorías, despachos de abogados, departamentos de RR. HH. Ahora la selección llega a su destino.
Un detalle: esta exposición se dirige explícitamente a clientes y extensiones de terceros, es decir, a integraciones construidas sobre el User Portal y no al Parallels Client nativo.
La corrección crítica: el bloqueo del Provider Agent
Es la única entrada de la build marcada como Critical Fix. El Provider Agent podía bloquearse en tres situaciones: durante la gestión de Hyper-V, durante la clonación de VDI o al limpiar sesiones de invitado activas mientras un host se apagaba. Las causas indicadas son errores de acceso intermitentes y reinicios de conexión.
Por qué importa: el Provider Agent es el componente que habla con el hipervisor. Si cae, el broker pierde la visibilidad sobre el pool VDI: no hay aprovisionamiento, no hay gestión de energía y los hosts quedan en estados incoherentes. En infraestructuras que clonan en horario laboral para absorber carga, es una caída funcional inmediata.
La palabra intermitente es clave: este tipo de bloqueo no se reproduce a voluntad, aparece bajo carga o durante las ventanas de mantenimiento. Si ves en tus registros de eventos reinicios inexplicables del servicio RAS Provider, probablemente acabas de encontrar la explicación.
Hyper-V Cluster: dos correcciones que te ahorran limpieza manual
Dos correcciones distintas que cuentan la misma historia: la gestión de los clústeres Hyper-V tenía margen de mejora.
Borrado de hosts que dejaba recursos huérfanos
El borrado de hosts de un Hyper-V Cluster podía fallar de forma esporádica y dejar máquinas virtuales o recursos de disco huérfanos en el hipervisor. Es el típico bug que pasa desapercibido: la consola de RAS muestra el host como eliminado, el administrador sigue con lo suyo y los archivos VHDX siguen ocupando el CSV durante meses. En un pool VDI que se recrea con frecuencia, la acumulación es rápida.
Si usas una versión anterior, merece la pena auditar tus CSV antes de parchear: compara las máquinas que conoce el broker con lo que realmente hay en el clúster.
Clonación en nodos no disponibles
La clonación de hosts VDI en un Hyper-V Cluster podía fallar cuando el sistema intentaba colocar nuevos hosts en nodos en pausa, aislados o en cuarentena.
Es un escenario de mantenimiento de manual: pones un nodo en pausa para aplicar parches, RAS lo sigue considerando un destino válido y el aprovisionamiento se rompe. La corrección tiene en cuenta el estado real del nodo. En la práctica, vaciar un nodo para mantenimiento ya no exige coordinarlo con la suspensión del aprovisionamiento en RAS.
Universal Printing: bandejas correctas y compatibilidad con AVD recuperada
Nombres de bandeja que por fin significan algo
Las preferencias de impresión podían mostrar nombres de bandeja genéricos o sin relación cuando una impresora redirigida no tenía preferencias específicas en el cliente. Desde el punto de vista del usuario: etiquetas que no corresponden a nada físico y un ticket de soporte cada vez.
Las opciones Paper Source, Paper Form y Print Quality corresponden ahora correctamente a los ajustes de la impresora local.
Impresión universal en AVD
Más drástico: la RAS Universal Printing simplemente fallaba en los recursos de Azure Virtual Desktop. En las infraestructuras híbridas que publican tanto RDSH on-premises como AVD, eso significaba una experiencia de impresión de dos velocidades según el origen del recurso. Ya está corregido.
Identidad: Enrollment Server y Web Authentication
Enrollment Server: contaminación silenciosa del directorio
La corrección más delicada de la build. Si la entidad de certificación no está disponible cuando arranca el Enrollment Server, el servidor podía generar un número excesivo de certificados en Active Directory y no limpiar las claves privadas asociadas.
Son dos problemas en uno. Primero, la proliferación de objetos de certificado en el directorio, que engorda los objetos de usuario. Segundo, claves privadas abandonadas en el servidor sin un certificado utilizable asociado: una acumulación que no pinta nada ahí, y en un componente sensible por definición.
El escenario desencadenante es de lo más corriente: un reinicio del Enrollment Server mientras la CA está caída, ya sea por mantenimiento, un reinicio agrupado tras el Patch Tuesday o un corte de red entre ambos. Si usas inicio de sesión con tarjeta inteligente o Web Authentication, esta corrección por sí sola justifica la actualización.
Web Authentication: el error que no lo es
Web Authentication podía mostrar un error de nombre de usuario o contraseña incorrectos con certificados recién emitidos, aunque el inicio de sesión funcionaba una vez cerrado el aviso.
Técnicamente menor, operativamente irritante: es justo el tipo de comportamiento que genera llamadas al soporte y mina la confianza de los usuarios en la plataforma. Un usuario acostumbrado a ignorar un error ignorará también el siguiente, incluido el que de verdad importa.
Balanceo de carga: asignación múltiple cuando el búfer se agota
A los usuarios se les podían asignar por error varios hosts del mismo host pool al lanzar una aplicación si no había hosts disponibles en el búfer.
El escenario: el búfer está vacío —pico de conexiones por la mañana, aprovisionamiento que va con retraso o un pool infradimensionado— y el mecanismo de asignación entrega varias máquinas al mismo usuario en lugar de una. Resultado: hosts consumidos para nada, lo que agrava precisamente la escasez que causó el problema. Una bola de nieve de manual.
Si dimensionas tus búferes al mínimo para controlar costes —algo típico en Azure—, esta corrección te interesa.
Las notas de la versión completas están disponibles en el KB 131037.
