Dela via


Stödmatris för Hyper-V-utvärdering

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som närmar sig slutstatus. Överväg att använda och planera i enlighet med detta.

Den här artikeln sammanfattar krav och supportkrav när du identifierar och utvärderar lokala servrar som körs i en Hyper-V-miljö för migrering till Azure med hjälp av verktyget Azure Migrate: Discovery och utvärdering . Om du vill migrera servrar som körs på Hyper-V till Azure läser du matrisen för migreringsstöd.

Om du vill konfigurera identifiering och utvärdering av servrar som körs på Hyper-V skapar du ett projekt och lägger till verktyget Azure Migrate: Discovery och utvärdering i projektet. När verktyget har lagts till distribuerar du Azure Migrate-installationen. Installationen identifierar kontinuerligt lokala servrar och skickar servermetadata och prestandadata till Azure. När identifieringen är klar samlar du in identifierade servrar i grupper och kör en utvärdering för en grupp.

Begränsningar

Support Information
Utvärderingsgränser Du kan identifiera och utvärdera upp till 35 000 servrar i ett enda projekt.
Projektgränser Du kan skapa flera projekt i en Azure-prenumeration. Förutom servrar på Hyper-V kan ett projekt innehålla servrar på VMware och fysiska servrar, upp till utvärderingsgränserna för var och en.
Identifiering Azure Migrate-installationen kan identifiera upp till 5 000 servrar som körs på Hyper-V.

Enheten kan ansluta till upp till 300 Hyper-V-värdar.
Utvärdering Du kan lägga till upp till 35 000 servrar i en enda grupp.

Du kan utvärdera upp till 35 000 servrar i en enda utvärdering för en grupp.

Läs mer om utvärderingar.

Förutsättningar för Hyper-V-värdar

Support Details
Hyper-V-värd Hyper-V-värden kan vara fristående eller distribueras i ett kluster.

Hyper-V-värden kan köra Windows Server 2022, Windows Server 2019, Windows Server 2016 eller Windows Server 2012 R2. Serverkärninstallationer av dessa operativsystem stöds också.
Du kan inte utvärdera servrar som finns på Hyper-V-värdar som kör Windows Server 2012.
Behörigheter Du behöver administratörsbehörighet på Hyper-V-värden.
Om du inte vill tilldela administratörsbehörigheter skapar du ett lokalt användarkonto eller domänanvändarkonto och lägger till användarkontot i dessa grupper: Fjärrhanteringsanvändare, Hyper-V-administratörer och Prestandaövervakare.
PowerShell-fjärranvändning PowerShell-fjärrkommunikation måste vara aktiverat på varje Hyper-V-värd.
Hyper-V-replikering Om du använder Hyper-V-replik (eller om du har flera servrar med samma serveridentifierare) och du identifierar både de ursprungliga och replikerade servrarna med hjälp av Azure Migrate och Modernize kanske utvärderingen som genereras av Azure Migrate och Modernize inte är korrekt.

Serverkrav

Support Details
Operativsystem Alla operativsystem kan utvärderas för migrering.
Integration Services Hyper-V Integration Services måste köras på servrar som du bedömer för att samla in information om operativsystemet.
Lagring Lokal disk, DAS, JBOD, Lagringsutrymmen, CSV och SMB. Dessa Hyper-V-värdlagringar som VHD/VHDX lagras på stöds.
Virtuella IDE- och SCSI-styrenheter stöds.

Installationskrav för Azure Migrate

Azure Migrate och Modernize använder Azure Migrate-installationen för identifiering och utvärdering. Du kan distribuera installationen med hjälp av en komprimerad virtuell Hyper-V-hårddisk som du laddar ned från portalen eller med hjälp av ett PowerShell-skript. Mer information:

Portåtkomst

I följande tabell sammanfattas portkraven för utvärdering.

Enhet Anslutning
Apparat Inkommande anslutningar på TCP-port 3389 för att tillåta fjärrskrivbordsanslutningar till installationen.

Inkommande anslutningar på port 44368 för fjärråtkomst till programhanteringsappen med hjälp av URL:en: https://<appliance-ip-or-name>:44368

Utgående anslutningar på port 443 (HTTPS) för att skicka identifierings- och prestandametadata till Azure Migrate och Modernisera.
Hyper-V-värd/-kluster Inkommande anslutning på WinRM-port 5985 (HTTP) för att hämta metadata och prestandadata för servrar på Hyper-V med hjälp av en CIM-session (Common Information Model).
Servrar Windows-servrar behöver åtkomst på port 5985 (HTTP). Linux-servrar behöver åtkomst på port 22 (TCP) för att utföra programvaruinventering och agentlös beroendeanalys.

Krav för programvaruinventering

Förutom att identifiera servrar kan Azure Migrate: Identifiering och utvärdering utföra programvaruinventering på servrar. Programvaruinventering innehåller en lista över program, roller och funktioner som körs på Windows- och Linux-servrar som identifieras med hjälp av Azure Migrate och Modernisera. Det hjälper dig att identifiera och planera en migreringsväg som är anpassad för dina lokala arbetsbelastningar.

Support Details
Servrar som stöds Du kan utföra programvaruinventering på upp till 5 000 servrar som körs över Hyper-V-värdar/-kluster som läggs till i varje Azure Migrate-installation.
Operativsystem Alla Windows- och Linux-versioner med Hyper-V-integreringstjänster aktiverade.
Serverkrav Windows-servrar måste ha PowerShell-fjärrkommunikation aktiverat och PowerShell version 2.0 eller senare installerat.

WMI måste vara aktiverat och tillgängligt på Windows-servrar för att samla in information om de roller och funktioner som är installerade på servrarna.

Linux-servrar måste ha SSH-anslutning (Secure Shell) aktiverat och se till att följande kommandon kan köras på Linux-servrarna för att hämta programdata: lista, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Baserat på operativsystemtyp och vilken typ av pakethanterare som används finns här några fler kommandon: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Serveråtkomst Du kan lägga till autentiseringsuppgifter för flera domäner och icke-domäner (Windows/Linux) i installationskonfigurationshanteraren för programvaruinventering.

Du måste ha ett gästanvändarkonto för Windows-servrar och ett standardanvändarkonto (icke-sudo-åtkomst) för alla Linux-servrar.
Portåtkomst Windows-servrar behöver åtkomst på port 5985 (HTTP). Linux-servrar behöver åtkomst på port 22 (TCP).

Om du använder domänautentiseringsuppgifter måste Azure Migrate-installationen kunna ansluta till följande TCP- och UDP-portar:

TCP 135 – RPC-slutpunkt
TCP 389 – LDAP
TCP 636 – LDAP SSL
TCP 445 – SMB
TCP/UDP 88 – Kerberos-autentisering
TCP/UDP 464 – Kerberos-ändringsåtgärder
Identifiering Programvaruinventeringen utförs genom att direkt ansluta till servrarna med hjälp av de serverautentiseringsuppgifter som lagts till på installationen.

Installationen samlar in information om programvaruinventeringen från Windows-servrar med hjälp av PowerShell-fjärrkommunikation och från Linux-servrar med hjälp av SSH-anslutningen.

Programvaruinventeringen är agentlös. Ingen agent är installerad på servrarna.

Krav för SQL Server-instans och databasidentifiering

Programvaruinventering identifierar SQL Server-instanser. Installationen använder den här informationen och försöker ansluta till respektive SQL Server-instanser via autentiseringsuppgifterna för Windows-autentisering eller SQL Server-autentisering som anges i installationskonfigurationshanteraren. Enheten kan bara ansluta till de SQL Server-instanser som den har nätverksansikte till. Programvaruinventering i sig kanske inte behöver någon nätverkslinje.

När installationen är ansluten samlar den in konfigurations- och prestandadata för SQL Server-instanser och databaser. SQL Server-konfigurationsdata uppdateras en gång var 24:e timme. Prestandadata samlas in var 30:e sekund.

Support Details
Servrar som stöds Stöds endast för servrar som kör SQL Server i dina VMware-, Microsoft Hyper-V- och fysiska/bare metal-miljöer och IaaS-servrar (infrastruktur som en tjänst) i andra offentliga moln, till exempel Azure Web Services och Google Cloud Platform.

Du kan identifiera upp till 750 SQL Server-instanser eller 15 000 SQL-databaser, beroende på vilket som är mindre, från en enskild installation. Vi rekommenderar att du ser till att en installation är begränsad till att identifiera färre än 600 servrar som kör SQL för att undvika skalningsproblem.
Windows-servrar Windows Server 2008 och senare stöds.
Linux-servrar Stöds inte för närvarande.
Autentiseringsmekanism Både Windows- och SQL Server-autentisering stöds. Du kan ange autentiseringsuppgifter för båda autentiseringstyperna i konfigurationshanteraren för installationen.
SQL Server-åtkomst För att identifiera SQL Server-instanser och databaser måste Windows- eller SQL Server-kontot vara medlem i sysadmin-serverrollen eller ha dessa behörigheter för varje SQL Server-instans.
SQL Server-versioner SQL Server 2008 och senare stöds.
SQL Server-utgåvor Enterprise-, Standard-, Developer- och Express-utgåvor stöds.
SQL-konfiguration som stöds Identifiering av fristående, högtillgängliga och katastrofskyddade SQL-distributioner stöds. Identifiering av SQL-distributioner med hög tillgänglighet och haveriberedskap som drivs av AlwaysOn-redundansklusterinstanser och AlwaysOn-tillgänglighetsgrupper stöds också.
SQL-tjänster som stöds Endast SQL Server Database Engine stöds.

Identifiering av SQL Server Reporting Services, SQL Server Integration Services och SQL Server Analysis Services stöds inte.

Kommentar

Som standard använder Azure Migrate och Modernize det säkraste sättet att ansluta till SQL-instanser. Azure Migrate och Modernize krypterar alltså kommunikationen mellan Azure Migrate-installationen och SQL Server-källinstanserna genom att ställa in TrustServerCertificate egenskapen på true. Dessutom använder transportlagret Secure Socket Layer för att kryptera kanalen och kringgå certifikatkedjan för att verifiera förtroendet. Därför måste installationsservern konfigureras för att kunna lita på certifikatets rotutfärdare.

Du kan dock ändra anslutningsinställningarna genom att välja Redigera SQL Server-anslutningsegenskaper på enheten. Lär dig mer om vad du ska välja.

Konfigurera anpassad inloggning för SQL Server-identifiering

Använd följande exempelskript för att skapa en inloggning och etablera den med nödvändiga behörigheter.

Windows-autentisering

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

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

Krav för identifiering av webbappar

Programvaruinventering identifierar webbserverrollen som finns på identifierade servrar. Om en server visar sig ha en webbserver installerad identifierar Azure Migrate och Modernize webbappar på servern.

Du kan lägga till både domän- och icke-domänautentiseringsuppgifter på enheten. Kontrollera att det konto som används har lokal administratörsbehörighet på källservrar. Azure Migrate och Modernize mappar automatiskt autentiseringsuppgifter till respektive servrar, så du behöver inte mappa dem manuellt. Dessa autentiseringsuppgifter skickas aldrig till Microsoft och finns kvar på enheten som körs i källmiljön.

När installationen är ansluten samlar den in konfigurationsdata för ASP.NET webbappar (IIS-webbserver) och Java-webbappar (Tomcat-servrar). Konfigurationsdata för webbappar uppdateras en gång var 24:e timme.

Support ASP.NET-webbappar Java-webbappar
Stack VMware, Hyper-V och fysiska servrar. VMware, Hyper-V och fysiska servrar.
Windows-servrar Windows Server 2008 R2 och senare stöds. Stöds ej.
Linux-servrar Stöds ej. Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7 och Red Hat Enterprise Linux 5/6/7.
Webbserverversioner IIS 7.5 och senare. Tomcat 8 eller senare.
Privilegier som krävs Lokal administratör. Rot- eller sudo-användare.

Kommentar

Data krypteras alltid i vila och under överföring.

Krav för beroendeanalys (agentlös)

Beroendeanalys hjälper dig att analysera beroendena mellan de identifierade servrarna. Du kan enkelt visualisera beroenden med en kartvy i ett Azure Migrate-projekt. Du kan använda beroenden för att gruppera relaterade servrar för migrering till Azure. I följande tabell sammanfattas kraven för att konfigurera agentlös beroendeanalys.

Support Details
Servrar som stöds Du kan aktivera agentlös beroendeanalys på upp till 1 000 servrar (över flera Hyper-V-värdar/-kluster) som identifieras per installation.
Operativsystem Alla Windows- och Linux-versioner med Hyper-V-integreringstjänster aktiverade.
Serverkrav Windows-servrar måste ha PowerShell-fjärrkommunikation aktiverat och PowerShell version 2.0 eller senare installerat.

Linux-servrar måste ha SSH-anslutning aktiverat och se till att följande kommandon kan köras på Linux-servrarna: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Åtkomst till Windows-server Ett användarkonto (lokalt eller domän) med administratörsbehörighet på servrar.
Åtkomst till Linux-server Ett sudo-användarkonto med behörighet att köra ls- och netstat-kommandon. Om du anger ett sudo-användarkonto kontrollerar du att du aktiverar NOPASSWD för kontot för att köra nödvändiga kommandon utan att fråga efter ett lösenord varje gång ett sudo-kommando anropas.

Du kan också skapa ett användarkonto som har CAP_DAC_READ_SEARCH- och CAP_SYS_PTRACE behörigheter för /bin/netstat- och /bin/ls-filer, som anges med hjälp av följande kommandon:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Portåtkomst Windows-servrar behöver åtkomst på port 5985 (HTTP). Linux-servrar behöver åtkomst på port 22 (TCP).
Identifieringsmetod Agentlös beroendeanalys utförs genom att direkt ansluta till servrarna med hjälp av de serverautentiseringsuppgifter som lagts till på installationen.

Installationen samlar in beroendeinformation från Windows-servrar med hjälp av PowerShell-fjärrkommunikation och från Linux-servrar med hjälp av SSH-anslutningen.

Ingen agent installeras på servrarna för att hämta beroendedata.

Krav för agentbaserad beroendeanalys

Beroendeanalys hjälper dig att identifiera beroenden mellan lokala servrar som du vill utvärdera och migrera till Azure. Tabellen sammanfattar kraven för att konfigurera agentbaserad beroendeanalys. Hyper-V stöder för närvarande endast agentbaserad beroendevisualisering.

Krav Information
Före distributionen Du bör ha ett projekt på plats med verktyget Azure Migrate: Discovery och utvärdering som lagts till i projektet.

Du distribuerar beroendevisualisering när du har konfigurerat en Azure Migrate-installation för att identifiera dina lokala servrar.

Lär dig hur du skapar ett projekt för första gången.
Lär dig hur du lägger till verktyget Azure Migrate: Identifiering och utvärdering i ett befintligt projekt.
Lär dig hur du konfigurerar installationen för identifiering och utvärdering av servrar på Hyper-V.
Azure Government Beroendevisualisering är inte tillgängligt i Azure Government.
Log Analytics Azure Migrate och Modernize använder lösningen Tjänstkarta i Azure Monitor-loggar för beroendevisualisering.

Du associerar en ny eller befintlig Log Analytics-arbetsyta med ett projekt. Du kan inte ändra arbetsytan för ett projekt när du har lagt till arbetsytan.

Arbetsytan måste finnas i samma prenumeration som projektet.

Arbetsytan måste finnas i regionerna USA, östra, Sydostasien eller Europa, västra. Arbetsytor i andra regioner kan inte associeras med ett projekt.

Arbetsytan måste finnas i en region där tjänstkarta stöds. Du kan övervaka virtuella Azure-datorer i valfri region. De virtuella datorerna är inte begränsade till de regioner som stöds av Log Analytics-arbetsytan.

I Log Analytics taggas arbetsytan som är associerad med Azure Migrate och Modernize med migreringsprojektnyckeln och projektnamnet.
Obligatoriska agenter Installera följande agenter på varje server som du vill analysera:

Microsoft Monitoring Agent (MMA)
Beroendeagent

Om lokala servrar inte är anslutna till Internet måste du ladda ned och installera Log Analytics-gatewayen på dem.

Läs mer om att installera beroendeagenten och MMA.
Log Analytics-arbetsyta Arbetsytan måste finnas i samma prenumeration som projektet.

Azure Migrate och Modernize stöder arbetsytor som finns i regionerna USA, östra, Sydostasien och Europa, västra.

Arbetsytan måste finnas i en region där tjänstkarta stöds. Du kan övervaka virtuella Azure-datorer i valfri region. De virtuella datorerna är inte begränsade till de regioner som stöds av Log Analytics-arbetsytan.

Du kan inte ändra arbetsytan för ett projekt när du har lagt till arbetsytan.
Kostnader Service Map-lösningen medför inga avgifter under de första 180 dagarna. Antalet börjar från den dag då du associerar Log Analytics-arbetsytan med projektet.

Efter 180 dagar gäller standardpriserna för Log Analytics.

Om du använder någon annan lösning än Tjänstkarta på den associerade Log Analytics-arbetsytan debiteras standardavgifter för Log Analytics.

När projektet tas bort tas inte arbetsytan bort tillsammans med det. När du har tagit bort projektet är användning av tjänstkarta inte kostnadsfritt. Varje nod debiteras enligt den betalda nivån på Log Analytics-arbetsytan.

Om du har projekt som du skapade före allmän tillgänglighet för Azure Migrate (GA den 28 februari 2018) kan du debiteras andra Service Map-avgifter. För att säkerställa betalning endast efter 180 dagar rekommenderar vi att du skapar ett nytt projekt. Arbetsytor som skapades före allmän tillgänglighet kan fortfarande debiteras.
Hantering När du registrerar agenter på arbetsytan använder du det ID och den nyckel som tillhandahålls av projektet.

Du kan använda Log Analytics-arbetsytan utanför Azure Migrate och Modernisera.

Om du tar bort det associerade projektet tas arbetsytan inte bort automatiskt. Ta bort den manuellt.

Ta inte bort arbetsytan som skapats av Azure Migrate och Modernisera om du inte tar bort projektet. Om du gör det fungerar inte beroendevisualiseringsfunktionen som förväntat.
Internet-anslutning Om servrar inte är anslutna till Internet måste du installera Log Analytics-gatewayen på dem.
Azure Government Agentbaserad beroendeanalys stöds inte.

Nästa steg

Förbered för utvärdering av servrar som körs på Hyper-V.