Introducción a la Virtualización de Aplicaciones con App-V

La principal plataforma de Microsoft para la Virtualización de Aplicaciones es APP-V, conocido anteriormente como SoftGrid Application Virtualization, cuyo origen está en la compra de la empresa Softricity, que fue adquirida por Microsoft en 2006. Desde la perspectiva de Microsoft, tenemos más alternativas para el despliegue de Aplicaciones Virtualizadas, como podría ser Windows Virtual PC con Windows XP Mode, o Microsoft Enterprise Desktop Virtualization (MED-V), aunque con ciertas diferencia (tanto Windows Virtua PC con Windows XP Mode como MED-V, basan su tecnología en la virtualización de una Máquina Virtual completa, mientras que App-V se limita a virtualizar estrictamente las Aplicaciones). Además, ciertas aplicaciones no pueden ser virtualizadas con App-V, como es el caso de Internet Explorer, por lo que quizás la solución de Virtualización de Aplicaciones que necesitemos deba estar formada por un entorno mixto (ej: App-V + Med-V).

Podemos distinguir entre dos ediciones distintas de App-V:

• App-V for Desktops. Facilita la creación de Aplicaciones Virtuales para su despliegue directamente sobre los equipos de escritorio que las ejecutarán. App-V for Desktops está disponible como parte del producto Microsoft Desktop Optimization Pack (MDOP), a través de Software Assurance, y/o de subscripciones MSDN y TechNet (téngase en cuenta las limitaciones de las licencias correspondientes a MSDN y TechNet).
• App-V for Terminal Services (TS) ó App-V for Remote Desktop Services (RDS). Facilita la creación de Aplicación Virtuales para su despliegue a equipos Terminal Server sobre los que se ejecutarán. De este modo, los usuarios o equipos clientes, se utilizarán sesiones RDP sobre dichos equipo Terminal Server, accediendo de este modo, a las Aplicaciones Virtualizadas. App-V for Terminal Services ó App-V for Remote Desktop Services, están disponible como un producto independiente y/o a través de subscripciones MSDN y TechNet (téngase en cuenta las limitaciones de las licencias correspondientes a MSDN y TechNet). Actualmente, está disponible para descargar directamente desde la Web de Microsoft el App-V 4.6 for Remote Desktop Services (RDS).

A continuación se muestra una pantalla capturada de la correspondiente página de descarga de una Subscripción MSDN, en la que se puede observar la diferenciación en estos productos.

¿Qué es App-V? ¿Cómo se ejecutan las Aplicaciones Virtuales?

App-V permite crear (secuenciar) Aplicaciones Virtuales, las cuales son empaquetadas y distribuidas a los clientes (sean clientes de escritorio o servidores de Terminal Server o Remote Desktop Services), ejecutándose dichas aplicaciones en los propios clientes. El truco está, en que estas Aplicaciones Virtuales son ejecutadas de forma aislada sobre en entorno virtual dentro de los propios equipos clientes, el cual actúa como un contenedor o SandBox. Dicho entorno virtual (App-V Virtual Environment) ofrece todos los recursos necesarios para hacer posible la ejecución de la Aplicación Virtual en el propio equipo cliente, para lo cual se utiliza el App-V Client, que deberá estar instalado en los equipos clientes en los que deseemos ejecutar Aplicaciones Virtuales, ya que es el encargado de crear dicho entorno virtual. De este modo, se consiguen virtualizar diferentes tipos de recursos para su utilización por parte de las Aplicaciones Virtuales:

• Virtual COM. Gestiona los objetos COM creados por la Aplicación Virtual, y evita conflictos con los mismos objetos existente fuera del App-V Virtual Environment.
• Virtual directory, Virtual file, y Virtual file system. Permiten gestionar el acceso al sistema de ficheros, creando un sistema de ficheros virtual para su utilización por parte de las Aplicaciones Virtuales.
• Virtual registry. Gestiona el acceso al Registro de Windows realizado por la Aplicación Virtual, de tal modo, que las aplicaciones instaladas localmente en el cliente puedan acceder directamente al Registro de Windows, mientras que las Aplicaciones Virtuales sean redireccionadas a un Registro de Windows Virtual.
• Virtual services. Actúa como un Service Control Manager para los Servicios de Windows ejecutados en el App-V Virtual Environment como parte de la ejecución de las Aplicaciones Virtuales.

Este entorno virtual, no sólo permite la ejecución de las Aplicaciones Virtuales, sino que gracias a que dichas Aplicaciones Virtuales se ejecutan de forma aislada en su entorno virtual, se evitan los conflictos entre las aplicaciones.

Evidentemente, las Aplicaciones Virtuales de App-V se ejecutan en el propio equipo cliente de App-V, consumiendo su Memoria y CPU, accediendo a sus unidades de red, etc. Sin embargo, mientras con MED-V se virtualiza un máquina completa (o varias), con App-V tan sólo se virtualiza una aplicación concreta (o varias).

Otra ventaja de utilizar Aplicaciones Virtuales con App-V, es que debido a que estas se ejecutan de forma aislada dentro de su propio contenedor o entorno virtual (App-V Virtual Environment), las Aplicaciones Virtuales de App-V pueden permanecer inmunes a borrados o modificaciones accidentales de ficheros críticos de la aplicación necesarios para su ejecución, ya que los usuarios no podrán ver los ficheros y ramas de registro de la Aplicación Virtual. Esto puede ayudar a reducir las llamadas a los equipos de soporte y HelpDesk.

En consecuencia, cuando llegue el final del ciclo de vida de una Aplicación Virtual de App-V, es suficiente con dejar de utilizarla, es decir, no será necesario desinstalarla, y además no evitaremos molestas desinstalaciones que dejan mogollón de morralla por todas partes (ficheros y directorios sin borrar, ramas del registro que tampoco se eliminan, etc.).

Otra utilidad de utilizar Aplicaciones Virtuales de App-V se encuentra en la posibilidad de controlar el número máximo de usuarios concurrentes que pueden acceder a una Aplicación Virtual de App-V, para lo cual, se puede aprovechar la característica de licenciamiento, pudiendo administrar las licencias de forma centralizada desde el App-V Management Server. El App-V Management Server permite la creación de diferentes tipos de licencias:

• Licencias de acceso concurrente. Las utilizadas habitualmente para controlar el número de usuarios concurrentes utilizando una aplicación.
• Licencias de acceso ilimitado. Sirven para poder evaluar el consumo de licencias de un aplicación, previo a su configuración con Licencias de acceso concurrente.
• Licencias con nombre (Named Licenses). Permite asignar licencias a usuarios específicos.

Secuenciación de Aplicaciones ¿Qué es el App-V Sequencer?

El proceso de convertir una aplicación tradicional en una Aplicación Virtual, es lo que se llama secuenciación de una aplicación, y la herramienta que utilizaremos para tal tarea es el App-V Sequencer. Al secuenciar una aplicación, estaremos generando un paquete con la nueva Aplicación Virtual, para su posterior despliegue y ejecución. Para ello, el App-V Sequencer incluye un asistente que permite monitorizar la instalación de una aplicación sobre la unidad Q (hablamos de la unidad Q o la unidad App-V, un poco más adelante) y monitorizar una primera ejecución representativa (capturando las rutas, claves de registro, etc., utilizadas por la aplicación y en el proceso de instalación), que nos permitirá crear el correspondiente paquete de Aplicación Virtual, para su posterior despliegue y publicación. A continuación se muestran los ficheros resultantes de secuenciar una aplicación, en nuestro caso de ejemplo, la aplicación TextPad.

Entrando en algo más de detalle:

• TextPad Icons. Esta carpeta contiene los iconos utilizados por la Aplicación Virtual, con el fin, de poder utilizarlos en el equipo cliente.
• TextPad.msi. Este fichero se genera de manera opcional (sólo si indicamos al App-V Sequencer que deseamos generar un fichero MSI), y sirve para poder desplegar nuestra Aplicación Virtual a través de su instalación manual (modo StandAlone) o bien a través de cualquier sistema ESD (Enterprise Software Deployment) como Microsoft SMS (Systems Management Server), Microsoft SCCM (System Center Configuration Manager), u otros de terceros.
• TextPad.osd. La extensión OSD corresponde a Open Software Descriptor. Se trata de un fichero XML que le indica al equipo cliente de App-V cómo obtener la Aplicación Virtual (desde el App-V Management Server o desde el App-V Streaming Server) y cómo ejecutar dicha Aplicación Virtual, es decir, contiene la propia definición del paquete.
• TextPad.sft. Contiene una o varias Aplicaciones Virtuales (en nuestro caso, solamente una, el TextPad), almacenadas en bloques, para poder ser ofrecidas directamente haciendo Streaming.
• TextPad.sprj. La extensión SPRJ corresponde a Sequencer Project. Se trata de un fichero XML con información propia del App-V Sequencer, en relación con el proyecto de secuenciación de la Aplicación Virtualizada.
• TextPad_manifest.xml. Fichero XML de manifiesto del paquete.

Una vez que hemos secuenciado una aplicación, deberemos copiar los ficheros resultantes a la carpeta Content del App-V Management Server (alternativamente, los ficheros OSD y los iconos podrían ser publicados en un servidor Web para ser entregados a los clientes App-V a través de HTTP o de HTTPS). Seguidamente, es habitual importar la nueva Aplicación Virtual en el App-V Management Server, utilizando la App-V Management Console, para lo cual utilizaremos los ficheros SPRJ o de los ficheros OSD, teniendo en cuenta que con los ficheros OSD deberemos importar cada Aplicación Virtual de una en una, y con el fichero SPRJ se importarán todas las Aplicaciones Virtuales de una única atacada.

Debe tenerse en cuenta, que no se pueden instalar sobre la misma máquina el App-V Sequencer y el App-V Desktop Client. De hecho, el App-V Sequencer debe instalarse en una máquina independiente, sin ningún otro componente de App-V, y con un sistema operativo similar al de las máquinas destino que actuarán como clientes de App-V. Es más, quizás nos pueda interesar tener varias máquinas con el App-V Sequencer, por ejemplo, para secuenciar aplicaciones para diferentes versiones y/o arquitecturas de sistema operativo (ej: Windows XP x86, Windows 7 x64, etc.). Es una buena práctica utilizar Máquinas Virtuales para el App-V Sequencer, ya que aprovechando los Snapshots y/o los discos de diferenciación, pueden utilizarse dichas Máquinas Virtuales para secuenciar una aplicación en particular, pero a continuación podríamos revertir el estado de la Máquina Virtual utilizada a su estado inicial, para así poder volver a secuenciar una nueva aplicación cuando nos resulte necesario, sin necesidad de ir acumulando porquería y evitando problemas en posteriores secuenciaciones por los restos de aplicaciones instaladas anteriormente. Es decir, así siempre podríamos secuenciar nuevas aplicaciones partiendo de un mismo y limpio punto de partida. En el caso de utilizar Máquinas Virtuales y revertir su estado para cada nueva secuenciación, resulta de utilidad activar a través de GPOs la política Domain member: Disable machine account password changes, que podemos encontrar en:

• Windows Server 2008: Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options – Domain member: Disable machine account password changes.
• Windows Server 2003: Computer Configuration – Windows Settings – Security Settings – Local Policies – Security Options – Domain member: Disable machine account password changes.

Es una buena práctica utilizar una unidad Q (la unidad App-V) y un directorio raíz sobre la unidad Q con nomenclatura 8.3 (los nombres cortos del MSDOS de toda la vida) para la instalación durante la secuenciación de la aplicación. Es decir, durante la secuenciación de la aplicación, no instalaremos la misma sobre C:\Program Files\Microsoft Office (por poner un ejemplo), sino que instalaremos sobre Q:\Off2k7\Microsoft Office (por poner otro ejemplo). Realmente, es indiferente si decidimos utilizar como unidad App-V una unidad Q o una unidad J, pero si es interesante elegir una en particular (mojémonos con la Q, por seleccionar alguna), de tal modo que tanto el equipo que utilicemos como secuenciador, como los equipos destino que actuarán como clientes de App-V, todos ellos tengan una unidad Q, para la instalación de todas las Aplicaciones Virtuales, cada una sobre su propio directorio (nada de un Q:\Program Files compartido, si no un Q:\Off2k7, un Q:\Off2k10, un Q:\AdoRead, etc., y sobre cada uno, instalar el correspondiente software, como sería un Q:\Off2k7\Microsoft Office, un Q:\Off2k7\Microsoft Office Communicator, un Q:\Off2k10\Microsoft Office, un Q:\AdoRead\Reader 9.0, etc.).

Siguiendo con el tema de la secuenciación de aplicaciones, es posible crear actualizaciones de las Aplicaciones Virtuales existente de App-V, de tal modo, que puedan ser publicadas y de este modo actualizar de forma sencilla y masiva nuestra Aplicación Virtual. Para ello se puede utilizar el paquete original y con el App-V Secuencer, realizar una actualización del paquete a la nueva versión, para seguidamente actualizar el correspondiente paquete en el App-V Management Server. El proceso es similar a la creación/secuenciación de un nuevo paquete de Aplicación Virtual, excepto que utilizaremos la opción Upgrade a Package (deberemos abrir el paquete que deseamos actualizar, para seguidamente a través de asistente monitorizar sus actualización), en lugar de la opción Create a Package.

Llegados a este punto, es importante entender la diferencia entre Aplicación Virtual y Paquete. Al importar una Aplicación Virtual en el App-V Management Server, se creará tanto una Aplicación Virtual como un Paquete. Entonces, ¿Cuál es la diferencia? Pues bien, la Aplicación Virtual representa el fichero OSD y el fichero ICO de la propia Aplicación Virtual, esto es, la definición de la propia aplicación, que suele desplegarse habitualmente por HTTP o por SMB a través de una ruta UNC. Sin embargo, el Paquete representa el fichero SFT que contiene la propia Aplicación Virtual en sí, que habitualmente desplegaremos por Streaming.

Publicación de Aplicaciones Virtuales con App-V

Una vez que hemos secuenciado nuestras aplicaciones, y por tanto, tenemos disponibles los paquetes correspondientes a nuestras Aplicaciones Virtuales, llega el momento de Publicar nuestras Aplicaciones Virtuales de App-V a nuestros clientes App-V. Existen principalmente tres métodos de Publicación de Aplicaciones Virtuales de App-V.

• Utilizando el App-V Management Server.
• Utilizando un sistema ESD (Enterprise Software Deployment) como Microsoft SMS (Systems Management Server), Microsoft SCCM (System Center Configuration Manager), u otros de terceros. De este modo es posible desplegar de forma masiva los ficheros MSI correspondientes a los paquetes de las Aplicaciones Virtuales de App-V.
• Ejecutando manualmente en los MSI correspondientes a los paquetes de las Aplicaciones Virtuales de App-V, en cada equipo cliente de App-V (a este método se le conoce como StandAlone).

Recapitulamos: Componentes de App-V y un vistazo a la Arquitectura

Ahora que ya hemos cogido algunos conceptos e idea de qué es eso de App-V, es un buen momento para recapiturar, y hacer el ejercicio de identificar los diferentes posibles componentes de una arquitectura de App-V y tomar conciencia de diferentes escenarios o arquitecturas posibles con App-V.

Una infraestructura de App-V está formada por diferentes elementos o componentes. A continuación, a modo de resumen, se comentan los diferentes componentes de App-V, teniendo en cuenta que no es necesario tenerlos todos instalados para poder utilizar App-V.

• App-V Management Server. Se utiliza para publicar a los Clientes App-V los accesos directos de las Aplicaciones Virtuales y sus los tipos de fichero asociados a las mismas. También se utiliza para realizar Streaming bajo demanda de las Aplicaciones Virtuales a los Clientes App-V autorizados, para lo cual puede utilizar los protocolos RTSP, RTSPS, HTTP o HTTPS. Otra utilidad es poder utilizar la característica de licenciamiento, por ejemplo para poder controlar el número máximo de usuarios concurrentes que pueden acceder a una Aplicación Virtual de App-V. También permite hacer Active Upgrade, es decir, actualizar automáticamente una aplicación en todos los equipos clientes, en el siguiente ciclo de refresco de publicación (publishing refresh cycle). El App-V Management Server debe instalarse como un servidor dedicado, y requiere acceso a una base de datos SQL Server y a la carpeta Content. Es habitual utilizar múltiples App-V Management Server. Se administra utilizando la App-V Management Console.
• App-V Management Web Service. Es el componente intermedio entre la Management Console y el Data Store, accedido desde la Management Console utilizando .Net Remoting. Puede instalarse en el App-V Management Server, o en un servidor independiente, el cual debe ejecutar IIS6 o superior, MDAC 2.7 o superior, y .Net Framework 2.0.
• App-V Data Store. Consiste en una base de datos SQL Server 2005 o 2008, la cual almacena toda la información de la infraestructura App-V (App-V Management Server Configuration and Reporting, Logging, Licensing, etc.).
• App-V Streaming Server. Puede verse como una versión ligera del App-V Management Server, que permite hacer Streaming de Aplicaciones Virtuales y soporta Active Upgrade, que no requiere de SQL Server, y que no incluye ni la App-V Management Console ni el App-V Management Web Service (utiliza ACLs para conceder permisos a los ficheros de las Aplicaciones Virtuales). Es decir, su función es hacer Streaming de los ficheros SFT a través de RTSP ó RTSPS. Evidentemente, requiere acceso a la una carpeta Content, que podría ser una carpeta Content local, con los correspondientes permisos (ACLs).
  Existen diferentes escenarios de despliegue, como no utilizar el App-V Streaming Server (es decir, utilizar sólo el App-V Management Server), utilizar sólo el App-V Streaming Server (y no utilizar el App-V Management Server, en cuyo caso, deberemos evaluar qué método utilizar para el despliegue de los iconos y ficheros OSD a los Clientes App-V), y utilizar el App-V Management Server en la oficina central y App-V Streaming Server en las sucursales (esto requiere configurar el valor del Application Source Root de los Clientes App-V de las sucursales especificando los datos del App-V Streaming Server de la sucursal, consiguiendo de este modo sobrescribir la información de los propios ficheros OSD, que apuntarían al App-V Management Server, es decir, los iconos y ficheros OSD se publican desde el App-V Management Server en las oficinas centrales, mientras que las Aplicaciones Virtuales o ficheros SFT se descargan por Streaming desde los App-V Streaming Server locales de cada sucursal; También sería posible configurar los valores Icon Source Root y OSD Source Root en los equipos Clientes App-V).
• App-V Management Console. Se trata de una consola MMC a través de la cual se pueden importar Aplicaciones Virtuales al App-V Management Server desde los ficheros SPRJ o desde los ficheros OSD (esto creará los correspondientes Paquetes), crear Grupos de Aplicaciones (facilita la gestión de las Aplicaciones Virtuales, como la concesión de permisos, accesos directos, licenciamiento, etc.), gestionar las asociaciones de ficheros a Aplicaciones Virtuales, gestionar los Paquetes (estos representan los ficheros SFT), gestionar el licenciamiento, gestionar los Grupos de Servidores (crear o eliminar Grupos de Servidores, añadir servidores de App-V o de Streaming a los Grupos de Servidores, configurar el puerto RTSP o RTSPS utilizado por los servidores, configurar la utilización de memoria de los servidores, etc.), gestionar informes (ej: pueden crearse diferentes tipos de informes, exportarlos como PDF, etc.), gestionar políticas (Provider Policies), pertenencia al grupo de administración de App-V, etc. La App-V Management Console puede instalarse localmente con el App-V Management Server, o también en equipos de escritorio que tengan MMC 3.0 y .Net Framework 2.0.
• App-V Sequencer. Se trata de la herramienta utilizada para convertir una aplicación, en Aplicación Virtual. Ya fue presentada con mayor detalle, anteriormente en este mismo artículo.
• App-V Client. Se trata del software instalado en los equipos que actúan como clientes de la infraestructura App-V. Este software realiza varias funciones, desde gestionar la obtención de las Aplicaciones Virtuales haciendo Streaming desde un App-V Management Server o desde un App-V Streaming Server, hasta proporcionar el entorno virtual para la ejecución de las propias Aplicaciones Virtuales de App-V. Como ya comentamos, existen dos tipos de clientes App-V: App-V for Desktops y App-V for Terminal Services (TS) ó App-V for Remote Desktop Services (RDS). El Cliente App-V debe configurarse con el nombre o IP de un Servidor de Publicación, del que pueda obtener los iconos y ficheros OSD. Existen varios detalles adicionales de interés. Por ejemplo, la primera vez que se ejecuta una Aplicación Virtual de App-V a través de Streaming, no es necesario descargar completamente la misma, sino que habitualmente es suficiente con descargar sólo una parte para poder empezar a ejecutar dicha Aplicación Virtual, evitando largas esperas. Además, las Aplicaciones Virtuales son cacheadas en los equipos clientes, de tal modo que las ejecuciones sucesivas sean más rápidas. El Cliente App-V también puede incluir la Application Virtualization Client Console (no confundir con la App-V Management Console), una herramienta administrativa que permite realizar diferentes tareas relacionadas con las Aplicaciones Virtuales, asociaciones de ficheros a Aplicaciones Virtuales, y servidores de publicación (Publishing Servers). También se pueden realizar tareas administrativas en el cliente desde línea de comandos, utilizando el comando SFTMIME.

En consecuencia, desde el punto de vista de arquitectura, podemos identificar diferentes escenarios:

• Full Infrastructure. Utiliza App-V Management Server para obtener capacidades de Streaming, Desktop Configuration Service, active/package upgrade, licensing and metering, etc. Requiere de Directorio Activo y de SQL Server. Es una actualización de SoftGrid Virtual Application Server.
• Lightweight Infrastructure. Utiliza App-V Streaming Server, lo cual, no require de Directorio Activo ni de SQL Server, pero prescinde de ciertas funcionalidades propias del App-V Management Server (ej: no soporta licensing and metering ni la App-V Management Console).
• Standalone mode. El App-V Sequencer tiene la opción de crear un fichero MSI, el cual, se puede instalar directamente sobre los clientes App-V, ya sea a través de algún un sistema ESD (Enterprise Software Deployment) como Microsoft SMS o Microsoft SCCM, o bien instalando manualmente el fichero MSI en cada equipo cliente, desde una carpeta compartida, grabándolo previamente en un CD o DVD, etc. En este modo no se utiliza Streaming. Resulta útil para probar el secuenciamiento de aplicaciones, de tal modo, que se realiza una prueba empaquetando en MSI, y seguidamente se prueba, y si es necesario, repetimos el proceso cuantas veces sea necesario hasta que funcione nuestra nueva Aplicación Virtual. Y entonces, la publicamos a nuestros usuarios por el método corporativo que tengamos procedimentado.

Quizás nos interese utilizar un modo en particular, o quizás nos interesen dos modos o incluso los tres. Es decir, para ciertos usuarios que pertenecen a empresas colaboradoras a la nuestra podríamos entregarles los ficheros MSI de las Aplicaciones Virtuales App-V que les corresponda (modo Standalone), en las oficinas centrales utilizar una App-V Managment Server (modo Full Infrastructure) y en algunas delegaciones utilizar el App-V Streaming Server (modo Lightweight Infrastructure).

Así mismo, también podemos jugar con los protocolos de entrega de paquetes, por ejemplo, utilizar HTTPS para la distribución de nuestras Aplicaciones Virtuales de App-V a clientes App-V a través de Internet, o incluso utilizar SMB (es decir, carpetas compartidas) para la distribución de nuestras Aplicaciones Virtuales de App-V en alguna sucursal (ej: copiamos los ficheros de nuestras Aplicaciones Virtuales a una carpeta compartida en un servidor de la sucursal, utilizando un software ESD).

Un posible escenario, sería utilizar un App-V Streaming Server en la oficina central para desplegar por Streaming (RTSPS) nuestras Aplicaciones Virtuales a los Clientes de dicha ubicación, mientras que en las sucursales se copian las Aplicaciones Virtuales a una carpeta compartida a través de un software ESD, para que se puedan desplegar las Aplicaciones Virtuales a los clientes a través de SMB. Por último, para los clientes App-V disponibles a través de Internet, se utiliza un servidor IIS para desplegar las Aplicaciones Virtuales de App-V a través de HTTPS.

Algunas mejoras de App-V frente a SoftGrid

App-V incorpora varias mejoras sobre SoftGrid Application Virtualization.

• Dynamic Suite Composition. Permite identificar las dependencias entre Aplicaciones Virtuales, lo cual, implica varias ventajas. Si tomamos como ejemplo dos aplicaciones virtualizadas, las cuales requieren de la misma versión de Java JRE para poder ejecutarse, podríamos secuenciar (crear una Aplicación Virtual) para Java JRE, y adicionalmente podríamos secuenciar por separado ambas Aplicaciones Virtuales. ¿Cuál es la ventaja? Que podremos definir como dependencia en ambas Aplicaciones Virtuales, al propio Java JRE, de tal modo que si se ejecutan ambas Aplicaciones Virtuales en un mismo equipo de escritorio, será necesario secuenciar (instanciar) una única vez la Aplicación Virtual correspondiente a Java JRE, optimizando la utilización de recursos. Claro, esto lo haremos si nos es necesario, ya que podría ocurrir que ambas aplicaciones requieran de versiones de Java JRE distintas, en cuyo caso, podríamos secuenciar junto tanto Java JRE como la aplicación en sí.
• Mejoras en Escalabilidad. App-V es capaz de interoperar con diferentes sistemas ESD (Enterprise Software Deployment) como Microsoft SMS (Systems Management Server), Microsoft SCCM (System Center Configuration Manager), y otros sistemas ESD de terceros. Incluso soporta un modo StandAlone, en el cual, el App-V Sequencer es capaz de crear un fichero MSI para la instalación de una nueva Aplicación Virtual (sin Streaming).
• Globalización. App-V soporta aplicaciones y sistemas operativos en diferentes idiomas. Por ejemplo, un cliente App-V podría utilizar el idioma francés y acceder a un servidor App-V en idioma inglés.
• Mejoras en Seguridad. Incluye soporte para TLS, Kerberos, autenticación de servidor basada en certificados, etc.

Actualmente, existen dos versiones de App-V.

• App-V 4.5 SP1. Incluye soporte para Windows 7, integración con AppLocker, soporte para BranchCache (una característica de Windows Server 2008 R2), soporte para securizar aplicaciones en dispositivos removibles con BitLockerToGo y Streaming de Aplicaciones Virtuales desde USB, integración con directorios LDAP de terceros, etc.
• App-V 4.6. Soporte para arquitecturas x86 y x64, incluyendo la posibilidad de secuenciar aplicaciones de 64-bits.

Despedida y cierre

Aunque no soy en absoluto un gran conocedor de App-V, a través de este artículo he intentado hacer un resumen de aquellas cosas que he podido aprender sobre App-V en las últimas semanas, tanto por satisfacer mi interés personal en conocer más este producto, como en la preparación para el examen de certificación 70-669: Windows Server 2008 R2, Desktop Virtualization. Algunas cosas las he podido probar, mientras que en otras tan sólo he podido documentarme, por lo que confío no presentar errores (mis disculpas, si así fuese). Como siempre, confío que esta información os pueda resultar de interés. Cualquier comentario será bienvenido !