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 asignado el rol Administrador de acceso de usuarios 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": []
}

Cuando se asigna un usuario a un grupo de aplicaciones, el servicio realiza una simple asignación de roles de Azure. Como consecuencia, la instancia de Azure Active Directory (Azure AD) del usuario y la instancia de Azure AD del grupo de aplicaciones deben estar en la misma ubicación. Todos los objetos de servicio, como los grupos de hosts, los grupos de aplicaciones y las áreas de trabajo, también deben estar en el mismo Azure AD que el usuario.

Puede crear máquinas virtuales (VM) en otra instancia de Azure AD siempre que sincronice la instancia de Active Directory con la instancia de Azure AD del usuario en la misma red virtual (VNET).

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 establecer las aplicaciones del menú Inicio. Para cualquier acción del grupo de aplicaciones, también necesitará un acceso a 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. Siempre que el área de trabajo se actualiza, 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 cuentas de usuario invitado de Azure AD. 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 Azure AD de otra empresa. La otra empresa administraría los objetos de usuario de los usuarios invitados tanto en Azure AD 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 durante el inicio y cierre de 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 núcleos que se pueden crear por región y por suscripción. Por ejemplo, si tiene una suscripción de Contrato Enterprise, puede crear 350 núcleos. Tendrá que dividir 350 por el número predeterminado de núcleos por VM o por su propio límite de núcleos para conocer el número de VM que puede crear cada vez que ejecuta la plantilla. Más información sobre los Límites de Virtual Machines: Azure Resource Manager.

• El nombre del prefijo de la VM y el número de VM tiene menos 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 Azure AD, los clientes de Lighthouse aún tienen que iniciar sesión en la instancia de Azure AD 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 podrán 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 impedirá 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 el 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 Azure Active Directory.

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