Montando un escenario de Virtualización del Escritorio: Virtualizando una aplicación con el Secuenciador de App-V

Posts anteriores:

• Montando un escenario de Virtualización del Escritorio: El objetivo
• Montando un escenario de Virtualización del Escritorio: El Servidor de App-V
• Montando un escenario de Virtualización del Escritorio: El Cliente de App-V

Hola.

En los dos últimos posts de esta serie dejamos montado lo que constituye la base del sistema de distribución y ejecución de aplicaciones virtualizadas. Falta la parte fundamental, que es el proceso de virtualizar la aplicación y generar el/los paquetes correspondientes, que es los que se conoce como proceso de secuenciación.

Como de costumbre, antes de continuar, os recomiendo un par de imprescindibles, si bien internet está llena de guías con pistas y trucos para secuenciar aplicaciones, tanto genéricas como de casos particulares:

• App-V 4.5 Sequencing Guide
• Sequencing Best Practices en el App-V Team Blog

Para ilustrar el proceso, voy a utilizar una aplicación que todos conocemos, y que nos lleva acompañando en las demos durante ya unos años porque ofrece un ejemplo de aplicación de esta tecnología muy jugoso. El programa Padre (Renta 2008) de la Agencia Tributaria. Así además, los más rezagados pueden aun aprovecharse de todo esto antes de que se termine el plazo para presentar la declaración del año pasado (para los que me leáis desde fuera de España, el programa Padre es una aplicación que se usa para ayudarnos en nuestra declaración anual de impuestos). Sin embargo, el éxito en la correcta secuenciación de una aplicación depende MUCHO del grado de conocimiento que se tenga de ella. Dado que de los que se trata es de meter en una especie de burbuja todo lo relativa a ellas, cuanto más sepamos del uso que hace del sistema de archivos, objetos del sistema, registro, etc. mejor seremos capaces de meter dentro todo lo que necesita para funcionar.

1.- Preparando la máquina para secuenciar e instalación del secuenciador.

La secuenciación de la aplicación la haremos en una máquina física o virtual que tendrá dos particularidades. Primero, tendrá como sistema operativo la versión “más baja” de todos aquellos sobre los que correrá posteriormente virtualizada. Generalmente se utiliza Windows XP en la que habremos definido al menos dos particiones sobre el mismo o diferentes discos. El segundo de ellos lo marcaremos con la letra Q:. La guía de recomendaciones sobre cómo configurar la estación de trabajo sobre la que secuenciamos está en apartado “Sequencer Workstation Configuration” de la guía mencionada arriba.

No voy a insistir mucho sobre la instalación del propio secuenciador, porque es un puro siguiente, siguiente, finalizar que no tiene ningún misterio.

2.- Secuenciación de la aplicación.

La secuenciación de una aplicación se lleva a cabo en cuatro fases. En tres de ellas el secuenciador monitoriza su instalación, ejecución y personalización, y en la última se genera el paquete teniendo en cuanta como será utilizado posteriormente.

Primeramente, el secuenciador nos solicita un nombre para la aplicación:

Tras ello, nos pide que lancemos el proceso de instalación de la aplicación, así como la carpeta que usaremos como directorio principal dentro de la partición Q: que tenemos preparada para ello. En este caso me estoy saltando una ”best-practice”, ya que debería haber elegido un nombre más representativo de la versión (AEAT2008, RENTA2008, etc.) para que si quiero tener diferentes versiones de la aplicación corriendo simultáneamente, cada una use su propia carpeta:

Se carga el entorno virtual, y se nos solicita que se inicie la instalación de la aplicación:

 

Lanzamos la instalación de la aplicación y seguimos el proceso que marque. De hecho la instalación esta sucediendo realmente en la estación donde estemos secuenciando. Tras finalizar el proceso, se descarga automáticamente el entorno virtual:

Es posible que la aplicación necesite que se agregue algún archivo en particular para que funcione correctamente. Dependencias de ejecutables o dlls, ficheros específicos de configuración, etc. Este es un punto donde cobra especial importancia el conocimiento de la aplicación. En nuestro caso, que sepamos, no se requiere nada en particular:

 

Cambiamos de fase, y el secuenciador nos pide que lancemos las aplicaciones que se han agregado al sistema durante el proceso de instalación y que las configuremos. En este caso el paquete tendrá tres componentes individuales, que se usarán y descargarán según se vayan o no ejecutando. La propia aplicación, la Ayuda y el Léame. Pedimos al secuenciador que las ejecute. De nuevo, este paso es importante y será más efectivo según el conocimiento que se tenga de la aplicación. Es el momento de configurar la apariencia de la aplicación y asegurarnos de que se instancian todos los componentes que pudiera contener, de modo que todo eso vaya a parar dentro del paquete. En este caso lo cierto es que no tiene demasiado misterio (podría eliminarse, por ejemplo, el mensaje de bienvenida del Renta 2008 para que no aparezca en las posteriores ejecuciones de la aplicación. Este primer uso decidirá además que partes se meten en la primera descarga mínima que hará el cliente para usar la aplicación por primera vez (es posible que en ese primer uso se utilicen ya directamente todos los ficheros y no se observe una descarga progresiva durante el uso posterior de la aplicación).

 

Tras esta fase de ejecución/configuración, dejamos que el secuenciador genere el paquete de la aplicación virtualizada:

 

Por último, deberemos personalizar el paquete. Aunque parece trivial, lo cierto es que tiene su miga. Aquí será donde “conectaremos” este paquete en particular con la configuración que hayamos elegido para nuestro sistema de distribución de aplicaciones. En la segunda imagen se observa cómo se configura el servidor de streaming, la carpeta a partir de la cual se intentará localizar el paquete (si especie de “directorio virtual” usando un paralelismo con IIS) y los sistemas operativos en los que puede funcionar el paquete. También se puede generar un MSI para distribuir la aplicación mediante cualquier técnica de despliegue de software.

 

Por último se elige el nombre del paquete, se salva, y en la carpeta elegida tenemos todos estos ficheros:

• El .sprj (Sequencer Project File) contiene toda la información para importar el paquete en la consola del servidor de App-V.
• Los .osd: Son los “equivalentes” a los ficheros de configuración de una máquina virtual, para entendernos. Son un ficherito editable con el bloc de notas, aunque no está de más hacerse con el OSD Editor.
• El .stf es el propio paquete de la aplicación virtualizada.

Por último, veamos cómo se importa todo esto en la consola del servidor de App-V mediante el asistenta para importar aplicaciones (puede hacerse también manualmente a base de los OSD y los STF):

Se nos pregunta dónde se quiere que aparezcan los iconos y los grupos de usuarios de Directorio Activo que tendrán derecho a utilizarlos. Solamente a ellos se les mostrará la existencia de la aplicación correspondiente:

Por último, el asistente de importación copiará los .OSD y las carpetas con los iconos a los lugares adecuados dentro del sistema de directorios virtuales del servidor de management de App-V. Por razones que no vienen al caso, entre las que se encuentra la vaguería, esta imagen es inconsistente con algunas de las anteriores en el nombre UNC (vamos, que esta sacado de otro servidor diferente y debiera poner [\\TS-APPV\App-V-Content\](file://\\TS-APPV\App-V-Content\)… para ser consistente con lo que especifiqué aquí.

 

Una vez colocada cada cosa en si lugar el proceso es el que sigue. Todo este proceso se encuentra perfectamente detallado en el documento App V Application Publishing And Client Interaction:

• El usuario inicia sesión.
• El cliente de App-V va al servidor y por http/https es informado de las aplicaciones que hay para ese usuario y, en este caso, el path UNC donde localizar el .osd (primer punto de fallo, que lo que este en las propiedades de la aplicación sea incongruente con donde realmente esta el .osd. Si el cliente no es capaz de localizar el osd donde se le indica, la aplicación ni siquiera aparece).
• Se procesa el OSD. Se analizar si el paquete funciona en el Sistema Operativo actual.
• En función de la información del OSD, o de lo que se indicó en esta opción de la instalación del cliente (que manda), se compone la URL desde que se descargará el stf por rtsp/rtsps. El path en el que se intenta localizar dicho fichero es el que marca la ultima de las imágenes del párrafo anterior (el path relativo en las propiedades del paquete). Este es otro punto de fallo frecuente. Si el cliente no localizar el .stf usando estos protocolos, la aplicación se ve pero no se lanza.

He de reconocer que hasta la fecha he sido incapaz de montar un sistema como el descrito en estos tres post que funcionase a la primera. Fallos de sintaxis en los paths y en las URLs, olvidos a la hora de poner la lista de sistemas operativos soportados, etc. son frecuentes cuando se monta algo de este estilo. No os desaniméis, que, como todo, cuando se le pilla el tranquillo la cosa es ciertamente gratificante y te sentirás el dueño y señor de las aplicaciones que se despliegan en tu infraestructura.

En los próximos capítulos, Remote Desktop Services y VDI, que combinan muy bien con todo esto :-)

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Posts anteriores: Montando un escenario de Virtualización del Escritorio: El objetivo Montando un escenario

• Anonymous
  June 03, 2009
  Esta genial este producto. Virtualiza prácticamente cualquier aplicación. Nosotros lo estamos usando de momento para desplegar aplicaciones en entornos Citrix pero estamos planeando seriamente distribuir el agente por los desktops y que los usuarios puedan lanzar aplicaciones empaquetadas con softgrid (ahora app-v).