Unterstützungsmatrix für die Ermittlung und Bewertung physischer Server

Artikel
03/13/2024

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status nähert. Sie sollten Ihre Nutzung entsprechend planen.

Dieser Artikel bietet eine Übersicht über die Voraussetzungen und Unterstützungsanforderungen bei der Bewertung von physischen Servern für die Migration zu Azure mithilfe des Tools Azure Migrate: Ermittlung und Bewertung. Wenn Sie physische Server zu Azure migrieren möchten, schauen Sie sich die Migrationsunterstützungsmatrix an.

Zum Bewerten physischer Server erstellen Sie ein Projekt und fügen dem Projekt das Azure Migrate-Tool zur Ermittlung und Bewertung hinzu. Nachdem Sie das Tool hinzugefügt haben, stellen Sie die Azure Migrate-Appliance bereit. Die Appliance ermittelt kontinuierlich lokale Server und sendet Servermetadaten und Leistungsdaten an Azure. Nach Abschluss der Ermittlung ordnen Sie die ermittelten Server in Gruppen und führen eine Bewertung für die Gruppen aus.

Begrenzungen

Unterstützung	Details
Bewertungseinschränkungen	Sie können bis zu 35.000 physische Server in einem einzelnen Projekt ermitteln und bewerten.
Projekteinschränkungen	Sie können mehrere Projekte in einem Azure-Abonnement erstellen. Zusätzlich zu physischen Servern kann ein Projekt bis zum jeweiligen Bewertungsgrenzwert auch VMware- und Hyper-V-Server enthalten.
Ermittlung	Die Azure Migrate-Appliance kann bis zu 1,000 physische Server ermitteln.
Bewertung	Sie können einer einzelnen Gruppe bis zu 35.000 Server hinzufügen. Sie können bis zu 35.000 Server in einem einzelnen Vorgang bewerten.

Hier erfahren Sie mehr über Bewertungen.

Anforderungen für physische Server

Bereitstellung eines physischen Servers: Der physische Server kann eigenständig oder in einem Cluster bereitgestellt werden.
Servertyp: Bare-Metal-Server, virtualisierte Server, die lokal ausgeführt werden, oder andere Clouds wie Amazon Web Services (AWS), Google Cloud Platform (GCP) und Xen.

Hinweis

Derzeit unterstützt Azure Migrate die Ermittlung paravirtualisierter Server nicht.
Betriebssystem: Alle Windows- und Linux-Betriebssysteme können für die Migration bewertet werden.

Berechtigungen für Windows-Server

Verwenden Sie für Windows-Server ein Domänenkonto für in die Domäne eingebundene Server und ein lokales Konto für nicht in die Domäne eingebundene Server.
Geben Sie bei der physischen Ermittlung den Benutzernamen im Format der Unterebene (Domäne\Benutzername) an, und das UPN-Format (username@domain.com) ist nicht unterstützt.

Sie können das Benutzerkonto auf eine der folgenden beiden Arten erstellen.

Option 1:

Erstellen Sie ein Konto mit Administratorrechten auf den Servern. Verwenden Sie dieses Konto für:

Pullkonfigurations- und Leistungsdaten über eine Common Information Model (CIM)-Verbindung.
Führen Sie eine Softwareinventur aus (Ermittlung installierter Anwendungen).
Aktivieren Sie die Abhängigkeitsanalyse ohne Agent mithilfe von PowerShell-Remoting.

Hinweis

Wenn Sie die Softwareinventur (Ermittlung installierter Anwendungen) durchführen und die Abhängigkeitsanalyse ohne Agent auf Windows-Servern aktivieren möchten, empfiehlt sich, dass Sie die Option 1 verwenden.

Option 2:

Fügen Sie das Benutzerkonto den folgenden Gruppen hinzu: „Remoteverwaltungsbenutzer“, „Systemmonitorbenutzer“ und „Leistungsprotokollbenutzer“.
Wenn die Gruppe „Remoteverwaltungsbenutzer“ nicht vorhanden ist, fügen Sie der Gruppe WinRMRemoteWMIUsers_ das folgende Benutzerkonto hinzu.
Das Konto benötigt diese Berechtigungen, damit die Appliance eine CIM-Verbindung mit dem Server herstellen und die erforderlichen Konfigurations- und Leistungsmetadaten aus den hier aufgeführten Windows-Verwaltungsinstrumentation (WMI)-Klassen pullen kann.
In einigen Fällen gibt das Hinzufügen des Kontos zu diesen Gruppen möglicherweise nicht die erforderlichen Daten aus WMI-Klassen zurück. Das Konto kann nach Benutzerkontensteuerung (User Account Control, UAC) gefiltert werden. Um die UAC-Filterung außer Kraft zu setzen, muss das Benutzerkonto über die erforderlichen Berechtigungen für den CIMV2-Namespace und die untergeordneten Namespaces auf dem Zielserver verfügen. Informationen zum Aktivieren der erforderlichen Berechtigungen finden Sie unter Problembehandlung für die Azure Migrate-Appliance.

Hinweis

Stellen Sie für Windows Server 2008 und 2008 R2 sicher, dass Windows Management Framework 3.0 auf den Servern installiert ist.

Um SQL Server-Datenbanken auf Windows-Servern zu entdecken, werden sowohl die Windows- als auch die SQL Server-Authentifizierung unterstützt. Sie können im Appliance-Konfigurations-Manager Anmeldeinformationen für beide Authentifizierungstypen angeben. Für Azure Migrate ist ein Windows-Benutzerkonto erforderlich, das Mitglied der Sysadmin-Serverrolle ist.

Berechtigungen für Linux-Server

Für Linux-Server können Sie basierend auf den Features, die Sie verwenden möchten, ein Benutzerkonto auf eine von zwei der folgenden Arten erstellen.

Option 1:

Sie benötigen ein sudo-Benutzerkonto auf den Servern, die Sie ermitteln möchten. Verwenden Sie dieses Konto für:
- Pullkonfigurations- und Leistungsmetadaten.
- Führen Sie eine Softwareinventur aus (Ermittlung installierter Anwendungen).
- Aktivieren Sie die Abhängigkeitsanalyse ohne Agent mithilfe der SSH-Konnektivität (Secure Shell).
Sie müssen den sudo-Zugriff in /usr/bin/bash aktivieren, um die in Linux Servermetadaten aufgeführten Befehle auszuführen. Zusätzlich zu diesen Befehlen muss das Benutzerkonto auch die Berechtigung zum Ausführen der Befehle „ls“ und „netstat“ haben, um eine Abhängigkeitsanalyse ohne Agent durchzuführen.
Stellen Sie sicher, dass Sie NOPASSWD für das Konto aktivieren, um die erforderlichen Befehle auszuführen, ohne bei jedem Aufruf des sudo-Befehls ein Kennwort eingeben zu müssen.

Azure Migrate and Modernize unterstützt die folgenden Linux-Betriebssystemdistributionen für die Ermittlung mit einem Konto mit sudo-Zugriff:

Betriebssystem	Versionen
Red Hat Enterprise Linux	5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x
CentOS	5.1, 5.9, 5.11, 6.x, 7.x, 8.x
Ubuntu	12.04, 14.04, 16.04, 18.04, 20.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

Hinweis

Wenn Sie die Softwareinventur (Ermittlung installierter Anwendungen) durchführen und die Abhängigkeitsanalyse ohne Agent auf Linux-Servern aktivieren möchten, empfiehlt sich, dass Sie die Option 1 verwenden.

Option 2:

Wenn Sie das Stammkonto oder das Benutzerkonto nicht mit sudo-Zugriff bereitstellen können, können Sie den isSudo Registrierungsschlüssel auf den Wert 0 in der Registrierung HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance auf dem Appliance-Server festlegen. Stellen Sie ein Nonroot-Konto mit den erforderlichen Funktionen bereit, indem Sie die folgenden Befehle verwenden:

Get-Help	Zweck
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk	Erfasst Datenträgerkonfigurationsdaten.
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	Erfasst Datenträgerleistungsdaten.
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode	Erfasst BIOS-Seriennummer.
chmod a+r /sys/class/dmi/id/product_uuid	Erfasst BIOS-GUID.

Für die Abhängigkeitsanalyse ohne Agent auf dem Server müssen mithilfe der folgenden Befehle auch die erforderlichen Berechtigungen für Dateien in „/bin/netstat“ und „/bin/ls“ festgelegt werden:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat

Anforderungen für die Azure Migrate-Appliance

In Azure Migrate erfolgt die Ermittlung und Bewertung über die Azure Migrate-Appliance. Die Appliance für physische Server kann auf einem virtuellen Computer (VM) oder auf einem physischen Server ausgeführt werden.

Informationen zu den Applianceanforderungen für physische Server finden Sie hier.
Informationen zu den URLs, auf die die Appliance Zugriff benötigt, finden Sie unter URLs für die öffentliche Cloud und URLs für Azure Government-Clouds.
Die Einrichtung der Appliance erfolgt mithilfe eines PowerShell-Skripts, das Sie im Azure-Portal herunterladen.
Verwenden Sie dieses Skript, um die Appliance in Azure Government bereitzustellen.

Portzugriff

Die folgende Tabelle fasst die Portanforderungen für die Bewertung zusammen.

Sicherungsmedium Verbindung

Appliance Eingehende Verbindungen an TCP-Port 3389, um Remotedesktopverbindungen mit der Appliance zu ermöglichen

Eingehende Verbindungen an Port 44368, um über Remotezugriff über die URL https://<appliance-ip-or-name>:44368 auf die Applianceverwaltungs-App zugreifen zu können.

Ausgehende Verbindungen an Port 443 (HTTPS), um Ermittlungs- und Leistungsmetadaten an Azure Migrate and Modernize zu senden.

Physische Server Windows: Eingehende Verbindungen am WinRM-Port 5985 (HTTP) zum Pullen von Konfigurations- und Leistungsmetadaten von Windows-Servern.

Linux: Eingehende Verbindungen an Port 22 (TCP) zum Abrufen von Konfigurations- und Leistungsmetadaten von Linux-Servern.

Sicherungsmedium	Verbindung
Appliance	Eingehende Verbindungen an TCP-Port 3389, um Remotedesktopverbindungen mit der Appliance zu ermöglichen Eingehende Verbindungen an Port 44368, um über Remotezugriff über die URL `https://<appliance-ip-or-name>:44368` auf die Applianceverwaltungs-App zugreifen zu können. Ausgehende Verbindungen an Port 443 (HTTPS), um Ermittlungs- und Leistungsmetadaten an Azure Migrate and Modernize zu senden.
Physische Server	Windows: Eingehende Verbindungen am WinRM-Port 5985 (HTTP) zum Pullen von Konfigurations- und Leistungsmetadaten von Windows-Servern. Linux: Eingehende Verbindungen an Port 22 (TCP) zum Abrufen von Konfigurations- und Leistungsmetadaten von Linux-Servern.

Softwareinventarisierungsanforderungen

Zusätzlich zur Ermittlung von Servern kann die Azure Migrate-Ermittlung und -Bewertung Softwareinventarisierung für Server ausführen. Die Softwareinventur liefert die Liste der Anwendungen, Rollen und Features, die auf Windows- und Linux-Servern ausgeführt werden und mithilfe von Azure Migrate and Modernize ermittelt werden. Sie hilft bei der Ermittlung und Planung eines maßgeschneiderten Migrationspfads für Ihre lokalen Workloads.

Unterstützung	Details
Unterstützte Server	Die Softwareinventur kann auf bis zu 1.000 Servern durchgeführt werden, die von den einzelnen Azure Migrate-Appliances ermittelt wurden.
Betriebssysteme	Server mit beliebigen Windows- oder Linux-Versionen, die die Serveranforderungen erfüllen und über die erforderlichen Zugriffsberechtigungen verfügen, werden unterstützt.
Serveranforderungen	Auf Windows-Servern muss PowerShell-Remoting aktiviert und PowerShell ab Version 2.0 installiert sein. WMI muss aktiviert und auf Windows-Servern verfügbar sein, um die Details der auf den Servern installierten Rollen und Features zu erfassen. Für Linux-Server muss SSH-Konnektivität aktiviert und sichergestellt sein, dass die folgenden Befehle auf den Linux-Servern ausgeführt werden können, um die Anwendungsdaten zu pullen: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Je nach Betriebssystemtyp und dem Typ des Paket-Managers gibt es noch einige zusätzliche Befehle: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Windows-Serverzugriff	Ein Gastbenutzerkonto für Windows-Server.
Linux-Serverzugriff	Ein Standardbenutzerkonto (ohne sudo-Zugriff) für alle Linux-Server.
Portzugriff	Windows-Server benötigen Zugriff auf Port 5985 (HTTP). Linux-Server benötigen Zugriff auf Port 22 (TCP).
Ermittlung	Die Softwareinventarisierung erfolgt durch direkte Verbindung mit den Servern unter Verwendung der auf der Appliance hinzugefügten Server-Anmeldeinformationen. Die Appliance sammelt die Informationen zum Softwarebestand von Windows-Servern mithilfe von PowerShell-Remoting und von Linux-Servern mithilfe der SSH-Verbindung. Softwareinventarisierung erfolgt ohne Agent. Auf den Servern wird kein Agent installiert.

SQL Server-Instanz- und -Datenbank-Ermittlungsanforderungen

Bei der Softwareinventarisierung werden SQL Server-Instanzen identifiziert. Die Appliance versucht mithilfe der im Konfigurations-Manager der Appliance angegebenen Anmeldeinformationen für die Windows-Authentifizierung oder die SQL Server-Authentifizierung eine Verbindung mit den entsprechenden SQL Server-Instanzen herzustellen. Die Appliance kann sich nur mit den SQL Server-Instanzen verbinden, zu denen sie eine Netzwerk-Sichtverbindung hat. Für die Softwareinventur selbst ist eventuell keine Netzwerk-Sichtverbindung erforderlich.

Sobald die Appliance verbunden ist, sammelt sie Konfigurations- und Leistungsdaten für SQL Server-Instanzen und -Datenbanken. Die Appliance aktualisiert die SQL Server-Konfigurationsdaten einmal alle 24 Stunden und erfasst die Leistungsdaten alle 30 Sekunden.

Unterstützung	Details
Unterstützte Server	Wird nur für Server unterstützt, auf denen SQL Server in Ihren VMware-, Microsoft Hyper-V- und physischen/Bare-Metal-Umgebungen und Infrastruktur-as-a-Service (IaaS)-Servern anderer öffentlicher Clouds ausgeführt wird, z. B. AWS und GCP. Sie können bis zu 750 SQL Server-Instanzen oder 15.000 SQL-Datenbanken aus einer einzelnen Appliance ermitteln, je nachdem, welcher Wert kleiner ist. Es wird empfohlen, sicherzustellen, dass eine Appliance auf die Ermittlung von weniger als 600 Servern beschränkt ist, auf denen SQL ausgeführt wird, um Skalierungsprobleme zu vermeiden.
Windows-Server	Windows Server 2008 oder höher wird unterstützt.
Linux-Server	Wird derzeit nicht unterstützt.
Authentifizierungsmechanismus	Sowohl Windows- als auch SQL Server-Authentifizierung werden unterstützt. Sie können im Appliance-Konfigurations-Manager Anmeldeinformationen für beide Authentifizierungstypen angeben.
SQL-Serverzugriff	Um SQL Server-Instanzen und -Datenbanken zu ermitteln, muss das Windows- oder SQL Server-Konto Mitglied der Serverrolle Systemadministrator sein oder über diese Berechtigungen für jede SQL Server-Instanz verfügen.
SQL Server-Versionen	SQL Server 2008 oder höher wird unterstützt.
SQL Server-Editionen	Die Enterprise, Standard, Developer und Express Edition werden unterstützt.
Unterstützte SQL-Konfiguration	Die Ermittlung eigenständiger, hochverfügbarer und notfallgeschützter SQL-Bereitstellungen wird unterstützt. Die Ermittlung von SQL-Bereitstellungen mit Hochverfügbarkeit und Notfallwiederherstellung, die von Always On-Failoverclusterinstanzen und Always On-Verfügbarkeitsgruppen wird ebenfalls unterstützt.
Unterstützte SQL-Dienste	Nur die SQL Server-Datenbank-Engine wird unterstützt. Die Ermittlung von SQL Server Reporting Services, SQL Server Integration Services und SQL Server Analysis Services wird nicht unterstützt.

Hinweis

Azure Migrate verwendet standardmäßig die sicherste Verbindungsart zu SQL-Instanzen. Das heißt, Azure Migrate and Modernize verschlüsselt die Kommunikation zwischen der Azure Migrate-Appliance und den SQL Server-Quellinstanzen durch Festlegen der TrustServerCertificate-Eigenschaft auf true. Zudem verwendet die Transportschicht Secure Socket Layer zum Verschlüsseln des Kanals und Umgehen der Zertifikatkette zur Überprüfung der Vertrauenswürdigkeit. Deshalb muss der Applianceserver so eingerichtet sein, dass er die Stammzertifizierungsstelle des Zertifikats als vertrauenswürdig einstuft.

Sie können die Verbindungseinstellungen jedoch ändern, indem Sie in der Appliance SQL Server-Verbindungseigenschaften bearbeiten auswählen. Hier erfahren Sie mehr, um zu verstehen, was Sie auswählen müssen.

Verwenden Sie die folgenden Beispielskripte zum Erstellen einer Anmeldung und Bereitstellen mit den erforderlichen Berechtigungen.

Windows-Authentifizierung

-- 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

SQL Server-Authentifizierung

--- 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

Anforderungen für die Erkennung von Web-Apps

Die Softwareinventarisierung identifiziert die Webserverrolle, die auf entdeckten Servern vorhanden ist. Wenn auf einem Server ein Webserver installiert ist, erkennt Azure Migrate and Modernize Web-Apps auf dem Server.

Sie können sowohl Domänen- als auch Nicht-Domänen-Anmeldeinformationen auf der Appliance hinzufügen. Stellen Sie sicher, dass das verwendete Konto über lokale Administratorrechte auf den Quellservern verfügt. Azure Migrate and Modernize ordnet Anmeldeinformationen automatisch den jeweiligen Servern zu, sodass Sie diese nicht manuell zuordnen müssen. Am wichtigsten ist, dass diese Anmeldeinformationen niemals an Microsoft gesendet werden und auf der Appliance verbleiben, die in der Quellumgebung ausgeführt wird.

Nachdem die Appliance verbunden wurde, sammelt sie Konfigurationsdaten für ASP.NET-Web-Apps (IIS-Webserver) und Java-Web-Apps (Tomcat-Server). Konfigurationsdaten von Web-Apps werden alle 24 Stunden aktualisiert.

Unterstützung	ASP.NET-Web-Apps	Java-Web-Apps
Stapel	VMware-, Hyper-V- und physische Server.	VMware-, Hyper-V- und physische Server.
Windows-Server	Windows Server 2008 R2 oder höher wird unterstützt.	Wird nicht unterstützt.
Linux-Server	Wird nicht unterstützt.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7 und Red Hat Enterprise Linux 5/6/7.
Webserverversion	IIS 7.5 und höher.	Tomcat 8 oder höher.
Erforderliche Privilegien	Lokaler Administrator.	Root- oder sudo-Benutzer.

Hinweis

Daten werden im Ruhezustand und während der Übertragung immer verschlüsselt.

Anforderungen der Abhängigkeitsanalyse (ohne Agent)

Die Abhängigkeitsanalyse hilft Ihnen, die Abhängigkeiten zwischen den ermittelten Servern zu analysieren. Sie können Abhängigkeiten einfach mit einer Zuordnungsansicht in einem Azure Migrate-Projekt visualisieren. Sie können Abhängigkeiten verwenden, um zusammenhängende Server für die Migration zu Azure zu gruppieren. In der folgenden Tabelle werden die Anforderungen zum Einrichten der Abhängigkeitsanalyse ohne Agent zusammengefasst.

Unterstützung	Details
Unterstützte Server	Sie können die Abhängigkeitsanalyse ohne Agent auf bis zu 1,000 Servern aktivieren, die pro Appliance ermittelt werden.
Betriebssysteme	Server mit beliebigen Windows- oder Linux-Versionen, die die Serveranforderungen erfüllen und über die erforderlichen Zugriffsberechtigungen verfügen, werden unterstützt.
Serveranforderungen	Auf Windows-Servern muss PowerShell-Remoting aktiviert und PowerShell ab Version 2.0 installiert sein. Für Linux-Server muss SSH-Konnektivität aktiviert und sichergestellt sein, dass die folgenden Befehle auf den Linux-Servern ausgeführt werden können: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Windows-Serverzugriff	Ein Benutzerkonto (lokal oder Domänenkonto) mit Administratorberechtigungen für Server.
Linux-Serverzugriff	Ein sudo-Benutzerkonto mit Berechtigungen zum Ausführen der Befehle „ls“ und „netstat“. Wenn Sie ein sudo-Benutzerkonto bereitstellen, stellen Sie sicher, dass Sie NOPASSWD für das Konto aktiviert haben, um die erforderlichen Befehle auszuführen, ohne bei jedem Aufruf des sudo-Befehls ein Kennwort eingeben zu müssen. Alternativ können Sie ein Benutzerkonto erstellen, das die Berechtigungen CAP_DAC_READ_SEARCH und CAP_SYS_PTRACE für die Dateien „/bin/netstat“ und „/bin/ls“ hat, die mit den folgenden Befehlen festgelegt werden: `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`
Portzugriff	Windows-Server benötigen Zugriff auf Port 5985 (HTTP). Linux-Server benötigen Zugriff auf Port 22 (TCP).
Discovery-Methode	Eine Abhängigkeitsanalyse ohne Agent wird durchgeführt, indem unter Verwendung der Serveranmeldeinformationen, die auf der Appliance hinzugefügt wurden, eine direkte Verbindung mit den Servern hergestellt wird. Die Appliance sammelt die Abhängigkeitsinformationen von Windows-Servern mithilfe von PowerShell-Remoting und von Linux-Servern mithilfe der SSH-Verbindung. Auf den Servern wird kein Agent zum Pullen von Abhängigkeitsdaten installiert.

Anforderungen der Agent-basierten Abhängigkeitsanalyse

Mit der Abhängigkeitsanalyse können Sie Abhängigkeiten zwischen lokalen Servern identifizieren, die Sie bewerten und zu Azure migrieren möchten. In der folgenden Tabelle werden die Anforderungen zum Einrichten der Agent-basierten Abhängigkeitsanalyse zusammengefasst. Für physische Server wird derzeit nur die Abhängigkeitsanalyse mit Agent unterstützt.

Anforderung	Details
Vor der Bereitstellung	Sie sollten über ein Projekt verfügen, dem das Azure Migrate-Tool zur Ermittlung und Bewertung hinzugefügt wurde. Sie stellen die Abhängigkeitsvisualisierung nach dem Einrichten einer Azure Migrate-Appliance zum Ermitteln Ihrer lokalen Server bereit. Erfahren Sie, wie Sie erstmalig ein Projekt erstellen. Erfahren Sie, wie Sie einem vorhandenen Projekt ein Bewertungstool hinzufügen. Erfahren Sie, wie Sie eine Azure Migrate-Appliance für die Bewertung von Hyper-V-, VMware- oder physischen Servern einrichten.
Azure Government	Abhängigkeitsvisualisierung ist in Azure Government nicht verfügbar.
Log Analytics	Azure Migrate and Modernize verwendet für die Abhängigkeitsvisualisierung die Dienstzuordnung in Azure Monitor-Protokolle. Sie ordnen einem Projekt einen neuen oder vorhandenen Log Analytics-Arbeitsbereich zu. Sie können den Arbeitsbereich für ein Projekt nicht ändern, nachdem Sie den Arbeitsbereich hinzugefügt haben. Der Arbeitsbereich muss sich in demselben Abonnement befinden wie das Projekt. Der Arbeitsbereich muss sich in einer der Regionen „USA, Osten“, „Asien, Südosten“ oder „Europa, Westen“ befinden. Arbeitsbereiche in anderen Regionen können keinem Projekt zugeordnet werden. Der Arbeitsbereich muss sich in einer Region befinden, in der Dienstzuordnung unterstützt wird. Sie können Azure-VMs in jeder Region überwachen. Die VMs selbst sind nicht auf die vom Log Analytics-Arbeitsbereich unterstützten Bereiche beschränkt. In Log Analytics wird der Arbeitsbereich, der Azure Migrate and Modernize zugeordnet ist, mit dem Schlüssel des Migrationsprojekts und dem Projektnamen gekennzeichnet.
Erforderliche Agents	Installieren Sie auf jedem Server, den Sie analysieren möchten, die folgenden Agents: - Microsoft Monitoring Agent (MMA) - Dependency-Agent Wenn lokale Server nicht mit dem Internet verbunden sind, müssen Sie das Log Analytics-Gateway auf diesen Servern herunterladen und installieren. Erfahren Sie mehr über das Installieren von Dependency-Agent und MMA.
Log Analytics-Arbeitsbereich	Der Arbeitsbereich muss sich in demselben Abonnement befinden wie das Projekt. Azure Migrate and Modernize unterstützt Arbeitsbereiche, die sich in den Regionen „USA, Osten“, „Asien, Südosten“ und „Europa, Westen“ befinden. Der Arbeitsbereich muss sich in einer Region befinden, in der Dienstzuordnung unterstützt wird. Sie können Azure-VMs in jeder Region überwachen. Die VMs selbst sind nicht auf die vom Log Analytics-Arbeitsbereich unterstützten Bereiche beschränkt. Sie können den Arbeitsbereich für ein Projekt nicht ändern, nachdem Sie den Arbeitsbereich hinzugefügt haben.
Kosten	Die Dienstzuordnungslösung verursacht in den ersten 180 Tagen keine Gebühren. Die Zählung beginnt an dem Tag, an dem Sie den Log Analytics-Arbeitsbereich mit dem Projekt verknüpfen. Nach 180 Tagen fallen die Log Analytics-Standardgebühren an. Für andere Lösungen als die Dienstzuordnung im zugeordneten Log Analytics-Arbeitsbereich fallen die Standardgebühren für Log Analytics an. Beim Löschen des Projekts wird der Arbeitsbereich nicht automatisch gelöscht. Nachdem Sie das Projekt gelöscht haben, ist die Nutzung der Dienstzuordnung nicht mehr kostenlos. Jeder Knoten wird gemäß der kostenpflichtigen Stufe des Log Analytics-Arbeitsbereichs in Rechnung gestellt. Wenn Sie über Projekte verfügen, die Sie vor der allgemeinen Verfügbarkeit von Azure Migrate (28. Februar 2018) erstellt haben, fallen für Sie möglicherweise zusätzliche Gebühren für die Dienstzuordnung an. Um sicherzustellen, dass erst nach 180 Tagen Gebühren anfallen, empfehlen wir Ihnen, ein neues Projekt zu erstellen. Arbeitsbereiche, die vor der allgemeinen Verfügbarkeit erstellt wurden, sind weiterhin kostenpflichtig.
Verwaltung	Wenn Sie Agents im Arbeitsbereich registrieren, verwenden Sie die ID und den Schlüssel, die vom Projekt bereitgestellt werden. Sie können den Log Analytics-Arbeitsbereich außerhalb von Azure Migrate und Modernize verwenden. Wenn Sie das zugehörige Projekt löschen, wird der Arbeitsbereich nicht automatisch gelöscht. Löschen Sie ihn manuell. Löschen Sie den von Azure Migrate and Modernize erstellten Arbeitsbereich nur, wenn Sie auch das Projekt löschen. Wenn Sie anders vorgehen, funktioniert die Abhängigkeitsvisualisierung nicht wie erwartet.
Internetkonnektivität	Wenn Server nicht mit dem Internet verbunden sind, installieren Sie das Log Analytics-Gateway auf diesen Servern.
Azure Government	Die Agent-basierte Abhängigkeitsanalyse wird nicht unterstützt.

Nächste Schritte

Vorbereitung auf die physische Ermittlung und Bewertung.

Unterstützungsmatrix für die Ermittlung und Bewertung physischer Server

Begrenzungen

Anforderungen für physische Server

Berechtigungen für Windows-Server

Option 1:

Option 2:

Berechtigungen für Linux-Server

Option 1:

Option 2:

Anforderungen für die Azure Migrate-Appliance

Portzugriff

Softwareinventarisierungsanforderungen

SQL Server-Instanz- und -Datenbank-Ermittlungsanforderungen

Konfigurieren der benutzerdefinierten Anmeldung für die SQL Server-Ermittlung

Windows-Authentifizierung

SQL Server-Authentifizierung

Anforderungen für die Erkennung von Web-Apps

Anforderungen der Abhängigkeitsanalyse (ohne Agent)

Anforderungen der Agent-basierten Abhängigkeitsanalyse

Nächste Schritte

Zusätzliche Ressourcen