Asociación de aplicaciones en Azure Virtual Desktop

2025-06-20

La asociación de aplicaciones le permite adjuntar aplicaciones dinámicamente desde un paquete de aplicación a una sesión de usuario en Azure Virtual Desktop. Las aplicaciones no se instalan localmente en hosts de sesión o imágenes, lo que facilita la creación de imágenes personalizadas para los hosts de sesión y reduce la sobrecarga operativa y los costos de la organización. Las aplicaciones se ejecutan en 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.

Estas son algunas de las principales ventajas de App Attach:

Las aplicaciones se entregan mediante RemoteApp o como parte de una sesión de escritorio. Los permisos se aplican por aplicación por usuario, lo que proporciona un mayor control sobre las aplicaciones a las que los usuarios pueden acceder en una sesión remota. Los usuarios de escritorio solo ven las aplicaciones de asociación de aplicaciones asignadas.
El mismo paquete de aplicación se puede usar en varios grupos de hosts.
Las aplicaciones se pueden ejecutar en cualquier host de sesión que ejecute un sistema operativo cliente Windows en la misma región de Azure que el paquete de aplicación.
Las aplicaciones se pueden actualizar a una nueva versión de la aplicación con una nueva imagen de disco sin necesidad de una ventana de mantenimiento.
Los usuarios pueden ejecutar varias versiones de la misma aplicación simultáneamente en el mismo host de sesión.
La telemetría para el uso y el 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
Paquete MSIX y MSIX	`.msix` `.msixbundle`
Paquete de Appx y Appx	`.appx` `.appxbundle`
App-V	`.appv`

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 en 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, donde la principal diferencia es 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 adecuado para uso empresarial.

Microsoft Application Virtualization (App-V) para Windows ofrece 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 ellos como si se hubieran instalado localmente.

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, consulte ¿Qué es MSIX?.

Cómo obtiene un usuario una aplicación

Puede asignar diferentes aplicaciones a distintos usuarios en el 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 correcta en el momento adecuado:

La aplicación debe asignarse al grupo host. La asignación de la aplicación al grupo de hosts le permite ser selectivo sobre los grupos de hosts en los que la aplicación está disponible para asegurarse de que la aplicación puede usar los recursos de hardware adecuados. Por ejemplo, si una aplicación consume muchos gráficos, puede asegurarse de que solo se ejecuta en un grupo de hosts con hosts de sesión optimizados para GPU.
El usuario debe poder iniciar sesión en los hosts de sesión del grupo de hosts, por lo que debe estar en un grupo de aplicaciones Escritorio o RemoteApp. Para un grupo de aplicaciones 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 proporciona control sobre quién obtiene una aplicación en qué grupo host y también cómo es posible que los usuarios de un único grupo de hosts o incluso que hayan iniciado sesión en el mismo host de sesión multisesión obtengan combinaciones de aplicaciones diferentes. Los usuarios que no cumplen los requisitos no obtienen la aplicación.

Imágenes de aplicación

Para poder usar paquetes de aplicaciones MSIX con Azure Virtual Desktop, debe crear una imagen MSIX a partir de los paquetes de aplicación existentes. Como alternativa, puede usar un paquete de App-V en su lugar. A continuación, debe almacenar cada imagen MSIX o paquete de App-V 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 de archivos.

Tipos de imagen de disco

En el caso de las imágenes de disco MSIX y Appx, puede usar el sistema de archivos de imagen compuesta (CimFS),VHDX o VHD, pero no se recomienda usar VHD. El montaje y desmontaje de imágenes CimFS es más rápido que las imágenes 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 tiene la extensión de .cim archivo y contiene metadatos, junto con al menos otros dos archivos, uno a objectid_ partir de y el otro a region_ partir de que contienen los datos reales de la aplicación. Los archivos que acompañan al .cim archivo no tienen una extensión de archivo. En la tabla siguiente se muestra una lista de archivos de ejemplo que 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 fueron el resultado de una ejecución de prueba con 500 archivos de 300 MB cada uno por formato y las pruebas se realizaron en una máquina virtual de Azure DSv4.

Métrica	VHD	CimFS
Tiempo medio de montaje	356 ms	255 ms
Promedio de tiempo de desmontaje	1615 ms	36 ms
Consumo de memoria	6% (de 8 GB)	2% (de 8 GB)
CPU (pico de recuento)	Se ha agotado varias veces	Ningún efecto

Precaución

Un problema afecta actualmente a las imágenes cimFS con Windows 11, versión 24H2, lo que impide que se monten las imágenes. Estamos trabajando activamente en una corrección que se estima que estará disponible en junio de 2025. Las soluciones alternativas son usar imágenes VHDX en su lugar o usar una versión de Windows 11 antes de 24H2.

Registro de la aplicación

App Attach monta imágenes de disco o paquetes de App-V que contienen las aplicaciones de un recurso compartido de archivos en 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:

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. A petición es el tipo de registro que se recomienda usar, ya que no afecta al tiempo que se tarda en iniciar sesión en Azure Virtual Desktop. A petición es el método de registro predeterminado.
Bloqueo de inicio de sesión: cada aplicación que asigne a un usuario está totalmente registrada. El registro se produce mientras el usuario inicia sesión en su sesión, lo que podría afectar al tiempo de inicio de sesión en Azure Virtual Desktop.

Importante

Todos los paquetes de aplicaciones MSIX y Appx incluyen un certificado. Es responsable de asegurarse de que los certificados son 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 los usuarios pueden usar. 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 puede admitir. Para obtener más información, vea Recurso compartido de archivos.

Estado de la aplicación

Los paquetes de aplicación se establecen como activos o inactivos. Los paquetes establecidos en activo hacen que la aplicación esté disponible para los usuarios. Azure Virtual Desktop omite los paquetes establecidos en inactivos y 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 esta 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 host y usuarios que la aplicación existente.
En contexto: cree una nueva imagen donde cambie el número de versión de la aplicación y, a continuación, 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 actualizado, los usuarios obtienen 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.

Proveedores de identidades

Estos son los proveedores de identidades que puede usar con App Attach:

Proveedor de identidades	Estado
Microsoft Entra ID	Compatible
Servicios de dominio de Active Directory (AD DS)	Compatible
Servicios de dominio de Microsoft Entra	No se admite

La asociación de aplicaciones requiere que las imágenes de la 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 o Servicios de dominio de Active Directory, y ofrece un gran valor entre costo y sobrecarga de administración.

También puede usar Azure NetApp Files, pero esto requiere que los hosts de sesión se unan a Servicios de dominio de Active Directory.

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

Permissions

Cada host de sesión monta imágenes de aplicación del recurso compartido de archivos. Debe configurar NTFS y compartir permisos para permitir que cada objeto de equipo host de sesión tenga acceso de lectura a los archivos y al recurso compartido de archivos. La forma de configurar el permiso correcto depende del proveedor de almacenamiento y el 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 el rol de control de acceso basado en rol (RBAC) de Acceso a datos y lector a las entidades de servicio del proveedor de ARM de Azure Virtual Desktop y Azure Virtual Desktop. Esta asignación de roles de RBAC permite a los hosts de sesión acceder 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 tendrá que 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, Servicios de dominio de Active Directory o Servicios de dominio de Microsoft Entra, consulte Información general de Azure Files opciones de autenticación basadas en identidad para el acceso SMB.

Advertencia

La asignación de la entidad de servicio del proveedor de ARM de Azure Virtual Desktop a la cuenta de almacenamiento concede el servicio Azure Virtual Desktop a todos los datos dentro de la cuenta de almacenamiento. Se recomienda almacenar solo aplicaciones para usarlas con App Attach en esta cuenta de almacenamiento y rotar las claves de acceso con regularidad.
Para Azure Files con Servicios de dominio de Active Directory, debe asignar el rol de control de acceso basado en rol (RBAC) del lector de recursos compartidos smb de datos de almacenamiento de Azure como permiso de nivel de recurso compartido predeterminado y configurar permisos NTFS para conceder acceso de lectura al objeto de equipo de cada host de sesión.

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, Servicios de dominio de Active Directory o Servicios de dominio de Microsoft Entra, consulte Información general de Azure Files opciones de autenticación basadas en identidad para el acceso SMB.
Por Azure NetApp Files, puede crear un volumen SMB y configurar permisos NTFS para dar acceso de lectura al objeto de equipo de cada host de sesión. Los hosts de sesión deben estar unidos a Servicios de dominio de Active Directory o Servicios de dominio de Microsoft Entra.

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 en gran medida en función del número de aplicaciones empaquetadas almacenadas en una imagen y debe probar las aplicaciones para comprender sus requisitos. Para imágenes más grandes, debe 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:

Recurso	Requisitos
IOPS de estado estable	Un IOP
Inicio de sesión de arranque de máquina	10 E/S por segundo
Latencia	400 ms

Para optimizar el rendimiento de las aplicaciones, se recomienda:

El recurso compartido de archivos debe estar en la misma región de Azure que los hosts de sesión. Si usa Azure Files, la cuenta de almacenamiento debe estar en la misma región de Azure que los hosts de sesión.
Excluya las imágenes de disco que contienen las aplicaciones de los exámenes antivirus, ya que son de solo lectura.
Asegúrese 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 de Azure Virtual Desktop deben incluir la replicación del recurso compartido de archivos en la ubicación de conmutación por error secundaria. También debe asegurarse de que la ruta de acceso del recurso compartido de archivos es 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 entre diferentes recursos compartidos de archivos. Para 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 el número de identificadores abiertos por directorio raíz, directorio y archivo. Las imágenes de disco VHDX o CimFS se montan mediante la cuenta de equipo del host de sesión, lo que significa que se abre un identificador por host de sesión por imagen de disco, en lugar de por usuario. Para obtener más información sobre los límites y la guía de ajuste de tamaño, consulte Azure Files objetivos de escalabilidad y rendimiento y Azure Files guía de ajuste de tamaño para Azure Virtual Desktop.

Certificados de paquete MSIX y Appx

Todos los paquetes MSIX y Appx requieren un certificado de firma de código válido. Para usar estos paquetes con App Attach, 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 1.3.6.1.5.5.7.3.3de objeto . Puede obtener un certificado de firma de código para los paquetes de:

Una entidad de certificación (CA) pública.
Una entidad de certificación independiente o empresarial interna, como Servicios de certificados de Active Directory. Debe exportar el certificado de firma de código, incluida su clave privada.
Una herramienta como el cmdlet de PowerShell New-SelfSignedCertificate que genera un certificado autofirmado. Solo debe usar certificados autofirmados en un entorno de prueba. Para obtener más información sobre cómo crear un certificado autofirmado para paquetes MSIX y Appx, consulte Creación de un certificado para la firma de paquetes.

Una vez que obtenga un certificado, debe firmar digitalmente los paquetes MSIX o Appx con el certificado. Puede usar msix packaging tool 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 los hosts de sesión confíen en toda la cadena de certificados. La forma en que los hosts de sesión confían en la cadena de certificados depende de dónde obtuvo el certificado y de cómo administre los hosts de sesión y el proveedor de identidades que use. 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 forma predeterminada en Windows y Windows Server.
Ca de empresa interna:
- En el caso de los hosts de sesión unidos a Active Directory, con AD CS configurado como la CA empresarial interna, son de confianza de forma predeterminada y se almacenan en el contexto de nomenclatura de configuración de Servicios de dominio de Active Directory. Cuando AD CS está configurado como ca independiente, debe configurar directiva de grupo para distribuir los certificados raíz e intermedio a los hosts de sesión. Para obtener más información, consulte Distribución de certificados a dispositivos Windows mediante 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 intermedio a los hosts de sesión. Para obtener más información, consulte Perfiles de certificado raíz de confianza para Microsoft Intune.
- En el caso de los hosts de sesión que usan Microsoft Entra unión híbrida, 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 directiva de grupo o Intune, ya que solo se debe usar para las pruebas.

Importante

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

Pasos siguientes

Aprenda a agregar y administrar aplicaciones de Asociación de aplicaciones en Azure Virtual Desktop.