> 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/automatisation/connecting-azure-automation/managed-app-migration.md). # Passage à l’application gérée RealmJoin Remplacez l’inscription d’application de gestion des runbooks RealmJoin propre au Tenant et son secret client par l’application gérée multitenant RealmJoin, à l’aide du module PowerShell RealmJoin. ## Vue d'ensemble Les Tenants qui ont connecté Azure Automation avant l’intégration basée sur PowerShell utilisent un **Gestion des runbooks RealmJoin** enregistrement d’application dans leur propre Tenant. RealmJoin s’authentifie auprès de votre Automation Account avec l’ID client et le secret client de cette application. Les nouveaux tenants intégrés ne font plus cela : RealmJoin utilise son propre **application multitenant**, auquel est accordé le rôle Contributeur sur votre Automation Account, et rien d’autre. Vous pouvez basculer une configuration existante avec le [module PowerShell RealmJoin](/fr/deploiement/onboarding-realmjoin-portal/advanced-setup.md). {% hint style="info" %} Le passage à l’application gérée est recommandé. La configuration héritée reste actuellement prise en charge ; cela peut changer à l’avenir, et les clients concernés seront informés séparément. {% endhint %} ### Pourquoi basculer * **Aucun secret client à faire pivoter.** Le secret par Tenant expire et doit être renouvelé ; lorsqu’il expire, la synchronisation des runbooks et l’exécution des runbooks s’arrêtent jusqu’à ce que quelqu’un s’en aperçoive. L’application gérée n’a aucun secret de votre côté. * **Aucun enregistrement d’application à maintenir** dans votre Tenant. * **Périmètre plus restreint.** Le Service Principal hérité recevait généralement le rôle Contributeur sur l’ensemble du groupe de ressources. L’application gérée reçoit Contributeur uniquement sur l’Automation Account. * L’Automation Account (nom et groupe de ressources), son identité gérée attribuée par le système avec son ID d’objet, les rôles Entra ID et les autorisations d’application attribués à cette identité, ainsi que les runbooks importés, sont conservés. ## Ce que le basculement modifie La même chose `Set-RJAutomationAccount` commande que pour une nouvelle configuration est utilisée, en pointant vers votre **existant** Automation Account. Elle : * crée le **RealmJoin Azure Resources** Service Principal dans votre Tenant, s’il n’existe pas encore * lui accorde **Contributeur** sur cet Automation Account * réapplique les autorisations d’application de l’identité gérée — Microsoft Graph, Exchange Online, Defender et SharePoint — pour l’ensemble fourni par le module * indique à RealmJoin de s’authentifier désormais avec l’application gérée Votre Automation Account conserve son nom, son identité gérée et son ID d’objet, de sorte que les rôles Entra ID et toutes les autorisations que vous lui avez attribuées restent valides. Les runbooks ne sont pas réimportés depuis zéro. {% hint style="warning" %} L’enregistrement réinitialise la **branche** du dépôt de runbooks partagé sur `production`. Si votre Tenant suit délibérément une branche différente, définissez-la à nouveau dans le Portail ensuite sous Paramètres → Runbooks. {% endhint %} ## Prérequis Les mêmes que pour une nouvelle configuration — voir [Prérequis](/fr/automatisation/connecting-azure-automation.md#prerequisites) sur la page d’intégration. En bref : * Accès à la zone Paramètres du Portail RealmJoin, pour obtenir la commande et son jeton * PowerShell 5.1 ou version ultérieure, dans une session locale fraîchement ouverte — **pas** Azure Cloud Shell * Un compte qui peut créer des Service Principals et accorder des autorisations d’application dans Entra ID (*Administrateur général* ou *Administrateur de rôle privilégié*) et qui peut créer des affectations de rôle dans l’abonnement (*Propriétaire*, ou *Contributeur* plus *Administrateur de l’accès utilisateur*) ## Migration {% stepper %} {% step %} #### Copiez la commande depuis le Portail RealmJoin Dans le Portail RealmJoin, allez à **Paramètres → Runbooks** (). La page affiche l’avis **"Passer à l’application gérée RealmJoin"** ainsi qu’un bloc de commande prêt à copier. Utilisez le **Copier** bouton pour le copier.
Settings → Runbooks with the notice "Switch to the RealmJoin managed app" and the pre-filled Set-RJAutomationAccount command

Avis de migration et commande dans Paramètres → Runbooks

La commande est préremplie avec votre groupe de ressources actuel, le nom de l’Automation Account et l’abonnement : ```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-RJAutomationAccount -ResourceGroupName "" -AutomationAccountName "" -SubscriptionId "" -Token "" 6>&1 ``` {% hint style="warning" %} Assurez-vous que `-AutomationAccountName` est présent et nomme votre **existant** compte. Sans cela, le module crée un nouvel Automation Account vide au lieu de basculer celui que vous utilisez. {% endhint %} {% endstep %} {% step %} #### Exécutez la commande Collez le bloc dans une nouvelle session PowerShell et exécutez-le. Le jeton est valide pendant environ une heure — s’il a expiré, rechargez la page des paramètres et recopiez la commande. Il vous sera demandé de vous connecter avec `Connect-AzAccount`. Le déploiement indique ensuite chaque ressource et chaque affectation de rôle au fur et à mesure qu’elles sont appliquées ; tout ce qui existe déjà est détecté et ignoré. {% hint style="info" %} **Déconnexion ensuite :** la connexion Azure reste active après la fin de la commande. Une fois terminé, exécutez `Disconnect-AzAccount` pour vous déconnecter de la session existante. {% endhint %} {% endstep %} {% step %} #### Vérifier dans le Portail Revenez à **Paramètres → Runbooks** et sélectionnez **Actualiser**. L’avis de migration a disparu, et la page affiche maintenant **Paramètres de synchronisation des runbooks** avec les options de branche et de Hybrid Runbook Worker, ainsi qu’une **connexion Azure** section en lecture seule. L’ID client et le secret client ne font plus partie de la configuration.
Settings → Runbooks after the switch, with Runbook sync settings and the read-only Azure connection section

Configuration des runbooks après le basculement

Vérifiez que la branche est bien celle que vous souhaitez, puis exécutez un runbook pour confirmer que l’exécution fonctionne toujours. {% endstep %} {% step %} #### Nettoyer l’ancien enregistrement d’application Une fois que tout fonctionne, l’ **Gestion des runbooks RealmJoin** enregistrement d’application n’est plus utilisé pour les runbooks et peut être supprimé dans Entra ID, ainsi que son affectation de rôle Contributeur sur le groupe de ressources. {% hint style="warning" %} Vérifiez d’abord ce qui utilise encore cet enregistrement d’application. C’est la même application que la configuration héritée [Log Analytics](/fr/supervision-et-journaux/log-analytics.md) peut réutiliser — si votre Tenant est encore sur l’API Data Collector là-bas, ou lit encore des données de journaux écrites avant cette migration, l’enregistrement d’application et son secret sont toujours nécessaires. Voir [Migration vers l’API Log Ingestion](/fr/supervision-et-journaux/log-ingestion-api-migration.md). {% endhint %} {% endstep %} {% endstepper %} ## 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. 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 d’une version autre que celle à laquelle le module RealmJoin est fixé 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 exécutez à nouveau la commande. C’est aussi la raison pour laquelle il ne faut pas utiliser Azure Cloud Shell.
Le déploiement échoue lors de la création des affectations de rôle La création de l’affectation Contributeur sur l’Automation Account nécessite un rôle capable de gérer les accès — par exemple *Propriétaire*, *Administrateur de l’accès utilisateur* ou *Administrateur du contrôle d’accès en fonction du rôle*. *Contributeur* seul ne suffit pas. Les affectations de rôle déjà existantes sont détectées et ignorées ; il est donc sans danger de relancer la commande après avoir corrigé les autorisations.
Le déploiement échoue lors de l’attribution des autorisations d’application L’octroi des rôles d’application Graph, Exchange, Defender et SharePoint à l’identité gérée nécessite *Administrateur général* ou *Administrateur de rôle privilégié*. Faites exécuter la commande par une personne disposant de ce rôle, ou réexécutez-la vous-même une fois le rôle activé.
La synchronisation des runbooks cesse de fonctionner après le basculement Ouvrez **Paramètres → Runbooks** et vérifiez l’avertissement affiché en haut de la page — RealmJoin vérifie la configuration de l’Automation Account chaque fois que la page se charge. Ensuite, utilisez **Afficher la cmdlet** sous Connexion Azure pour relancer la commande de configuration ; elle est idempotente et réapplique tout ce qui manque.
--- # 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/automatisation/connecting-azure-automation/managed-app-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.