Microsoft App-V

Microsoft Application Virtualization (también conocido como App-V ; ^{[ 1 ]} anteriormente Softricity SoftGrid ) ^{[ 2 ]} es una solución de virtualización y transmisión de aplicaciones de Microsoft . Fue desarrollada originalmente por Softricity, una empresa con sede en Boston , Massachusetts , adquirida por Microsoft el 17 de julio de 2006. ^{[ 3 ]} App-V representa la entrada de Microsoft al mercado de la virtualización de aplicaciones, junto con sus otras tecnologías de virtualización como Hyper-V , Microsoft User Environment Virtualization (UE-V), ^{[ 4 ]} Remote Desktop Services y System Center Virtual Machine Manager . ^{[ 5 ]}

App-V permite implementar aplicaciones ("transmitir") en tiempo real a cualquier cliente desde un servidor de aplicaciones virtual. Elimina la necesidad de la instalación local tradicional de las aplicaciones, aunque también admite un método de implementación independiente. Con una implementación basada en transmisión, el cliente de App-V debe instalarse en las máquinas cliente y los datos de la aplicación almacenados en el servidor de aplicaciones virtual se instalan (transmiten) a la caché del cliente bajo demanda cuando se usa por primera vez, o bien se preinstalan en una caché local. La pila de App-V aísla el entorno de ejecución para que una aplicación no realice cambios directamente en el sistema de archivos del sistema operativo subyacente ni en el Registro de Windows , sino que se encuentre contenida en una "burbuja" específica de la aplicación. Las aplicaciones de App-V también están aisladas entre sí, de modo que se pueden ejecutar diferentes versiones de la misma aplicación bajo App-V simultáneamente y pueden coexistir aplicaciones mutuamente excluyentes en el mismo sistema. Sin embargo, esta separación no constituye una barrera de seguridad. ^{[ 6 ]}

App-V permite la instalación y gestión centralizada de las aplicaciones implementadas. Admite el control de acceso basado en políticas; los administradores pueden definir y restringir el acceso a las aplicaciones a determinados usuarios o en determinados equipos, mediante la definición de políticas que rigen su uso. App-V también incluye una interfaz de seguimiento para monitorizar el uso de la aplicación virtualizada. Los servidores pueden implementarse en configuraciones de alta disponibilidad cuando se desee.

El cliente App-V ofrece al usuario una experiencia de aplicación limpia y similar a la de una aplicación instalada localmente para aplicaciones virtualizadas. El acceso para iniciar la aplicación virtualizada es idéntico al de una aplicación instalada localmente, ya que las extensiones de la aplicación se integran en el escritorio del usuario mediante el cliente App-V. Cuando dos o más aplicaciones virtuales dependen unas de otras, también se pueden configurar para que se ejecuten juntas en un entorno aislado.

Microsoft App-V es un componente adicional que requiere licencia para su uso. La licencia es por usuario y se adquiere mediante la licencia de Microsoft Desktop Optimization Pack (MDOP) para su uso en sistemas operativos cliente, o como parte de la licencia de acceso de cliente de Microsoft Remote Desktop Server para su uso en servidores de escritorio remoto. MDOP es un conjunto de tecnologías disponible mediante suscripción para clientes de Software Assurance. También existe un modelo de licencia para proveedores de alojamiento (servicios en la nube).

Microsoft lanzó la versión 5 de App-V a finales de noviembre de 2012, una importante renovación de la plataforma. Esta versión modernizó el producto, reemplazando componentes diseñados originalmente para Windows NT y Windows 2000, once años antes. La renovación también permitió la compatibilidad con funciones más recientes del sistema operativo y mejoras en la virtualización.

La versión 4.x del producto sigue siendo de uso generalizado y actualmente cuenta con soporte activo. Microsoft extendió el soporte para la versión 4 hasta los sistemas operativos cliente Windows 8.1 y Server 2012 R2; sin embargo, algunas de las características más recientes del sistema operativo no están disponibles para las aplicaciones virtualizadas que utilizan App-V 4.x. La fecha estándar de finalización del soporte de Microsoft para App-V 4.x fue julio de 2015. ^{[ 7 ]}

Las versiones 3.x y 2.x ya no se utilizan en producción; el soporte para estas versiones finalizó con la adquisición de Softricity por parte de Microsoft. Las versiones 2.x a 4.x representan la segunda generación del producto de virtualización de aplicaciones.

No existía una versión 1.x del producto. Antes del lanzamiento de SoftGrid 2.0, Softricity era conocida como SoftwareWow.com . ^{[ 8 ]} SoftwareWow.com fue uno de los primeros proveedores de servicios en la nube con una tienda de aplicaciones que transmitía aplicaciones (principalmente juegos) a los consumidores. El servicio utilizaba un producto propio de primera generación para proporcionar Software como Servicio (SaaS). Aunque hoy en día existe poca información en línea sobre la empresa, ^{[ 9 ]} este producto proporcionaba servicios de transmisión con un soporte de virtualización muy limitado.

Microsoft lanzó una versión derivada de App-V bajo el nombre de Microsoft Server Application Virtualization («App-V para servidores»). ^{[ 10 ]} Esta plataforma, que admite la redirección de virtualización pero sin aislamiento, está diseñada para ofrecer cargas de servidor virtualizadas que no presenten conflictos entre aplicaciones. El producto está disponible como parte de System Center Virtual Machine Manager y se utiliza normalmente para crear nuevas instancias de servidores según la demanda.

Microsoft ofrece tres opciones para la implementación de aplicaciones virtuales, lo que afecta a los componentes arquitectónicos utilizados:

• Un conjunto de servidores dedicados a App-V.
• Integración con System Center Configuration Manager.
• Modo "autónomo", en el que la aplicación puede distribuirse por otros medios.

La implementación de estas tres opciones de despliegue difiere según se utilice la versión 5.x o la 4.x de App-V. Cada una se describe por separado.

Aparte de las operaciones asociadas con las operaciones de despliegue, la virtualización de aplicaciones de App-V se compone principalmente de dos componentes : el secuenciador de App-V y el cliente de App-V . 

El secuenciador de App-V es el componente que reempaqueta una aplicación para su virtualización y transmisión. Analiza la aplicación para determinar los recursos que requiere, admite la personalización de las aplicaciones y, a partir de esto, crea un paquete que contiene los componentes ejecutables, los archivos de datos y la configuración del registro necesarios para la aplicación. El formato del paquete para las versiones 4.x y 5.x es bastante diferente:

• La versión 5.x utiliza el formato App-V, que se basa en formatos de compresión estándar con funciones adicionales. Internamente, gran parte del formato de metadatos se ha tomado prestado de AppX.
• Las versiones App-V 4.x producen paquetes que utilizan el formato SFT, ^{[ 12 ]} junto con archivos adicionales basados ​​en una versión modificada ^{[ 13 ]} de la especificación Open Software Description (OSD) propuesta originalmente al WC3 en 1997 por Microsoft y Marimba. ^{[ 14 ]}

El secuenciador supervisa la instalación, configuración y uso en tiempo de ejecución de los recursos de archivos y registro de la aplicación para determinar el contenido y la configuración del paquete. Abstrae la información específica de la máquina y del usuario para mejorar la portabilidad de los componentes de la aplicación, lo que permite que la mayoría de las aplicaciones se ejecuten por diferentes usuarios, en diferentes hardware e incluso en diferentes sistemas operativos en algunos casos. El paquete también está configurado para operaciones de transmisión, donde se pueden entregar porciones de archivos a los clientes según sea necesario. Las directrices para la secuenciación de aplicaciones son diferentes para las versiones 4.x ^{[ 15 ]} y 5.x ^{[ 16 ]} .

El cliente de App-V recibe definiciones de paquetes de aplicaciones virtuales de varias maneras. Cuando se configura para recibirlas de un servidor de infraestructura completa de App-V, esto ocurre automáticamente al iniciar sesión o mediante un temporizador, y es iniciado por el cliente de App-V. También se pueden enviar instrucciones a través de una API de cliente, que se utiliza en las implementaciones de System Center, el MSI virtual y los métodos independientes. La API del cliente de App-V 5.x se basa en PowerShell, mientras que el cliente 4.x utiliza una interfaz sftmime propietaria.

Al recibir el paquete, el cliente descargará los metadatos correspondientes y, posiblemente (dependiendo de la configuración del paquete y del cliente), algunos o todos los componentes del paquete. El cliente está diseñado para utilizar un sistema de archivos de transmisión que funciona de forma similar a la paginación de archivos local. Esto permite iniciar la aplicación sin que todos los archivos estén presentes en la caché local. Cuando la aplicación requiere una parte de un archivo que no está presente, se realiza una operación denominada fallo de transmisión que recupera la parte del archivo necesaria. El contenido del paquete transmitido se almacena en caché en la memoria del cliente durante la sesión de la aplicación y puede conservarse en una caché de disco local para su uso posterior.

La configuración del usuario se almacena en el propio sistema local mediante redirección para garantizar que la copia en caché de la aplicación no se modifique. En algunos casos, esto permite implementar aplicaciones que no admiten múltiples usuarios en sistemas de Host Compartido de Escritorio Remoto.

La versión 5.x, además de ser un rediseño, añadió una serie de funcionalidades que no estaban disponibles en la versión 4.x. El Service Pack 2 de la versión 5.0 añadió algunas de ellas. Entre ellas se incluyen:

• Compatibilidad con integraciones adicionales . Las aplicaciones tienen muchas maneras de integrarse con el sistema operativo y el entorno de escritorio del usuario. Anteriormente, solo estaban disponibles los accesos directos a aplicaciones, las asociaciones de tipos de archivo y las integraciones COM para brindar al usuario una experiencia similar a la nativa. La versión 5.x, especialmente con el Service Pack 2 y posteriores, amplió significativamente los tipos de integraciones, denominadas Extensiones de aplicación en App-V. Además de la compatibilidad mejorada con accesos directos, se agregaron controladores de protocolo, capacidades de aplicación, clientes de software, rutas de aplicación y una variedad de extensiones de shell, objetos auxiliares del navegador e integraciones ActiveX. Muchas de estas extensiones ayudan a superar las objeciones a la virtualización de aplicaciones complejas como Microsoft Office y los complementos de Office.
• Tamaño de la aplicación . La limitación de tamaño de paquete de 4 GB ha desaparecido. No existe ningún límite documentado para los paquetes de App-v 5.x.
• Mejoras en la creación de scripts . Los componentes dependientes que no se pueden virtualizar ahora pueden instalarse localmente mediante el cliente App-V cuando sea necesario, utilizando la nueva interfaz de scripts, incluso cuando el usuario que ha iniciado sesión no tiene privilegios de administrador para instalar software. Esto incluye los controladores de dispositivos dependientes.
• Grupos de conexión : Se utilizan cuando varios paquetes necesitan trabajar juntos en un único entorno de aplicación virtual. Esta función reemplaza la Composición dinámica de suites añadida a App-V 4.5. La principal ventaja de este rediseño es que los Grupos de conexión ahora son objetos gestionados a nivel de App-V o Configuration Manager, en lugar de modificaciones ocultas realizadas por un administrador.
• RunVirtual : En ocasiones, las aplicaciones virtuales se inician utilizando componentes instalados localmente, como un navegador web local con complementos virtualizados. Anteriormente, la virtualización de estas aplicaciones causaba problemas a los usuarios que ya habían creado accesos directos al componente local. Con RunVirtual , el administrador puede garantizar que cualquier inicio del componente local se realice de forma virtual.

• Complementos de Microsoft Office : Si bien es posible secuenciar los complementos de Microsoft Office, no se recomienda hacerlo debido a diversos problemas técnicos y de uso. Por ejemplo, si un usuario utiliza más de dos complementos y estos se ejecutan por separado, no tendrá control sobre qué secuencia se inicia al abrir un documento. La única solución es crear un conjunto único o dinámico de todos los complementos.
• Tamaño de la aplicación : Si el tamaño máximo de caché del cliente se establece en al menos 4 GB (el máximo puede ser de 64 GB), entonces el tamaño máximo de la aplicación (archivo .sft) que se puede transmitir en esa máquina es de 4 GB. Todas las aplicaciones que tengan un tamaño de instalación mayor o igual al tamaño máximo del cliente, establecido por el cliente, no deben secuenciarse. El tamaño máximo de aplicación que Softgrid puede manejar es de 4 GB, debido al uso del sistema de archivos FAT32 . ^{[ 17 ]}
• Controlador de dispositivo : Actualmente, App-V no admite la secuenciación de controladores de dispositivo en modo kernel; por lo tanto, ninguna aplicación que instale un controlador de dispositivo puede secuenciarse. La única excepción es cuando el controlador de dispositivo se puede preinstalar localmente; en este caso, la aplicación se secuencia sin el controlador de dispositivo.
• Accesos directos : Las aplicaciones deben tener al menos un acceso directo. Si no hay accesos directos, la aplicación debe estar incluida en un conjunto junto con las demás aplicaciones que la necesiten. Los complementos de Internet Explorer requieren un acceso directo especial para iniciar el proceso del navegador bajo la capa de virtualización.
• Middleware : Las aplicaciones de middleware pueden no ser buenas candidatas para la secuenciación, ya que pueden ser prerrequisitos de tiempo de ejecución para múltiples aplicaciones. Con versiones posteriores de App-V, se pueden secuenciar en un paquete separado al que se vinculan otras aplicaciones virtuales mediante una función llamada Composición dinámica de suites . ^{[ 18 ]}
• Codificación fija de rutas : La aplicación no debe tener rutas de carpetas o archivos codificadas directamente en su código. Algunas aplicaciones codifican las rutas de los archivos en sus ejecutables en lugar de parametrizarlas o almacenarlas en el Registro de Windows. Los archivos de configuración con extensiones como ini, conf, dat y txt son buenos lugares para buscar configuraciones específicas de la aplicación que puedan causar problemas. En caso contrario, se puede usar un adaptador para solucionar el problema cuando no se dispone del código fuente o de una actualización.
• Actualización automática : Las aplicaciones con actualizaciones automáticas no deben incluirse en la secuencia si no se puede desactivar su mecanismo de actualización. En ocasiones, las aplicaciones con actualización automática no se actualizan correctamente. Además, permitir la actualización automática puede provocar que la versión de la aplicación no sea la correcta.
• Servicios : No se admite la virtualización de servicios que deban iniciarse al arrancar el sistema. Todos los demás tipos de servicios generalmente se pueden virtualizar; se inician cuando la aplicación virtual se inicia y se detiene, o cuando finaliza el ejecutable principal de una aplicación.
• Políticas de licenciamiento : Aplicaciones con licencia vinculada al equipo, por ejemplo, la licencia está vinculada a la dirección MAC del sistema o al número de serie del disco duro. Este tipo de aplicación no debe secuenciarse si el usuario no puede activarla al ejecutarla por primera vez, ya sea manualmente o mediante un script.
• Internet Explorer y Service Packs : Microsoft no admite la secuenciación de ninguna versión de Internet Explorer.

• Liquidware FlexApp
• Cameyo
• Citrix XenApp (anteriormente incluido como "Application Streaming"/"Project Tarpon". Se descontinuó a partir de Windows Server 2012. ^{[ 19 ]} Ahora también usa App-V.)
• Puente sin instalación
• Virtualización de aplicaciones de Novell ZENworks
• Turbo Studio (anteriormente Spoon Studio y Xenocode Virtual Application)
• VMware ThinApp

• Virtualización de aplicaciones de Microsoft 4.6