Requisitos previos del agente de Connected Machine

En este artículo se describen los requisitos previos técnicos, los entornos admitidos y las especificaciones necesarios para incorporar correctamente servidores físicos y virtuales a servidores habilitados para Azure Arc. Los administradores e ingenieros que planean implementar Azure Arc en sus entornos deben revisar esta información. Algunos métodos de incorporación pueden tener más requisitos.

Entornos admitidos

Los servidores habilitados para Azure Arc admiten la instalación del agente de Connected Machine en servidores físicos y máquinas virtuales alojadas fuera de Azure, incluso en plataformas como:

  • VMware (Azure VMware Solution incluido)
  • Azure Local
  • Otro entornos de nube

Nota:

No debe instalar Azure Arc en máquinas virtuales hospedadas en Azure, Azure Stack Hub o Azure Stack Edge, ya que ya tienen funcionalidades similares. Puede usar una máquina virtual de Azure para simular un entorno local solo con fines de prueba.

Consideraciones sobre imágenes clonadas y doradas

Tenga cuidado adicional al usar Azure Arc en sistemas que son:

  • Clonado
  • Restaurado a partir de la copia de seguridad como segunda instancia del servidor
  • Usado para crear una "imagen dorada" a partir de la cual se crean otras máquinas virtuales

Si dos agentes usan el mismo identificador de origen, encontrará comportamientos incoherentes cuando ambos agentes intenten actuar como un recurso de Azure. El procedimiento recomendado para estas situaciones es usar una herramienta de automatización o un script para incorporar el servidor a Azure Arc después de clonarlo, restaurarlo a partir de una copia de seguridad o crearlo a partir de una imagen dorada. Para obtener más información sobre la clonación de máquinas que se van a usar como servidores habilitados para Arc, consulte Directrices de clonación.

Nota:

Para más información sobre el uso de servidores habilitados para Azure Arc en entornos de VMware, consulte las preguntas más frecuentes sobre VMware.

Sistemas operativos admitidos

Azure Arc es compatible con los sistemas operativos de Windows y Linux que se indican en la tabla. Si no aparece una versión del sistema operativo, Azure Arc no lo admite.

La arquitectura x86-64 (64 bits) es totalmente compatible, mientras que solo algunas características pueden admitirse en Arm64. El agente de Azure Connected Machine no se ejecuta en arquitecturas de 32 bits.

Sistema operativo Versión x86-64 ARM64 Fin esperado de la compatibilidad con Arc Notas
AlmaLinux 8 Mayo de 2029
AlmaLinux 9 Agosto de 2032
Amazon Linux 2 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Amazon Linux 2023 Agosto de 2027
Azure Linux (CBL-Mariner) 3.0 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Azure Local
Debian 11 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Debian 12 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Debian 13
Oracle Linux 7 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Oracle Linux 8 Agosto de 2029
Oracle Linux 9 Agosto de 2032
Oracle Linux 10
Red Hat Enterprise Linux (RHEL) 7 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Red Hat Enterprise Linux (RHEL) 8 Agosto de 2029
Red Hat Enterprise Linux (RHEL) 9 Agosto de 2032
Red Hat Enterprise Linux (RHEL) 10 Agosto de 2035
Rocky Linux 8 Agosto de 2029
Rocky Linux 9 Agosto de 2032
SUSE Linux Enterprise Server (SLES) 12 SP5 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
SUSE Linux Enterprise Server (SLES) 15 SP3 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
SUSE Linux Enterprise Server (SLES) 15 SP4 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
SUSE Linux Enterprise Server (SLES) 15 SP5 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
SUSE Linux Enterprise Server (SLES) 15 SP6 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
SUSE Linux Enterprise Server (SLES) 15 SP7 Agosto de 2031
Ubuntu 18,04 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Ubuntu 20.04 ⚠️ ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Ubuntu 22.04 Mayo de 2027
Ubuntu 24.04 Mayo de 2029
Ubuntu 26.04
Cliente Windows 10 consulte Guía del sistema operativo cliente
Cliente Windows 11 consulte Guía del sistema operativo cliente
Windows IoT Enterprise 10 (22H2) consulte Guía del sistema operativo cliente
Windows IoT Enterprise 11 consulte Guía del sistema operativo cliente
Windows IoT Enterprise LTSC 10 (2021) consulte Guía del sistema operativo cliente
Windows IoT Enterprise LTSC 11 (2024) consulte Guía del sistema operativo cliente
Servidor de Windows 2012 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Servidor de Windows 2012 R2 ⚠️ Noviembre de 2026 Aproximación al final del soporte técnico de Arc
Servidor de Windows 2016 Febrero de 2030
Servidor de Windows 2019
Servidor de Windows 2022
Servidor de Windows 2025

En el caso de Windows Server, se admiten las experiencias de Escritorio y Server Core. Las ediciones de Azure se admiten en Azure Local.

El agente de Azure Connected Machine no se prueba en los sistemas operativos protegidos por el Centro de pruebas de seguridad de la información (CIS).

Compatibilidad con la arquitectura Arm64

No todas las características, las extensiones de máquina virtual y los servicios se admiten en Arm64 en este momento. Para más información sobre la compatibilidad de Arm64 o para comprobar si se admiten otros servicios, consulte la documentación del servicio que desea usar. A continuación se indican algunas características que se sabe que son compatibles con Arm64:

  • RunCommand
  • CustomScriptExtension
  • Agente de Azure Monitor

Nota:

La configuración de la máquina no es compatible con Arm64 en este momento.

Sistemas operativos cliente

El servicio Azure Arc y el agente de Azure Connected Machine se admiten en sistemas operativos cliente de Windows 10 y 11 solo cuando se usan esos equipos en un entorno similar al servidor. Es decir, el equipo siempre debe estar:

  • Conectado a Internet
  • Conectado a una fuente de alimentación
  • Encendido

Por ejemplo, un equipo que ejecuta Windows 11 responsable de la señalización digital, las soluciones de punto de venta y las tareas generales de administración de back-office es un buen candidato para Azure Arc. Las máquinas de productividad del usuario final que pueden estar sin conexión durante largos períodos de tiempo no deben usar Azure Arc. Considere la posibilidad de usar Microsoft Intune o Microsoft Configuration Manager para esos escenarios.

Servidores de corta duración e infraestructura de escritorio virtual

Microsoft no recomienda ejecutar Azure Arc en servidores de corta duración (efímeros) ni máquinas virtuales de infraestructura de escritorio virtual (VDI). Azure Arc está diseñado para la administración a largo plazo de servidores y no está optimizado para escenarios en los que se crean y eliminan servidores con regularidad. Por ejemplo, Azure Arc no sabe si el agente está sin conexión debido al mantenimiento planeado del sistema o porque se eliminó la máquina virtual, por lo que no limpia automáticamente los recursos del servidor que dejaron de enviar latidos. Como resultado, podría producirse un conflicto si vuelve a crear una máquina virtual eliminada con el mismo nombre y hay un recurso de Azure Arc existente con el mismo nombre.

Azure Virtual Desktop en Azure Local no usa máquinas virtuales de corta duración y admite la ejecución de Azure Arc en las máquinas virtuales de escritorio.

Requisitos del software y del sistema

En esta sección se detallan los requisitos de software para el agente de Azure Connected Machine.

Requisitos del sistema operativo Linux

  • systemd
  • wget (para descargar el script de instalación)
  • openssl (software de cifrado)
  • gnupg (solo sistemas basados en Debian)

Derecho de inicio de sesión de usuario local para sistemas Windows

Azure Hybrid Instance Metadata Service se ejecuta en una cuenta virtual con pocos privilegios, NT SERVICE\himds. Esta cuenta necesita que se ejecute el derecho "iniciar sesión como un servicio" en Windows. En la mayoría de los casos, no es necesario hacer nada, ya que este derecho se concede a las cuentas virtuales de forma predeterminada. Sin embargo, si su organización usa la directiva de grupo para personalizar esta configuración, deberá agregar NT SERVICE\himds a la lista de cuentas que pueden iniciar sesión como servicio.

Para comprobar la directiva actual en el equipo, abra el Editor de directivas de grupo local (gpedit.msc) en el menú Inicio y vaya al siguiente elemento de directiva:

Configuración del equipo >Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario > Inicio de sesión como un servicio

Compruebe si alguno de NT SERVICE\ALL SERVICES, NT SERVICE\himds o S-1-5-80-4215458991-2034252225-2287069555-1155419622-2701885083 (el identificador de seguridad estático para NT SERVICE\himds) está en la lista. Si ninguno está en la lista, deberá trabajar con el administrador de directivas de grupo para agregar NT SERVICE\himds a las directivas que configuren asignaciones de derechos de usuario en los servidores. El administrador de la directiva de grupo debe realizar el cambio en un equipo con el agente de Azure Connected Machine instalado para que el selector de objetos resuelva la identidad correctamente. El agente no necesita configurarse ni conectarse a Azure para realizar este cambio.

Captura de pantalla del Editor de directivas de grupo local que muestra qué usuarios tienen permisos para iniciar sesión como servicio.

Permisos necesarios

Necesitará los siguientes roles integrados de Azure para distintos aspectos de la administración de máquinas conectadas:

  • Para incorporar máquinas, debe tener el rol Incorporación de Azure Connected Machine o Colaborador del grupo de recursos en el que administra los servidores.
  • Para leer, modificar y eliminar una máquina, debe tener el rol de administrador de recursos de Azure Connected Machine para el grupo de recursos.
  • Para seleccionar un grupo de recursos en la lista desplegable al usar el método Generar script, necesitará el rol Lector para ese grupo de recursos (u otro rol que incluya acceso de lector).
  • Al asociar un ámbito de Private Link con Arc Server, debe tener el permiso Microsoft.HybridCompute/privateLinkScopes/read en el recurso ámbito de Private Link.

Proveedores de recursos de Azure

Los siguientes proveedores de recursos de Azure deben registrarse en la suscripción para usar servidores habilitados para Azure Arc:

  • Microsoft.HybridCompute
  • Microsoft.GuestConfiguration
  • Microsoft.HybridConnectivity
  • Microsoft.AzureArcData (si planea habilitar SQL Server para Arc)
  • Microsoft.Compute (para Administrador de actualizaciones de Azure y actualizaciones automáticas de extensiones)

Puede registrar los proveedores de recursos con los siguientes comandos:

Azure PowerShell:

Connect-AzAccount
Set-AzContext -SubscriptionId [subscription you want to onboard]
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData

CLI de Azure:

az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'

También puede registrar los proveedores de recursos en Azure Portal.

Pasos siguientes