Prérequis de l’agent Connected Machine

  • Article

Attention

Cet article fait référence à CentOS, une distribution Linux proche de l’état EOL (End Of Life). Faites le point sur votre utilisation afin de vous organiser en conséquence. Pour plus d’informations, consultez l’aide Fin de vie CentOS.

Cette rubrique décrit les exigences de base requises pour l’installation de l’agent Connected Machine pour intégrer un serveur physique ou une machine virtuelle à des serveurs avec Azure Arc. Certaines méthodes d’intégration peuvent avoir des exigences supplémentaires.

Environnements pris en charge

Les serveurs avec Azure Arc prennent en charge l’installation de l’agent Connected Machine sur des serveurs physiques et des machines virtuelles hébergées en dehors d’Azure. Cela comprend la prise en charge des machines virtuelles s’exécutant sur des plateformes comme :

  • VMware (y compris Azure VMware Solution)
  • Azure Stack HCI
  • Autres environnements cloud

Vous ne devez pas installer Azure Arc sur des machines virtuelles hébergées dans Azure, Azure Stack Hub ou Azure Stack Edge, car elles disposent déjà de capacités similaires. Vous pouvez en revanche utiliser une machine virtuelle Azure pour simuler un environnement local uniquement à des fins de test.

Faites très attention lors de l’utilisation d’Azure Arc sur des systèmes sui sont :

  • Clonés.
  • Restaurés à partir d’une sauvegarde en tant que deuxième instance du serveur.
  • Utilisés pour créer une « image de référence » à partir de laquelle d’autres machines virtuelles sont créées.

Si deux agents utilisent la même configuration, vous observerez des comportements incohérents lorsque les deux agents essaieront d’agir en tant que ressource Azure unique. La bonne pratique pour ces situations consiste à utiliser un outil d’automatisation ou un script afin d’intégrer le serveur à Azure Arc une fois qu’il a été cloné, restauré à partir d’une sauvegarde ou créé à partir d’une image de référence.

Remarque

Pour plus d’informations sur l’utilisation de serveurs avec Azure Arc dans les environnements VMware, consultez le FAQ sur VMware.

Systèmes d’exploitation pris en charge

Azure Arc prend en charge les systèmes d’exploitation Windows et Linux suivants. Seules les architectures x86-64 (64 bits) sont prises en charge. L’agent Azure Connected Machine ne s’exécute pas sur des architectures x86 (32 bits) ou ARM.

  • AlmaLinux 9
  • Amazon Linux 2 et 2023
  • Azure Linux (CBL-Mariner) 1.0, 2.0
  • Azure Stack HCI
  • CentOS Linux 7 et 8
  • Debian 10, 11 et 12
  • Oracle Linux 7 et 8
  • Red Hat Enterprise Linux (RHEL) 7, 8 et 9
  • Rocky Linux 8 et 9
  • SUSE Linux Enterprise Server (SLES) 12 SP3-SP5 et 15
  • Ubuntu 16.04, 18.04, 20.04 et 22.04 LTS
  • Windows 10, 11 (voir les conseils sur le système d’exploitation client)
  • Windows IoT Entreprise
  • Windows Server 2008 R2 SP1, 2012, 2012 R2, 2016, 2019 et 2022
    • Les expériences Desktop et Server Core sont toutes deux prises en charge
    • Les éditions Azure sont prises en charge sur Azure Stack HCI

L’agent Azure Connected Machine n’a pas été testé sur les systèmes d’exploitation renforcés par le benchmark CIS (Center for Information Security).

Instructions relatives au système d’exploitation client

Le service Azure Arc et l’agent Azure Connected Machine Azure sont pris en charge sur les systèmes d’exploitation clients Windows 10 et 11 uniquement lors de l’utilisation de ces ordinateurs dans un environnement de type serveur. Autrement dit, l’ordinateur doit toujours être :

  • Connecté à Internet
  • Connecté à une source d’alimentation.
  • Sous tension

Par exemple, un ordinateur exécutant Windows 11 responsable de la signalisation numérique, de solutions de point de vente et de tâches générales d’administration de back-office est un bon candidat pour Azure Arc. Les machines de productivité des utilisateurs finaux, telles qu’un ordinateur portable, qui peuvent être hors connexion pendant de longues périodes, ne doivent pas utiliser Azure Arc mais plutôt Microsoft Intune ou Microsoft Configuration Manager.

Serveurs à courte durée de vie et infrastructure de bureau virtuel

Microsoft ne recommande pas d’exécuter Azure Arc sur des serveurs à courte durée de vie (éphémères) ou des machines virtuelles d’infrastructure de bureau virtuel (VDI). Azure Arc est conçu pour la gestion à long terme des serveurs, et n’est pas optimisé pour les scénarios où vous créez et supprimez régulièrement des serveurs. Par exemple, Azure Arc ne sait pas si l’agent est hors connexion en raison d’une maintenance planifiée du système ou si la machine virtuelle a été supprimée ; par conséquent, il ne nettoie pas automatiquement les ressources de serveur qui ont cessé d’envoyer des pulsations. Vous pourriez ainsi rencontrer un conflit si vous recréez la machine virtuelle avec le même nom et qu’il existe une ressource Azure Arc existante portant le même nom.

Azure Virtual Desktop sur Azure Stack HCI n’utilise pas de machines virtuelles à courte durée de vie, et prend en charge l’exécution d’Azure Arc dans les machines virtuelles de bureau.

Configuration logicielle requise

Systèmes d’exploitation Windows :

  • Windows Server 2008 R2 SP1 nécessite PowerShell 4.0 ou version ultérieure. Microsoft recommande d’exécuter la dernière version, Windows Management Framework 5.1.

Systèmes d’exploitation Linux :

  • systemd
  • wget (pour télécharger le script d’installation)
  • openssl
  • gnupg (systèmes Debian uniquement)

Droit d’ouverture de session utilisateur locale pour les systèmes Windows

Le service HIMDS (Hybrid Instance Metadata Service) Azure s’exécute sous un compte virtuel à faible privilège, NT SERVICE\himds. Ce compte a besoin du droit « Se connecter en tant que service » dans Windows pour s’exécuter. Dans la plupart des cas, vous n’avez rien à faire, car ce droit est accordé aux comptes virtuels par défaut. Toutefois, si votre organisation utilise la stratégie de groupe pour personnaliser ce paramètre, vous devez ajouter NT SERVICE\himds à la liste des comptes autorisés à se connecter en tant que service.

Vous pouvez vérifier la stratégie actuelle sur votre machine en ouvrant l’Éditeur de stratégie de groupe local (gpedit.msc) dans le menu Démarrer et en accédant à l’élément de stratégie suivant :

Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur > Se connecter en tant que service

Vérifiez si NT SERVICE\ALL SERVICES, NT SERVICE\himds ou S-1-5-80-4215458991-2034252225-2287069555-1155419622-2701885083 (les identificateurs de sécurité statiques pour NT SERVICE\himds) figure dans la liste. Si aucun d’eux n’est dans la liste, vous devez collaborer avec votre administrateur de stratégie de groupe pour ajouter NT SERVICE\himds à toutes les stratégies qui configurent des attributions de droits de l’utilisateur sur vos serveurs. L’administrateur de stratégie de groupe doit apporter la modification sur un ordinateur sur lequel l’agent Azure Connected Machine est installé, afin que le sélecteur d’objets résolve correctement l’identité. L’agent n’a pas besoin d’être configuré ou connecté à Azure pour apporter cette modification.

Capture d’écran de l’Éditeur de stratégie de groupe local montrant quels utilisateurs ont les autorisations nécessaires pour se connecter en tant que service.

Autorisations requises

Vous avez besoin des rôles intégrés Azure suivants pour différents aspects de la gestion des machines connectées :

  • Pour intégrer des machines, vous devez disposer du rôle Intégration Azure Connected Machine ou Contributeur pour le groupe de ressources dans lequel vous gérez les serveurs.
  • Pour lire, modifier et supprimer une machine, vous devez être membre du rôle Administrateur des ressources Azure Connected Machine pour le groupe de ressources.
  • Pour sélectionner un groupe de ressources dans la liste déroulante lors de l’utilisation de la méthode Générer un script, vous avez également besoin du rôle Lecteur pour ce groupe de ressources (ou d’un autre rôle qui comprend un accès Lecteur).

Limites du service et de l’abonnement Azure

Il n’existe aucune limite quant au nombre de serveurs avec Azure Arc que vous pouvez inscrire dans tout groupe de ressources, abonnement ou locataire unique.

Chaque serveur avec Azure Arc est associé à un objet Microsoft Entra et comptabilité dans le cadre de votre quota d’annuaire. Consultez Restrictions et limites du service Microsoft Entra pour plus d’informations sur le nombre maximal d’objets que vous pouvez avoir dans un annuaire Microsoft Entra.

Fournisseurs de ressources Azure

Pour utiliser des serveurs Azure Arc, les fournisseurs de ressources Azure suivants doivent être inscrits dans votre abonnement :

  • Microsoft.HybridCompute
  • Microsoft.GuestConfiguration
  • Microsoft.HybridConnectivity
  • Microsoft.AzureArcData (si vous envisagez d’activer Arc sur des serveurs SQL)
  • Microsoft.Compute (pour le Gestionnaire de mise à jour Azure et les mises à niveau automatiques d’extension)

Pour inscrire les fournisseurs de ressources, utilisez les commandes suivantes :

Azure PowerShell :

Connect-AzAccount
Set-AzContext -SubscriptionId [subscription you want to onboard]
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData

Azure CLI :

az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'

Vous pouvez également inscrire les fournisseurs de ressources dans le portail Azure.

Étapes suivantes