En la última nota llegamos a instalar y configurar Remote Desktop Connection Broker, en la infraestructura que ya teníamos de Remote Desktop Session Host implementada con RemoteApp y Remote Desktop Web Access.
Vamos ahora a poner “todo junto” y demostrar cómo Remote Desktop Connection Broker se encara de repartir la carga entre los servidores Remote Desktop Session Host, e inclusive cómo permite a un usuario con una sesión desconectada reconectarse a la misma, desde otra máquina.
Finalmente veremos algunas consideraciones importantes relacionadas con RemoteApp
Para hacer las pruebas, he creado cuatro usuarios más con características similares al ya creado anteriormente (RD-User1) y pertencientes al grupo RD-Users.
Además y aunque en varias ocasiones utilizaré Fast User Switching (Cambio rápido de usuario) en la misma máquina, he añadido un segundo cliente Windows 7 llamado CL2
Comencemos 🙂
En CL1 iniciamos sesión con RD-User1, entramos por Web Access y abrimos una aplicación (Calculadora por ejemplo)
Luego en RD1 y en RD2 busquemos en el Task Manager (Administrador de Tareas), en la ficha Users (Usuarios), dónde se ha creado la sesión de RD-User1.
En mi caso fue en RD2
Ahora en CL2 iniciemos sesión con RD-User2, igual que en el caso anterior ingresemos por Web Access y que acceda a la misma aplicación.
Igual que en el caso anterior, vemos que esta sesión se ha abierto en el otro servidor. En mi caso fue en RD1
Con esto podemos verificar que el sistema reparte la carga. Si queremos asegurarnos mejor, podemos usando Fast User Switching en CL1 y CL2 conectarnos con otros usuarios (RD-User3 y RD-User4) y ver cómo el sistema sigue repartiendo en forma alternada
Un detalle: con RD-User3 iniciemos la aplicación WordPad que más adelante nos servirá para probar la reconexión, dejando un texto sin salvar, y cerrando sesión en el cliente (no la aplicación sino la sesión)
Observemos en los Task Manager de cada RD cómo va repartiendo a los usuarios/sesiones
Ahora en CL1, cerremos la sesión (Logoff) de RD-User3 (la del WordPad), e inciemos sesión con este usuario (RD-User3) en CL2. Igual que ya hicimos conectemos por Web Access e inciemos WordPad.
Veremos que WordPad se abrirá con el documento que habíamos dejado inconcluso y sin guardar en la sesión anterior en CL1
Consideraciones adicionales de RemoteApp
Sigamos avanzando aún más con RemoteApp. Cuando utilizamos Remote Desktop, apenas el usuario cierra la sesión de escritorio remoto podemos observar que se elimina la sesión de Remote Desktop Sessión Host
¿Pero qué sucede cuando en lugar de un escritorio remoto estamos usando RemoteApp?
Aunque el usuario cierre la aplicación, cierre sesión en el explorador, y aún cerrando la sesión en la máquina cliente, la sesión queda abierta y desconectada en el Remote Desktop Session Host
Observemos las propiedades relacionadas con esto en la cuenta de usuario
Y veamos en RD1, Remote Desktop Session Host Configuration, propiedades de RD-tcp
En ninguno de los casos hay definido un cierre de sesiones desconectadas, o inactivas, ni aún un limite en la duración de las sesiones
Por lo tanto si deseamos reducir el consumo de recursos en los servidores Remote Desktop Session Host, o en las propiedades de los usuarios deberíamos seguramente poner un límite a estas duraciones
Resumiendo, en esta nota hemos verificado el funcionamiento conjunto de Remote Desktop Session Host, usando RemoteApp, accediendo el cliente por Remote Desktop Web Access, y repartiendo carga con Remote Desktop Connection Host
