Visa kända problem i Azure Stack HCI 2405-versionen
Gäller för: Azure Stack HCI, version 23H2
Den här artikeln identifierar de kritiska kända problemen och deras lösningar i Azure Stack HCI 2405-versionen.
Viktig information uppdateras kontinuerligt och när viktiga problem som kräver en lösning identifieras läggs de till. Innan du distribuerar din Azure Stack HCI bör du noggrant granska informationen i viktig information.
Viktigt!
Information om uppdaterade sökvägar som stöds för den här versionen finns i Versionsinformation.
Mer information om de nya funktionerna i den här versionen finns i Nyheter i 23H2.
Problem med version 2405
Den här programvaruversionen mappar till programvaruversionsnummer 2405.0.24.
Viktig information för den här versionen omfattar de problem som har åtgärdats i den här versionen, kända problem i den här versionen och kända problem som har överförts från tidigare versioner.
Åtgärdade problem
Här är de fasta problemen i den här versionen:
| Funktion | Problem | Lösning/kommentarer |
|---|---|---|
| Active Directory | Under klusterdistributioner som använder en stor Active Directory åtgärdas ett problem som kan orsaka tidsgränser när användare läggs till i den lokala administratörsgruppen. | |
| Utplacering | Nya ARM-mallar släpps för att skapa kluster som förenklar skapandet av beroenderesurser. Dessa mallar innehåller några korrigeringar som åtgärdade de obligatoriska fält som saknas. | |
| Utplacering | PowerShell-kommandot Set-AzureStackLCMUserPassword för hemlig rotation stöder en ny parameter för att hoppa över bekräftelsemeddelandet. |
|
| Utplacering | Förbättrade tillförlitligheten för hemlig rotation när tjänsterna inte startas om i tid. | |
| Utplacering | Ett problem har åtgärdats så att distributionen aktiveras när en uppdelad namnrymd används. | |
| Utplacering | Ett problem i distributionen har åtgärdats när diagnostiknivån i Azure och enheten konfigureras. | |
| SBE | Ett nytt PowerShell-kommando släpps som kan användas för att uppdatera de SBE-partneregenskapsvärden som angavs vid distributionstillfället. | |
| SBE | Ett problem som hindrar uppdateringstjänsten från att svara på begäranden efter en SBE-uppdateringskörning har åtgärdats. | |
| Lägg till server Reparationsserver |
Ett problem har åtgärdats som förhindrar att en nod ansluter till Active Directory under en tilläggsserveråtgärd. | |
| Nätverkande | Förbättrade tillförlitligheten för Network ATC när du konfigurerade värdnätverkskonfigurationen med vissa nätverkskorttyper. | |
| Nätverkande | Förbättrad tillförlitlighet vid identifiering av versioner av inbyggd programvara för diskenheter. | |
| Uppdateringar | Förbättrad tillförlitlighet för uppdateringsmeddelanden för hälsokontrollresultat som skickas från enheten till AUM (Azure Update Manager). I vissa fall kan meddelandestorleken vara för stor och gjorde att inga resultat visades i AUM. | |
| Uppdateringar | Ett fillåsproblem som kan orsaka uppdateringsfel för den betrodda vm-agenten (IGVM) har åtgärdats. | |
| Uppdateringar | Ett problem som förhindrade att orchestrator-agenten startades om under en uppdateringskörning har åtgärdats. | |
| Uppdateringar | Ett sällsynt tillstånd har åtgärdats där det tog lång tid för uppdateringstjänsten att identifiera eller starta en uppdatering. | |
| Uppdateringar | Ett problem har åtgärdats för cau-interaktion (Cluster-Aware Update) med orkestratorn när en pågående uppdatering rapporteras av CAU. | |
| Uppdateringar | Namngivningsschemat för uppdateringar justerades för att tillåta identifiering av funktionen jämfört med kumulativa uppdateringar. | |
| Uppdateringar | Förbättrade tillförlitligheten för att rapportera förloppet för klusteruppdateringen till orkestreraren. | |
| Azure Arc | Löste ett problem där Azure Arc-anslutningen gick förlorad när Hybrid Instance Metadata Service (HIMDS) startades om och Azure Portal funktioner bröts. Enheten initierar nu automatiskt Azure Arc-anslutningen igen i dessa fall. |
Kända problem i den här versionen
Här är de kända problemen i den här versionen:
| Funktion | Problem | Lösning/kommentarer | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hantering av virtuella Arc-datorer | I stora distributionsscenarier, till exempel omfattande distributioner av AVD-värdpooler eller storskalig VM-etablering, kan du stöta på tillförlitlighetsproblem som orsakas av ett externt hyper-V-socketbiblioteksproblem. | Följ de här stegen för att åtgärda problemet: 1. Kör kommandot Get-service mochostagent (\) get-process (\) kill. Kontrollera kommandots utdata och kontrollera om antalet handtag är i tusental. 2. Kör kommandot Get-service mochostagent (\) get-process för att avsluta processerna. 3. Kör kommandot restart-service mochostagent för att starta om tjänsten mochostagent. |
||||||||||||||||||
| Utplacering | När du distribuerar Azure Stack HCI, version 23H2 via Azure Portal, kan följande distributionsverifieringsfel uppstå:Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}]. Om du går till fliken Nätverk i Azure Portal distribution kan du se följande fel i konfigurationen för nätverks avsikt: Det valda fysiska nätverkskortet är inte kopplat till den virtuella växeln för hantering. |
Följ proceduren i Felsöka distributionsverifieringsfel i Azure Portal. | ||||||||||||||||||
| Utplacering | Distributionen via Azure Portal misslyckas med det här felet: Det gick inte att hämta hemliga LocalAdminCredential från nyckelvalvet. | Det finns ingen lösning på det här problemet i den här versionen. Om problemet uppstår kontaktar du Microsoft Support för nästa steg. | ||||||||||||||||||
| Utplacering | Den nya ISO-avbildningen för operativsystemet Azure Stack HCI version 23H2 återställdes till en tidigare version på grund av kompatibilitetsproblem med vissa maskinvarukonfigurationer. | Om du stöter på problem med Arc-registrering återställer du till den tidigare versionen. Ingen åtgärd krävs för dig om du redan har distribuerat den nyare avbildningen. Båda ISO-avbildningarna är samma version av operativsystemet. | ||||||||||||||||||
| Uppdatera | När du visar resultaten av beredskapskontrollen för ett Azure Stack HCI-kluster via Azure Update Manager kan det finnas flera beredskapskontroller med samma namn. | Det finns ingen känd lösning i den här versionen. Välj Visa information om du vill visa specifik information om beredskapskontrollen. | ||||||||||||||||||
| Utplacering | I vissa fall kan det här felet visas i felsökningsloggarna under registreringen av Azure Stack HCI-servrar: Det uppstod ett internt serverfel. Ett av de obligatoriska tilläggen för enhetsdistribution kanske inte är installerat. | Följ de här stegen för att åtgärda problemet: $Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" } New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController" New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade |
||||||||||||||||||
| Uppdatera | Det finns ett tillfälligt problem i den här versionen när Azure Portal felaktigt rapporterar uppdateringsstatusen som Misslyckad uppdatering eller Pågår även om uppdateringen är klar. | Anslut till din Azure Stack HCI via en fjärransluten PowerShell-session. Bekräfta uppdateringsstatusen genom att köra följande PowerShell-cmdletar: $Update = get-solutionupdate| ? version -eq "<version string>"Ersätt versionssträngen med den version som du kör. Till exempel "10.2405.0.23". $Update.stateOm uppdateringsstatusen är Installerad krävs ingen ytterligare åtgärd från din sida. Azure Portal uppdaterar statusen korrekt inom 24 timmar. Om du vill uppdatera statusen tidigare följer du de här stegen på en av klusternoderna. Starta om molnhanteringsklustergruppen. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Uppdatera | Under en första MOC-uppdatering uppstår ett fel på grund av att MOC-målversionen inte hittades i katalogcachen. Uppföljningsuppdateringarna och återförsöken visar MOC i målversionen, utan att uppdateringen lyckas, och därför misslyckas Arc Resource Bridge-uppdateringen. Om du vill verifiera det här problemet samlar du in uppdateringsloggarna med hjälp av Felsöka lösningsuppdateringar för Azure Stack HCI, version 23H2. Loggfilerna bör visa ett liknande felmeddelande (den aktuella versionen kan skilja sig åt i felmeddelandet): [ERROR: { "errorCode": "InvalidEntityError", "errorResponse": "{\n\"message\": \"the cloud fabric (MOC) is currently at version v0.13.1. A minimum version of 0.15.0 is required for compatibility\"\n}" }] |
Följ de här stegen för att åtgärda problemet: 1. Kör följande kommando för att hitta MOC-agentversionen: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Använd kommandots utdata för att hitta MOC-versionen från tabellen nedan som matchar agentversionen och ange $initialMocVersion den MOC-versionen. $targetMocVersion Ange genom att hitta den Azure Stack HCI-version som du uppdaterar till och hämta den matchande MOC-versionen från tabellen nedan. Använd dessa värden i åtgärdsskriptet nedan:
Om agentversionen till exempel är v0.13.0-6-gf13a73f7, v0.11.0-alpha.38,01/06/2024, och $initialMocVersion = "1.0.24.10106" om vi uppdaterar till 2405.0.23, sedan $targetMocVersion = "1.3.0.10418".3. Kör följande PowerShell-kommandon på den första noden: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# Importera MOC-modul två gånger import-module mocimport-module moc$verbosePreference = "Continue"# Rensa SFS-katalogcachen Remove-Item (Get-MocConfig).manifestCache# Ange version till den aktuella MOC-versionen före uppdateringen och ange tillstånd som uppdatering misslyckades Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Kör MOC-uppdateringen på nytt till önskad version Update-Moc -version $targetMocVersion4. Återuppta uppdateringen. |
||||||||||||||||||
| Säkerhet | Säkerhetsfunktionen SideChannelMitigation kanske inte visar ett aktiverat tillstånd även om den är aktiverad. Detta inträffar när du använder Windows Admin Center (klustersäkerhetsvy) eller när den här cmdleten returnerar False: Get-AzSSecurity -FeatureName SideChannelMitigation. |
Det finns ingen lösning i den här versionen för att åtgärda utdata från dessa program. Kör följande cmdlet för att verifiera det förväntade värdet: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*"Förväntade utdata är: FeatureSettingsOverride: 83886152 FeatureSettingsOverrideMask: 3 Om dina utdata matchar förväntade utdata kan du på ett säkert sätt ignorera utdata från Administrationscenter för Windows och Get-AzSSecurity cmdlet. |
Kända problem från tidigare versioner
Här är de kända problemen från tidigare versioner:
| Funktion | Problem | Lösning |
|---|---|---|
| AKS på HCI | AKS-klusterskapandet misslyckas med Error: Invalid AKS network resource id. Det här problemet kan inträffa när det associerade logiska nätverksnamnet har ett understreck. |
Understreck stöds inte i namn på logiska nätverk. Se till att inte använda understreck i namnen för logiska nätverk som distribueras på din Azure Stack HCI. |
| Reparationsserver | I sällsynta fall misslyckas åtgärden Repair-Server med HealthServiceWaitForDriveFW felet. I dessa fall tas inte de gamla enheterna från den reparerade noden bort och nya diskar fastnar i underhållsläget. |
För att förhindra det här problemet kontrollerar du att du INTE tömmer noden antingen via Administrationscenter för Windows eller använder PowerShell-cmdleten Suspend-ClusterNode -Drain innan du startar Repair-Server. Om problemet uppstår kontaktar du Microsoft Support för nästa steg. |
| Reparationsserver | Det här problemet uppstår när Azure Stack HCI för en enskild server uppdateras från 2311 till 2402 och sedan Repair-Server utförs. Reparationsåtgärden misslyckas. |
Innan du reparerar den enskilda noden följer du dessa steg: 1. Kör version 2402 för ADPrepTool. Följ stegen i Förbered Active Directory. Den här åtgärden går snabbt och lägger till nödvändiga behörigheter till organisationsenheten (OU). 2. Flytta datorobjektet från segmentet Datorer till rot-OU. Kör följande kommando: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
| Utplacering | Om du förbereder Active Directory på egen hand (inte med hjälp av skriptet och proceduren som tillhandahålls av Microsoft) kan active directory-valideringen misslyckas med behörigheten saknas Generic All . Detta beror på ett problem i verifieringskontrollen som söker efter en dedikerad behörighetspost för msFVE-RecoverInformationobjects – General – Permissions Full control, som krävs för BitLocker-återställning. |
Använd metoden Förbered AD-skript eller om du använder din egen metod måste du tilldela den specifika behörigheten msFVE-RecoverInformationobjects – General – Permissions Full control. |
| Utplacering | Det finns ett sällsynt problem i den här versionen där DNS-posten tas bort under Azure Stack HCI-distributionen. När det inträffar visas följande undantag: Type 'PropagatePublicRootCertificate' of Role 'ASCA' raised an exception:<br>The operation on computer 'ASB88RQ22U09' failed: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer ASB88RQ22U09.local. Verify that the computer exists on the network and that the name provided is spelled correctly at PropagatePublicRootCertificate, C:\NugetStore\Microsoft.AzureStack, at Orchestration.Roles.CertificateAuthority.10.2402.0.14\content\Classes\ASCA\ASCA.psm1: line 38, at C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 127,at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 123. |
Kontrollera DNS-servern för att se om några DNS-poster för klusternoderna saknas. Använd följande åtgärd på noderna där dns-posten saknas. Starta om DNS-klienttjänsten. Öppna en PowerShell-session och kör följande cmdlet på den berörda noden: Taskkill /f /fi "SERVICES eq dnscache" |
| Utplacering | I den här versionen uppstår ett fjärraktivitetsfel i en distribution med flera noder som resulterar i följande undantag:ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
Åtgärden är att starta om ECE-agenten på den berörda noden. Öppna en PowerShell-session på servern och kör följande kommando:Restart-Service ECEAgent. |
| Lägg till/reparera server | I den här versionen, när du lägger till eller reparerar en server, visas ett fel när programvarans lastbalanserare eller virtuella nätverksstyrenhetscertifikat kopieras från de befintliga noderna. Felet beror på att dessa certifikat inte genererades under distributionen/uppdateringen. | Det finns ingen lösning i den här versionen. Om du stöter på det här problemet kontaktar du Microsoft Support för att ta reda på nästa steg. |
| Utplacering | I den här versionen finns det ett tillfälligt problem som resulterar i distributionsfelet med följande undantag:Type 'SyncDiagnosticLevel' of Role 'ObservabilityConfig' raised an exception:*<br>*Syncing Diagnostic Level failed with error: The Diagnostic Level does not match. Portal was not set to Enhanced, instead is Basic. |
Eftersom det här är ett tillfälligt problem bör du åtgärda detta genom att försöka distribuera igen. Mer information finns i Köra distributionen igen. |
| Utplacering | I den här versionen finns det ett problem med fältet Hemligheter URI/plats. Det här är ett obligatoriskt fält som är markerat Som Inte obligatoriskt och resulterar i distributionsfel i Azure Resource Manager-mallar. | Använd exempelparametrar i mallen Distribuera Azure Stack HCI version 23H2 via Azure Resource Manager för att säkerställa att alla indata anges i det format som krävs och sedan prova distributionen. Om distributionen misslyckades måste du också rensa följande resurser innan du kör distributionen igen: 1. Ta bort C:\EceStore. 2. Ta bort C:\CloudDeployment. 3. Ta bort C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
| Säkerhet | För nya distributioner har enheter med säker kärna inte DRTM (Dynamic Root of Measurement) aktiverat som standard. Om du försöker aktivera (DRTM) med hjälp av cmdleten Enable-AzSSecurity visas ett fel om att DRTM-inställningen inte stöds i den aktuella versionen. Microsoft rekommenderar skydd på djupet, och UEFI Secure Boot skyddar fortfarande komponenterna i SRT-startkedjan (Static Root of Trust) genom att se till att de endast läses in när de är signerade och verifierade. |
DRTM stöds inte i den här versionen. |
| Nätverkande | En miljökontroll misslyckas när en proxyserver används. Avsiktligt skiljer sig listan över förbikopplingar för winhttp och wininet, vilket gör att verifieringskontrollen misslyckas. | Följ dessa lösningssteg: 1. Rensa listan över förbikoppling av proxy före hälsokontrollen och innan du startar distributionen eller uppdateringen. 2. När kontrollen har slutförts väntar du på att distributionen eller uppdateringen misslyckas. 3. Ställ in listan över förbikoppling av proxyn igen. |
| Hantering av virtuella Arc-datorer | Distribution eller uppdatering av Arc Resource Bridge kan misslyckas när den automatiskt genererade tillfälliga SPN-hemligheten under den här åtgärden börjar med ett bindestreck. | Försök att distribuera/uppdatera igen. Återförsöket bör återskapa SPN-hemligheten och åtgärden kommer sannolikt att lyckas. |
| Hantering av virtuella Arc-datorer | Arc-tillägg på virtuella Arc-datorer förblir i tillståndet "Skapa" på obestämd tid. | Logga in på den virtuella datorn, öppna en kommandotolk och skriv följande: Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Leta sedan upp resourcename egenskapen. Ta bort det GUID som läggs till i slutet av resursnamnet, så att den här egenskapen matchar namnet på den virtuella datorn. Starta sedan om den virtuella datorn. |
| Hantering av virtuella Arc-datorer | När en ny server läggs till i ett Azure Stack HCI-kluster skapas inte lagringssökvägen automatiskt för den nya volymen. | Du kan skapa en lagringssökväg manuellt för alla nya volymer. Mer information finns i Skapa en lagringssökväg. |
| Hantering av virtuella Arc-datorer | Omstarten av Arc VM-åtgärden slutförs efter cirka 20 minuter, även om själva den virtuella datorn startas om om ungefär en minut. | Det finns ingen känd lösning i den här versionen. |
| Hantering av virtuella Arc-datorer | I vissa fall visas statusen för det logiska nätverket som Misslyckad i Azure Portal. Detta inträffar när du försöker ta bort det logiska nätverket utan att först ta bort några resurser, till exempel nätverksgränssnitt som är associerade med det logiska nätverket. Du bör fortfarande kunna skapa resurser i det här logiska nätverket. Statusen är missvisande i den här instansen. |
Om statusen för det här logiska nätverket lyckades vid den tidpunkt då nätverket etablerades kan du fortsätta att skapa resurser i det här nätverket. |
| Hantering av virtuella Arc-datorer | I den här versionen misslyckas åtgärden med följande felmeddelande när du uppdaterar en virtuell dator med en datadisk som är ansluten till den med hjälp av Azure CLI: Det gick inte att hitta en virtuell hårddisk med namnet. |
Använd Azure Portal för alla vm-uppdateringsåtgärder. Mer information finns i Hantera virtuella Arc-datorer och Hantera arc-VM-resurser. |
| Uppdatera | I sällsynta fall kan det här felet uppstå när du uppdaterar din Azure Stack HCI: Skriv "UpdateArbAndExtensions" för rollen "MocArb" genererade ett undantag: Undantagsuppgradering av ARB och tillägg i steg [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml]. | Om du ser det här problemet kontaktar du Microsoft Support för att hjälpa dig med nästa steg. |
| Nätverkande | Det finns ett ovanligt DNS-klientproblem i den här versionen som gör att distributionen misslyckas på ett kluster med två noder med ett DNS-matchningsfel: En WebException inträffade när en RestRequest skickades. WebException.Status: NameResolutionFailure. Som ett resultat av felet tas DNS-posten för den andra noden bort strax efter att den har skapats, vilket resulterar i ett DNS-fel. | Starta om servern. Den här åtgärden registrerar DNS-posten, vilket förhindrar att den tas bort. |
| Azure Portal | I vissa fall kan Azure Portal ta en stund att uppdatera och vyn kanske inte är aktuell. | Du kan behöva vänta i 30 minuter eller mer för att se den uppdaterade vyn. |
| Hantering av virtuella Arc-datorer | Att ta bort ett nätverksgränssnitt på en virtuell Arc-dator från Azure Portal fungerar inte i den här versionen. | Använd Azure CLI för att först ta bort nätverksgränssnittet och sedan ta bort det. Mer information finns i Ta bort nätverksgränssnittet och se Ta bort nätverksgränssnittet. |
| Distribution | Att ange organisationsenhetens namn i en felaktig syntax identifieras inte i Azure Portal. Den felaktiga syntaxen innehåller tecken som inte stöds, till exempel &,",',<,>. Den felaktiga syntaxen identifieras i ett senare steg under klusterverifieringen. |
Kontrollera att OU-sökvägssyntaxen är korrekt och inte innehåller tecken som inte stöds. |
| Distribution | Distributioner via Azure Resource Manager överskrider tidsgränsen efter 2 timmar. Distributioner som överskrider 2 timmar visas som misslyckade i resursgruppen även om klustret har skapats. | Om du vill övervaka distributionen i Azure Portal går du till Azure Stack HCI-klusterresursen och går sedan till posten Nya distributioner. |
| Azure Site Recovery | Azure Site Recovery kan inte installeras på ett Azure Stack HCI-kluster i den här versionen. | Det finns ingen känd lösning i den här versionen. |
| Uppdatera | När du uppdaterar Azure Stack HCI-klustret via Azure Update Manager kanske uppdateringens förlopp och resultat inte visas i Azure Portal. | Om du vill undvika det här problemet lägger du till följande registernyckel på varje klusternod (inget värde behövs):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceStarta sedan om klustergruppen Cloud Management på en av klusternoderna. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Detta åtgärdar inte problemet helt eftersom förloppsinformationen kanske fortfarande inte visas under en varaktighet av uppdateringsprocessen. Du kan hämta den senaste uppdateringsinformationen genom att hämta uppdateringsstatusen med PowerShell. |
| Uppdatera | I sällsynta fall inaktiveras knappen Försök igen om en misslyckad uppdatering har fastnat i tillståndet Pågår i Azure Update Manager. | Kör följande PowerShell-kommando för att återuppta uppdateringen:Get-SolutionUpdate|Start-SolutionUpdate. |
| Uppdateringar | I vissa fall SolutionUpdate kan kommandon misslyckas om de Send-DiagnosticData körs efter kommandot. |
Se till att stänga PowerShell-sessionen som används för Send-DiagnosticData. Öppna en ny PowerShell-session och använd den för SolutionUpdate kommandon. |
| Uppdatera | I sällsynta fall, när du tillämpar en uppdatering från 2311.0.24 till 2311.2.4, rapporterar klusterstatus pågår i stället för förväntat Det gick inte att uppdatera. | Försök uppdatera igen. Kontakta Microsoft Support om problemet kvarstår. |
| Uppdatera | Försök att installera lösningsuppdateringar kan misslyckas i slutet av CAU-stegen med:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on. Det här sällsynta problemet uppstår om Cluster Name resurserna eller Cluster IP Address inte startar efter en omstart av noden och är mest typiska i små kluster. |
Om du stöter på det här problemet kontaktar du Microsoft Support för nästa steg. De kan arbeta med dig för att starta om klusterresurserna manuellt och återuppta uppdateringen efter behov. |
| Uppdatera | När du tillämpar en klusteruppdatering på 10.2402.3.11 kanske cmdleten Get-SolutionUpdate inte svarar och misslyckas till slut med en RequestTimeoutException efter cirka 10 minuter. Detta kommer sannolikt att inträffa efter ett tilläggs- eller reparationsserverscenario. |
Start-ClusterGroup Använd cmdletarna och Stop-ClusterGroup för att starta om uppdateringstjänsten. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Stop-ClusterGroup Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Start-ClusterGroup En lyckad körning av dessa cmdletar bör göra uppdateringstjänsten online. |
| Klustermedveten uppdatering | Det gick inte att återuppta noden genom att återuppta noden. | Det här är ett tillfälligt problem som kan lösas på egen hand. Vänta några minuter och försök igen. Kontakta Microsoft Support om problemet kvarstår. |
| Klustermedveten uppdatering | Åtgärden Pausa nod har fastnat i mer än 90 minuter. | Det här är ett tillfälligt problem som kan lösas på egen hand. Vänta några minuter och försök igen. Kontakta Microsoft Support om problemet kvarstår. |