Matrice de prise en charge pour la découverte et l’évaluation de serveurs physiques

Article
11/04/2024

Cet article résume les conditions préalables et les exigences de prise en charge lors de l’évaluation de serveurs physiques pour la migration vers Azure et utilise l’outil Azure Migrate : découverte et évaluation. Si vous souhaitez migrer des serveurs physiques vers Azure, consultez la matrice de prise en charge de la migration.

Pour évaluer des serveurs physiques, vous créez un projet et ajoutez l’outil Azure Migrate : découverte et évaluation. Après avoir ajouté l’outil, vous déployez l’appliance Azure Migrate. L’appliance découvre en permanence les serveurs locaux et envoie les métadonnées et données de performances des serveurs à Azure. Une fois la découverte terminée, vous rassemblez les serveurs découverts dans des groupes, puis évaluez ceux-ci.

Limites

Support	Détails
Limites d’évaluation	Vous pouvez découvrir et évaluer jusqu’à 35 000 serveurs physiques dans un même projet.
Limites de projet	Vous pouvez créer plusieurs projets dans un abonnement Azure. En plus de serveurs physiques, un projet peut inclure des serveurs sur VMware et sur Hyper-V, jusqu’aux limites d’évaluation pour chacun d’eux.
Découverte	L’appliance Azure Migrate peut découvrir jusqu’à 1 000 serveurs physiques.
Évaluation	Vous pouvez ajouter jusqu’à 35 000 serveurs dans un groupe unique. Vous pouvez évaluer jusqu’à 35 000 serveurs par évaluation.

Apprenez-en davantage sur les évaluations.

Conditions requises des serveurs physiques

Déploiement d'un ordinateur physique : le serveur physique peut être autonome ou déployé dans un cluster.
Type de serveurs : Serveurs nus, serveurs virtualisés exécutant des clouds locaux ou d’autres Clouds comme Amazon Web Services (AWS), Google Cloud Platform (GCP) et Xen.

Remarque

Actuellement, Azure Migrate ne prend pas en charge la découverte des serveurs para-virtualisés.
Système d'exploitation : tous les systèmes d’exploitation Windows et Linux peuvent être évalués pour la migration.

Autorisations pour des serveurs Windows

Pour les serveurs Windows, utilisez un compte de domaine pour les serveurs joints à un domaine et un compte local pour ceux qui ne le sont pas.
Pour la découverte physique, spécifiez le nom d’utilisateur au format de niveau inférieur (domaine\nom d’utilisateur), le format UPN (username@domain.com) n’étant pas pris en charge.

Vous pouvez créer le compte d’utilisateur de l’une des deux manières suivantes.

Option 1 :

créer un compte disposant de privilèges d’administrateur sur les serveurs. Utilisez ce compte pour :

extraire des données de configuration et de performances via une connexion CIM (Common Information Model) ;
effectuer l’inventaire logiciel (découverte d’applications installées) ;
activer l’analyse des dépendances sans agent à l’aide du remoting PowerShell.

Remarque

Si vous souhaitez effectuer un inventaire logiciel (détection des applications installées) et activer l’analyse des dépendances sans agent sur les serveurs Windows, il est recommandé d’utiliser l’option 1.

Option 2 :

Ajoutez le compte d’utilisateur aux groupes suivants : Utilisateurs de gestion à distance, Utilisateurs de l’Analyseur de performances et Utilisateurs du journal de performances.
Si le groupe Utilisateurs de gestion à distance n’est pas présent, ajoutez le compte d’utilisateur suivant au groupe WinRMRemoteWMIUsers_.
Le compte a besoin de ces autorisations pour que l’appliance puisse créer une connexion CIM avec le serveur et extraire les métadonnées de configuration et de performance nécessaires des classes Windows Management Instrumentation (WMI) listées ici.
Dans certains cas, l’ajout du compte à ces groupes peut ne pas renvoyer les données requises à partir des classes WMI. Le compte peut être filtré par contrôle de compte d’utilisateur (UAC). Pour surmonter le filtrage du Contrôle de compte d’utilisateur, le compte d’utilisateur doit disposer des autorisations nécessaires sur l’espace de noms CIMV2 et ses sous-espaces de noms sur le serveur cible. Pour activer les autorisations requises, consultez Résoudre les problèmes de l’appliance Azure Migrate.

Remarque

Pour Windows Server 2008 et 2008 R2, assurez-vous que Windows Management Framework 3.0 est installé sur les serveurs.

Pour découvrir les bases de données SQL Server sur les serveurs Windows, l’authentification Windows et SQL Server sont prises en charge. Vous pouvez fournir des informations d’identification des deux types d’authentification dans le gestionnaire de configuration de l’appliance. Azure Migrate nécessite un compte d’utilisateur Windows membre du rôle serveur sysadmin.

Autorisations pour un serveur Linux

Pour les serveurs Linux, en fonction des fonctionnalités que vous souhaitez exécuter, vous pouvez créer un compte d’utilisateur de l’une des deux manières suivantes.

Option 1 :

Vous devez disposer d’un compte d’utilisateur sudo sur les serveurs que vous souhaitez découvrir. Utilisez ce compte pour :
- extraire les métadonnées de configuration et de performances ;
- effectuer l’inventaire logiciel (découverte d’applications installées) ;
- activer l’analyse des dépendances sans agent à l’aide de la connectivité SSH (Secure Shell).
Vous devez activer l’accès sudo sur /usr/bin/bash pour exécuter les commandes répertoriées dans Métadonnées du serveur Linux. En plus de ces commandes, le compte d’utilisateur doit également disposer des autorisations nécessaires pour exécuter des commandes ls et netstat pour effectuer une analyse des dépendances sans agent.
Assurez-vous d’activer NOPASSWD pour que le compte exécute les commandes requises sans demander un mot de passe à chaque fois que la commande sudo est appelée.

Azure Migrate and Modernize prendre en charge les distributions de système d’exploitation Linux suivante pour la découverte à l’aide d’un compte avec accès sudo :

Système d’exploitation	Versions
Red Hat Enterprise Linux	5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x
Ubuntu	12.04, 14.04, 16.04, 18.04, 20.04, 22.04
Oracle Linux	6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5
SUSE Linux	10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3
Debian	7, 8, 9, 10, 11
Amazon Linux	2.0.2021
CoreOS Container	2345.3.0

Remarque

Si vous souhaitez effectuer un inventaire logiciel (détection des applications installées) et activer l’analyse des dépendances sans agent sur les serveurs Linux, il est recommandé d’utiliser l’option 1.

Option 2 :

Si vous ne pouvez pas fournir le compte racine ou le compte d’utilisateur avec un accès sudo, vous pouvez définir la clé de Registre isSudo sur la valeur 0 dans le registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance sur le serveur de l’appliance. Fournissez un compte non racine doté des fonctionnalités requises à l’aide des commandes suivantes :

Commande	Objectif
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk	Collecter les données de configuration du disque.
setcap "cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid, cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin, cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm	Collecter les données de performances du disque.
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode	Collecter le numéro de série du BIOS.
chmod a+r /sys/class/dmi/id/product_uuid	Collecte le GUID du BIOS.

Pour effectuer une analyse des dépendances sans agent sur le serveur, assurez-vous de définir également les autorisations requises sur les fichiers /bin/netstat et /bin/ls à l’aide des commandes suivantes :
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat

Conditions requises de l’appliance Azure Migrate

Azure Migrate utilise l’appliance Azure Migrate pour la découverte et l’évaluation. L’appliance pour les serveurs physiques peut s’exécuter sur une machine virtuelle ou sur un serveur physique.

En savoir plus sur les conditions requises de l’appliance pour les serveurs physiques.
En savoir plus sur les URL auxquelles l’appliance doit accéder dans les clouds publics et gouvernementaux.
Utilisez un script PowerShell que vous téléchargez à partir du Portail Azure afin de configurer l’appliance.
Utilisez ce script pour déployer l’appliance dans Azure Government.

Accès au port

Le tableau suivant résume les exigences du port pour l’évaluation.

Appareil Connexion

Appliance Connexions entrantes sur le port TCP 3389 pour permettre des connexions Bureau à distance avec l’appliance.

Connexions entrantes sur le port 44368 pour accéder à distance à l’application de gestion de l’appliance à l’aide de l’URL https://<appliance-ip-or-name>:44368.

Connexions sortantes sur le port 443 (HTTPS) pour envoyer les métadonnées de découverte et de performances à Azure Migrate and Modernize.

Serveurs physiques Windows : Connexion entrante sur le port WinRM 5985 (HTTP) pour extraire les métadonnées de configuration et de performances des serveurs Windows.

Linux : Connexions entrantes sur le port 22 (TCP) pour extraire les métadonnées de configuration et de performances des serveurs Linux.

Appareil	Connexion
Appliance	Connexions entrantes sur le port TCP 3389 pour permettre des connexions Bureau à distance avec l’appliance. Connexions entrantes sur le port 44368 pour accéder à distance à l’application de gestion de l’appliance à l’aide de l’URL `https://<appliance-ip-or-name>:44368`. Connexions sortantes sur le port 443 (HTTPS) pour envoyer les métadonnées de découverte et de performances à Azure Migrate and Modernize.
Serveurs physiques	Windows : Connexion entrante sur le port WinRM 5985 (HTTP) pour extraire les métadonnées de configuration et de performances des serveurs Windows. Linux : Connexions entrantes sur le port 22 (TCP) pour extraire les métadonnées de configuration et de performances des serveurs Linux.

Exigences pour l’inventaire des logiciels

Outre la découverte des serveurs, Azure Migrate : découverte et évaluation peuvent exécuter l’inventaire des logiciels sur les serveurs. L’inventaire logiciel fournit la liste des applications, des rôles et des fonctionnalités exécutés sur les serveurs Windows et Linux, découverts en utilisant Azure Migrate and Modernize. Il vous aide à identifier et à planifier un chemin de migration adapté à vos charges de travail locales.

Support	Détails
Serveurs pris en charge	Vous pouvez effectuer un inventaire logiciel sur un maximum de 1 000 serveurs découverts à partir de chaque appliance Azure Migrate.
Systèmes d’exploitation	Les serveurs fonctionnant sous toutes les versions de Windows et de Linux qui répondent à la configuration requise du serveur et qui disposent des autorisations d’accès requises sont pris en charge.
Configuration requise au niveau du serveur	La fonction de communication à distance PowerShell doit être activée et la version 2.0 ou ultérieure de PowerShell doit être installée sur les serveurs Windows. WMI doit être activé et disponible sur les serveurs Windows pour recueillir les détails des rôles et fonctionnalités installés sur les serveurs. La connectivité SSH doit être activée sur les serveurs Linux et les commandes suivantes doivent pouvoir être exécutées sur les serveurs Linux pour extraire les données de l’application : list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Selon le type de système d’exploitation et le type de gestionnaire de package utilisé, voici quelques commandes supplémentaires : rpm/snap/dpkg, yum/apt-cache, mssql-server.
Accès au serveur Windows	Compte d’utilisateur invité pour les serveurs Windows.
Accès au serveur Linux	Compte d’utilisateur standard (accès non-sudo) pour tous les serveurs Linux.
Accès au port	Les serveurs Windows ont besoin d’un accès sur le port 5985 (HTTP). Les serveurs Linux ont besoin d’un accès sur le port 22 (TCP).
Découverte	L’inventaire logiciel est effectué en se connectant directement aux serveurs avec les informations d’identification des serveurs ajoutées sur l’appliance. L’appliance recueille les informations relatives à l’inventaire logiciel auprès des serveurs Windows en utilisant la communication à distance PowerShell, et auprès des serveurs Linux en utilisant une connexion SSH. L’inventaire de logiciels est sans agent. Aucun agent n’est installé sur les serveurs.

Exigences en matière de découverte de base de données et d’instance SQL Server

L’inventaire de logiciels identifie des instances SQL Server. L’appliance tente de se connecter aux diverses instances SQL Server grâce aux informations d’identification pour l’authentification Windows ou SQL Server fournies dans le gestionnaire de configuration de l’appliance, à l’aide de ces informations. L’appliance peut se connecter seulement aux instances SQL Server vers lesquelles elle a une visibilité réseau. L’inventaire logiciel lui-même n’a pas nécessairement besoin d’une visibilité réseau.

Une fois connectée, l’appliance recueille les données de configuration et de performances pour les instances et bases de données SQL Server. L’appliance met à jour les données de configuration SQL Server une fois toutes les 24 heures et capture les données de performances toutes les 30 secondes.

Support	Détails
Serveurs pris en charge	Pris en charge seulement pour les serveurs exécutant SQL Server dans vos environnements VMware, Microsoft Hyper-V et les environnements physiques/nus, et pour les serveurs IaaS (Infrastructure as a Service) d’autres clouds publics, comme AWS et GCP. Vous pouvez découvrir jusqu’à 750 instances SQL Server ou 15 000 bases de données SQL, selon la valeur la plus faible, depuis une seule appliance. Nous vous recommandons de faire en sorte qu’une appliance soit limitée à la découverte de moins de 600 serveurs exécutant SQL, de façon à éviter les problèmes de mise à l’échelle.
Serveurs Windows	Windows Server 2008 et les versions ultérieures sont pris en charge.
Serveurs Linux	Non prise en charge.
Mécanisme d’authentification	Les authentifications Windows et SQL Server sont toutes deux prises en charge. Vous pouvez fournir des informations d’identification des deux types d’authentification dans le gestionnaire de configuration de l’appliance.
Accès à SQL Server	Pour découvrir des instances et des bases de données SQL Server, le compte Windows ou SQL Server doit être membre du rôle serveur sysadmin ou disposer de ces autorisations pour chaque instance SQL Server.
Versions de SQL Server	SQL Server 2008 et les versions ultérieures sont pris en charge.
Éditions de SQL Server	Les éditions Enterprise, Standard, Développeur et Express sont prises en charge.
Configuration de SQL prise en charge	La détection des déploiements SQL autonomes à haute disponibilité et protégés contre les sinistres est prise en charge. La découverte des déploiements SQL à haute disponibilité et de récupération d’urgence avec la technologie des instances de cluster de basculement Always On et des groupes de disponibilité Always On est également prise en charge.
Services SQL pris en charge	Seul le moteur de base de données SQL Server est pris en charge. La découverte de SQL Server Reporting Services, de SQL Server Integration Services et de SQL Server Analysis Services n’est pas prise en charge.

Remarque

Par défaut, Azure Migrate utilise le moyen le plus sécurisé de se connecter à des instances SQL. Ainsi, Azure Migrate and Modernize chiffre les communications entre l’appliance Azure Migrate et les instances SQL Server sources en définissant la propriété TrustServerCertificate sur true. De plus, la couche transport utilise Secure Socket Layer pour chiffrer le canal et contourner la chaîne de certificat pour valider l’approbation. Pour cette raison, le serveur de l’appliance doit être configuré pour approuver l’autorité racine du certificat.

Cependant, vous pouvez modifier les paramètres de connexion en sélectionnant Modifier les propriétés de connexion de SQL Server sur l’appliance. Plus d’informations pour comprendre ce que vous devez choisir.

Utilisez les exemples de scripts suivants pour créer une connexion et y provisionner les autorisations nécessaires.

Authentification Windows

-- Create a login to run the assessment
use master;
DECLARE @SID NVARCHAR(MAX) = N'';
CREATE LOGIN [MYDOMAIN\MYACCOUNT] FROM WINDOWS;
SELECT @SID = N'0x'+CONVERT(NVARCHAR, sid, 2) FROM sys.syslogins where name = 'MYDOMAIN\MYACCOUNT'
IF (ISNULL(@SID,'') != '')
  PRINT N'Created login [MYDOMAIN\MYACCOUNT] with SID = ' + @SID
ELSE
  PRINT N'Login creation failed'
GO    

-- Create user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
  USE [?];
  IF (''?'' NOT IN (''tempdb'',''model''))
  BEGIN
    DECLARE @is_secondary_replica BIT = 0;
    IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
    BEGIN
      DECLARE @innersql NVARCHAR(MAX);
      SET @innersql = N''
        SELECT @is_secondary_replica = IIF(
          EXISTS (
              SELECT 1
              FROM sys.availability_replicas a
              INNER JOIN sys.dm_hadr_database_replica_states b
              ON a.replica_id = b.replica_id
              WHERE b.is_local = 1
              AND b.is_primary_replica = 0
              AND a.secondary_role_allow_connections = 2
              AND b.database_id = DB_ID()
          ), 1, 0
        );
      '';
      EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
    END
    IF (@is_secondary_replica = 0)
    BEGIN
      CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT];
      GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
      GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
    END
  END'
GO

-- Provide server level read-only permissions
use master;
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT];
GO

-- Provide msdb specific permissions
use msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [MYDOMAIN\MYACCOUNT];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; DROP USER [MYDOMAIN\MYACCOUNT]'
-- DROP LOGIN [MYDOMAIN\MYACCOUNT];
--GO

Authentification SQL Server

--- Create a login to run the assessment
use master;
-- NOTE: SQL instances that host replicas of Always On availability groups must use the same SID for the SQL login.
 -- After the account is created in one of the members, copy the SID output from the script and include this value
 -- when executing against the remaining replicas.
 -- When the SID needs to be specified, add the value to the @SID variable definition below.
DECLARE @SID NVARCHAR(MAX) = N'';
IF (@SID = N'')
BEGIN
 CREATE LOGIN [evaluator]
     WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
 DECLARE @SQLString NVARCHAR(500) = 'CREATE LOGIN [evaluator]
   WITH PASSWORD = ''<provide a strong password>''
   , SID = ' + @SID
 EXEC SP_EXECUTESQL @SQLString
END
SELECT @SID = N'0x'+CONVERT(NVARCHAR(100), sid, 2) FROM sys.syslogins where name = 'evaluator'
IF (ISNULL(@SID,'') != '')
 PRINT N'Created login [evaluator] with SID = '''+ @SID +'''. If this instance hosts any Always On Availability Group replica, use this SID value when executing the script against the instances hosting the other replicas'
ELSE
 PRINT N'Login creation failed'
GO

-- Create user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
 USE [?];
 IF (''?'' NOT IN (''tempdb'',''model''))
 BEGIN
   DECLARE @is_secondary_replica BIT = 0;
   IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
   BEGIN
     DECLARE @innersql NVARCHAR(MAX);
     SET @innersql = N''
       SELECT @is_secondary_replica = IIF(
         EXISTS (
           SELECT 1
           FROM sys.availability_replicas a
           INNER JOIN sys.dm_hadr_database_replica_states b
             ON a.replica_id = b.replica_id
           WHERE b.is_local = 1
             AND b.is_primary_replica = 0
             AND a.secondary_role_allow_connections = 2
             AND b.database_id = DB_ID()
         ), 1, 0
       );
     '';
     EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
   END

   IF (@is_secondary_replica = 0)
   BEGIN
       CREATE USER [evaluator] FOR LOGIN [evaluator];
       GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
       GRANT VIEW DATABASE STATE TO [evaluator];
   END
 END'
GO

-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO

-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO

Exigences pour la découverte d’applications web

L’inventaire logiciel identifie le rôle de serveur web existant sur les serveurs découverts. Si un serveur web est installé sur un serveur, Azure Migrate and Modernize découvre les applications web sur le serveur.

Vous pouvez ajouter les informations d’identification de domaine et hors domaine sur l’appliance. Assurez-vous que le compte utilisé dispose de privilèges Administrateur local sur les serveurs sources. Azure Migrate and Modernize mappe automatiquement les informations d’identification aux serveurs respectifs : vous n’avez donc pas à les mapper manuellement. Plus important encore, ces informations d’identification ne sont jamais envoyées à Microsoft et restent sur l’appliance s’exécutant dans l’environnement source.

Une fois que l’appliance est connectée, elle recueille les données de configuration pour les applications web ASP.NET (serveur web IIS) et les applications web Java (serveurs Tomcat). Les données de configuration des applications web sont mises à jour une fois par jour.

Support	Applications web ASP.NET	Applications web Java
Pile	Serveurs VMware, Hyper-V et physiques.	Serveurs VMware, Hyper-V et physiques.
Serveurs Windows	Windows Server 2008 R2 et les versions ultérieures sont pris en charge.	Non pris en charge.
Serveurs Linux	Non pris en charge.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 et Red Hat Enterprise Linux 5/6/7.
Versions de serveur web	IIS 7.5 et versions ultérieures.	Tomcat 8 et versions ultérieures.
Privilèges requis	Administrateur local.	Utilisateur root ou sudo.

Remarque

Les données sont toujours chiffrées au repos et pendant le transit.

Conditions relatives à l’analyse des dépendances (sans agent)

L’analyse des dépendances vous aide à analyser les dépendances entre les serveurs découverts. Vous pouvez facilement visualiser les dépendances avec une vue cartographique dans un projet Azure Migrate. Vous pouvez utiliser des dépendances pour regrouper les serveurs associés pour la migration vers Azure. Le tableau suivant récapitule les conditions requises pour la configuration de l’analyse des dépendances sans agent.

Support	Détails
Serveurs pris en charge	Vous pouvez activer l’analyse des dépendances sans agent sur un maximum de 1 000 serveurs découverts par appliance.
Systèmes d’exploitation	Les serveurs fonctionnant sous toutes les versions de Windows et de Linux qui répondent à la configuration requise du serveur et qui disposent des autorisations d’accès requises sont pris en charge.
Configuration requise au niveau du serveur	La fonction de communication à distance PowerShell doit être activée et la version 2.0 ou ultérieure de PowerShell doit être installée sur les serveurs Windows. La connectivité SSH doit être activée sur les serveurs Linux et les commandes suivantes doivent pouvoir être exécutées sur les serveurs Linux : touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Accès au serveur Windows	Compte d'utilisateur invité
Accès au serveur Linux	Un compte d’utilisateur sudo disposant des autorisations nécessaires pour exécuter les commandes ls et netstat. Si vous fournissez un compte d’utilisateur sudo, veillez à activer NOPASSWD pour que le compte exécute les commandes nécessaires sans demander de mot de passe chaque fois que la commande sudo est appelée. Vous pouvez aussi créer un compte d’utilisateur disposant des autorisations CAP_DAC_READ_SEARCH et CAP_SYS_PTRACE sur les fichiers /bin/netstat et /bin/ls, définies en utilisant les commandes suivantes : `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/ls` `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/netstat`
Accès au port	Les serveurs Windows ont besoin d’un accès sur le port 5985 (HTTP). Les serveurs Linux ont besoin d’un accès sur le port 22 (TCP).
Méthode de détection	L’analyse des dépendances sans agent est effectuée en se connectant directement aux serveurs avec les informations d’identification des serveurs ajoutées sur l’appliance. L’appliance recueille les informations relatives aux dépendances auprès des serveurs Windows en utilisant la communication à distance PowerShell, et auprès des serveurs Linux en utilisant la connexion SSH. Aucun agent n’est installé sur les serveurs pour extraire les données de dépendance.

Conditions requises de l’analyse des dépendances basées sur un agent

L’analyse des dépendances vous permet d’identifier les dépendances entre les machines locales que vous souhaitez évaluer et migrer vers Azure. Le tableau suivant récapitule les conditions requises pour la configuration de l’analyse des dépendances basées sur un agent. Actuellement, seule l’analyse des dépendances basées sur un agent est prise en charge pour les serveurs physiques.

Condition requise	Détails
Avant le déploiement	Vous devez disposer d’un projet, avec l’outil Azure Migrate : Découverte et évaluation ajouté au projet. Vous déployez la visualisation des dépendances après avoir configuré une appliance Azure Migrate pour découvrir vos serveurs locaux. Découvrez comment créer un projet pour la première fois. Découvrez comment ajouter un outil d’évaluation à un projet existant. Découvrez comment configurer l’appliance Azure Migrate pour l’évaluation de serveurs Hyper-V, VMware ou physiques.
Azure Government	La visualisation des dépendances n’est pas disponible dans Azure Government.
Log Analytics	Azure Migrate and Modernize utilise la solution Service Map dans Journaux Azure Monitor pour la visualisation des dépendances. Vous associez un espace de travail Log Analytics nouveau ou déjà existant à un projet. Vous ne pouvez pas modifier l’espace de travail pour un projet après avoir ajouté un espace de travail. L’espace de travail doit se trouver dans le même abonnement que le projet. L’espace de travail doit résider dans les régions USA Est, Asie Sud-Est ou Europe Ouest. Les espaces de travail des autres régions ne peuvent pas être associés à un projet. L’espace de travail doit se trouver dans une région dans laquelle Service Map est pris en charge. Vous pouvez surveiller les machines virtuelles Azure de n’importe quelle région. Les machines virtuelles elles-même ne sont pas limitées aux régions prises en charge par l’espace de travail Log Analytics. Dans Log Analytics, l’espace de travail associé à Azure Migrate and Modernize est étiqueté avec la clé du projet de migration et le nom du projet.
Agents nécessaires	Sur chaque serveur à analyser, installez les agents suivants : - Microsoft Monitoring Agent (MMA) - Agent de dépendances Si les serveurs locaux ne sont pas connectés à Internet, vous devez télécharger et installer la passerelle Log Analytics sur ceux-ci. En savoir plus sur l’installation de Dependency Agent et de MMA.
Espace de travail Log Analytics	L’espace de travail doit se trouver dans le même abonnement qu’un projet. Azure Migrate and Modernize prend en charge les espaces de travail qui se trouvent dans les régions USA Est, Asie Sud-Est et Europe Ouest. L’espace de travail doit se trouver dans une région dans laquelle Service Map est pris en charge. Vous pouvez surveiller les machines virtuelles Azure de n’importe quelle région. Les machines virtuelles elles-même ne sont pas limitées aux régions prises en charge par l’espace de travail Log Analytics. Vous ne pouvez pas modifier l’espace de travail pour un projet après avoir ajouté un espace de travail.
Coûts	La solution Service Map n’entraîne aucun frais durant les 180 premiers jours. Le décompte débute le jour où vous associez l’espace de travail Log Analytics au projet. Au bout de 180 jours, des frais Log Analytics standard s’appliquent. L’utilisation d’une autre solution que Service Map dans l’espace de travail Log Analytics associé entraîne des frais standard pour l’espace de travail Log Analytics. Lorsque le projet est supprimé, l’espace de travail n’est pas supprimé automatiquement. Une fois que vous avez supprimé le projet, l’utilisation de Service Map n’est plus gratuite. Chaque nœud est facturé en fonction du niveau payant de l’espace de travail Log Analytics. Si vous avez créé des projets avant la disponibilité générale d’Azure Migrate (le 28 février 2018), vous pouvez encourir d’autres frais liés à Service Map. Pour garantir que des frais ne vous sont facturés qu’après 180 jours, nous vous recommandons de créer un nouveau projet. Les espaces de travail créés avant la disponibilité générale sont toujours facturables.
Gestion	Lorsque vous inscrivez des agents dans l’espace de travail, utilisez l’ID et la clé fournis par le projet. Vous pouvez utiliser l’espace de travail Log Analytics en dehors d’Azure Migrate and Modernize. Si vous supprimez le projet associé, l’espace de travail n’est pas automatiquement supprimé. Supprimez-le manuellement. Ne supprimez pas l’espace de travail créé par Azure Migrate and Modernize, sauf si vous supprimez le projet. La suppression de l’espace de travail entraînerait un dysfonctionnement de la fonctionnalité de visualisation des dépendances.
Connectivité Internet	Si les serveurs ne sont pas connectés à Internet, installez la passerelle Log Analytics sur ceux-ci.
Azure Government	L'analyse des dépendances basée sur un agent n'est pas prise en charge.

Étapes suivantes

Préparer la découverte de serveurs physiques.

Partager via

Matrice de prise en charge pour la découverte et l’évaluation de serveurs physiques

Limites

Conditions requises des serveurs physiques

Autorisations pour des serveurs Windows

Option 1 :

Option 2 :

Autorisations pour un serveur Linux

Option 1 :

Option 2 :

Conditions requises de l’appliance Azure Migrate

Accès au port

Exigences pour l’inventaire des logiciels

Exigences en matière de découverte de base de données et d’instance SQL Server

Authentification Windows

Authentification SQL Server

Exigences pour la découverte d’applications web

Conditions relatives à l’analyse des dépendances (sans agent)

Conditions requises de l’analyse des dépendances basées sur un agent

Étapes suivantes

Commentaires

Ressources supplémentaires

Partager via

Matrice de prise en charge pour la découverte et l’évaluation de serveurs physiques

Limites

Conditions requises des serveurs physiques

Autorisations pour des serveurs Windows

Option 1 :

Option 2 :

Autorisations pour un serveur Linux

Option 1 :

Option 2 :

Conditions requises de l’appliance Azure Migrate

Accès au port

Exigences pour l’inventaire des logiciels

Exigences en matière de découverte de base de données et d’instance SQL Server

Configurer la connexion personnalisée pour la découverte de SQL Server

Authentification Windows

Authentification SQL Server

Exigences pour la découverte d’applications web

Conditions relatives à l’analyse des dépendances (sans agent)

Conditions requises de l’analyse des dépendances basées sur un agent

Étapes suivantes

Commentaires

Ressources supplémentaires