Cet article a été traduit automatiquement. La traduction peut contenir des imprécisions.
Passer à la version originale en anglais.
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Aperçu

Les locataires qui ont connecté Azure Automation avant l’intégration basée sur PowerShell utilisent une RealmJoin Runbook Management inscription d’application dans leur propre locataire. RealmJoin s’authentifie auprès de votre Automation Account avec l’ID client et le secret client de cette application.

Les locataires nouvellement intégrés ne font plus cela : RealmJoin utilise sa propre application multilocataire, à laquelle le rôle Contributor est attribué sur votre Automation Account et rien d’autre. Vous pouvez basculer une configuration existante avec la module PowerShell RealmJoin.

Il n’y a ici aucune échéance. Contrairement à la migration de Log Analytics, rien n’est retiré par Microsoft — l’ancien chemin continue de fonctionner. Basculez quand cela vous convient.

Pourquoi basculer

  • Aucun secret client à renouveler. Le secret par locataire 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 managée n’a aucun secret de votre côté.

  • Aucune inscription d’application à maintenir dans votre locataire.

  • Périmètre plus restreint. Le Service Principal hérité se voyait généralement attribuer Contributor sur l’ensemble du groupe de ressources. L’application managée se voit attribuer Contributor uniquement sur le compte Automation.

  • Votre compte Automation, son identité managée, ses autorisations et vos runbooks restent tous exactement tels quels.

Ce que la bascule modifie

La même Set-RJAutomationAccount commande que pour une nouvelle configuration est utilisée, pointée vers votre espace de travail compte Automation. Elle :

  • crée le RealmJoin Azure Resources Service Principal dans votre locataire, s’il n’existe pas encore

  • lui attribue Contributor sur ce compte Automation

  • réapplique les autorisations d’application de l’identité managée — Microsoft Graph, Exchange Online, Defender et SharePoint — pour le jeu fourni par le module

  • indique à RealmJoin de s’authentifier désormais avec l’application managée

Votre compte Automation conserve son nom, son identité managé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 à partir de zéro.

L’inscription réinitialise la branche du dépôt de runbooks partagé sur production. Si votre locataire suit délibérément une autre branche, définissez-la à nouveau dans le Portail ensuite sous Paramètres → Runbooks.

Prérequis

Comme pour une nouvelle configuration — voir Prérequis 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 — renverrait Azure Cloud Shell

  • Un compte qui peut créer des Service Principals et attribuer des autorisations d’application dans Entra ID (Global Administrator ou Privileged Role Administrator) et qui peut créer des attributions de rôles dans l’abonnement (Owner, ou Contributor plus User Access Administrator)

Migration

1

Copiez la commande depuis RealmJoin Portal

Dans le RealmJoin Portal, allez à Paramètres → Runbooks (https://portal.realmjoin.com/settings/runbooks-configuration).

La page affiche l’avis "Passer à l’application managée RealmJoin" avec un bloc de commande prêt à copier. Utilisez le bouton Copier pour le copier.

La commande est préremplie avec votre groupe de ressources actuel, le nom du compte Automation et l’abonnement :

Assurez-vous que -AutomationAccountName est présent et nomme votre espace de travail compte. Sans lui, le module crée un nouveau compte Automation vide au lieu de basculer celui que vous utilisez.

2

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 et attribution de rôle au fur et à mesure de son application ; tout ce qui existe déjà est détecté et ignoré.

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.

3

Vérifier dans le Portail

Retournez à 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 la branche et les options Hybrid Runbook Worker, ainsi qu’une section en lecture seule Connexion Azure section. L’ID client et le secret client ne font plus partie de la configuration.

Vérifiez que la branche est celle que vous souhaitez, puis exécutez un runbook pour confirmer que l’exécution fonctionne toujours.

4

Nettoyer l’ancienne inscription d’application

Une fois que tout fonctionne, l’ RealmJoin Runbook Management inscription d’application n’est plus utilisée pour les runbooks et peut être supprimée dans Entra ID, ainsi que son attribution de rôle Contributor sur le groupe de ressources.

Vérifiez d’abord ce qui utilise d’autre cette inscription d’application. C’est la même application que l’ancienne Log Analytics configuration peut réutiliser — si votre locataire utilise encore l’API Data Collector là-bas, ou lit encore les données de journal écrites avant cette migration, l’inscription d’application et son secret sont toujours nécessaires. Voir Migration vers l'API Log Ingestion.

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 exécutez la dernière version publiée. Installez la version actuelle, puis fermez la session et ouvrez-en une nouvelle :

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.

Le déploiement échoue lors de la création des affectations de rôle

La création de l’attribution Contributor sur le compte Automation nécessite un rôle capable de gérer les accès — par exemple Owner, User Access Administrator ou Role Based Access Control Administrator. 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 lors de l’attribution des autorisations d’application

L’attribution des rôles d’application Graph, Exchange, Defender et SharePoint à l’identité managée nécessite Global Administrator ou Privileged Role Administrator. Demandez à quelqu’un disposant de ce rôle d’exécuter la commande, ou exécutez-la à nouveau vous-même après l’activation du rôle.

La synchronisation des runbooks cesse de fonctionner après la bascule

Ouvrez Paramètres → Runbooks et vérifiez l’avertissement affiché en haut de la page — RealmJoin vérifie la configuration du compte Automation chaque fois que la page se charge. Utilisez ensuite Afficher la cmdlet dans la connexion Azure pour relancer la commande de configuration ; elle est idempotente et réapplique tout ce qui manque.

Mis à jour

Ce contenu vous a-t-il été utile ?