Compartir vía

Requisitos previos para Azure Virtual Desktop

  • Artículo

Hay algunas cosas que necesita para empezar a usar Azure Virtual Desktop. Aquí puede encontrar los requisitos previos que debe completar para proporcionar correctamente a los usuarios escritorios y aplicaciones.

A un nivel general, necesita:

  • Una cuenta de Azure con una suscripción activa
  • Un proveedor de identidades compatible
  • Un sistema operativo compatible para máquinas virtuales de host de sesión
  • Licencias adecuadas
  • Conectividad de red
  • Un cliente de Escritorio remoto

Cuenta de Azure con una suscripción activa

Necesitará una cuenta de Azure con una suscripción activa para implementar Azure Virtual Desktop. Si aún no la tiene, puede crear una cuenta gratis.

Para implementar Azure Virtual Desktop, debe asignar los roles de control de acceso basado en rol (RBAC) de Azure pertinentes. Los requisitos de rol específicos se tratan en cada artículo relacionado para implementar Azure Virtual Desktop, que se enumeran en la sección Pasos siguientes.

También debe asegurarse de que ha registrado el proveedor de recursos Microsoft.DesktopVirtualization para la suscripción. Para comprobar el estado del proveedor de recursos y registrarse si fuera necesario, seleccione la pestaña correspondiente para su escenario y siga los pasos.

Importante

Debe tener permiso para registrar un proveedor de recursos, lo que requiere la operación */register/action. Se incluye si se asigna a su cuenta el rol de colaborador o propietario en la suscripción.

  1. Inicie sesión en Azure Portal.

  2. Seleccione Suscripciones.

  3. Seleccione el nombre de la suscripción.

  4. Seleccione Proveedores de recursos.

  5. Search for Microsoft.DesktopVirtualization.

  6. Si el estado es NotRegistered, seleccione Microsoft.DesktopVirtualization y, a continuación, seleccione Registrar.

  7. Compruebe que el estado de Microsoft.DesktopVirtualization es Registrado.

Identidad

Para acceder a los escritorios y las aplicaciones desde los hosts de sesión, los usuarios deben poder autenticarse. Microsoft Entra ID es el servicio de identidad en la nube centralizado de Microsoft que permite esta funcionalidad. Microsoft Entra ID siempre se usa para autenticar a los usuarios para Azure Virtual Desktop. Los hosts de sesión se pueden unir al mismo inquilino de Microsoft Entra o a un dominio de Active Directory mediante Active Directory Domain Services (AD DS) o Microsoft Entra Domain Services (Microsoft Entra Domain Services), lo que le proporciona una opción de opciones de configuración flexibles.

Hosts de sesión

Debe unir los hosts de sesión que proporcionen escritorios virtuales y aplicaciones al mismo inquilino de Microsoft Entra que los usuarios o un dominio de Active Directory (AD DS o Microsoft Entra Domain Services).

Nota:

Para Azure Local, solo puede unir hosts de sesión a un dominio de Active Directory Domain Services. Solo puede unir hosts de sesión en Azure Local a un dominio de Active Directory Domain Services (AD DS). Esto incluye el uso de combinación híbrida de Microsoft Entra, donde puede beneficiarse de algunas de las funciones proporcionadas por Microsoft Entra ID.

Para unir hosts de sesión a Microsoft Entra ID o a un dominio de Active Directory, necesita los siguientes permisos:

Usuarios

Los usuarios necesitan cuentas que estén en Microsoft Entra ID. Si también usa AD DS o Microsoft Entra Domain Services en la implementación de Azure Virtual Desktop, estas cuentas tendrán que ser identidades híbridas, lo que significa que la cuenta de usuario está sincronizada. Deberá tener en cuenta lo siguiente en función del proveedor de identidades que use:

  • Si usa Microsoft Entra ID con AD DS, deberá configurar Microsoft Entra Connect para sincronizar los datos de identidad del usuario entre AD DS y Microsoft Entra ID.
  • Si está usando Microsoft Entra ID con Microsoft Entra Domain Services, las cuentas de usuario se sincronizan de una manera, de Microsoft Entra ID a Microsoft Entra Domain Services. Este proceso de sincronización es automático;

Importante

La cuenta de usuario debe existir en el inquilino de Microsoft Entra que use para Azure Virtual Desktop. Azure Virtual Desktop no admite cuentas B2B, B2C o de Microsoft personales.

Al usar identidades híbridas, UserPrincipalName (UPN) o el identificador de seguridad (SID) deben coincidir en Active Directory Domain Services y Microsoft Entra ID. Para obtener más información, consulte Identidades admitidas y métodos de autenticación.

Escenarios de identidad admitidos

En la tabla siguiente se resumen los escenarios de identidad que admite actualmente Azure Virtual Desktop:

Escenario de identidad Hosts de sesión Cuentas de usuario
Microsoft Entra ID + AD DS Unidos a AD DS En Microsoft Entra ID y AD DS, sincronizado
Microsoft Entra ID + AD DS Unido a Microsoft Entra ID En Microsoft Entra ID y AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Unido a Microsoft Entra Domain Services En Microsoft Entra ID y Microsoft Entra Domain Services, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Unido a Microsoft Entra Domain Services En Microsoft Entra ID y AD DS, sincronizado
Microsoft Entra ID + Microsoft Entra Domain Services Unido a Microsoft Entra ID En Microsoft Entra ID y Microsoft Entra Domain Services, sincronizado
Solo Microsoft Entra Unido a Microsoft Entra ID En Microsoft Entra ID

Para obtener información más detallada sobre los escenarios de identidad admitidos, incluido el inicio de sesión único y la autenticación multifactor, consulte Identidades admitidas y métodos de autenticación.

Contenedor de perfiles de FSLogix

Para usar el contenedor de perfiles de FSLogix al unir los hosts de sesión a Microsoft Entra ID, deberá almacenar perfiles en Azure Files o Azure NetApp Files. Además, las cuentas de usuario deben ser identidades híbridas. Debe crear estas cuentas en AD DS y sincronizarlas con Microsoft Entra ID. Para obtener más información sobre la implementación del contenedor de perfiles de FSLogix en diferentes escenarios de identidad, consulte los artículos siguientes:

Parámetros de implementación

Deberá especificar los siguientes parámetros de identidad al implementar hosts de sesión:

  • Nombre de dominio, si utiliza AD DS o Microsoft Entra Domain Services.
  • Credenciales para unir hosts de sesión al dominio.
  • Unidad organizativa (UO), que es un parámetro opcional que permite colocar hosts de sesión en la unidad organizativa deseada en el momento de la implementación.

Importante

La cuenta que use para unirse a un dominio no puede tener habilitada la autenticación multifactor (MFA).

Sistemas operativos y licencias

Tiene una selección de sistemas operativos (SO) que puede usar para que los hosts de sesión proporcionen escritorios y aplicaciones. Puede usar diferentes sistemas operativos con distintos grupos de hosts para proporcionar flexibilidad a los usuarios. Se admiten los sistemas operativos y las SKU de 64 bits en las siguientes listas de tablas (en las que las versiones y fechas admitidas están alineadas con la Directiva de ciclo de vida de Microsoft), junto con los métodos de licencia aplicables para cada propósito comercial:

Sistema operativo
(solo 64 bits)		 Método de licencia
(Fines comerciales internos)		 Método de licencia
(Fines comerciales externos)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Beneficio de Uso de Estudiante
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • VDA de Windows por usuario
  • Licencia de acceso de cliente (CAL) de Servicios de Escritorio remoto (RDS) con Software Assurance (por usuario o por dispositivo)
  • Licencias de suscripción de usuario de RDS.
  • Licencia de acceso de suscriptor de RDS (SAL) de Windows Server.

Los precios de acceso por usuario no están disponibles para los sistemas operativos Windows Server.

Para más información sobre las licencias que puede usar, incluidos los precios de acceso por usuario, consulte Licencias de Azure Virtual Desktop.

Importante

Para Azure, puede usar imágenes de sistema operativo proporcionadas por Microsoft en Azure Marketplace, o bien crear sus propias imágenes personalizadas almacenadas en una instancia de Azure Compute Gallery o como una imagen administrada. El uso de plantillas de imagen personalizadas para Azure Virtual Desktop le permite crear fácilmente una imagen personalizada que podrá usar al implementar máquinas virtuales (VM) de host de sesión. Para obtener más información sobre cómo crear imágenes personalizadas, consulte:

Como alternativa, para Azure Local puede usar imágenes de sistema operativo desde:

Puede implementar máquinas virtuales (VM) que se usarán como hosts de sesión desde estas imágenes con cualquiera de los métodos siguientes:

Si su licencia le permitiera usar Azure Virtual Desktop, no es necesario que instale o aplique una licencia independiente, pero si usa precios de acceso por usuario para usuarios externos, deberá inscribir una suscripción de Azure. Deberá asegurarse de que la licencia de Windows usada en los hosts de sesión esté asignada correctamente en Azure y que el sistema operativo esté activado. Para obtener más información, consulte Aplicación de una licencia de Windows a las máquinas virtuales de un host de sesión.

Para los hosts de sesión en Azure Local, debe conceder licencias y activar las máquinas virtuales que usa antes de utilizarlas con Azure Virtual Desktop. Para activar Windows 10 y Windows 11 Enterprise multisesión y Windows Server 2022 Datacenter: Azure Edition, use la comprobación de Azure para máquinas virtuales. Para todas las demás imágenes del sistema operativo (como Windows 10 y Windows 11 Enterprise, y otras ediciones de Windows Server), debe seguir usando los métodos de activación existentes. Para más información, consulte Activación de máquinas virtuales de Windows Server en Azure Local.

Nota:

Para garantizar la funcionalidad continua con la actualización de seguridad más reciente, actualice las máquinas virtuales de Azure Local a la actualización acumulativa más reciente del 17 de junio de 2024. Esta actualización es esencial para que las máquinas virtuales sigan usando las ventajas de Azure. Para obtener más información, consulte Comprobación de Azure para máquinas virtuales.

Sugerencia

Para simplificar los derechos de acceso de los usuarios durante el desarrollo y las pruebas iniciales, Azure Virtual Desktop admite los precios de Azure Dev/Test. Si implementa Azure Virtual Desktop en una suscripción a Azure Dev/Test, los usuarios finales pueden conectarse a esa implementación sin necesidad de tener derechos de licencia independientes, con el fin de realizar pruebas de aceptación o proporcionar comentarios.

Red

Hay varios requisitos de red que deberá cumplir para implementar correctamente Azure Virtual Desktop. Esto permite a los usuarios conectarse a sus escritorios y aplicaciones, a la vez que les proporciona la mejor experiencia de usuario posible.

Los usuarios que se conectan a Azure Virtual Desktop establecen de forma segura una conexión inversa al servicio, lo que significa que no es necesario abrir ningún puerto de entrada. El Protocolo de control de transmisión (TCP) en el puerto 443 se usa de forma predeterminada, pero RDP Shortpath se puede usar para redes administradas y redes públicas que establecen un transporte directo basado en el Protocolo de datagramas de usuario (UDP).

Para implementar correctamente Azure Virtual Desktop, deberá cumplir los siguientes requisitos de red:

  • Necesitará una red virtual y una subred para los hosts de sesión. Si crea los hosts de sesión al mismo tiempo que un grupo de hosts, debe crear esta red virtual de antemano para que aparezca en la lista desplegable. La red virtual debe estar en la misma región de Azure que el host de sesión.

  • Asegúrese de que esta red virtual puede conectarse a los controladores de dominio y a los servidores DNS pertinentes si usa AD DS o Microsoft Entra Domain Services, ya que deberá unir los hosts de sesión al dominio.

  • Los hosts de sesión y los usuarios deben poder conectarse al servicio Azure Virtual Desktop. Estas conexiones también usan TCP en el puerto 443 para una lista específica de direcciones URL. Para más información, consulte Lista de direcciones URL requeridas. Debe asegurarse de que el filtrado de red o un firewall no bloqueen estas direcciones URL para que la implementación funcione correctamente y sea compatible. Si los usuarios necesitan acceder a Microsoft 365, asegúrese de que los hosts de sesión pueden conectarse a puntos de conexión de Microsoft 365.

Tenga en cuenta lo siguiente:

  • Es posible que los usuarios necesiten acceso a aplicaciones y datos hospedados en redes diferentes, por lo que debe asegurarse de que los hosts de sesión pueden conectarse a ellas.

  • La latencia de ida y vuelta (RTT) desde la red del cliente hasta la región de Azure que contiene los grupos de hosts debe ser inferior a 150 ms. Para ver qué ubicaciones tienen la mejor latencia, busque la ubicación deseada en Estadísticas de latencia de ida y vuelta de red de Azure. Para optimizar el rendimiento de la red, se recomienda crear hosts de sesión en la región de Azure más cercana a los usuarios.

  • Use implementaciones de Azure Firewall para Azure Virtual Desktop para ayudarle a bloquear el entorno y filtrar el tráfico saliente.

  • Para ayudar a proteger su entorno de Azure Virtual Desktop en Azure, se recomienda no abrir el puerto de entrada 3389 en los host de sesión. Azure Virtual Desktop no requiere que haya un puerto de entrada abierto. Si debe abrir el puerto 3389 para solucionar problemas, se recomienda usar acceso de máquina virtual Just-in-Time. También se recomienda no asignar una dirección IP pública a los hosts de sesión.

Para obtener más información, consulte Descripción de la conectividad de red de Azure Virtual Desktop.

Nota:

Para que Azure Virtual Desktop siga siendo confiable y escalable, agregamos patrones de tráfico y uso para comprobar el estado y el rendimiento del plano de control de infraestructura. Agregamos esta información desde todas las ubicaciones en las que se encuentra la infraestructura de servicio y, a continuación, la enviamos a la región de EE. UU. Los datos enviados a la región de EE. UU. incluyen datos limpios, pero no datos de clientes. Para más información, vea Ubicaciones de datos para Azure Virtual Desktop.

Administración de host de sesión

Tenga en cuenta los siguientes puntos al administrar hosts de sesión:

  • No habilite ninguna directiva ni configuración que deshabilite Windows Installer. Si deshabilita Windows Installer, el servicio no puede instalar actualizaciones del agente en los hosts de sesión y estos no funcionan correctamente.

  • Si va a unir hosts de sesión a un dominio de AD DS y quiere administrarlos mediante Intune, deberá configurar Microsoft Entra Connect para habilitar Unión híbrida a Microsoft Entra.

  • Si va a unir hosts de sesión a un dominio de Microsoft Entra Domain Services, no podrá administrarlos mediante Intune.

  • Si usa la unión a Microsoft Entra con Windows Server para los hosts de sesión, no puede inscribirlos en Intune, ya que Windows Server no es compatible con Intune. Deberá usar la unión híbrida a Microsoft Entra y la directiva de grupo desde un dominio de Active Directory o directiva de grupo local en cada host de sesión.

Regiones de Azure

Puede implementar grupos de hosts, áreas de trabajo y grupos de aplicaciones en las siguientes regiones de Azure. Esta lista de regiones es donde se pueden almacenar los metadatos del grupo de hosts. Sin embargo, los hosts de sesión de las sesiones de usuario se pueden ubicar en cualquier región de Azure y en el entorno local al usar Azure Virtual Desktop en Azure Local, lo que le permite implementar recursos de proceso cerca de los usuarios. Para más información sobre los tipos de datos y ubicaciones, consulte Ubicaciones de datos para Azure Virtual Desktop.

  • Este de Australia
  • Centro de Canadá
  • Este de Canadá
  • Centro de la India
  • Centro de EE. UU.
  • Este de EE. UU.
  • Este de EE. UU. 2
  • Japón Oriental
  • Centro-Norte de EE. UU
  • Norte de Europa
  • Centro-sur de EE. UU.
  • Sur de Reino Unido 2
  • Oeste de Reino Unido
  • Centro-Oeste de EE. UU.
  • Oeste de Europa
  • Oeste de EE. UU.
  • Oeste de EE. UU. 2
  • Oeste de EE. UU. 3

Azure Virtual Desktop también está disponible en nubes soberanas, como Azure para US Government y Azure operado por 21Vianet en China.

Para más información sobre la arquitectura y la resistencia del servicio Azure Virtual Desktop, consulte Arquitectura y resistencia del servicio Azure Virtual Desktop.

Clientes de Escritorio remoto

Los usuarios necesitarán un cliente de Escritorio remoto para conectarse a escritorios virtuales y aplicaciones remotas. Los clientes siguientes admiten Azure Virtual Desktop:

Importante

Azure Virtual Desktop no admite conexiones del cliente de Conexión de RemoteApp y Escritorio (RADC) ni del cliente de Conexión a Escritorio remoto (MSTSC).

Para saber qué direcciones URL usan los clientes para conectarse y que debe permitir a través de firewalls y filtros de Internet, consulte la lista de direcciones URL requeridas.

Pasos siguientes