Felsöka Azure Stack HCI-registrering

Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2

Felsökning av problem med Azure Stack HCI-registrering kräver att du tittar på både PowerShell-registreringsloggar och hcisvc-felsökningsloggar från varje server i klustret.

Samla in PowerShell-registreringsloggar

Register-AzStackHCI När cmdletarna och Unregister-AzStackHCI körs skapas loggfiler med namnet RegisterHCI_{yyyymmdd-hhss}.log och UnregisterHCI_{yyyymmdd-hhss}.log för varje försök. Du kan ange loggkatalogen för dessa loggfiler med hjälp av parametern -LogsDirectory i cmdleten Register-AzStackHCI och anropa Get-AzStackHCILogsDirectory för att hämta platsen. Som standard skapas dessa filer i C:\ProgramData\AzureStackHCI\Registration. För PowerShell-modul version 2.1.2 eller tidigare skapas dessa filer i arbetskatalogen för PowerShell-sessionen där cmdletarna körs.

Som standard ingår inte felsökningsloggar. Om det finns ett problem som behöver ytterligare felsökningsloggar anger du felsökningsinställningen till Fortsätt genom att köra följande cmdlet innan du kör Register-AzStackHCI eller Unregister-AzStackHCI:

$DebugPreference = 'Continue'

Samla in lokala hcisvc-loggar

Om du vill aktivera felsökningsloggar för hcisvc kör du följande kommando i PowerShell på varje server i klustret:

wevtutil.exe sl /q /e:true Microsoft-AzureStack-HCI/Debug

Så här hämtar du loggarna:

Get-WinEvent -Logname Microsoft-AzureStack-HCI/Debug -Oldest -ErrorAction Ignore

Det gick inte att registrera. Det gick inte att generera självsignerade certifikat på noder {Node1,Node2}. Det gick inte att ange och verifiera registreringscertifikatet på noderna {Node1,Node2}

Förklaring av feltillstånd:

Under registreringen måste varje server i klustret vara igång med utgående Internetanslutning till Azure. Cmdleten Register-AzStackHCI pratar med varje server i klustret för att etablera certifikat. Varje server använder sitt certifikat för att göra ett API-anrop till HCI-tjänster i molnet för att verifiera registreringen.

Om registreringen misslyckas kan följande meddelande visas: Det gick inte att registrera. Det gick inte att generera självsignerade certifikat på noder {Node1,Node2}. Det gick inte att ange och verifiera registreringscertifikatet på noderna {Node1,Node2}

Om det finns nodnamn efter att det inte gick att generera självsignerade certifikat på noder i felmeddelandet kunde systemet inte generera certifikatet på dessa servrar.

Reparationsåtgärd:

  1. Kontrollera att varje server som anges i meddelandet ovan är igång. Du kan kontrollera statusen för hcisvc genom att köra sc.exe query hcisvc och starta den om det behövs med start-service hcisvc.

  2. Kontrollera att varje server som anges i felmeddelandet har anslutning till den dator där cmdleten Register-AzStackHCI körs. Kontrollera detta genom att köra följande cmdlet från datorn som Register-AzStackHCI körs, med hjälp av New-PSSession för att ansluta till varje server i klustret och kontrollera att den fungerar:

    New-PSSession -ComputerName {failing nodes}
    

Om det finns nodnamn efter att det inte gick att ange och verifiera registreringscertifikatet på noderna i felmeddelandet kunde tjänsten generera certifikatet på servrarna, men servrarna kunde inte anropa HCI-molntjänst-API:et. Så här felsöker du:

  1. Kontrollera att varje server har den Internetanslutning som krävs för att kommunicera med Azure Stack HCI-molntjänster och andra Nödvändiga Azure-tjänster som Microsoft Entra-ID och att den inte blockeras av brandväggar. Se Brandväggskrav för Azure Stack HCI.

  2. Prova att köra cmdleten Invoke-AzStackHciConnectivityValidation från modulen AzStackHCI.EnvironmentChecker och kontrollera att den lyckas. Den här cmdleten anropar hälsoslutpunkten för HCI-molntjänster för att testa anslutningen.

  3. Titta på hcisvc-felsökningsloggarna på varje nod som anges i felmeddelandet.

    • Det är OK att meddelandet ExecuteWithRetry-åtgärden AADTokenFetch misslyckades med ett nytt försöksfel visas några gånger innan det antingen misslyckas med executeWithRetry-åtgärden AADTokenFetch misslyckades när alla återförsök eller ExecuteWithRetry-åtgärden AADTokenFetch lyckades igen.
    • Om du stöter på ExecuteWithRetry-åtgärden AADTokenFetch misslyckades efter alla återförsök i loggarna, kunde systemet inte hämta Microsoft Entra token från tjänsten även efter alla återförsök. Det kommer att finnas ett associerat Microsoft Entra undantag som loggas med det här meddelandet.
    • Om du ser AADSTS700027: Klientkontroll innehåller en ogiltig signatur. [Orsak – Den nyckel som används har upphört att gälla. Tumavtryck för nyckeln som används av klienten: {SomeThumbprint}, Hittade nyckeln Start=06/29/2021 21:13:15, End=06/29/2023 21:13:15, detta är ett problem med hur tiden anges på servern. Kontrollera UTC-tiden på alla servrar genom att köra [System.DateTime]::UtcNow i PowerShell och jämför den med den faktiska UTC-tiden. Om tiden inte är korrekt anger du rätt tider på servrarna och försöker registrera igen.

Problem med att ta bort HCI-resursen från portalen och registrera om samma kluster

Förklaring av feltillstånd:

Om du uttryckligen tog bort Azure Sack HCI-klusterresursen från Azure Portal utan att först avregistrera klustret från Windows Admin Center eller PowerShell, resulterar borttagning av en HCI Azure-Resource Manager resurs direkt från portalen i ett resurstillstånd med fel kluster. Avregistreringen ska alltid utlösas inifrån HCI-klustret med hjälp av cmdleten Unregister-AzStackHCI för en ren avregistrering. I det här avsnittet beskrivs rensningssteg för scenarier där HCI-klusterresursen togs bort från portalen.

Reparationsåtgärd:

  1. Logga in på den lokala HCI-klusterservern med autentiseringsuppgifterna för klusteranvändaren.
  2. Kör cmdleten Unregister-AzStackHCI på klustret för att rensa klustrets registreringstillstånd och klustrets Arc-tillstånd.
    • Om avregistreringen lyckas navigerar du till Microsoft Entra ID > Appregistreringar (Alla program) och söker efter namnmatchningen clusterName och clusterName.arc. Ta bort de två app-ID:na om de finns.
    • Om avregistreringen misslyckas med felet FEL: Det gick inte att inaktivera Azure Arc-integrering på nodnamnet <>kan du prova att köra cmdleten Disable-AzureStackHCIArcIntegration på noden. Om noden är i ett tillstånd där Disable-AzureStackHCIArcIntegration det inte går att köra noden tar du bort noden från klustret och försöker köra cmdleten Unregister-AzStackHCI igen. Logga in på varje enskild nod:
      1. Ändra katalogen till den plats där Arc-agenten är installerad: cd 'C:\Program Files\AzureConnectedMachineAgent\'.
      2. Hämta status för arcmagent.exe och fastställa den Azure-resursgrupp som den beräknas till: .\azcmagent.exe show. Utdata för det här kommandot visar resursgruppsinformationen.
      3. Framtvinga frånkoppling av Arc-agenten från noden: .\azcmagent.exe disconnect --force-local-only.
      4. Logga in på Azure Portal och ta bort Arc-for-Server-resursen från resursgruppen som fastställdes i steg ii.

Användaren har tagit bort app-ID:t av misstag

Förklaring av feltillstånd:

Om klustret är frånkopplat i mer än 8 timmar är det möjligt att de associerade Microsoft Entra appregistreringar som representerar HCI-klustret och Arc-registreringarna kan ha tagits bort av misstag. För att HCI-kluster- och Arc-scenarier ska fungera korrekt skapas två appregistreringar i klientorganisationen under registreringen.

  • <clustername> Om app-ID:t tas bort visas Azure-anslutningen för klusterresursen i Azure Portal Frånkopplad – klustret är inte i anslutet tillstånd på mer än 8 timmar. Titta på HCIsvc-felsökningsloggarna på noden: felmeddelandet är Program med identifieraren "<ID>" hittades inte i katalogen "Standardkatalog". Detta kan inträffa om programmet inte har installerats av administratören för klientorganisationen eller godkänts av någon användare i klientorganisationen. Du kan ha skickat din autentiseringsbegäran till fel klientorganisation.
  • Om <clustername>.arc det skapas under arc-aktivering tas bort, finns det inga synliga fel under normal drift. Den här identiteten krävs endast under registrering och avregistrering. I det här scenariot misslyckas avregistreringen med felet Det gick inte att inaktivera Azure Arc-integrering på Nodnodnamn<>. Prova att köra cmdleten Disable-AzureStackHCIArcIntegration på noden. Om noden är i ett tillstånd där det inte gick att köra Disable-AzureStackHCIArcIntegration-cmdleten tar du bort noden från klustret och försöker köra cmdleten Unregister-AzStackHCI igen.

Om du tar bort något av dessa program misslyckas kommunikationen från HCI-klustret till molnet.

Reparationsåtgärd:

  • Om endast <clustername> AppId tas bort utför du en reparationsregistrering i klustret för att konfigurera Microsoft Entra-programmen:

    Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -RepairRegistration
    

    När du reparerar registreringen återskapas de nödvändiga Microsoft Entra program samtidigt som annan information bevaras, till exempel resursnamn, resursgrupp och andra registreringsalternativ.

  • <clustername>.arc Om app-ID:t tas bort finns det inget synligt fel i loggarna. Avregistreringen misslyckas om <clustername>.arc tas bort. Om avregistreringen misslyckas följer du samma åtgärd som beskrivs i det här avsnittet.

Fel om att principen är slut

Förklaring av feltillstånd:

Om ett tidigare registrerat kluster visar statusen OutOfPolicy kan ändringar i systemkonfigurationen ha orsakat att registreringsstatusen för Azure Stack HCI inte omfattas av principen.

Systemändringar kan till exempel vara, men är inte begränsade till, följande:

  • Inaktivering av inställningar för säker start med konflikter på den registrerade noden.
  • Rensning av TPM (Trusted Platform Module).
  • En betydande ändring av systemtiden.

Anteckning

Azure Stack HCI 21H2 med KB5010421 och senare versioner försöker automatiskt återställa från OutOfPolicy-tillståndet . Läs händelseloggen Microsoft-AzureStack-HCI/Admin för mer information om den aktuella OutOfPolicy-statusen och annan information.

Vilka "OutOfPolicy"-händelse-ID-meddelanden kan jag förvänta mig att se under registreringen?

Det finns tre typer av händelse-ID-meddelanden: information, varningar och fel.

Följande meddelanden var uppdateringar med Azure Stack HCI 21H2 med KB5010421 och visas inte om denna KB inte är installerad.

Informationshändelse-ID

Informationshändelse-ID-meddelanden som inträffar under registreringen. Granska och följ igenom eventuella förslag i meddelandet:

  • (Information) Händelse-ID 592: "Azure Stack HCI har initierat en reparation av sina data. Ingen ytterligare åtgärd från användaren krävs just nu."

  • (Information) Händelse-ID 594: "Azure Stack HCI påträffade ett fel vid åtkomst till dess data. Kontrollera vilka noder som påverkas om hela klustret är OutOfPolicy (kör Get-AzureStackHCI) genom att köra Unregister-AzStackHCI i klustret, starta om och sedan köra Register-AzStackHCI. Om endast den här noden påverkas tar du bort den här noden från klustret, startar om och väntar på att reparationen ska slutföras och återansluter sedan till klustret."

Varningshändelse-ID

Med varningsmeddelanden slutförs inte registreringens status. Det kan finnas ett problem. Granska först händelse-ID-meddelandet innan du utför några felsökningssteg.

(Varning) Händelse-ID 585: "Azure Stack HCI kunde inte förnya licensen från Azure. Om du vill få mer information om det specifika felet aktiverar du händelsekanalen Microsoft-AzureStack-HCI/Debug."

Anteckning

Möjliga fördröjningar vid återupprättande av en fullständig anslutning till Azure förväntas efter en lyckad automatisk reparation och kan resultera i att händelse-ID 585 visas. Detta påverkar inte arbetsbelastningar eller licensiering av noden. Det vill säger att det fortfarande finns en installerad licens, såvida inte noden var ute ur 30-dagarsfönstret före automatisk reparation.

Anteckning

I vissa fall kanske Azure Stack HCI inte lyckas med automatisk återställning. Detta kan inträffa när registreringsstatusen för alla noder i klustret inte har någon princip. Vissa manuella steg krävs. Se händelse-ID-meddelandena för Microsoft-AzureStack-HCI/Admin.

Felhändelse-ID

Felmeddelanden om händelse-ID identifierar ett fel i registreringsprocessen. Felmeddelandet innehåller instruktioner om hur du löser felet.

  • (Fel) Händelse-ID 591: "Azure Stack HCI kunde inte ansluta till Azure. Om du fortsätter att se det här felet kan du försöka köra Register-AzStackHCI igen med parametern -RepairRegistration ."

  • (Fel) Händelse-ID 594: "Azure Stack HCI påträffade ett fel vid åtkomst till dess data. Om du vill reparera kontrollerar du vilka noder som påverkas – om hela klustret är OutOfPolicy (kör Get-AzureStackHCI), kör Unregister-AzStackHCI på klustret, startar om och kör Register-AzStackHCIsedan . Om endast den här noden påverkas tar du bort den här noden från klustret, startar om, väntar tills reparationen har slutförts och återansluter sedan klustret.”

Kluster- och Arc-resursen i Azure Portal finns men Get-AzureStackHCI statusen "Inte ännu" registrerad

Förklaring av feltillstånd:

Det här problemet orsakas av avregistrering av ett HCI-kluster med fel molnmiljö eller felaktig prenumerationsinformation. Om en användare kör cmdleten Unregister-AzStackHCI med fel -EnvironmentName eller -SubcriptionId parametrar för ett kluster tas klustrets registreringstillstånd bort från själva det lokala klustret, men klustret och Arc-resurserna i Azure Portal finns fortfarande i den ursprungliga miljön eller prenumerationen.

Exempel:

  • Fel -EnvironmentName <value>: Du registrerade klustret i -EnvironmentName AzureUSGovernment som i följande exempel. Observera att standardvärdet -EnvironmentName är "Azurecloud". Du har till exempel kört:

    Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -EnvironmentName AzureUSGovernment
    

    Men sedan körde du cmdleten Unregister-AzStackHCI med -EnvironmentName Azurecloud (standardinställningen) på följande sätt:

    Unregister-AzStackHCI -SubscriptionId "<subscription_ID>"
    
  • Fel -SubscriptionId <value>: Du har registrerat klustret med -SubscriptionId "<subscription_id_1>" på följande sätt:

    Register-AzStackHCI  -SubscriptionId "<subscription_id_1>"
    

    Men sedan körde du cmdleten Unregister-AzStackHCI för ett annat prenumerations-ID:

    Unregister-AzStackHCI -SubscriptionId "<subscription_id_2>"
    

Åtgärd:

  1. Ta bort klustret och Arc-resurserna från portalen.
  2. Gå till Microsoft Entra ID > Appregistreringar (Alla program) och sök efter namnmatchningen <clusterName> och <clusterName>.arcoch ta sedan bort de två app-ID:t.

Utfärdande av Sync-AzureStackHCI omedelbart efter omstart av noderna i klustret resulterar i borttagning av Arc-resurs

Förklaring av feltillstånd:

Om du utför en folkräkningssynkronisering före nodsynkronisering kan synkroniseringen skickas till Azure, vilket inte inkluderar noden. Detta resulterar i att Arc-resursen för noden tas bort. Cmdleten Sync-AzureStackHCI får endast användas för att felsöka HCI-klustrets molnanslutning. HCI-klustret har en liten uppvärmningstid efter en omstart för att stämma av klustertillståndet. Därför ska du inte köra Sync-AzureStackHCI strax efter omstart av en nod.

Åtgärd:

  1. Logga in på noden som visas som Inte installerad på Azure Portal.

  2. Koppla från Arc-agenten med följande två kommandon:

    cd "C:\Program Files\AzureConnectedMachineAgent"
    

    sedan

    .\azcmagent.exe disconnect --force-local-only
    
  3. Reparera registreringen:

    Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1  -RepairRegistration
    
  4. Efter reparationsåtgärden återgår noden till ett anslutet tillstånd.

Registreringen slutförs men Azure Arc-anslutningen i portalen säger Inte installerad

Scenario 1

Förklaring av feltillstånd:

Detta kan inträffa om den roll som Azure Connected Machine Resource Manager krävs tas bort från HCI-resursprovidern i resursgruppen Arc-for-Server.

Du hittar behörigheten under bladet Access Control i resursgruppen i Azure Portal. Följande bild visar behörigheten:

Skärmbild av åtkomstkontrollbladet.

Åtgärd:

Kör cmdleten för reparationsregistrering:

Register-AzStackHCI -TenantId "<tenant_ID>" -SubscriptionId "<subscription_ID>" -ComputerName Server1  -RepairRegistration

Scenario 2

Förklaring av feltillstånd:

Det här meddelandet kan också bero på ett tillfälligt problem som ibland uppstår när du utför Azure Stack HCI-registrering. När det händer visar cmdleten Register-AzStackHCI följande varningsmeddelande:

Skärmbild av utdatameddelande från Register-AzStackHCI cmdlet.

Åtgärd:

Vänta i 12 timmar efter registreringen för att problemet ska lösas automatiskt.

Scenario 3

Förklaring av feltillstånd:

Detta kan också inträffa när proxyn inte är korrekt konfigurerad för en anslutning till Azure ARC-molntjänster från HCI-noder. Du kan se följande fel i Arc-agentloggarna:

Skärmbild av Arc-agentloggar.

Åtgärd:

Lös problemet genom att följa riktlinjerna för att uppdatera proxyinställningarna. Registrera sedan Azure Stack HCI-klustret igen.

Det går inte att rotera certifikat i Fairfax och Mooncake

Förklaring av feltillstånd:

  1. Från Azure Portal visar klusterresursen Azure ConnectionFrånkopplad.
  2. Titta på HCIsvc-felsökningsloggarna på noden. Felmeddelandet är ett undantag: AADSTS700027: Verifieringen av klientkontrollen misslyckades.
  3. Felet kan också visas som RotateRegistrationCertificate misslyckades: Ogiltig målgrupp.

Åtgärd:

Utför en reparationsregistrering i klustret för att lägga till nya certifikat i Microsoft Entra-programmet:

Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -RepairRegistration

När du reparerar registreringen genereras nya ersättningscertifikat i Microsoft Entra-programmet, samtidigt som annan information bevaras, till exempel resursnamn, resursgrupp och andra registreringsalternativ.

OnPremisesPasswordValidationTimeSkew

Förklaring av feltillstånd:

Microsoft Entra tokengenerering misslyckas med ett tidsfel om den lokala nodtiden är för långt ifrån synkroniserad med true current time (UTC). Microsoft Entra ID returnerar följande fel:

AADSTS80013: OnPremisesPasswordValidationTimeSkew – Autentiseringsförsöket kunde inte slutföras på grund av tidsförskjutning mellan den dator som kör autentiseringsagenten och AD. Åtgärda problem med tidssynkronisering.

Åtgärd:

Se till att tiden synkroniseras till en känd och korrekt tidskälla.

Det går inte att hämta token för klientorganisationen med fel

Förklaring av feltillstånd:

Om användarkontot som används för registrering ingår i flera Microsoft Entra klienter måste du ange -TenantId under klusterregistreringen och avregistreringen. Annars misslyckas det med felet Det går inte att hämta token för klientorganisationen med fel. Du måste använda multifaktorautentisering för att få åtkomst till klientorganisationen. Kör igen Connect-AzAccount med ytterligare parameter -TenantId.

Åtgärd:

  • För klusterregistrering anger du parametern -TenantId :

    Register-AzStackHCI  -SubscriptionId "<subscription_ID>" -ComputerName Server1 -TenantId <Tenant_ID>
    
  • För avregistrering anger du parametern -TenantId :

    Unregister-AzStackHCI -ComputerName ClusterNode1 -SubscriptionId "<subscription ID GUID>" -ResourceName HCI001 -TenantId <Tenant_ID>
    

En eller flera klusternoder kan inte ansluta till Azure

Förklaring av feltillstånd:

Det här problemet inträffar när en eller flera klusternoder hade anslutningsproblem efter registreringen och inte kunde ansluta till Azure på länge. Även efter lösningen av anslutningsproblem kan noderna inte återansluta till Azure på grund av de utgångna certifikaten.

Åtgärd:

  1. Logga in på den frånkopplade noden.

  2. Kör Disable-AzureStackHCIArcIntegration.

  3. Kontrollera statusen för ARC-integreringen genom att köra Get-AzureStackHCIArcIntegration och se till att den nu står "Inaktiverad" för den frånkopplade noden:

    Skärmbild av Get-AzureStackHCIArcIntegration cmdlet-utdata.

  4. Logga in på Azure Portal och ta bort Azure Resource Manager resurs som representerar Arc-servern för den här noden.

  5. Logga in på den frånkopplade noden igen och kör Enable-AzureStackHCIArcIntegration.

  6. Kör Sync-AzureStackHCI på noden.

Jobbfel vid försök att skapa en virtuell dator

Förklaring av feltillstånd:

Om klustret inte är registrerat i Azure vid distributionen, eller om klustret är registrerat men inte har anslutit till Azure på mer än 30 dagar, tillåter systemet inte att nya virtuella datorer skapas eller läggs till. När detta inträffar visas följande felmeddelande när du försöker skapa virtuella datorer:

There was a failure configuring the virtual machine role for 'vmname'. Job failed. Error opening "vmname" clustered roles. The service being accessed is licensed for a particular number of connections. No more connections can be made to the service at this time because there are already as many connections as the service can accept.

Åtgärd:

Registrera ditt HCI-kluster med Azure. Information om hur du registrerar klustret finns i anvisningarna i Register-AzStackHCI dokumentationen.

Använda en gemensam resursgrupp för kluster- och Arc-for-Server-resurser

Den senaste PowerShell-modulen har stöd för att ha en gemensam resursgrupp för både kluster- och Arc-for-Server-resurser, eller att använda en befintlig resursgrupp för Arc-for-Server-resurser.

För kluster som registrerats med PowerShell-modul version 1.4.1 eller tidigare kan du utföra följande steg för att använda den nya funktionen:

  1. Avregistrera klustret genom att köra Unregister-AzStackHCI från en av noderna. Se Avregistrera Azure Stack HCI med PowerShell.
  2. Installera den senaste PowerShell-modulen: Install-Module Az.StackHCI -Force.
  3. Kör Register-AzStackHCI genom att skicka lämpliga parametrar för -ResourceGroupName och -ArcForServerResourceGroupName.

Anteckning

Om du använder en separat resursgrupp för Arc-for-Server-resurser rekommenderar vi att du använder en resursgrupp med Arc-for-Server-resurser som endast är relaterade till Azure Stack HCI. Azure Stack HCI-resursprovidern har behörighet att hantera andra Arc-for-Server-resurser i ArcServerResourceGroup.

Nästa steg