Azure Arc ajoute un plan de gestion, pas une migration
Azure Arc-enabled Servers inscrit un serveur physique ou une machine virtuelle Windows ou Linux hébergée sur place ou dans un autre nuage comme ressource Azure. Le serveur conserve son hyperviseur, son stockage, son adresse IP et ses applications. L’agent Connected Machine crée une identité managée et transmet les métadonnées nécessaires au plan de gestion.
La valeur apparaît quand cette représentation est utilisée pour normaliser les groupes de ressources, les étiquettes, le contrôle d’accès, les requêtes d’inventaire, les politiques et les correctifs. Arc ne remplace pas à lui seul la sauvegarde, la surveillance, l’EDR, WSUS ou les processus d’exploitation : il fournit un point de contrôle auquel ces services peuvent être rattachés.
Ce qui reste local et ce qui apparaît dans Azure
Choisissez la région en tenant compte de la résidence des métadonnées. Documentez aussi les informations collectées par l’agent avant le pilote : nom, FQDN, domaine AD, caractéristiques matérielles, interfaces réseau, versions et état de conformité lorsque ces fonctions sont utilisées.
| Élément | Reste sur le serveur | Devient une ressource ou une donnée Azure |
|---|---|---|
| Charge de travail | VM, applications, fichiers et bases de données | Aucun déplacement automatique |
| Identité de gestion | Services de l’agent et certificat | Identité managée et Azure Resource ID |
| Inventaire | Système d’exploitation et matériel | Nom, FQDN, OS, version d’agent, CPU, mémoire, réseau et étiquettes |
| Configuration | Paramètres Windows ou Linux | État de conformité si Machine Configuration est activé |
| Journaux | Événements et compteurs locaux | Seulement les données configurées avec Azure Monitor ou un autre service |
1. Dessiner la gouvernance avant l’installation
Un agent installé sans modèle cible produit rapidement un nouvel inventaire incohérent. Définissez d’abord les abonnements, groupes de ressources, régions, conventions de nom et étiquettes. Le regroupement doit soutenir les délégations et les opérations, pas seulement reproduire chaque OU Active Directory.
Une structure pragmatique sépare au minimum production, non-production et laboratoire. Les étiquettes complètent cette structure avec le site, le propriétaire, l’application, la criticité, la fenêtre de maintenance et la politique de sauvegarde. Utilisez Azure Policy pour imposer les champs obligatoires et empêcher la dérive.
| Étiquette | Exemple | Usage |
|---|---|---|
| Environment | Production | Portée des politiques et rapports |
| Site | Montreal-DC1 | Localisation et fenêtre de maintenance |
| ServiceOwner | Infrastructure | Responsable opérationnel |
| Application | ERP | Dépendances et priorisation |
| Criticality | Tier-1 | Ordre de correction et escalade |
| PatchRing | Wave-2 | Ciblage dynamique des correctifs |
2. Préparer les identités et le réseau
L’agent communique vers Azure en HTTPS sur TCP 443; aucune connexion entrante publique n’est nécessaire. Validez les URL requises, l’inspection TLS, le proxy et les règles de sortie pour l’agent et pour chaque extension prévue. Le Log Analytics Gateway ne sert pas de proxy au Connected Machine agent, même s’il peut être utilisé par Azure Monitor Agent.
Pour un déploiement à grande échelle, utilisez un principal de service réservé à l’intégration avec le rôle Azure Connected Machine Onboarding limité au groupe de ressources cible. Il sert à inscrire la machine, puis l’identité managée propre au serveur prend le relais. Ne distribuez jamais les droits Contributor ou les identifiants personnels d’un administrateur dans un script de déploiement.
- Enregistrer les fournisseurs Microsoft.HybridCompute, Microsoft.GuestConfiguration et Microsoft.HybridConnectivity.
- Créer un groupe de ressources pilote et une identité d’intégration dédiée.
- Autoriser TCP 443 vers les points de terminaison documentés ou utiliser un proxy pris en charge.
- Évaluer Private Link pour les environnements qui exigent un chemin privé.
- Tester l’inspection TLS et les listes de révocation de certificats avant le déploiement massif.
3. Commencer par un véritable pilote
Sélectionnez quelques serveurs représentatifs : Windows et Linux, VM et physique, sites différents, proxy, application métier et système moins critique. Évitez de commencer par les contrôleurs de domaine ou les systèmes dont la fenêtre de changement est difficile à obtenir.
Générez le script d’intégration depuis Azure Arc > Machines afin de récupérer les bons paramètres de tenant, abonnement, groupe de ressources et région. Conservez le secret du principal de service dans le mécanisme sécurisé de votre outil de déploiement et faites-le pivoter après la vague d’intégration.
azcmagent connect `
--service-principal-id '<application-id>' `
--service-principal-secret '<secret-fourni-de-facon-securisee>' `
--tenant-id '<tenant-id>' `
--subscription-id '<subscription-id>' `
--resource-group 'rg-arc-prod-canadacentral' `
--location 'canadacentral' `
--tags 'Environment=Production,Site=Montreal-DC1,PatchRing=Wave-1'Attention à la découverte automatique de SQL Server
Lorsqu’un serveur Windows ou Linux connecté héberge SQL Server, Azure Arc peut également intégrer automatiquement les instances SQL et déployer l’extension correspondante. Cette fonction ajoute un inventaire détaillé et des capacités de gestion, mais elle doit être incluse dans la revue de sécurité, de licences et de coûts.
Si le pilote ne doit pas intégrer SQL Server, ajoutez avant la connexion l’étiquette ArcSQLServerExtensionDeployment=Disabled. Ne découvrez pas cette conséquence après avoir inscrit plusieurs centaines de serveurs.
--tags 'Environment=Pilot,ArcSQLServerExtensionDeployment=Disabled'4. Valider l’agent sur chaque plateforme
L’intégration réussie ne se limite pas à voir une ligne dans le portail. Confirmez l’état local, la connectivité vers chaque service, les étiquettes, l’identité, la version de l’agent et le fonctionnement des services. Sur Windows, les journaux principaux se trouvent sous ProgramData\AzureConnectedMachineAgent; sur Linux, sous /var/opt/azcmagent.
L’agent envoie normalement un heartbeat toutes les cinq minutes. Un serveur passe généralement à Disconnected après 15 à 30 minutes sans signal. Créez une alerte Resource Health et une procédure qui distingue une panne réelle, un service arrêté, un proxy bloquant et une machine retirée volontairement.
azcmagent show
azcmagent check
azcmagent config list
azcmagent version
azcmagent logs --full5. Exploiter l’inventaire avec Azure Resource Graph
Chaque serveur connecté reçoit un Azure Resource ID et devient interrogeable avec Azure Resource Graph. Cela permet de répondre rapidement à des questions simples mais coûteuses à consolider : quels serveurs sont déconnectés, quelles versions de système sont encore présentes, quels agents vieillissent et quelles étiquettes manquent.
Resource Graph interroge les métadonnées Azure, pas le contenu complet du serveur. Pour les logiciels, changements, journaux et performances détaillés, ajoutez explicitement Change Tracking, Azure Monitor Agent ou un autre outil adapté.
Resources
| where type =~ 'microsoft.hybridcompute/machines'
| extend status = tostring(properties.status),
os = tostring(properties.osName),
osVersion = tostring(properties.osVersion),
agentVersion = tostring(properties.agentVersion)
| project name, resourceGroup, subscriptionId, location,
status, os, osVersion, agentVersion, tags
| order by resourceGroup asc, name asc$query = @"
Resources
| where type =~ 'microsoft.hybridcompute/machines'
| project name, resourceGroup, location, properties.status,
properties.osName, properties.agentVersion, tags
"@
Search-AzGraph -Query $query -First 10006. Gérer les correctifs avec Azure Update Manager
Azure Update Manager peut évaluer et corriger les serveurs Windows et Linux connectés par Arc sans dépendre de l’ancien compte Azure Automation ou de Log Analytics. L’évaluation périodique recherche les mises à jour environ toutes les 24 heures; les installations peuvent être immédiates ou liées à une configuration de maintenance.
Conservez les sources de correctifs existantes : Windows Update, Microsoft Update ou WSUS pour Windows, et les dépôts configurés pour Linux. Arc orchestre l’évaluation et l’installation, mais ne rend pas un paquet incompatible soudainement sûr. Déployez par anneaux, définissez les fenêtres, le comportement de redémarrage et les critères d’arrêt.
| Anneau | Cibles | Décalage conseillé | Critère de sortie |
|---|---|---|---|
| 0 — Laboratoire | Serveurs jetables ou non critiques | Dès la disponibilité | Installation et redémarrage validés |
| 1 — Pilote | Services TI représentatifs | Quelques jours | Aucun incident applicatif |
| 2 — Production | Charges standard | Après le pilote | Conformité et sauvegarde confirmées |
| 3 — Critique | Tier-1 et grappes | Fenêtre approuvée | Plan de bascule et tests fonctionnels |
7. Appliquer Azure Policy sans écraser les GPO
Azure Policy peut vérifier la présence d’étiquettes, les régions autorisées, les extensions attendues et l’état de services de gestion. Machine Configuration va plus loin en auditant ou en appliquant des paramètres à l’intérieur de Windows ou Linux. Commencez par Audit et DeployIfNotExists avant d’utiliser Deny ou une correction automatique.
Une politique Azure et une GPO peuvent viser le même paramètre avec des calendriers différents. Établissez une matrice d’autorité : qui gère Defender, Windows Update, les services, les certificats et la journalisation. Utilisez Arc pour mesurer la conformité avant de déplacer l’autorité de configuration.
- Audit des étiquettes et de la structure Azure.
- Déploiement contrôlé d’Azure Monitor Agent ou d’autres extensions approuvées.
- Machine Configuration en audit pour les paramètres internes.
- Exclusions documentées pour les systèmes hérités.
- Remédiation automatique seulement après un pilote et un plan de retour.
8. Limiter RBAC, extensions et exécution distante
Arc étend le plan de contrôle Azure jusqu’aux serveurs. Une personne capable d’installer une extension, d’exécuter une commande ou d’attribuer une identité peut obtenir un impact local important. Séparez les rôles d’intégration, de lecture, de correctifs et d’administration; protégez les rôles privilégiés avec PIM et Conditional Access.
N’autorisez que les extensions nécessaires. Journalisez les changements Azure Activity Log, surveillez les installations d’extensions et limitez les groupes autorisés à utiliser Run Command ou SSH Arc. L’identité managée du serveur doit recevoir uniquement les accès Azure requis par sa charge de travail.
9. Prévoir l’entretien et les coûts
Le plan de contrôle Arc, l’inventaire, les étiquettes et les requêtes Resource Graph sont offerts sans frais. Les services ajoutés peuvent être facturés : Azure Update Manager pour un serveur Arc est affiché à environ 5 $ US par serveur par mois, et Machine Configuration avec Change Tracking à 6 $ US. Azure Monitor et Sentinel ajoutent des coûts d’ingestion et de rétention.
Certaines licences Windows Server avec Software Assurance ou abonnement actif, ainsi que Defender for Servers Plan 2, peuvent inclure des capacités autrement facturées. Calculez le coût sur le nombre réel de serveurs, les données ingérées et les options retenues; ne supposez pas que connecter Arc active gratuitement tout le portefeuille Azure.
Microsoft prend officiellement en charge les versions du Connected Machine agent publiées dans la dernière année. L’automatisation de sa mise à niveau existe en préversion à partir de l’agent 1.57; autrement, intégrez sa mise à jour à votre outil de déploiement et suivez Azure Advisor.
Plan de déploiement en cinq vagues
Azure Arc est surtout utile lorsqu’il simplifie une exploitation déjà disciplinée. Commencez par rendre l’inventaire fiable, puis ajoutez gouvernance et correctifs avec des responsabilités claires. Vous obtenez ainsi un plan de gestion commun sans transformer un projet d’administration en migration précipitée vers Azure.
- Documenter les données envoyées et la région choisie.
- Conserver une identité d’intégration à privilèges minimaux.
- Tester proxy, inspection TLS, extensions et déconnexion.
- Traiter les serveurs clones et modèles avant la connexion.
- Surveiller les agents déconnectés, expirés ou trop anciens.
- Déployer Policy et Update Manager en audit ou par anneaux.
- Mesurer les coûts avant d’activer Monitor, Sentinel ou Defender à grande échelle.
- Prévoir le retrait propre d’un serveur décommissionné.
| Vague | Portée | Résultat attendu |
|---|---|---|
| 0 — Conception | Région, RBAC, groupes, étiquettes, réseau et coûts | Modèle approuvé |
| 1 — Connexion | Quelques serveurs représentatifs | Agent stable et inventaire exact |
| 2 — Visibilité | Resource Graph, alertes et tableaux de bord | Déconnectés et dérive détectés |
| 3 — Gouvernance | Policies et Machine Configuration en audit | Conformité mesurée sans interruption |
| 4 — Opérations | Correctifs par anneaux et extensions approuvées | Fenêtres, reprise et délégation testées |