Me gustaría compartir una historia breve pero cierta que ilustra una lección importante. Recientemente, una empresa global de servicios profesionales decidió acelerar su transición a la nube. Desde su perspectiva, Azure Virtual Desktop (AVD) parecía la elección obvia.
Contaban con miles de usuarios. Experimentaban picos estacionales de personal. Su objetivo era reducir rápidamente su infraestructura on-premise.
AVD cumplía todos los requisitos, pero lo que nadie se esperaba era que la impresión—una idea tardía al comienzo de la planificación—casi descarrilaría el despliegue.
El despliegue AVD que parecía perfecto sobre el papel
Los pilotos tempranos discurrieron sin problemas. Los tiempos de login eran rápidos. Las aplicaciones funcionaban bien. El equipo de desktop declaró el éxito, hasta que los usuarios de negocio empezaron a usarlo en producción.
En ese momento, el output produjo el embotellamiento
En pocos días, comenzaron a emanar las quejas típicas—solo que esta vez a más volumen:
- “Mis documentos van a la impresora incorrecta”.
- “La impresión funcionaba ayer pero no hoy”.
- “Cada vez que entro, veo diferentes impresoras”.
- “Esta sesión se bloqueó cuando intenté imprimir”.
La raíz no era AVD. El problema era una arquitectura on-premise de impresión Windows heredada que chocaba con un nuevo modelo de desktop nativo de la nube. Este entorno todavía dependía de servidores de impresión Windows basados en el anfitrión de la sesión y cientos de drivers específicos de vendedores. También había llevado una reliquia del entorno heredado al nuevo entorno de desktop en la nube: mapeos de impresoras que estaban conectados a dispositivos que ya no existían.
LRS cambia el output para un mundo de desktops en la nube
En lugar de intentar “reparar la impresión” dentro de AVD, el equipo reformuló la pregunta. ¿Qué ocurriría si la función de impresión no le perteneciera al desktop en absoluto?
La empresa implementó una plataforma de gestión de output corporativa diseñada para mantenerse fuera del nivel de desktop virtual. El cambio fue arquitectónico, no cosmético.
Pronto, la impresión se desconectó de las sesiones AVD. Los anfitriones del desktop virtual Azure dejaron de gestionar las impresoras y las colas, lo que ayudó a eliminar el caos relacionado con los drivers y el movimiento de las configuraciones específicas de anfitrión. Desconectar la impresión del desktop también permitió la instalación de colas estandarizadas, donde las colas provistas durante el login se basaban en el nombre del ordenador, subred, usuario o grupo.
Este fue un primer paso en la dirección correcta, aunque la externalización de la función de gestión de la impresión también ofrecía otros beneficios. Por ejemplo, cientos de drivers de impresoras se redujeron a menos de diez, resultando en imágenes más pequeñas, aprovisionamiento más rápido de anfitrión y una gran reducción de las horas de trabajo para soporte de la impresión por desktop.
Como resultado de estos cambios, el output se convirtió en algo más impulsado por la política. En lugar de depender del mapeo Windows, el output se encaminaba en base al flujo de trabajo y la función del usuario. El contexto de la aplicación determinaba la entrega. Además, los usuarios habían dejado de pensar en las impresoras por completo… y ese era exactamente el objetivo.
El personal de TI recuperó la visibilidad de sus procesos de impresión, y por primera vez, la organización pudo responder a pregustas como:
- ¿Quién es el que más imprime?
- ¿Desde qué aplicaciones?
- ¿Hacia qué destinos?
- ¿Dónde se están produciendo fallos?
El output dejó de ser un agujero negro. Como resultado, la adopción de AVD se aceleró. Una vez estabilizada la impresión, los grupos de anfitriones AVD se adaptaron limpiamente y los tiempos de login continuaron reduciéndose. Se produjo una disminución drástica de las solicitudes de soporte relacionadas con la impresión, por lo que el equipo de desktop pudo dedicar menos tiempo a apagar incendios y más tiempo a optimizar su entorno.
Lo que empezó como un riesgo para el proyecto – el proceso de impresión – se convirtió en un multiplicador de fuerza.
La lección más grande
Los proyectos AVD no fallan debido a flujos de trabajo particulares, sino que fallan porque sin una infraestructura de impresión como LRS, continúan dependiendo del spooling de impresión Windows basado en tecnología de la década de 1990. LRS sitúa a tu empresa en el futuro mediante la creación de una infraestructura de impresión a prueba de balas. Nuestro software se construye desde la base y con la seguridad, la eficiencia, la tolerancia de fallos y la fiabilidad en mente.
TL;DR — con LRS, AVD puede entregar todo lo que promete.