Aplicación Microsoft V

Microsoft Application Virtualization (también conocida como App-V; anteriormente Softricity SoftGrid) es una solución de virtualización de aplicaciones 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. App-V representa la entrada de Microsoft al mercado de virtualización de aplicaciones, junto con otras tecnologías de virtualización como Hyper-V, Microsoft User Environment Virtualization (UE-V), Remote Desktop Services y System Center Virtual Machine Manager.

App-V permite que las aplicaciones se implementen (transmitan) 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 se 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 que se almacenan en el servidor de aplicaciones virtual se instalan (transmiten) a la memoria caché del cliente a pedido cuando se utilizan por primera vez, o se preinstalan en una memoria caché local. La pila de App-V aísla el entorno de ejecución de modo que una aplicación no realice cambios directamente en el sistema de archivos del sistema operativo subyacente y/o en el Registro de Windows, sino que se contenga 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 con App-V simultáneamente y de modo que las aplicaciones mutuamente excluyentes puedan coexistir en el mismo sistema. Sin embargo, la separación no es un límite de seguridad.

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

El cliente App-V presenta al usuario una experiencia de aplicación limpia y localmente instalada para aplicaciones virtualizadas. El acceso para iniciar la aplicación virtualizada parece ser idéntico al de la aplicación instalada localmente, ya que las extensiones para la aplicación están integradas en el shell del escritorio del usuario por el cliente App-V. Cuando dos o más aplicaciones virtuales tienen una dependencia entre sí, las aplicaciones virtualizadas individuales también pueden configurarse para ejecutarse juntas en una única burbuja aislada.

Microsoft App-V es un componente adicional que requiere licencia para su uso. La licencia se basa en el 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 disponibles como suscripción para clientes de Software Assurance. También existe un modelo de licencias para proveedores de alojamiento (servicios en la nube).

Microsoft lanzó la versión 5 de App-V a fines de noviembre de 2012, que es un rediseño importante de tercera generación de toda la plataforma. La versión 5 modernizó el producto y reemplazó los componentes diseñados originalmente para su uso contra Windows NT y Windows 2000 unos 11 años antes. El rediseño también permitió la compatibilidad con características más nuevas del sistema operativo y mejoras en la compatibilidad con la virtualización.

La versión 4.x del producto todavía se utiliza ampliamente y actualmente se encuentra en soporte activo. Microsoft extendió el soporte basado en la versión 4 para sistemas operativos cliente hasta Windows 8.1 y Server 2012 R2; sin embargo, algunas de las características más nuevas del sistema operativo no están disponibles para aplicaciones virtualizadas que utilicen App-V 4.x. La fecha estándar de finalización del soporte de Microsoft para App-V 4.x fue julio de 2015.

No se tiene conocimiento de que las versiones 3.x y 2.x sigan utilizándose 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 de productos de virtualización de aplicaciones.

No existía una versión 1.x del producto. Antes del lanzamiento de SoftGrid 2.0, Softricity se conocía como SoftwareWow.com. SoftwareWow.com fue uno de los primeros proveedores de servicios basados en la nube con una tienda de aplicaciones que transmitía aplicaciones (principalmente juegos) a los consumidores. El servicio utilizaba un producto interno 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, este producto proporcionaba servicios de transmisión con un soporte de virtualización muy limitado.

Microsoft lanzó una versión derivada de App-V con el nombre de Microsoft Server Application Virtualization (“App-V para servidores”). Esta plataforma, que admite la redirección de virtualización pero sin aislamiento, está destinada a ofrecer cargas de servidores virtualizados que no tengan conflictos entre aplicaciones. El producto está disponible como parte de System Center Virtual Machine Manager y se utiliza normalmente para poner en marcha 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 System Center Configuration Manager.
• Modo "Stand-alone" en el que la aplicación puede ser entregada a través de otros medios.

La implementación de estas tres opciones de implementación es diferente cuando se utiliza la versión 5.x o 4.x de App-V. Cada una se describe por separado.

La arquitectura basada en 5.x tiene tres opciones principales que pueden utilizarse. Las tres opciones utilizan algunos componentes comunes:

• Microsoft Application Virtualization 5.x Sequencer, que se utiliza para empaquetar una aplicación personalizada para la entrega virtualizada.
• Microsoft Application Virtualization 5.x Client, que se utiliza en el sistema operativo utilizado para ejecutar la aplicación virtual. Existen dos formas del cliente, una para los sistemas operativos de escritorio (como Windows 7 con Service Pack 1 y Windows 8), y otra para los sistemas operativos del servidor configurados para su uso como servidores Host de sesión de escritorio remoto.
• Microsoft Application Virtualization Report Server, un componente opcional que puede reunir información de uso (llamado medición) de las aplicaciones virtualizadas.
• Microsoft Aplicación Virtualization Client Console, un componente opcional que se puede entregar a los sistemas cliente como aplicación virtual. Por lo general, la consola no es necesaria para usuarios finales, sin embargo el despliegue de la aplicación de consola proporciona al usuario control adicional sobre las aplicaciones virtuales que han sido previamente autorizadas y entregadas.

El resto de la arquitectura 5.x depende de la opción de implementación utilizada.

El servidor completo de App-V 5.x está compuesto por los siguientes componentes adicionales:

• Microsoft Application Virtualization 5.x Management Server, utilizado para definir aplicaciones y grupos de conexión y asignarlos a grupos de seguridad Active Directory que contienen listas de usuarios o ordenadores autorizados para utilizar la aplicación. Este servidor también distribuye un resumen de esta información a múltiples servidores publicitarios. El servidor de gestión se implementa como servicio web que almacena información de configuración en una base de datos de back-end. El Servicio Web se puede acceder utilizando un navegador web habilitado para Silverlight o PowerShell.
• Microsoft Application Virtualization Editor Server, utilizado para autenticar usuarios y computadoras y entregar metadatos de aplicaciones virtuales apropiados para publicar al cliente.
• Package Store, una simple cuota de archivo que será utilizado por los clientes para transmitir aplicaciones virtuales de. En algunos casos, la tienda de paquetes puede ser encabezada por un servidor web.

El Administrador de configuración está compuesto por los siguientes componentes:

• Microsoft System Center Configuration Manager Site Server, utilizado para definir imágenes operativas, paquetes de aplicaciones tradicionales para la instalación, aplicaciones virtuales y otras tareas de implementación. Estos artículos también pueden ser asignados a colecciones de usuarios y computadoras, junto con requisitos y dependencias. Esta información se almacena en una base de datos y se entrega, a través de un punto de distribución, a las máquinas cliente.
• Microsoft System Center Distribution Point, utilizado para el contenido de caché para el despliegue para una solución altamente escalable.
• Agente cliente de Microsoft System Center, utilizado para extraer metadatos de implementación y contenido del Punto de Distribución, e implementar una variedad de acciones de componentes cliente. Desde una perspectiva App-V, este componente entrega la aplicación virtual al Cliente App-V.

App-V 5 requiere el uso de System Center Configuration Manager 2012 o superior para obtener compatibilidad total con las características de App-V. La implementación mediante versiones anteriores u otros sistemas de entrega electrónica también es posible mediante el método de implementación msi virtual.

Los clientes de App-V 5.x contienen una API de PowerShell que, en última instancia, utilizan ambos modos de servidor anteriores. A veces, es conveniente utilizar esta API directamente en el cliente, ya sea de forma manual o mediante herramientas adicionales desarrolladas por terceros.

La arquitectura basada en 4.x tiene tres opciones principales que también se pueden utilizar. Las tres opciones utilizan un par de componentes comunes:

• Microsoft Application Virtualization 4.x Sequencer, que se utiliza para empaquetar una aplicación personalizada para la entrega virtualizada.
• Microsoft Application Virtualization 4.x Client, que se utiliza en el sistema operativo utilizado para ejecutar la aplicación virtual. Existen cuatro formas del cliente, combinadas en conjuntos que soportan sistemas operativos x86 o x64. Un set para sistemas operativos de escritorio (como Windows XP y arriba), y el otro sistema para sistemas operativos de servidor configurado para su uso como servidores Host de sesión de escritorio remoto.

La arquitectura del sistema App-V 4.x se compone de los siguientes componentes:

• Microsoft Systems Center Virtual Application Management Server, que se utiliza para definir aplicaciones y asignarlas a Usuarios Active Directory, o Grupos de Seguridad que contienen listas de usuarios, autorizados para utilizar la aplicación. El servidor también realiza la autenticación de tiempo de ejecución contra listas autorizadas y registra la información de uso (mediación) en una base de datos para la presentación de informes.
• Microsoft Systems Center Virtual Application Management Service, que es un.NET remoting servicio web, gestiona solicitudes de clientes para aplicaciones. Este servidor trabaja junto con el Servidor de Gestión para proporcionar metadatos de aplicación autorizados para la publicación, verificación del uso autorizado y datos de presentación de informes. El servidor también maneja operaciones de streaming de los paquetes virtualizados utilizando una extensión del protocolo RTSP.
• App-V Management Console, la herramienta de gestión para configurar, administrar y administrar servidores App-V. Puede utilizarse para definir políticas que rigen el uso de las aplicaciones. También se puede utilizar para crear, administrar, actualizar y replicar paquetes de aplicaciones virtualizados.

En 2009, Microsoft ofreció una nueva forma de implementar App-V con mejoras en System Center Configuration Manager. La arquitectura de System Center Configuration Manager consta de los siguientes componentes:

• System Center Configuration Manager Site Server, sirviendo como el repositorio primario para tener imágenes del sistema, paquetes de aplicaciones creados con instaladores tradicionales y aplicaciones virtuales.
• Administrador de configuración del sistema Servidor de distribución, utilizado para caché y distribuir el software en un nivel más local.

App-V 4.x tiene integraciones directas con Configuration Manager 2007 SP1 a 2012 R2.

Los clientes de App-V también pueden utilizarse en un "modo autónomo" sin ninguna de las infraestructuras de servidor descritas anteriormente. En este caso, los paquetes secuenciados se entregan utilizando una técnica externa, como un sistema de entrega electrónica de software o una implementación manual.

Además de las operaciones asociadas con las operaciones de implementación, App-V Application Virtualization consta principalmente de dos componentes: el Secuenciador de App-V y el Cliente de App-V.

El secuenciador de App-V es el componente que vuelve a empaquetar una aplicación para la virtualización y la transmisión. Analiza la aplicación en busca de los recursos que necesita, 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 las configuraciones de registro que necesita la aplicación. El formato del paquete para las versiones 4.x y 5.x es bastante diferente:

• El producto 5.x utiliza un formato App-V que se basa en formatos de compresión estándar con características adicionales. Internamente, gran parte del formato de metadatos es prestado de AppX.
• Las versiones App-V 4.x producen paquetes usando el formato SFT, junto con archivos adicionales basados en una versión modificada de la especificación de Open Software Description (OSD) originalmente propuesta al WC3 en 1997 por Microsoft y Marimba.

El secuenciador supervisa la instalación, configuración y uso de recursos de archivos y registros en tiempo de ejecución de la aplicación para determinar el contenido y la configuración del paquete. Extrae 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 sean ejecutadas 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 partes de archivos según sea necesario a los clientes. Las pautas para la secuenciación de aplicaciones son diferentes para las versiones 4.x y 5.x.

El cliente de App-V recibe definiciones de paquetes de aplicaciones virtuales de varias maneras. Cuando se configura para recibirlas desde un servidor de infraestructura de App-V completo, esto ocurre automáticamente al iniciar sesión o mediante un temporizador, y lo inicia el cliente de App-V. También se pueden enviar instrucciones a través de una API de cliente, que se utiliza en implementaciones de System Center, el msi virtual y los métodos independientes. La API de 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 (según las configuraciones del cliente y del paquete), algunos o todos los componentes del paquete. El cliente está diseñado para utilizar un sistema de archivos de transmisión que funciona de manera muy similar a la actividad de paginación de archivos local. Esto permite iniciar la aplicación sin todos los archivos presentes en la memoria caché local. Cuando la aplicación requiere una parte de archivo que no está presente, se realiza una operación denominada stream-fault que recupera la parte de archivo necesaria. El cliente almacena en caché el contenido del paquete transmitido en la memoria durante la sesión de la aplicación y puede conservarse en una memoria caché de disco local para su uso futuro.

Las configuraciones de usuario se almacenan en el propio sistema local mediante una redirección para garantizar que no se modifique la copia en caché de la aplicación. En algunos casos, esto permite la implementación de aplicaciones que no son compatibles con varios usuarios para su uso en sistemas host compartidos de escritorio remoto.

La versión 5.x, además de ser un rediseño, agregó una serie de funciones que no estaban disponibles anteriormente en la versión 4.x. A estas se sumó el Service Pack 2 de la versión 5.0, que incluye:

• Apoyo a las integraciones adicionales. Las aplicaciones tienen muchas maneras de proporcionar la integración al sistema operativo y la cáscara de escritorio del usuario. Anteriormente, sólo atajos de aplicaciones, asociaciones de tipos de archivos e integraciones COM estaban disponibles para proporcionar al usuario una experiencia similar a la nativa. Versión 5.x, especialmente con Service Pack 2 y más allá, expandió significativamente los tipos de integraciones, llamadas Extensiones de aplicación en App-V. Además de mejorar el soporte atajo, Manejadores de Protocolo, Capacidades de Aplicación, Clientes de Software, Senderos de Aplicación, y una variedad de extensiones de shell, objetos de ayuda del navegador, e integraciones Active-X fueron añadidos. Muchas de estas extensiones ayudan a superar las objeciones a virtualizar aplicaciones complicadas como Microsoft Office y plug-ins a Office.
• Tamaño de la aplicación. La limitación del tamaño del paquete 4GB se ha ido. No existe límite documentado para los paquetes App-v 5.x.
• Guión mejorado. Los componentes dependientes que no pueden virtualizarse ahora pueden ser instalados localmente por el cliente App-V cuando sea necesario utilizando la nueva interfaz de scripting, incluso cuando el usuario conectado no tiene privilegios administrativos para instalar software. Esto incluye controladores de dispositivo dependientes.
• Grupos de conexión: Utilizado cuando múltiples paquetes necesitan trabajar juntos en un único entorno de aplicación virtual, esto reemplaza la composición de la suite dinámica agregada a App-V 4.5. El principal beneficio de este rediseño es que los Grupos de Conexión ahora son objetos gestionados a nivel de App-V o Administrador de Configuración, en lugar de modificaciones ocultas hechas por un administrador.
• RunVirtual: A veces las aplicaciones virtuales se inician utilizando componentes instalados localmente, como un navegador web local utilizando plug-ins virtualizados. Anteriormente, la virtualización de estas aplicaciones causó problemas para los usuarios que ya crearon sus propios atajos al componente local. Uso RunVirtual, el administrador puede asegurar que cualquier lanzamiento del componente local será virtualizado.

• Plug-ins de Microsoft Office: Aunque uno puede secuenciar plug-ins de Microsoft Office, no se recomienda secuenciarlos debido a muchos problemas técnicos de uso. Por ejemplo, en una situación en la que hay más de dos plug-ins utilizados por un usuario, si se secuencian por separado, entonces el usuario no tiene control sobre qué secuencia de plug-in comienza cuando abre un documento. El único trabajo alrededor para resolver el problema es creando una suite única o una suite dinámica de todos los plug-ins.
• Tamaño de la aplicación: Si el tamaño máximo de la caché del cliente se establece a por lo menos 4 GB (el máximo puede ser de 64 GB), entonces el tamaño máximo de la aplicación (archón de popa) que se puede transmitir en esa máquina es de 4 GB. Todas las aplicaciones que tienen una huella instalada mayor o igual al tamaño máximo del cliente, fijado por el cliente, no deben ser secuenciadas. El tamaño máximo de la aplicación Softgrid puede manejar es 4GB, debido al uso del sistema de archivos FAT32.
• Conductor de dispositivo: App-V actualmente no admite la secuenciación de los controladores de dispositivo de modo de núcleo; por lo tanto, cualquier aplicación que instale un controlador de dispositivo no puede ser secuenciada. La única excepción a esto es cuando el controlador del dispositivo se puede preinstalar localmente; en este caso, la aplicación se secuencia sin el controlador del dispositivo.
• Atajos: Las aplicaciones deben tener mínimo un atajo. Si no hay atajos, la aplicación debe ser secuenciada en una suite junto con la aplicación que lo necesita. Los plugins de Internet Explorer requieren un atajo especial para iniciar el proceso del navegador bajo la capa de virtualización.
• Middleware: Las aplicaciones de Middleware pueden no ser buenos candidatos para secuenciar ya que pueden ser requisitos de tiempo de ejecución para múltiples aplicaciones. Con versiones posteriores de App-V, se pueden secuenciar en un paquete separado que otras aplicaciones virtuales están vinculadas a usar una característica llamada Composición de suite dinámica.
• Camino de codificación dura: La aplicación no debe tener carpeta / ruta de archivo codificado duro en la aplicación misma. Algunas aplicaciones código duro el camino de los archivos en sus ejecutables en lugar de parameterlos o almacenarlos en el Registro de Windows. Los archivos de configuración que terminan en extensiones como ini, conf, dat y txt son buenos lugares para buscar configuraciones específicas de la información de ruta que pueden causar problemas. De lo contrario, un shim se puede utilizar para remediar la aplicación donde no está disponible el código fuente o una actualización.
• Actualización automática: Las aplicaciones con actualizaciones automáticas no deben ser secuenciadas si su mecanismo de actualización no puede ser deshabilitado. Las aplicaciones secuenciadas a veces no se actualizan. Además, permitir la actualización automática conduce al incumplimiento de la versión de aplicación.
• Servicios: La virtualización de los servicios que deben comenzar en el arranque no son compatibles. Todos los demás tipos de servicios se pueden virtualizar generalmente; se inician cuando la aplicación virtual comienza y cierra o cuando una aplicación principal ejecutable termina.
• Políticas de concesión de licencias: Aplicaciones con aplicación de licencias atadas a la máquina, por ejemplo, la licencia está atada a la dirección MAC del sistema o el número de serie de disco duro. Este tipo de aplicación no debe secuenciarse si la activación no puede ser realizada por el usuario en el primer lanzamiento de la aplicación secuenciada, manualmente o por script.
• Internet Explorer & paquetes de servicio: Microsoft no admite la secuenciación de ninguna versión de Internet Explorer.

• Liquidware FlexApp
• Cameyo
• Citrix XenApp (Formariamente incluido como "Application Streaming"/"Project Tarpon". Descanso a Windows Server 2012. Ahora utiliza App-V también.)
• Puente sin instalación
• Novell ZENworks Aplicación Virtualización
• Turbo Studio (anteriormente Spoon Studio y Xenocode Virtual Application)
• VMware ThinApp

• Microsoft Application Virtualization 4.6