Compartir a través de

Conexión de aplicaciones y conexión de aplicaciones MSIX en Azure Virtual Desktop

  • Artículo

Hay dos características en Azure Virtual Desktop que permiten asociar dinámicamente las aplicaciones de un paquete de aplicaciones a una sesión de usuario en Azure Virtual Desktop: conexión de aplicaciones y conexión de aplicaciones MSIX. Tanto con la conexión de aplicaciones como con la conexión de aplicaciones MSIX, las aplicaciones no se instalan localmente en hosts o imágenes de sesión, lo que facilita la creación de imágenes personalizadas para los hosts de sesión y reduce la sobrecarga operativa y los costes de la organización. Las aplicaciones se ejecutan dentro de contenedores, que separan los datos de usuario, el sistema operativo y otras aplicaciones, lo que aumenta la seguridad y facilita la solución de problemas.

En la tabla siguiente se compara la asociación de aplicaciones MSIX con la asociación de aplicaciones:

Asociación de aplicaciones en formato .MSIX Conexión de aplicaciones
Las aplicaciones se entregan mediante RemoteApp o como parte de una sesión de escritorio. Los permisos se controlan mediante la asignación a grupos de aplicaciones, pero todos los usuarios de escritorio ven todas las aplicaciones de asociación de aplicaciones MSIX en el grupo de aplicaciones de escritorio. Las aplicaciones se entregan mediante RemoteApp o como parte de una sesión de escritorio. Los permisos se aplican por aplicación y por usuario, lo que proporciona un mayor control con respecto a qué aplicaciones pueden acceder los usuarios en una sesión remota. Los usuarios de escritorio solo ven las aplicaciones de asociación de aplicaciones que tienen asignadas.
Las aplicaciones solo se pueden ejecutar en un grupo de hosts. Si quiere que se ejecute en otro grupo de hosts, debe crear otro paquete. El mismo paquete de aplicación se puede usar en varios grupos de hosts.
Las aplicaciones solo se pueden ejecutar en el grupo de hosts en el que se agregan. Las aplicaciones se pueden ejecutar en cualquier host de sesión que ejecute un sistema operativo de cliente de Windows en la misma región de Azure que el paquete de aplicación.
Para actualizar la aplicación, debe eliminar la aplicación y volver a crearla con otra versión del paquete. Debe actualizar la aplicación en una ventana de mantenimiento. Las aplicaciones se pueden actualizar a una nueva versión de aplicación con una nueva imagen de disco sin necesidad de una ventana de mantenimiento.
Los usuarios no pueden ejecutar dos versiones de la misma aplicación en el mismo host de sesión. Los usuarios pueden ejecutar dos versiones de la misma aplicación simultáneamente en el mismo host de sesión.
La telemetría de uso y estado no está disponible a través de Azure Log Analytics. La telemetría de uso y estado está disponible a través de Azure Log Analytics.

Puede usar los siguientes tipos de paquete de aplicación y formatos de archivo:

Tipo de paquete Formatos de archivo Disponibilidad de características
MSIX y paquete MSIX .msix
.msixbundle		 Asociación de aplicaciones en formato .MSIX
Asociación de aplicaciones
Appx y paquete Appx .appx
.appxbundle		 Solo asociación de aplicaciones
App-V .appv Solo asociación de aplicaciones

MSIX y Appx son formatos de paquete de aplicación de Windows que proporcionan una experiencia de empaquetado moderna a las aplicaciones de Windows. Las aplicaciones se ejecutan dentro de contenedores, que separan los datos de usuario, el sistema operativo y otras aplicaciones, lo que aumenta la seguridad y facilita la solución de problemas. MSIX y Appx son similares, con la principal diferencia de que MSIX es un superconjunto de Appx. MSIX admite todas las características de Appx, además de otras características que hacen que sea más conveniente para su uso en empresas.

Microsoft Application Virtualization (App-V) para Windows entrega aplicaciones Win32 a los usuarios como aplicaciones virtuales. Las aplicaciones virtuales se instalan en servidores administrados centralmente y se entregan a los usuarios como servicio en tiempo real y según sea necesario. Los usuarios inician aplicaciones virtuales desde puntos de acceso conocidos e interactúan con ellas como si se instalaran localmente.

Sugerencia

Seleccione un botón en la parte superior de este artículo para elegir entre la conexión de aplicaciones y la conexión de aplicaciones MSIX para ver la documentación correspondiente.

Puede obtener paquetes MSIX de proveedores de software o puede crear un paquete MSIX a partir de un instalador existente. Para obtener más información sobre MSIX, vea ¿Qué es MSIX?

Cómo obtiene un usuario una aplicación

Puede asignar distintas aplicaciones a distintos usuarios del mismo grupo de hosts o en el mismo host de sesión. Durante el inicio de sesión, se deben cumplir los tres requisitos siguientes para que el usuario obtenga la aplicación adecuada en el momento adecuado:

  • La aplicación debe asignarse al grupo de hosts. La asignación de la aplicación al grupo de hosts le permite seleccionar en qué grupos de hosts estará disponible la aplicación para asegurarse de que la aplicación disponga de los recursos de hardware adecuados para usarlos. Por ejemplo, si una aplicación consume muchos gráficos, puede asegurarse de que solo se ejecute en un grupo de hosts con hosts de sesión optimizados para GPU.

  • El usuario debe poder iniciar sesión en hosts de sesión en el grupo de hosts, por lo que debe estar en un grupo de aplicaciones de escritorio o RemoteApp. Si se trata de un grupo de aplicaciones de RemoteApp, la aplicación de asociación de aplicaciones debe agregarse al grupo de aplicaciones, pero no es necesario agregar la aplicación a un grupo de aplicaciones de escritorio.

  • La aplicación debe asignarse al usuario. Puede usar un grupo o una cuenta de usuario.

Si se cumplen todos estos requisitos, el usuario obtiene la aplicación. Este proceso permite controlar quién obtiene una aplicación en cada grupo de hosts y también cómo pueden los usuarios de un mismo grupo de hosts o incluso los que han iniciado sesión en el mismo host de sesión múltiple obtener distintas combinaciones de aplicaciones. Los usuarios que no cumplen los requisitos no obtienen la aplicación.

Cómo obtiene un usuario una aplicación

Puede asignar distintas aplicaciones a distintos usuarios del mismo grupo de hosts. Con la asociación de aplicaciones MSIX, se agregan paquetes MSIX a un grupo de hosts y se controla la asignación de aplicaciones mediante grupos de aplicaciones de escritorio o RemoteApp. Durante el inicio de sesión, se deben cumplir los requisitos siguientes para que el usuario obtenga la aplicación adecuada en el momento adecuado:

  • El usuario debe poder iniciar sesión en hosts de sesión en el grupo de hosts, por lo que debe estar en un grupo de aplicaciones de escritorio o RemoteApp.

  • La imagen MSIX debe agregarse al grupo de hosts.

Si se cumplen estos requisitos, el usuario obtiene la aplicación. La asignación de aplicaciones mediante un grupo de aplicaciones de escritorio las agrega al menú Inicio del usuario. Los usuarios que no cumplen los requisitos no obtienen la aplicación.

Imágenes de aplicación

Para poder usar los paquetes de aplicación con Azure Virtual Desktop, debe crear una imagen MSIX a partir de los paquetes de aplicación existentes mediante la herramienta MSIXMGR. A continuación, debe almacenar cada imagen de disco en un recurso compartido de archivos al que puedan acceder los hosts de sesión. Para obtener más información sobre los requisitos de un recurso compartido de archivos, consulte Recurso compartido.

::: zone-pivot="app-attach" If using App-V, consulte Creación y administración de aplicaciones virtualizadas de App-V. ::: zone-end

Tipos de imágenes de disco

En el caso de las imágenes de disco MSIX y Appx, puede usar Composite Image File System (CimFS), VHDX o VHD para las imágenes de disco, pero no se recomienda usar VHD. El montaje y desmontaje de imágenes CimFS es más rápido que el de archivos VHD y VHDX y también consume menos CPU y memoria. Solo se recomienda usar CimFS para las imágenes de aplicación si los hosts de sesión ejecutan Windows 11.

Una imagen CimFS es una combinación de varios archivos: un archivo que tiene la extensión de archivo .cim y contiene metadatos, junto con al menos dos otros archivos, uno que empieza por objectid_ y otro que empieza por region_, que contienen los datos reales de la aplicación. Los archivos que acompañan al archivo .cim no tienen una extensión de archivo. En la tabla siguiente se muestra una lista de ejemplo de los archivos que puede encontrar para una imagen CimFS:

Nombre de archivo Size
MyApp.cim 1 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264 132 KB

La tabla siguiente es una comparación de rendimiento entre VHDX y CimFS. Estos números son el resultado de una serie de pruebas con 500 archivos de 300 MB cada uno por formato. Las pruebas se realizaron en una máquina virtual de Azure DSv4.

Metric VHD CimFS
Tiempo medio de montaje 356 ms 255 ms
Tiempo medio de desmontado 1615 ms 36 ms
Consumo de memoria 6 % (de 8 GB) 2 % (de 8 GB)
CPU (pico de recuento) Supere el tiempo de espera varias veces Sin efecto

Registro de la aplicación

La asociación de aplicaciones monta imágenes de disco o paquetes de App-V que contienen las aplicaciones de un recurso compartido de archivos a la sesión de un usuario durante el inicio de sesión y, a continuación, un proceso de registro hace que las aplicaciones estén disponibles para el usuario. Hay dos tipos de registro:

La asociación de aplicaciones MSIX monta imágenes de disco que contienen las aplicaciones de un recurso compartido de archivos en la sesión de un usuario durante el inicio de sesión. A continuación, un proceso de registro hace que las aplicaciones estén disponibles para el usuario. Hay dos tipos de registro:

  • A petición: las aplicaciones solo se registran parcialmente al iniciar sesión, y el registro completo de una aplicación se pospone hasta que el usuario inicia la aplicación. Se recomienda usar el tipo de registro A petición, ya que no afecta al tiempo necesario para iniciar sesión en Azure Virtual Desktop. El método de registro predeterminado es A petición.

  • Bloqueo al iniciar sesión: cada aplicación que se asigna a un usuario está totalmente registrada. El registro se produce mientras el usuario inicia sesión, lo que puede afectar al tiempo de inicio de sesión en Azure Virtual Desktop.

Importante

Todos los paquetes de aplicación MSIX y Appx incluyen un certificado. Usted es responsable de asegurarse de que los certificados sean de confianza en su entorno. Los certificados autofirmados se admiten con la cadena de confianza adecuada.

La asociación de aplicaciones no limita el número de aplicaciones que pueden usar los usuarios. Debe tener en cuenta el rendimiento de red disponible y el número de identificadores abiertos por archivo (cada imagen) que admite el recurso compartido de archivos, ya que podría limitar el número de usuarios o aplicaciones que se pueden admitir. Para obtener más información, consulte Recurso compartido de archivos.

Importante

Todos los paquetes de aplicación MSIX incluyen un certificado. Usted es responsable de asegurarse de que los certificados sean de confianza en su entorno. Se admiten certificados autofirmados.

La asociación de aplicaciones MSIX no limita el número de aplicaciones que pueden usar los usuarios. Debe tener en cuenta el rendimiento de red disponible y el número de identificadores abiertos por archivo (cada imagen) que admite el recurso compartido de archivos, ya que podría limitar el número de usuarios o aplicaciones que se pueden admitir. Para obtener más información, consulte Recurso compartido de archivos.

Estado de la aplicación

Los paquetes de aplicación se establecen como activos o inactivos. Los paquetes establecidos como activos permiten que la aplicación esté disponible para los usuarios. Azure Virtual Desktop omite los paquetes establecidos como inactivos y estos no se agregan cuando un usuario inicia sesión.

Los paquetes MSIX pueden establecerse como activos o inactivos. Los paquetes MSIX establecidos como activos permiten que la aplicación esté disponible para los usuarios. Azure Virtual Desktop omite los paquetes MSIX establecidos como inactivos y estos no se agregan cuando un usuario inicia sesión.

Nuevas versiones de aplicaciones

Puede agregar una nueva versión de una aplicación proporcionando una nueva imagen que contenga la aplicación actualizada. Puede usar este nueva imagen de dos maneras:

  • En paralelo: cree una nueva aplicación con la nueva imagen de disco y asígnela a los mismos grupos de hosts y usuarios que la aplicación existente.

  • Local: cree una nueva imagen en la que cambie el número de versión de la aplicación y luego actualice la aplicación existente para usar la nueva imagen. El número de versión puede ser superior o inferior, pero no se puede actualizar una aplicación con el mismo número de versión. No elimine la imagen existente hasta que todos los usuarios terminen de usarla.

Una vez actualizada, los usuarios obtendrán la versión actualizada de la aplicación la próxima vez que inicien sesión. Los usuarios no necesitan dejar de usar la versión anterior para agregar una nueva versión.

Nuevas versiones de aplicaciones

Con la asociación de aplicaciones MSIX, debe eliminar el paquete de aplicación y, luego, crear una nueva aplicación con la nueva imagen de disco y asignarla a los mismos grupos de hosts. No se puede actualizar localmente como ocurre con la asociación de aplicaciones. Los usuarios obtendrán la nueva imagen con la aplicación actualizada la próxima vez que inicien sesión. Debe realizar estas tareas durante una ventana de mantenimiento.

Proveedores de identidades

Estos son los proveedores de identidades que puede usar con la asociación de aplicaciones:

Proveedor de identidades Estado
Microsoft Entra ID Compatible
Active Directory Domain Services (AD DS) Compatible
Servicios de dominio de Microsoft Entra No compatible

Estos son los proveedores de identidades que puede usar con la asociación de aplicaciones MSIX:

Proveedor de identidades Estado
Microsoft Entra ID No compatible
Active Directory Domain Services (AD DS) Compatible
Microsoft Entra Domain Services (Azure AD DS) No compatible

Recurso compartido de archivos

La asociación de aplicaciones requiere que las imágenes de aplicación se almacenen en un recurso compartido de archivos SMB, que luego se monta en cada host de sesión durante el inicio de sesión. La asociación de aplicaciones no tiene dependencias en el tipo de tejido de almacenamiento que usa el recurso compartido de archivos. Se recomienda usar Azure Files, ya que es compatible con Microsoft Entra ID y Active Directory Domain Services y ofrece una excelente relación entre costos y sobrecarga de administración.

También puede usar Azure NetApp Files, pero eso requiere que los hosts de sesión se unan a Active Directory Domain Services.

La asociación de aplicaciones MSIX requiere que las imágenes de aplicación se almacenen en un recurso compartido de archivos SMB, versión 3, que luego se monta en cada host de sesión durante el inicio de sesión. La conexión de aplicaciones en formato MSIX no tiene dependencias en el tipo de tejido de almacenamiento que usa el recurso compartido de archivos. Se recomienda usar Azure Files, ya que es compatible con los proveedores de identidades admitidos que puede usar para la asociación de aplicaciones MSIX y ofrece una excelente relación entre costos y sobrecarga de administración. También puede usar Azure NetApp Files, pero eso requiere que los hosts de sesión se unan a Active Directory Domain Services.

En las secciones siguientes se proporcionan algunas instrucciones sobre los permisos, el rendimiento y la disponibilidad necesarios para el recurso compartido de archivos.

Permisos

Cada host de sesión monta imágenes de aplicación desde el recurso compartido de archivos. Debe configurar los permisos NTFS y de recursos compartidos para permitir que cada objeto de equipo de host de sesión tenga acceso de lectura a los archivos y al recurso compartido de archivos. La configuración del permiso correcto dependerá del proveedor de almacenamiento y del proveedor de identidades que use para el recurso compartido de archivos y los hosts de sesión.

  • Para usar Azure Files cuando los hosts de sesión se unen a Microsoft Entra ID, debe asignar rol de control de acceso basado en roles (RBAC) de Azure de lectura y acceso a los datos a las entidades de servicio de Azure Virtual Desktop y proveedor de ARM de Azure Virtual Desktop. Esta asignación de roles de RBAC permite que los hosts de sesión accedan a la cuenta de almacenamiento mediante claves de acceso o Microsoft Entra.

  • Para obtener información sobre cómo asignar un rol RBAC de Azure a las entidades de servicio de Azure Virtual Desktop, consulte Asignación de roles RBAC a las entidades de servicio de Azure Virtual Desktop. En una actualización futura, no será necesario asignar la entidad de servicio del Proveedor de ARM de Azure Virtual Desktop.

    Para obtener más información sobre el uso de Azure Files con hosts de sesión que están unidos a Microsoft Entra ID, Active Directory Domain Services o Microsoft Entra Domain Services, consulte Introducción a las opciones de autenticación basada en la identidad de Azure Files con el acceso SMB.

    Advertencia

    La asignación de la entidad de servicio de proveedor ARM de Azure Virtual Desktop a la cuenta de almacenamiento permite el servicio Azure Virtual Desktop para todos los datos de la cuenta de almacenamiento. Se recomienda almacenar en esta cuenta de almacenamiento únicamente las aplicaciones que se vayan a usar con la asociación de aplicaciones y renovar las claves de acceso con regularidad.

  • Para Azure NetApp Files, puede crear un volumen SMB y configurar permisos NTFS para conceder acceso de lectura al objeto de equipo de cada host de sesión. Los hosts de sesión deben unirse a Active Directory Domain Services o Microsoft Entra Domain Services.

Puede comprobar que los permisos son correctos mediante PsExec. Para obtener más información, consulte Comprobación del acceso al recurso compartido de archivos.

Rendimiento

Los requisitos pueden variar considerablemente en función de cuántas aplicaciones empaquetadas están almacenadas en una imagen, por lo que debe probar las aplicaciones para saber cuáles son los requisitos. En el caso de imágenes de mayor tamaño, deberá asignar más ancho de banda. En la tabla siguiente, se proporciona un ejemplo de los requisitos de una sola imagen de 1 GB o un paquete de App-V que contiene una aplicación que requiere por host de sesión:

Resource Requisitos
IOPS de estado estable Una IOP
Inicio de sesión de arranque de la máquina 10 IOPS
Latencia 400 ms

Para optimizar el rendimiento de las aplicaciones, se recomienda lo siguiente:

  • El recurso compartido de archivos debe estar en la misma región de Azure que los hosts de sesión. Si se usa Azure Files, la cuenta de almacenamiento debe estar en la misma región de Azure que los hosts de sesión.

  • Excluir las imágenes de disco que contienen las aplicaciones de los exámenes antivirus, ya que son de solo lectura.

  • Asegurarse de que el almacenamiento y el tejido de red pueden proporcionar un rendimiento adecuado. Debe evitar usar el mismo recurso compartido de archivos con contenedores de perfiles de FSLogix.

Disponibilidad

Los planes de recuperación ante desastres para Azure Virtual Desktop deben incluir la replicación del recurso compartido de archivos en la ubicación secundaria de conmutación por error. También deberá asegurarse de que la ruta de acceso del recurso compartido de archivos sea accesible en la ubicación secundaria. Por ejemplo, puede usar espacios de nombres del Sistema de archivos distribuido (DFS) con Azure Files para proporcionar un único nombre de recurso compartido en distintos recursos compartidos de archivos. Para obtener más información sobre la recuperación ante desastres para Azure Virtual Desktop, consulte Configuración de un plan de continuidad empresarial y recuperación ante desastres.

Azure Files

Azure Files tiene límites en cuanto al número de identificadores abiertos por directorio raíz, directorio y archivo. Al usar la conexión de aplicaciones o la conexión de aplicaciones MSIX, las imágenes de disco VHDX o CimFS se montan con la cuenta de equipo del host de sesión, lo que significa que se abre un identificador por host de sesión y por imagen de disco, en lugar de por usuario. Para más información sobre los límites y las instrucciones de ajuste de tamaño, vea Objetivos de escalabilidad y rendimiento de Azure Files y Guía de dimensionamiento de Azure Files para Azure Virtual Desktop.

Certificados de paquetes MSIX y Appx

Todos los paquetes MSIX y Appx requieren un certificado válido de firma de código. Para usar estos paquetes con la asociación de aplicaciones, debe asegurarse de que toda la cadena de certificados es de confianza en los hosts de sesión. Un certificado de firma de código tiene el identificador de objeto 1.3.6.1.5.5.7.3.3. Puede obtener un certificado de firma de código para los paquetes desde lo siguiente:

Una vez que haya obtenido un certificado, debe firmar digitalmente los paquetes MSIX o Appx con el certificado. Puede usar la herramienta de empaquetado MSIX para firmar los paquetes al crear un paquete MSIX. Para obtener más información, consulte Creación de un paquete MSIX desde cualquier instalador de escritorio.

Para asegurarse de que el certificado es de confianza en los hosts de sesión, necesita que estos hosts confíen en toda la cadena de certificados. La forma de hacerlo depende de dónde obtuvo el certificado y de cómo administra los hosts de sesión y el proveedor de identidades que utilice. En la tabla siguiente se proporcionan algunas instrucciones sobre cómo asegurarse de que el certificado es de confianza en los hosts de sesión:

  • CA pública: los certificados de una CA pública son de confianza de manera predeterminada en Windows y Windows Server.

  • CA empresarial interna:

    • en el caso de los hosts de sesión unidos a Active Directory, con AD CS configurado como entidad de certificación empresarial interna, se confía de manera predeterminada y se almacenan en el contexto de nomenclatura de configuración de Active Directory Domain Services. Cuando AD CS es una entidad de certificación independiente configurada, debe configurar la directiva de grupo para distribuir los certificados raíz e intermedios a los hosts de sesión. Para obtener más información, consulte Distribución de certificados a dispositivos Windows mediante la directiva de grupo.

    • En el caso de los hosts de sesión unidos a Microsoft Entra ID, puede usar Microsoft Intune para distribuir los certificados raíz e intermedios a los hosts de sesión. Para obtener más información, consulte Perfiles de certificados raíz de confianza para Microsoft Intune.

    • En el caso de los hosts de sesión que usan la unión híbrida de Microsoft Entra, puede usar cualquiera de los métodos anteriores, en función de sus requisitos.

  • Autofirmado: instale la raíz de confianza en el almacén de Entidades de certificación raíz de confianza en cada host de sesión. No se recomienda distribuir este certificado mediante la directiva de grupo o Intune, ya que solo se debe usar para las pruebas.

Importante

Debe establecer la marca de tiempo del paquete para que su validez pueda durar más que la fecha de expiración del certificado. De lo contrario, una vez que el certificado haya expirado, debe actualizar el paquete con un nuevo certificado válido y, una vez más, asegurarse de que es de confianza en los hosts de sesión.

Pasos siguientes

Aprenda a Agregar y administrar aplicaciones de asociación de aplicaciones en Azure Virtual Desktop.