> For the complete documentation index, see [llms.txt](https://docs.realmjoin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.realmjoin.com/fr/supervision-et-journaux/log-ingestion-api-migration.md). # Migration vers l’API Log Ingestion Microsoft retire l’API HTTP Data Collector de Log Analytics. Migrez RealmJoin vers l’API Log Ingestion basée sur DCR avec le module PowerShell RealmJoin. ## Aperçu RealmJoin écrit ses journaux d’audit, opérationnels et Runbook dans votre propre Log Analytics Workspace. Jusqu’à présent, il le faisait via Azure Monitor **API HTTP Data Collector**, qui s’authentifie à l’aide de la clé partagée de l’espace de travail. Microsoft met fin à la prise en charge de cette API le **14 septembre 2026**. Son successeur est l’ **API d’ingestion des journaux** (appelée *API d’ingestion des journaux* dans le RealmJoin Portal), qui repose sur [les Data Collection Rules (DCRs)](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/data-collection-rule-overview) et l’authentification Microsoft Entra ID à la place d’une clé partagée. RealmJoin la prend en charge, et le basculement se fait avec le [module PowerShell RealmJoin](/fr/deploiement/onboarding-realmjoin-portal/advanced-setup.md). {% hint style="info" %} Cette page ne s’applique que si [Log Analytics](/fr/supervision-et-journaux/log-analytics.md) est déjà configuré pour votre tenant. Si ce n’est pas le cas, il n’y a rien à migrer — la même page de paramètres propose une commande qui configure immédiatement un espace de travail sur l’API d’ingestion des journaux. Nous recommandons quand même de le configurer, afin que vos journaux d’audit, opérationnels et Runbook soient stockés dans votre propre tenant. {% endhint %} ### Quelque chose cassera-t-il à la date de mise hors service ? Très probablement rien. La documentation actuelle de Microsoft décrit une *dépréciation progressive* : les anciens points de terminaison ne sont plus pris en charge à partir de cette date, mais ils n’arrêtent pas d’accepter des données, et l’ingestion continue de fonctionner tant que les clients utilisent TLS 1.2 ou une version plus récente. La formulation plus stricte de l’annonce originale de 2023 — selon laquelle les points de terminaison deviendraient tout simplement indisponibles — est obsolète. La migration reste néanmoins recommandée : l’ancien chemin n’est pas pris en charge, dépend d’une clé partagée et ne reçoit plus de correctifs. ### Ce qui change {% columns %} {% column %} #### Avant — API Data Collector * Authentification avec l’espace de travail **clé partagée** ("Customer Workspace Key") * Un **enregistrement d’application Entra ID appartenant au client** avec un secret client * Tables `AuditLogs_CL`, `OperationalLogs_CL`, `RunbookLogs_CL` * Configuré manuellement dans le Portail {% endcolumn %} {% column %} #### Après — API d’ingestion des journaux * Authentification avec **Microsoft Entra ID**, sans clé partagée * Le **RealmJoin Azure Resources** Service Principal, limité à l’espace de travail et à ses règles * Tables `RJAuditLogs_CL`, `RJOperationalLogs_CL`, `RJRunbookLogs_CL` * Déployé et maintenu par le module PowerShell RealmJoin {% endcolumn %} {% endcolumns %} La migration réutilise votre **espace de travail** existant, donc vos journaux existants restent là où ils sont. RealmJoin interroge côte à côte les anciennes et les nouvelles tables, ce qui signifie que les données historiques restent visibles dans le Portail après la migration. ### Ce que la migration déploie L’exécution de la commande de migration dans votre abonnement crée : * Le **RealmJoin Azure Resources** Service Principal dans votre tenant Entra ID (s’il n’existe pas encore) * Trois tables personnalisées dans votre espace de travail existant : `RJAuditLogs_CL`, `RJOperationalLogs_CL`, `RJRunbookLogs_CL` * Une Data Collection Rule par table (`dcr-rj-aud-logs-*`, `dcr-rj-op-logs-*`, `dcr-rj-rb-logs-*`), chacune avec son propre point de terminaison d’ingestion direct * Exactement deux types d’affectation de rôle pour RealmJoin, et rien d’autre : * **Log Analytics Reader** sur l’espace de travail, afin que le Portail puisse interroger vos journaux * **Monitoring Metrics Publisher** sur chacune des trois Data Collection Rules, afin que RealmJoin puisse y écrire RealmJoin ne reçoit aucune autre autorisation dans votre abonnement. Le déploiement est idempotent — relancer la même commande est sans danger et n’applique que ce qui manque. ## Prérequis ### Dans le Portail RealmJoin * Un rôle qui accorde l’accès à la zone Paramètres (`CanReadSettingsDetails`, voir [Autorisations disponibles](/fr/administration-et-parametres/permission/custom-roles/available-permissions.md)). La page Paramètres génère la commande de migration, y compris un jeton d’intégration à courte durée de vie. ### Sur la machine qui exécute PowerShell * **PowerShell 7** ou version ultérieure * Accès à la [PowerShell Gallery](https://www.powershellgallery.com/packages/RealmJoin) pour installer le module RealmJoin * Le `Az.Accounts`, `Az.Resources` et `Az.Automation` modules — le module RealmJoin les installe automatiquement dans les versions verrouillées, pour l’utilisateur actuel ### Autorisations du compte avec lequel vous vous connectez * **Microsoft Entra ID :** autorisation de créer des Service Principals, par exemple *Application Administrator*, *Cloud Application Administrator* ou *Global Administrator*. Nécessaire uniquement la première fois, lorsque le Service Principal RealmJoin Azure Resources n’existe pas encore. * **Abonnement Azure :** autorisation de déployer dans le groupe de ressources de l’espace de travail **et** pour y créer des affectations de rôle — par exemple *Owner*, ou *Contributor* combiné avec *User Access Administrator* / *Role Based Access Control Administrator*. * La connexion se fait via `Connect-AzAccount`, qui utilise l’ **Azure PowerShell** application de première partie. Les tenants qui limitent le consentement utilisateur peuvent devoir accorder d’abord un consentement d’administrateur à cette application. {% hint style="info" %} Le groupe de ressources et l’espace de travail Log Analytics existent déjà dans votre cas — la migration ne les crée pas. Les commandes du Portail sont préremplies avec votre abonnement, votre groupe de ressources et le nom de votre espace de travail actuels. {% endhint %} ## Où exécuter les commandes Exécutez les commandes dans une **session PowerShell locale** sur une station de travail administrative — de la même façon que vous exécuteriez le script d’onboarding RealmJoin. {% hint style="warning" %} Utilisez une **tout juste ouverte** session PowerShell et évitez **Azure Cloud Shell**. Le module RealmJoin exige des versions exactes des `Az.*` modules. Si une version différente d’un `Az` module est déjà chargé dans la session — ce qui est généralement le cas dans Cloud Shell — le module ne peut pas se rétablir et s’arrête avec un message de conflit de version. Fermer la session et en ouvrir une nouvelle résout ce problème. {% endhint %} Une session élevée ("Exécuter en tant qu’administrateur") n’est pas requise : les modules sont installés avec `-Scope CurrentUser`. ## Migration {% stepper %} {% step %} #### Ouvrez les paramètres Log Analytics dans le Portail Accédez à **Paramètres → Log Analytics** (). Tant que votre tenant est encore sur l’API Data Collector, la page affiche l’avis **"Migrer vers l’API d’ingestion des journaux (recommandé)"** avec un bloc de commande prêt à copier. Utilisez le bouton **Copier** pour le copier. {% endstep %} {% step %} #### Vérifiez la commande copiée La commande ressemble à ceci, avec vos propres valeurs renseignées : ```powershell $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 "" -WorkspaceName "" -SubscriptionId "" -Token "" 6>&1 Grant-RJUpdateComplianceWorkspaceAccess -WorkspaceId "" 6>&1 ``` * Les premières lignes installent ou mettent à jour le module RealmJoin et l’importent. * `Set-RJLogAnalyticsWorkspace` effectue la migration proprement dite et enregistre le résultat auprès de RealmJoin à l’aide du `-Token`. * `Grant-RJUpdateComplianceWorkspaceAccess` n’apparaît que si vous avez configuré un [espace de travail Update Compliance](/fr/supervision-et-journaux/log-analytics.md#windows-update-for-business-reports). Il accorde à RealmJoin *Log Analytics Reader* sur cet espace de travail afin que les données Windows Update continuent de fonctionner sans votre propre enregistrement d’application. {% hint style="warning" %} Assurez-vous que `-ResourceGroupName`, `-WorkspaceName` et `-SubscriptionId` sont présents et pointent vers votre **espace de travail** espace de travail. Si `-WorkspaceName` manque, le module crée un **nouvel** espace de travail au lieu de migrer l’existant, et vos anciens et nouveaux journaux se retrouvent à des endroits différents. Ajoutez manuellement le paramètre manquant si nécessaire. {% endhint %} {% hint style="info" %} **À propos `6>&1`:** ces commandes signalent leur progression sur le flux d’information de PowerShell. La `6>&1` redirection affiche cette sortie dans la console — sans elle, vous ne verrez aucun message de progression. {% endhint %} {% endstep %} {% step %} #### Exécutez la commande Collez le bloc dans une nouvelle session PowerShell et exécutez-le. Le jeton est valable environ une heure — s’il a expiré, rechargez la page des paramètres et copiez la commande à nouveau. Vous serez invité à vous connecter avec `Connect-AzAccount`. Le déploiement signale ensuite chaque ressource au fur et à mesure de sa création : le Service Principal, les tables personnalisées, les Data Collection Rules et les affectations de rôle. Une seule exécution prend généralement quelques minutes. {% hint style="info" %} Vous voulez voir d’abord ce qui se passerait ? Ajoutez `-WhatIf` à `Set-RJLogAnalyticsWorkspace` pour un aperçu What-If d’Azure Resource Manager. Notez que la connexion et l’installation des `Az` modules se produisent quand même, car l’aperçu a besoin des deux. {% endhint %} {% hint style="info" %} **Se déconnecter ensuite :** la connexion Azure reste active une fois la commande terminée. Une fois que vous avez terminé, exécutez `Disconnect-AzAccount` pour vous déconnecter de la session existante. {% endhint %} {% endstep %} {% step %} #### Vérifier dans le Portail Retournez à **Paramètres → Log Analytics** et sélectionnez **Actualiser**. La page affiche maintenant la configuration de l’API d’ingestion des journaux — abonnement, groupe de ressources, nom de l’espace de travail, ID de l’espace de travail client et ID du tenant — sous forme de champs en lecture seule, puisque ces paramètres sont désormais gérés par le module PowerShell. Sous **Avancé** vous pouvez examiner les points de terminaison, les noms de règles et les noms de flux des trois Data Collection Rules. Sélectionnez **Vérifier les problèmes de configuration** pour vérifier que toutes les autorisations Azure requises sont en place sur l’espace de travail et sur chaque Data Collection Rule. {% endstep %} {% step %} #### Confirmez que les journaux arrivent Ouvrez [Journal d’audit](/fr/supervision-et-journaux/audit-log.md), les [journaux Runbook](/fr/automatisation/runbooks/runbook-logs.md) ou les journaux opérationnels et confirmez que de nouvelles entrées apparaissent. Les entrées existantes d’avant la migration restent également visibles. {% hint style="info" %} Azure a besoin de quelques minutes pour rendre disponible une table personnalisée nouvellement créée et sa règle. Si rien n’arrive immédiatement, patientez un peu et actualisez. {% endhint %} {% endstep %} {% endstepper %} ## Après la migration ### Conservez l’ancien enregistrement d’application pour l’instant Les entrées historiques dans `AuditLogs_CL`, `OperationalLogs_CL` et `RunbookLogs_CL` sont toujours lues avec votre **enregistrement d’application existant et votre secret client**. Le Portail interroge les anciennes et les nouvelles tables en parallèle. {% hint style="warning" %} Ne supprimez pas l’enregistrement d’application et continuez à renouveler son secret client tant que vous souhaitez encore voir les données de journal d’avant la migration. Seule la **clé partagée de l’espace de travail** n’est plus nécessaire à RealmJoin — elle n’est plus utilisée pour l’écriture. {% endhint %} Une fois que les anciennes données ont dépassé la [rétention de votre espace de travail](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-retention-archive?tabs=portal-1%2Cportal-2), vous pouvez supprimer l’enregistrement d’application. ### Maintenir le schéma à jour Si RealmJoin étend le schéma des journaux dans une future version, la page Paramètres affiche un avis indiquant que le schéma Log Analytics déployé n’est pas à jour, ainsi que la commande pour le mettre à jour. C’est la **même** `Set-RJLogAnalyticsWorkspace` commande — exécutez-la à nouveau et les tables et les règles sont mises à jour sur place. ## Dépannage
« Le module RealmJoin est obsolète - l’exécution ne peut pas continuer » Chaque cmdlet vérifie une fois par session que vous utilisez la dernière version publiée du module. Installez la version actuelle, puis fermez la session et ouvrez-en une nouvelle : ```powershell Install-Module -Name RealmJoin -Force -Scope CurrentUser ```
Un conflit de version du module est signalé Un `Az.*` module dans une version différente de celle verrouillée par le module RealmJoin est déjà chargé dans la session. Cela ne peut pas être corrigé dans la session en cours — fermez PowerShell, ouvrez une nouvelle session et relancez la commande. C’est aussi la raison de ne pas utiliser Azure Cloud Shell.
« Besoin d’approbation de l’administrateur » ou erreur de consentement lors de la connexion La connexion utilise l’ **Azure PowerShell** application de première partie. Si votre tenant limite le consentement utilisateur, un administrateur doit accorder une fois le consentement d’administrateur à cette application.
Le déploiement échoue lors de la création des affectations de rôle La création des *Log Analytics Reader* et *Monitoring Metrics Publisher* affectations nécessite un rôle capable de gérer l’accès — par exemple *Owner*, *User Access Administrator* ou *Role Based Access Control Administrator* sur le groupe de ressources ou l’abonnement. *Contributor* à lui seul ne suffit pas. Les affectations de rôle déjà existantes sont détectées et ignorées, donc relancer la commande après avoir corrigé les autorisations est sans danger.
Le déploiement échoue avec une erreur concernant la région de l’espace de travail Le déploiement cible la région du groupe de ressources. Si votre espace de travail existant se trouve dans une région différente de celle de son groupe de ressources, Azure rejette la modification, car l’emplacement d’un espace de travail existant ne peut pas être modifié. Veuillez contacter le support RealmJoin dans ce cas.
Le jeton n’est plus accepté Le jeton d’intégration de la commande générée est de courte durée (environ une heure). Rechargez **Paramètres → Log Analytics** dans le Portail, copiez de nouveau la commande et relancez-la. Le déploiement Azure lui-même est idempotent, donc un second passage ne fait pas de mal.
L’espace de travail Update Compliance se trouve dans un autre abonnement `Grant-RJUpdateComplianceWorkspaceAccess` recherche l’espace de travail dans l’abonnement actuellement sélectionné. Si l’espace de travail Update Compliance se trouve ailleurs, transmettez l’abonnement explicitement : ```powershell Grant-RJUpdateComplianceWorkspaceAccess -WorkspaceId "" -SubscriptionId "" 6>&1 ```
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.realmjoin.com/fr/supervision-et-journaux/log-ingestion-api-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.