Preguntas frecuentes de Azure Virtual Desktop

Si desea crear grupos de hosts y otros objetos, debe tener asignado el rol Colaborador en la suscripción o grupo de recursos con el que está trabajando.

Debe tener asignada el rol de administrador de acceso de usuario en un grupo de aplicaciones para publicar grupos de aplicaciones para usuarios o grupos de usuarios.

Para impedir que un administrador solo administre las sesiones de usuario, como el envío de mensajes a los usuarios, el cierre de la sesión de los usuarios, etc., puede crear roles personalizados. Por ejemplo:

    "actions": [
        "Microsoft.Resources/deployments/operations/read",
        "Microsoft.Resources/tags/read",
        "Microsoft.Authorization/roleAssignments/read",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/*",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
        "Microsoft.DesktopVirtualization/hostpools/sessionhosts/write"
    ],
    "notActions": [],
    "dataActions": [],
    "notDataActions": []
}

Los usuarios deben estar en el mismo inquilino de Microsoft Entra que su área de trabajo asignada, el grupo de hosts y el grupo de aplicaciones. Tener todo en el mismo inquilino le permite asignar usuarios a roles adecuados de control de acceso basado en rol (RBAC) para que puedan acceder a sus recursos.

Sin embargo, puede implementar máquinas virtuales (VM) en un inquilino de Microsoft Entra diferente si están unidos a la misma instancia de AD que el usuario o un AD que tiene una relación de confianza con el AD del usuario.

Todos los recursos de servicio tienen una ubicación asociada a ellos. La ubicación de un grupo de hosts determina en qué área geográfica se almacenan los metadatos del servicio para el grupo de hosts. Un grupo de aplicaciones no puede existir sin un grupo de hosts. Si agrega aplicaciones a un grupo de aplicaciones de RemoteApp, también necesitará un host de sesión para determinar las aplicaciones del menú de inicio. Para cualquier acción de grupo de aplicaciones, también necesitará un acceso de datos relacionado en el grupo de hosts. Para asegurarse de que los datos no se transfieran entre varias ubicaciones, la ubicación del grupo de aplicaciones debe ser la misma que la del grupo de hosts.

Las áreas de trabajo también deben estar en la misma ubicación que sus grupos de aplicaciones. Cada vez que se actualiza el área de trabajo, el grupo de aplicaciones relacionado se actualiza junto con él. Al igual que con los grupos de aplicaciones, el servicio requiere que todas las áreas de trabajo estén asociadas a grupos de aplicaciones creados en la misma ubicación.

Al ejecutar un cmdlet de PowerShell, solo ve el nombre y la ubicación del recurso.

Por ejemplo:

Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg

Location Name   Type
-------- ----   ----
westus   0224hp Microsoft.DesktopVirtualization/hostpools

Para ver todas las propiedades de un recurso, agregue format-list o fl al final del cmdlet.

Por ejemplo:

Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg |fl

Para ver propiedades específicas, agregue los nombres de propiedad específicos después format-list o fl.

Por ejemplo:

Get-AzWvdHostPool -Name demohp -ResourceGroupName 0414rg |fl CustomRdpProperty

CustomRdpProperty : audiocapturemode:i:0;audiomode:i:0;drivestoredirect:s:;redirectclipboard:i:1;redirectcomports:i:0;redirectprinters:i:1;redirectsmartcards:i:1;screen modeid:i:2;

Azure Virtual Desktop no admite las cuentas de usuario invitado de Microsoft Entra. Por ejemplo, supongamos que un grupo de usuarios invitados tiene licencias de Microsoft 365 E3 por usuario, Windows E3 por usuario o WIN VDA en su propia empresa, pero son usuarios invitados en la instancia de Microsoft Entra ID de otra empresa. La otra empresa administraría los objetos de usuario de los usuarios invitados tanto en Microsoft Entra ID como en Active Directory como cuentas locales.

No puede usar sus propias licencias en beneficio de un tercero. Además, Azure Virtual Desktop no es compatible actualmente con las cuentas de Microsoft (MSA).

Actualmente no hay una manera confiable de recopilar las direcciones IP del cliente web, por lo que no se incluye ese valor en la tabla.

Hay varias opciones en Azure Virtual Desktop para controlar las copias de seguridad. En el nivel de Compute, la copia de seguridad solo se recomienda para grupos de hosts personales a través de Azure Backup. En el nivel de Storage, la solución de copia de seguridad recomendada varía en función del almacenamiento back-end usado para almacenar perfiles de usuario. Si se usa el recurso compartido de Azure Files, se recomienda Azure Backup para el recurso compartido. Si se usa Azure NetApp Files, Insantáneas/Directivas o Copia de seguridad de Azure NetApp Files están disponibles.

Actualmente, Azure Virtual Desktop está optimizado para Teams. En este momento, Microsoft no admite aplicaciones de colaboración de terceros, como Zoom. Las organizaciones externas son responsables de proporcionar las instrucciones de compatibilidad a sus clientes. Además, Azure Virtual Desktop no admite Skype Empresarial.

Una vez que se crea un grupo de hosts, no se puede cambiar el tipo. Sin embargo, las VM que registre en un grupo de hosts pueden moverse a otro tipo de grupo de hosts.

Las limitaciones o cuotas de FSLogix dependen del tejido de almacenamiento usado para almacenar los archivos VHD(X) de perfil de usuario.

En la tabla siguiente se muestra un ejemplo de las operaciones de E/S que necesita un perfil de FSLogix para admitir cada usuario. Los requisitos pueden variar enormemente en función del usuario, las aplicaciones y la actividad de cada perfil.

El ejemplo de esta tabla corresponde a un solo usuario, pero se puede usar para calcular los requisitos del número total de usuarios en su entorno. Por ejemplo, necesitaría aproximadamente 1000 IOPS para 100 usuarios, y alrededor de 5000 IOPS al iniciar y cerrar sesión.

Los factores siguientes pueden afectar al límite de escala de los grupos de hosts:

• La plantilla de Azure está limitada a 800 objetos. Para obtener más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure. Cada VM crea también aproximadamente seis objetos; es decir, que puede crear alrededor de 132 VM cada vez que ejecuta la plantilla.

• Existen restricciones en cuanto a la cantidad de CPU virtuales que se pueden crear por región y por suscripción. Por ejemplo, si tiene una suscripción de Contrato Enterprise, puede crear de manera predeterminada 350 CPU virtuales. Tiene que dividir 350, o bien por el número predeterminado de CPU virtuales por máquina virtual, o bien por su propio límite de CPU virtuales para conocer el número de máquina virtual que puede crear cada vez que ejecuta la plantilla. Más información sobre los Límites de Virtual Machines: Azure Resource Manager y Comprobación de las cuotas de CPU virtuales.

• El nombre del prefijo de máquina virtual no puede superar los 11 caracteres, por lo que cuando se agrega un número secuencial, el nombre total tiene un máximo de 15 caracteres. Para obtener más información, consulte Reglas y restricciones de nomenclatura para los recursos de Azure.

Azure Lighthouse no es totalmente compatible con la administración de entornos de Azure Virtual Desktop. Dado que Lighthouse actualmente no admite la administración de usuarios inquilinos entre instancias de Microsoft Entra ID, los clientes de Lighthouse aún tienen que iniciar sesión en la instancia de Microsoft Entra ID que los clientes usan para administrar usuarios.

Tampoco puede usar las suscripciones de espacio aislado de CSP con el servicio Azure Virtual Desktop. Para obtener más información, consulte Cuenta de espacio aislado de integración.

Por último, si ha habilitado el proveedor de recursos de la cuenta de propietario de CSP, las cuentas de cliente de CSP no pueden modificar el proveedor de recursos.

Después de registrar una máquina virtual en un grupo de hosts en el servicio Azure Virtual Desktop, el agente actualiza periódicamente el token de la máquina virtual cada vez que la máquina virtual está activa. El certificado para el token de registro es válido durante 90 días. Debido a este límite de 90 días, se recomienda que las máquinas virtuales estén en línea durante 20 minutos cada 90 días, a fin de que puedan pueda actualizar sus tokens y actualizar el agente y los componentes de la pila en paralelo. La activación de la máquina virtual en este límite de tiempo impide que su token de registro expire o deje de ser válido. Si ha iniciado la máquina virtual después de 90 días y está experimentando problemas de registro, siga las instrucciones de la guía de solución de problemas del agente de Azure Virtual Desktop para quitar la máquina virtual del grupo de hosts, reinstalar el agente y volver a registrarlo en el grupo.

Sí. Los grupos de hosts de Azure Virtual Desktop tienen una opción para seleccionar el conjunto de disponibilidad o las zonas de disponibilidad cuando se crea una máquina virtual. Estas opciones de disponibilidad son las mismas que usa Azure Compute. Si selecciona una zona para la máquina virtual que crea en un grupo de hosts, la configuración se aplica automáticamente a todas las máquinas virtuales que cree en esa zona. Si prefiere distribuir las máquinas virtuales del grupo de hosts en varias zonas, deberá seguir las instrucciones de Agregar máquinas virtuales con Azure Portal para seleccionar manualmente una zona nueva para cada nueva máquina virtual que cree.

Asegúrese de que las zonas de disponibilidad de Azure están disponibles en la región donde se encuentran las máquinas virtuales.

La opción de disponibilidad que debe usar para las máquinas virtuales depende de la ubicación de la imagen. En la tabla siguiente se explica la relación que tiene cada valor de configuración con estas variables para ayudarle a averiguar qué opción es la mejor para su implementación.

Se recomienda usar el Control de aplicaciones de Windows Defender en lugar de AppLocker.

Sí. Puede tener ambas implementaciones en el mismo inquilino de Microsoft Entra.

No. Azure Virtual Desktop no admite discos efímeros de sistema operativo con máquinas virtuales Azure.

Los metadatos de un grupo de hosts se replican dentro de una geografía para lograr resistencia. Si la región en la que se encuentra el grupo de hosts deja de funcionar, se conmuta por error a su réplica. Durante este período de conmutación por error, Azure Virtual Desktop no acepta nuevas conexiones de usuario a las máquinas virtuales del host de sesión de ese grupo de hosts hasta que se complete la conmutación por error. Las sesiones que haya en las máquinas virtuales del host de sesión de ese grupo de hosts permanecen conectadas y no se ven afectadas. Para más información sobre cómo se implementa la resistencia del servicio Azure Virtual Desktop, consulte Arquitectura y resistencia del servicio Azure Virtual Desktop.

Si intenta superar las 200 máquinas virtuales en un conjunto de disponibilidad en Azure Virtual Desktop, recibirá un mensaje de error que indica "No se puede crear la máquina virtual porque ya se ha alcanzado el límite de 200 máquinas virtuales". Para más información, consulte Información general sobre los conjuntos de disponibilidad.

Sí. Para más información, consulte Actualización local para máquinas virtuales compatibles que ejecutan Windows en Azure y Actualización local para máquinas virtuales que ejecutan Windows Server en Azure.