Requisitos previos para Azure Virtual Desktop

Hay algunas cosas que debe comenzar a usar Azure Escritorio virtual. Aquí puede encontrar los requisitos previos que debe completar para proporcionar con éxito escritorios y aplicaciones a los usuarios.

A rasgos generales, se necesita:

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

Cuenta de Azure con una suscripción activa

Necesita una cuenta de Azure con una suscripción activa para implementar Azure escritorio virtual. Si aún no tienes una, puedes crear una cuenta de forma gratuita.

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

Asegúrese también de haber registrado el proveedor de recursos Microsoft.DesktopVirtualization para su suscripción. Para comprobar el estado del proveedor de recursos y registrarse si es necesario, seleccione la pestaña pertinente para su escenario y siga los pasos.

Importante

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

  1. Inicie sesión en el portal de Azure.

  2. Seleccione Suscripciones.

  3. Selecciona el nombre de tu suscripción.

  4. Seleccione Proveedores de recursos.

  5. Busque Microsoft.DesktopVirtualization.

  6. Si el estado es NotRegistered, seleccione Microsoft.DesktopVirtualization y, después, seleccione Register.

  7. Compruebe que el estado Microsoft.DesktopVirtualization está 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 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 Servicios de dominio de Active Directory (AD DS) o Servicios de dominio de Microsoft Entra, lo que le proporciona una opción de opciones de configuración.

Hosts de sesión

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

Nota:

Para Azure Local, solo puede unir hosts de sesión a un dominio de Servicios de dominio de Active Directory. Solo puede unir los hosts de sesión de Azure Local a un dominio de Servicios de dominio de Active Directory (AD DS). Esto incluye el uso de la unión híbrida de Microsoft Entra, donde puede beneficiarse de algunas de las funcionalidades 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 Servicios de dominio de Microsoft Entra en la implementación de Azure Virtual Desktop, estas cuentas deben ser identidades híbridas, lo que significa que las cuentas de usuario están sincronizadas. Debe tener en cuenta lo siguiente en función del proveedor de identidad que use:

  • Si usa Microsoft Entra ID con AD DS, debe configurar Microsoft Entra Connect para sincronizar los datos de identidad de usuario entre AD DS y Microsoft Entra ID.
  • Si usa Microsoft Entra ID con Servicios de dominio de Microsoft Entra, las cuentas de usuario se sincronizan de una manera desde Microsoft Entra ID a Servicios de dominio de Microsoft Entra. Este proceso de sincronización es automático.

Importante

La cuenta de usuario debe existir en el inquilino de Microsoft Entra que usa para Azure Virtual Desktop. Azure Virtual Desktop no admite cuentas personales de Microsoft.

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

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 Unido a AD DS En Microsoft Entra ID y AD DS, sincronizados
Microsoft Entra ID + AD DS Unido a Microsoft Entra ID En Microsoft Entra ID y AD DS, sincronizados
Microsoft Entra ID + Servicios de dominio de Microsoft Entra Unido a Servicios de dominio de Microsoft Entra En Microsoft Entra ID y Servicios de dominio de Microsoft Entra, sincronizado
Microsoft Entra ID + Servicios de dominio de Microsoft Entra + AD DS Unido a Servicios de dominio de Microsoft Entra En Microsoft Entra ID y AD DS, sincronizados
Microsoft Entra ID + Servicios de dominio de Microsoft Entra Unido a Microsoft Entra ID En Microsoft Entra ID y Servicios de dominio de Microsoft Entra, sincronizado
Solo entrada de Microsoft Entra Unido a Microsoft Entra ID En Microsoft Entra ID (incluidas las identidades externas)

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 y métodos de autenticación admitidos.

Contenedor de perfiles de FSLogix

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

Parámetros de implementación

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

  • Nombre de dominio, si utiliza AD DS o Servicios de dominio de Microsoft Entra.
  • Credenciales para unir hosts de sesión al dominio.
  • Unidad organizativa (OU), que es un parámetro opcional que permite colocar los 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

Puede elegir sistemas operativos (SO) que puede usar para que los hosts de sesión proporcionen escritorios y aplicaciones. Puede utilizar diferentes sistemas operativos con diferentes grupos de hosts para proporcionar flexibilidad a los usuarios. Admitimos los sistemas operativos de 64 bits y las SKU de las siguientes listas de tablas (donde las versiones y fechas admitidas están en línea 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, Empresa Premium, beneficio para uso de estudiantes
  • Windows Enterprise E3 y E5
  • Windows Education A3, A5
  • Windows VDA por usuario
 Precios de acceso por usuario mediante la inscripción de una suscripción de Azure.
  • 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.
 No admitida. Los precios de acceso por usuario no están disponibles para los sistemas operativos de Windows Server.

Para obtener 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 crear sus propias imágenes personalizadas almacenadas en una galería de proceso de Azure 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 puede usar al implementar máquinas virtuales (VM) del host de sesión. Para obtener más información sobre cómo crear imágenes personalizadas, consulta:

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

Puede implementar una máquina virtual (VM) para usarla como hosts de sesión a partir de estas imágenes con cualquiera de los métodos siguientes:

Si su licencia le da derecho a usar Azure Virtual Desktop, no es necesario instalar ni aplicar una licencia independiente. Sin embargo, si usa precios de acceso por usuario para usuarios externos, debe inscribir una suscripción a Azure. Debe asegurarse de que la licencia de Windows utilizada en los hosts de sesión está asignada correctamente en Azure y de que el sistema operativo está activado. Para obtener más información, consulte Aplicar licencia de Windows a máquinas virtuales del host de sesión.

Para los hosts de sesión en Azure Local, debe obtener una licencia y activar las máquinas virtuales que use antes de usarlas con Azure Virtual Desktop. Para activar Windows 10 y Windows 11 Empresas multisesión, y Windows Server 2022 Datacenter: Azure Edition, use la verificación de Azure para máquinas virtuales. Para todas las demás imágenes del sistema operativo (como Windows 10 y Windows 11 Empresas, 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 una funcionalidad continuada 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 antes del 17 de junio de 2024. Esta actualización es esencial para que las máquinas virtuales puedan seguir usando las ventajas de Azure. Para más información, consulte Verificación de máquinas virtuales de Azure.

Sugerencia

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

Red

Hay varios requisitos de red que debe cumplir para implementar correctamente Azure Virtual Desktop. Esto permite que los usuarios se conecten 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, debe cumplir los siguientes requisitos de red:

  • Necesita 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 con antelación para que aparezca en la lista desplegable. La red virtual debe estar en la misma región de Azure que el host de la 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 Servicios de dominio de Microsoft Entra, ya que necesita unir hosts de sesión al dominio.

  • Los hosts de sesión y los usuarios deben poder conectarse al servicio de Escritorio virtual de Azure. Estas conexiones también usan TCP en el puerto 443 a una lista específica de direcciones URL. Para obtener más información, consulte Lista de direcciones URL requeridas. Debes asegurarte de que estas direcciones URL no estén bloqueadas por un filtrado de red o un firewall 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 puedan conectarse a puntos de conexión de Microsoft 365.

Tenga en cuenta también lo siguiente:

  • Es posible que los usuarios necesiten acceso a aplicaciones y datos hospedados en redes diferentes, así que asegúrese de que los hosts de sesión puedan conectarse a ellos.

  • La latencia de tiempo de ida y vuelta (RTT) desde la red del cliente a 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 las estadísticas de latencia de ida y vuelta de la red de Azure. Para optimizar el rendimiento de la red, le recomendamos que cree hosts de sesión en la región de Azure más cercana a los usuarios.

  • Use Azure Firewall para Azure implementaciones de Virtual Desktop con el fin de proteger el entorno y filtrar el tráfico saliente.

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

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

Nota:

Para que Azure Virtual Desktop sea confiable y escalable, agregamos patrones de tráfico y uso para comprobar el estado y el rendimiento del plano de control de la infraestructura. Agregamos esta información de todas las ubicaciones donde está la infraestructura de servicio y después la enviamos a la región de Estados Unidos. Los datos enviados a la región de Estados Unidos incluyen datos depurados, pero no datos de clientes. Para obtener más información, consulte Ubicaciones de datos para Azure Virtual Desktop.

Administración del host de sesión

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

  • No habilite ninguna directiva o configuración que deshabilite Windows Installer. Si deshabilita Windows Installer, el servicio no podrá instalar las actualizaciones del agente en los hosts de sesión y los hosts de sesión no funcionarán correctamente.

  • Si va a unir hosts de sesión a un dominio de AD DS y desea administrarlos mediante Intune, debe configurar Microsoft Entra Connect para habilitar la unión híbrida de Microsoft Entra.

  • Si va a unir hosts de sesión a un dominio de Servicios de dominio de Microsoft Entra, no puede administrarlos mediante Intune.

  • Si usa la unión de 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. Debe usar la unión híbrida y la directiva de grupo de Microsoft Entra desde un dominio de Active Directory o una 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. En esta lista de regiones es donde se pueden almacenar los metadatos del grupo de hosts cuando el ámbito de implementación del grupo de hosts es geográfico.

Consulte Ubicaciones de datos de Azure Virtual Desktop para ver la lista de regiones para el almacenamiento de metadatos del grupo de hosts cuando el ámbito de implementación del grupo de hosts es regional.

Sin embargo, los hosts de sesión para las sesiones de usuario se pueden encontrar en cualquier región de Azure y en el entorno local cuando se usa 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.

Importante

Oeste de EE. UU. 3 no se admite para grupos de hosts automatizados (grupos de hosts que usan la configuración del host de sesión). Obtenga más información sobre la configuración del host de sesión en los enfoques de administración de grupos de hosts.

  • Este de Australia

  • Centro de Canadá

  • Este de Canadá

  • Centro de India

  • Centro de EE. UU.

  • Asia Oriental

  • Este de EE. UU.

  • Este de EE. UU. 2

  • Este de Japón

  • Oeste de Japón

  • Centro y norte de EE. UU.

  • Norte de Europa

  • Norte de Sudáfrica

  • Centro y Sur de EE. UU.

  • Sudeste de Asia

  • Sur de Reino Unido

  • Oeste de Reino Unido

  • Centro oeste de EE. UU.

  • Oeste de Europa

  • Oeste de EE. UU.

  • Oeste de EE. UU. 2

  • West US 3

Azure Virtual Desktop también está disponible en nubes soberanas, como Azure para el gobierno de Estados Unidos y Azure operado por 21Vianet en China.

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

Conectarse a una sesión remota

Los usuarios deben usar Aplicación de Windows o el cliente de Escritorio remoto para conectarse a escritorios y aplicaciones. Puedes conectarte desde:

  • Windows
  • macOS
  • iOS/iPadOS
  • Android/Chrome OS
  • Explorador web

Para obtener más información, consulta Introducción a Aplicación de Windows para conectarse a dispositivos y aplicaciones.

Importante

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

Para saber qué direcciones URL utilizan los clientes para conectarse y qué debes permitir a través de firewalls y filtros de Internet, consulta la lista de direcciones URL necesarias.

Pasos siguientes

  • Se actualizó por última vez el