Migrando a la API de ingesta de registros

Microsoft está retirando la API de Log Analytics HTTP Data Collector. Migra RealmJoin a la API de ingesta de registros basada en DCR con el módulo de PowerShell de RealmJoin.

Resumen

RealmJoin escribe sus registros de auditoría, operativos y de runbook en su propio Log Analytics Workspace. Hasta ahora lo hacía a través de Azure Monitor API de recopilación de datos HTTP, que se autentica con la clave compartida del workspace.

Microsoft deja de dar soporte a esa API el 14 de septiembre de 2026. Su sucesora es la API de ingesta de registros (llamada API de ingesta de registros en el Portal de RealmJoin), que se basa en Reglas de recopilación de datos (DCRs) y autenticación de Microsoft Entra ID en lugar de una clave compartida. RealmJoin lo admite, y el cambio se realiza con el módulo de RealmJoin para PowerShell.

Esta página solo se aplica si Log Analytics ya está configurado para su tenant. Si no lo está, no hay nada que migrar — la misma página de configuración ofrece un comando que configura de inmediato un workspace en la API de ingesta de registros. Aun así, recomendamos configurarlo, para que sus registros de auditoría, operativos y de runbook se almacenen en su propio tenant.

¿Se romperá algo en la fecha de retirada?

Lo más probable es que no. La documentación actual de Microsoft describe una suave obsolescencia gradual: los puntos de conexión antiguos ya no se admiten a partir de esa fecha, pero no dejan de aceptar datos, y la ingesta sigue funcionando mientras los clientes usen TLS 1.2 o una versión posterior. La redacción más estricta del anuncio original de 2023 — que los puntos de conexión simplemente dejarían de estar disponibles — está desactualizada.

No obstante, se recomienda migrar: la ruta antigua no cuenta con soporte, depende de una clave compartida y no recibe más correcciones.

Qué cambia

Antes — API de recopilación de datos

• Autenticación con el workspace clave compartida ("Customer Workspace Key")
• Una registro de aplicación de Entra ID propiedad del cliente con un secreto de cliente
• Tablas AuditLogs_CL, OperationalLogs_CL, RunbookLogs_CL
• Configurado manualmente en el Portal

Después — API de ingesta de registros

• Autenticación con Microsoft Entra ID, sin clave compartida
• El RealmJoin Azure Resources service principal, con ámbito restringido al workspace y sus reglas
• Tablas RJAuditLogs_CL, RJOperationalLogs_CL, RJRunbookLogs_CL
• Desplegado y mantenido por el módulo de RealmJoin para PowerShell

La migración reutiliza su existente workspace, por lo que sus registros existentes permanecen donde están. RealmJoin consulta las tablas antigua y nueva en paralelo, lo que significa que los datos históricos siguen siendo visibles en el Portal después de la migración.

Qué despliega la migración

Ejecutar el comando de migración en su suscripción crea:

• El RealmJoin Azure Resources service principal en su tenant de Entra ID (si todavía no existe)
• Tres tablas personalizadas en su workspace existente: RJAuditLogs_CL, RJOperationalLogs_CL, RJRunbookLogs_CL
• Una Regla de recopilación de datos por tabla (dcr-rj-aud-logs-*, dcr-rj-op-logs-*, dcr-rj-rb-logs-*), cada una con su propio endpoint de ingesta directa
• Exactamente dos tipos de asignación de roles para RealmJoin, y nada más:

  • Lector de Log Analytics en el workspace, para que el Portal pueda consultar sus registros
  • Publicador de métricas de supervisión en cada una de las tres Reglas de recopilación de datos, para que RealmJoin pueda escribir en ellas

RealmJoin no recibe ningún otro permiso en su suscripción. El despliegue es idempotente — volver a ejecutar el mismo comando es seguro y solo aplica lo que falta.

Requisitos previos

En el Portal de RealmJoin

• Un rol que concede acceso al área de Configuración (CanReadSettingsDetails, vea Permisos disponibles). La página de Configuración genera el comando de migración, incluido un token de incorporación de corta duración.

En la máquina que ejecuta PowerShell

• PowerShell 7 o posterior
• Acceso a la PowerShell Gallery para instalar el módulo de RealmJoin
• El Az.Accounts, Az.Resources y Az.Automation módulos — el módulo de RealmJoin los instala automáticamente en las versiones fijadas, para el usuario actual

Permisos de la cuenta con la que inicia sesión

• Microsoft Entra ID: permiso para crear service principals, por ejemplo Administrador de aplicaciones, Administrador de aplicaciones en la nube o Administrador global. Solo es necesario la primera vez, cuando el service principal de RealmJoin Azure Resources aún no existe.
• Suscripción de Azure: permiso para desplegar en el grupo de recursos del workspace y para crear asignaciones de roles en él — por ejemplo Propietario, o Colaborador combinado con Administrador de acceso de usuario / Administrador de Control de acceso basado en roles.
• El inicio de sesión se realiza a través de Connect-AzAccount, que usa la Azure PowerShell aplicación propia de Microsoft. Los tenants que restringen el consentimiento de usuario pueden necesitar conceder primero consentimiento de administrador a esa aplicación.

El grupo de recursos y el Log Analytics Workspace ya existen en su caso — la migración no los crea. Los comandos del Portal están precargados con su suscripción, grupo de recursos y nombre del workspace actuales.

Dónde ejecutar los comandos

Ejecute los comandos en una sesión local de PowerShell en una estación de trabajo administrativa — igual que ejecutaría el script de incorporación de RealmJoin.

Use una recién abierta sesión de PowerShell y evite Azure Cloud Shell. El módulo de RealmJoin requiere versiones exactas de los Az.* módulos. Si una versión diferente de un Az módulo ya está cargada en la sesión — que suele ser el caso en Cloud Shell — el módulo no puede recuperarse y se detiene con un mensaje de conflicto de versiones. Cerrar la sesión y abrir una nueva lo resuelve.

No se requiere una sesión elevada ("Ejecutar como administrador"): los módulos se instalan con -Scope CurrentUser.

Migración

1

Abra la configuración de Log Analytics en el Portal

Vaya a Configuración → Log Analytics (https://portal.realmjoin.com/settings/log-analytics-configuration).

Mientras su tenant siga usando la API de recopilación de datos, la página muestra el aviso "Migrar a la API de ingesta de registros (recomendado)" junto con un bloque de comandos listo para copiar. Use el Copiar botón para copiarlo.

2

Compruebe el comando copiado

El comando se ve así, con sus propios valores completados:

$latest = [version](Find-Module RealmJoin -Repository PSGallery -ErrorAction Stop).Version
if (-not (Get-Module -ListAvailable RealmJoin | Where-Object Version -ge $latest)) {
    Install-Module RealmJoin -Force -AllowClobber -ErrorAction Stop
}
Import-Module RealmJoin -Force
Set-RJLogAnalyticsWorkspace -ResourceGroupName "<ResourceGroupName>" -WorkspaceName "<WorkspaceName>" -SubscriptionId "<SubscriptionId>" -Token "<Token>" 6>&1
Grant-RJUpdateComplianceWorkspaceAccess -WorkspaceId "<WorkspaceId>" 6>&1

• Las primeras líneas instalan o actualizan el módulo de RealmJoin y lo importan.
• Set-RJLogAnalyticsWorkspace realiza la migración real y registra el resultado con RealmJoin usando el -Token.
• Grant-RJUpdateComplianceWorkspaceAccess solo aparece si ha configurado un workspace de Update Compliance. Concede a RealmJoin Lector de Log Analytics sobre ese workspace para que los datos de Windows Update sigan funcionando sin su propio registro de aplicación.

Asegúrese de que -ResourceGroupName, -WorkspaceName y -SubscriptionId están presentes y apuntan a su existente workspace. Si -WorkspaceName falta, el módulo crea un nuevo workspace en lugar de migrar el existente, y sus registros antiguos y nuevos terminan en lugares distintos. Añada manualmente el parámetro que falta si es necesario.

Acerca de 6>&1: estos comandos informan de su progreso en el flujo de Información de PowerShell. La 6>&1 redirección muestra esa salida en la consola — sin ella no verá ningún mensaje de progreso.

3

Ejecute el comando

Pegue el bloque en una nueva sesión de PowerShell y ejecútelo. El token es válido durante aproximadamente una hora — si ha expirado, vuelva a cargar la página de configuración y copie el comando de nuevo.

Se le pedirá que inicie sesión con Connect-AzAccount. Si su cuenta tiene acceso a varios tenants o suscripciones, el módulo le pide que elija.

A continuación, el despliegue informa de cada recurso a medida que se crea: el service principal, las tablas personalizadas, las Reglas de recopilación de datos y las asignaciones de roles. Una sola ejecución suele tardar unos minutos.

¿Quiere ver primero qué pasaría? Añada -WhatIf a Set-RJLogAnalyticsWorkspace para obtener una vista previa What-If de Azure Resource Manager. Tenga en cuenta que iniciar sesión e instalar los Az módulos sigue ocurriendo, porque la vista previa necesita ambos.

Cerrar sesión después: el inicio de sesión de Azure permanece activo después de que el comando haya terminado. Cuando haya terminado, ejecute Disconnect-AzAccount para cerrar sesión de la sesión existente.

4

Verifique en el Portal

Vuelva a Configuración → Log Analytics y seleccione Actualizar.

La página ahora muestra la configuración de la API de ingesta de registros — suscripción, grupo de recursos, nombre del workspace, ID del workspace del cliente e ID del tenant — como campos de solo lectura, ya que estos ajustes los mantiene a partir de ahora el módulo de PowerShell. En Avanzada puede revisar los puntos de conexión, los nombres de las reglas y los nombres de flujo de las tres Reglas de recopilación de datos.

Seleccione Compruebe si hay problemas de configuración para verificar que todos los permisos de Azure requeridos están presentes en el workspace y en cada Regla de recopilación de datos.

5

Confirme que llegan los registros

Abra Registro de auditoría, el Registros de runbook o los registros operativos y confirme que aparecen nuevas entradas. Las entradas existentes anteriores a la migración también siguen visibles.

Azure necesita unos minutos para poner disponible una tabla personalizada recién creada y su regla. Si no llega nada de inmediato, espere un poco y actualice.

Después de la migración

Mantenga por ahora el antiguo registro de aplicación

Las entradas históricas en AuditLogs_CL, OperationalLogs_CL y RunbookLogs_CL siguen leyéndose con su registro de aplicación y secreto de cliente existentes. El Portal consulta las tablas antigua y nueva en paralelo.

No elimine el registro de aplicación y siga renovando su secreto de cliente mientras quiera seguir viendo datos de registro anteriores a la migración. Solo la clave compartida del workspace ya no es necesaria para RealmJoin — ya no se usa para escribir.

Una vez que los datos antiguos hayan caducado de su retención del workspace, puede eliminar el registro de aplicación.

Mantener actualizado el esquema

Si RealmJoin amplía el esquema de registros en una futura versión, la página de configuración muestra un aviso de que el esquema desplegado de Log Analytics está desactualizado, junto con el comando para actualizarlo. Ese es el mismo Set-RJLogAnalyticsWorkspace comando — vuelva a ejecutarlo y las tablas y reglas se actualizarán in situ.

Solución de problemas

"El módulo de RealmJoin está desactualizado - no se puede continuar con la ejecución"

Cada cmdlet verifica una vez por sesión que está ejecutando la última versión publicada del módulo. Instale la versión actual, luego cierre la sesión y abra una nueva:

Install-Module -Name RealmJoin -Force -Scope CurrentUser

Se informa de un conflicto de versiones del módulo

Un Az.* módulo con una versión distinta de la fijada por el módulo de RealmJoin ya está cargado en la sesión. Esto no se puede corregir dentro de la sesión en ejecución — cierre PowerShell, abra una nueva sesión y ejecute el comando de nuevo. Esta es también la razón para no usar Azure Cloud Shell.

"Se necesita aprobación de administrador" o un error de consentimiento durante el inicio de sesión

El inicio de sesión usa la Azure PowerShell aplicación propia de Microsoft. Si su tenant restringe el consentimiento de usuario, un administrador tiene que conceder una vez el consentimiento de administrador a esa aplicación.

El despliegue falla al crear asignaciones de roles

Crear las Lector de Log Analytics y Publicador de métricas de supervisión asignaciones requiere un rol que pueda administrar el acceso — por ejemplo Propietario, Administrador de acceso de usuario o Administrador de Control de acceso basado en roles en el grupo de recursos o la suscripción. Colaborador por sí solo no es suficiente.

Las asignaciones de roles que ya existen se detectan y se omiten, por lo que volver a ejecutar el comando después de corregir los permisos es seguro.

El despliegue falla con un error sobre la región del workspace

El despliegue se dirige a la región del grupo de recursos. Si su workspace existente se encuentra en una región distinta de la de su grupo de recursos, Azure rechaza el cambio, porque no se puede modificar la ubicación de un workspace existente. En ese caso, póngase en contacto con el soporte de RealmJoin.

El token ya no se acepta

El token de incorporación del comando generado es de corta duración (aproximadamente una hora). Vuelva Configuración → Log Analytics en el Portal, copie el comando de nuevo y ejecútelo otra vez. El despliegue de Azure en sí es idempotente, por lo que una segunda ejecución no hace daño.

El workspace de Update Compliance está en una suscripción diferente

Grant-RJUpdateComplianceWorkspaceAccess busca el workspace en la suscripción seleccionada actualmente. Si el workspace de Update Compliance está en otro lugar, pase la suscripción explícitamente:

Grant-RJUpdateComplianceWorkspaceAccess -WorkspaceId "<WorkspaceId>" -SubscriptionId "<SubscriptionId>" 6>&1