Problema

En entornos con cientos de servidores Windows, es habitual usar Group Policy (GPO) para automatizar la instalación de agentes, extensiones o componentes de Azure Arc. El flujo típico consiste en crear una tarea programada que ejecuta el instalador, dejar que el cliente reporte “Task Completed” y, después, validar que el recurso aparece en el portal de Azure.

Lo que muchos administradores descubren demasiado tarde es que el mensaje “Task Completed” no garantiza que el agente haya quedado operativo. Los servidores aparecen como “onboarded” en los registros de GPO, la tarea se elimina y los logs de Azure Arc no muestran errores, pero el agente nunca se registra en Azure. El resultado son servidores “fantasma” que siguen fuera del control de políticas, de Monitor o de Defender for Cloud.

Este patrón se repite cuando:

  • Se despliega Azure Arc en Windows Server 2022 que ya incluye el feature AzureArcSetup.
  • La versión del instalador que GPO intenta aplicar difiere del modelo de instalación que el feature nativo gestiona.
  • El feature pre‑instalado detecta una versión conflictiva y bloquea la actualización sin generar eventos visibles.

El síntoma más claro es la ausencia del servidor en Azure pese a que la tarea de GPO finalizó sin errores.

Causa

1. Feature preinstalado que entra en conflicto

Windows Server 2022 trae el feature AzureArcSetup como una capa de gestión ligera. Cuando el feature está presente pero no configurado, su estado interno impide que el instalador tradicional de Azure Arc (el que GPO lanza) realice cambios. En lugar de sobrescribir, el instalador detecta la presencia del feature y termina exitosamente sin tocar nada.

2. Falta de sincronización de versiones

Los paquetes de Azure Arc publicados en el repositorio de Microsoft cambian el mecanismo de instalación cada cierto tiempo. Si la GPO sigue apuntando a una versión antigua, el instalador intenta registrar componentes que ya están gestionados por el feature nativo, provocando un “no‑op” que el programador interpreta como éxito.

3. Registro de eventos insuficiente

El instalador escribe en Event Viewer bajo la categoría AzureArc solo cuando ocurre un error crítico. Un bloqueo silencioso por conflicto de feature no genera evento, por lo que la única pista es la ausencia del recurso en Azure.

4. Configuración de la tarea programada demasiado restrictiva

Algunos administradores configuran la tarea con la opción “Run only when user is logged on” o con un runas que no tiene privilegios suficientes para desinstalar/reinstalar el feature. El instalador se ejecuta, verifica pre‑requisitos y sale sin tocar nada.

Solución

El objetivo es forzar al servidor a usar un único método de instalación, eliminando cualquier rastro del feature conflictivo antes de volver a aplicar la política.

Paso 1 – Detectar la presencia del feature

powershell -Command "Get-WindowsFeature -Name AzureArcSetup | Select-Object -ExpandProperty InstallState"

Si el resultado es Installed, el servidor está en riesgo de bloqueo.

Paso 2 – Desinstalar el feature

powershell -Command "Remove-WindowsFeature -Name AzureArcSetup -Restart"

El parámetro -Restart fuerza un reinicio inmediato; si se prefiere programar el reinicio, omítalo y ejecutar shutdown /r /t 0 después.

Paso 3 – Limpiar restos de la instalación previa

powershell -Command "Remove-Item -Recurse -Force 'C:\Program Files\AzureConnectedMachineAgent' 2>$null"
powershell -Command "Remove-Item -Recurse -Force 'C:\ProgramData\AzureArc' 2>$null"

Estos directorios pueden contener configuraciones parciales que confunden al nuevo instalador.

Paso 4 – Reprocesar la GPO

Una vez el servidor haya arrancado, forzar la actualización de políticas:

gpupdate /force

La tarea programada que lleva el instalador de Azure Arc volverá a ejecutarse. Esta vez no encontrará el feature y completará la instalación completa.

Paso 5 – Verificar la conexión en Azure

Después de unos minutos, el agente debe aparecer bajo Azure Arc → Machines. Si no, revisar los logs de C:\ProgramData\AzureArc\Logs\azureconnectedmachineagent.log.

Alternativa: Reemplazar la GPO por un script de arranque

En entornos donde el feature es obligatorio, se puede crear una GPO que primero elimine el feature y luego invoque el instalador directamente, evitando la dependencia de la tarea programada.

powershell -Command "if ((Get-WindowsFeature AzureArcSetup).InstallState -eq 'Installed') { Remove-WindowsFeature AzureArcSetup -Restart } ; Start-Process -FilePath 'C:\Temp\AzureArcSetup.exe' -ArgumentList '/quiet' -Wait"

Este enfoque garantiza que la desinstalación y la instalación ocurran en la misma sesión.

Cuándo aplicar esta solución

Se recomienda aplicar el procedimiento cuando:

  • La tarea programada de GPO muestra “Task Completed” pero el servidor no aparece en Azure Arc.
  • Los logs de Azure Arc no contienen errores y ArcInfo.json parece correcto.
  • El servidor ejecuta Windows Server 2022 (o versiones que incluyan el feature AzureArcSetup).
  • Se ha usado la misma GPO en varios servidores y el problema se reproduce de forma consistente.

No es necesario si:

  • El servidor es Windows 10/11 o versiones de Server que no incluyen el feature.
  • La instalación de Azure Arc se realiza mediante Azure CLI o PowerShell directamente, sin GPO.
  • Los logs indican un error explícito de red, credenciales o permisos.

Código

# Paso 1: comprobar estado del feature
powershell -Command "Get-WindowsFeature -Name AzureArcSetup | Select-Object -ExpandProperty InstallState"

# Paso 2: desinstalar feature y reiniciar
powershell -Command "Remove-WindowsFeature -Name AzureArcSetup -Restart"

# Paso 3: limpiar carpetas residuales
powershell -Command "Remove-Item -Recurse -Force 'C:\Program Files\AzureConnectedMachineAgent' 2>$null"
powershell -Command "Remove-Item -Recurse -Force 'C:\ProgramData\AzureArc' 2>$null"

# Paso 4: forzar actualización de GPO
gpupdate /force

Verificación

  1. Estado del feature – Ejecutar el comando del Paso 1 y confirmar que devuelve Removed.
  2. Servicio del agente – Get-Service -Name AzureConnectedMachineAgent debe mostrar Running.
  3. Portal Azure – En la sección Azure Arc → Machines buscar el nombre del host; debe aparecer dentro de los 5‑10 minutos posteriores al reinicio.
  4. Logs – Revisar C:\ProgramData\AzureArc\Logs\azureconnectedmachineagent.log para la línea Agent successfully registered.

Si alguno de estos pasos falla, volver a ejecutar los comandos con privilegios de administrador y confirmar que no haya políticas de restricción de ejecución (ExecutionPolicy) que bloqueen los scripts.

Notas adicionales

  • En entornos con cientos de servidores, automatizar la detección del feature con un script de PowerShell y exportar la lista a CSV permite planificar el reinicio masivo sin interrumpir servicios críticos.
  • Algunas versiones de Azure Arc incluyen un parámetro --force-reinstall que puede evitar el conflicto, pero no está garantizado en todas las builds; la eliminación del feature sigue siendo la solución más fiable.
  • Después de la corrección, actualizar la GPO para que incluya una verificación de estado (Get-Service) y reporte un error si el agente no está activo ayuda a detectar futuros fallos antes de que se conviertan en “silenciosos”.
  • Documentar el estado del feature en el inventario CMDB evita que futuros despliegues repitan el mismo error.