Kända problem i Azure Local 2411-versionen
Gäller för: Azure Local 2311.2 och senare
Den här artikeln identifierar kritiska kända problem och deras lösningar i Azure Local 2411-versionen.
Dessa releasenoter uppdateras kontinuerligt och när kritiska problem som kräver en övergångslösning upptäcks, läggs de till. Innan du distribuerar din Lokala Azure-instans bör du noggrant granska informationen här.
Viktig
Information om uppdateringssökvägar som stöds för den här versionen finns i Versionsinformation.
Mer information om nya funktioner i den här versionen finns i Nyheter i 23H2.
Kända problem för version 2411
Den här programvaruversionen mappar till programvaruversionsnumret 2411.0.24.
Viktig
De nya distributionerna av den här programvaran använder versionen 2411.0.22, medan du får versionen 2411.0.24 om du uppdaterar från 2408.2. Ingen åtgärd krävs om du redan har uppdaterat från 2408.2 till 2411.0.22.
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 problem med viktig information som har överförts från tidigare versioner.
Not
Detaljerad reparation för vanliga kända problem finns i Azure Local Supportability GitHub-lagringsplats.
Problem har åtgärdats
Följande problem åtgärdas i den här versionen:
| Funktion | Fråga | Tillfällig lösning/kommentarer |
|---|---|---|
| Hantering av virtuella Arc-datorer | Om du försöker aktivera gästhantering på en migrerad virtuell dator misslyckas åtgärden med följande fel: (InternalError)-antagningswebbhooken "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com" nekade begäran: OsProfile kan inte ändras när resursen har skapats |
Kända problem i den här versionen
I följande tabell visas de kända problemen i den här versionen:
| Funktion | Fråga | Lösning |
|---|---|---|
| Säkerhetsrisker | Microsoft har identifierat en säkerhetsrisk som kan exponera de lokala administratörsautentiseringsuppgifter som används när du skapar virtuella Arc-datorer på Azure Local för icke-administratörsanvändare på den virtuella datorn och på värdarna. Virtuella Arc-datorer som körs på versioner före Azure Local 2411-versionen är sårbara. |
Om du vill identifiera de virtuella Arc-datorer som kräver den här ändringen och ändra kontolösenorden läser du detaljerade instruktioner i: Säkerhetsrisk för virtuella Arc-datorer på Azure Local. |
| Distribution Uppgradera |
Om tidszonen inte är inställd på UTC innan du distribuerar Azure Local uppstår ett ArcOperationTimeOut- fel under verifieringen. Följande felmeddelande visas: OperationTimeOut, Inga uppdateringar har tagits emot från enheten för åtgärd. | Beroende på ditt scenario väljer du någon av följande lösningar för det här problemet: Scenario 1. Innan du startar distributionen kontrollerar du att tidszonen är inställd på UTC. Anslut till var och en av de lokala Azure-noderna och ändra tidszonen till UTC. Kör följande kommando: Set-TimeZone -Id "UTC". Scenario 2. Om du startade distributionen utan att ange UTC-tidszonen och fick felet som nämns i valideringsfasen följer du dessa steg: 1. Anslut till varje lokal Azure-nod. Ändra tidszonen till UTC med Set-TimeZone -Id "UTC". Starta om noderna.2. När noderna har startats om går du till den lokala Azure-resursen i Azure-portalen. Starta valideringen igen för att lösa problemet och fortsätt med distributionen eller uppgraderingen. Detaljerade åtgärdssteg finns i felsökningsguiden i Azure Local Supportability GitHub-lagringsplats. |
| Uppdatera | Vid uppdatering från version 2408.2.7 till 2411.0.24 kan uppdateringsprocessen misslyckas med följande felmeddelande: Type 'CauPreRequisites' of Role 'CAU' raised an exception: Could not finish cau prerequisites due to error 'Cannot remove item C:\UpdateDistribution\<any_file_name>: Access to the path is denied.' |
Detaljerade anvisningar om hur du åtgärdar det här problemet finns i lokal felsökningsguide för Azure för uppdatering. |
| Uppdatera | Med 2411-versionen kombineras inte lösningen och Solution Builder-tilläggsuppdateringen i en enda uppdateringskörning. | Om du vill använda ett Solution Builder-tilläggspaket behöver du en separat uppdateringskörning. |
| Uppdatera | När du tillämpar lösningsuppdateringen i den här versionen kan uppdateringen misslyckas. Detta inträffar endast om uppdateringen startades före den 26 november. Problemet som orsakar felet kan resultera i något av följande felmeddelanden: Fel 1 – Steget "uppdatera ARB och tillägg" fel "Clear-AzContext misslyckades med 0 och undantag som anropar "Initiera" med "1" argument: "Objektreferens inte inställd på en instans av ett objekt." på "Clear-AzPowerShellCache". Fel 2 – Steget "EvalTVMFlow"-felet "CloudEngine.Actions.InterfaceInvocationFailedException: Typ 'EvalTVMFlow' för rollen 'ArcIntegration' utlöste ett undantag: Den här modulen kräver Az.Accounts version 3.0.5. En tidigare version av Az.Accounts importeras i den aktuella PowerShell-sessionen. Öppna en ny session innan du importerar den här modulen. Det här felet kan tyda på att flera inkompatibla versioner av Azure PowerShell-cmdletarna är installerade i systemet. Mer information om felsökning finns i https://aka.ms/azps-version-error." Beroende på versionen av PowerShell-moduler kan ovanstående fel rapporteras för båda versionerna 3.0.4 och 3.0.5. |
Detaljerade anvisningar om hur du åtgärdar det här problemet finns i: https://aka.ms/azloc-update-30221399. |
Kända problem från tidigare versioner
I följande tabell visas kända problem från tidigare versioner:
| Funktion | Fråga | Lösning | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Reparera server | När du har reparerat en nod och kört kommandot Set-AzureStackLCMUserPasswordkan följande fel uppstå: CloudEngine.Actions.InterfaceInvocationFailedException: Type 'ValidateCredentials' of Role 'SecretRotation' raised an exception: Cannot load encryption certificate. The certificate setting 'CN=DscEncryptionCert' does not represent a valid base-64 encoded certificate, nor does it represent a valid certificate by file, directory, thumbprint, or subject name. at Validate-Credentials |
Följ de här stegen för att åtgärda problemet: $NewPassword = <Provide new password as secure string> $OldPassword = <Provide the old/current password as secure string> $Identity = <LCM username> $credential = New-Object -TypeName PSCredential -ArgumentList $Identity, $NewPassword 1. Importera den nödvändiga modulen: Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Kontrollera statusen för ECE-klustergruppen: $eceClusterGroup = Get-ClusterGroup | Where-Object {$_.Name -eq "Azure Stack HCI Orchestrator Service Cluster Group"} if ($eceClusterGroup.State -ne "Online") {Write-AzsSecurityError -Message "ECE cluster group is not in an Online state. Cannot continue with password rotation." -ErrRecord $_} 3. Uppdatera ECE med det nya lösenordet: Write-AzsSecurityVerbose -Message "Updating password in ECE" -Verbose $eceContainersToUpdate = @("DomainAdmin", "DeploymentDomainAdmin", "SecondaryDomainAdmin", "TemporaryDomainAdmin", "BareMetalAdmin", "FabricAdmin", "SecondaryFabric", "CloudAdmin") <br><br> foreach ($containerName in $eceContainersToUpdate) {Set-ECEServiceSecret -ContainerName $containerName -Credential $credential 3>$null 4>$null} <br><br> Write-AzsSecurityVerbose -Message "Finished updating credentials in ECE." -Verbose 4. Uppdatera lösenordet i Active Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Hantering av virtuella Arc-datorer | Det går inte att använda en exporterad OS-disk för virtuella Azure-datorer som en virtuell hårddisk för att skapa en galleriavbildning för etablering av en virtuell Arc-dator. | Kör kommandot restart-service mochostagent för att starta om tjänsten mochostagent. |
||||||||||||||||||
| Nätverk | När en nod konfigureras med en proxyserver som har versaler i sin adress, till exempel HTTPS://10.100.000.00:8080, kan Arc-tillägg inte installera eller uppdatera på noden i befintliga versioner, inklusive version 2408.1. Noden förblir dock Arc-ansluten. | Följ de här stegen för att åtgärda problemet: 1. Ange miljövärdena i gemener. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Kontrollera att värdena har angetts. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine").
3. Starta om Arc-tjänster. Restart-Service himds
Restart-Service ExtensionService
Restart-Service GCArcService
4. Signalera AzcmaAgent med proxyinformationen i små bokstäver. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080
& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| Nätverk | När Arc-datorerna går ned, visar sidan "Alla kluster" i den nya portalupplevelsen statusen "Delvisansluten" eller "Inte nyligen ansluten". Även om Arc-datorerna blir felfria kanske de inte visar statusen "Ansluten". | Det finns ingen känd lösning på det här problemet. Om du vill kontrollera anslutningsstatusen använder du den gamla upplevelsen för att se om den visas som "Ansluten". | ||||||||||||||||||
| Säkerhet | Säkerhetsfunktionen SideChannelMitigation kanske inte visar ett aktiverat tillstånd även om den är aktiverad. | 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. | ||||||||||||||||||
| Hantering av virtuella Arc-datorer | Mochostagent-tjänsten kan verka köras men kan fastna utan att uppdatera loggar i över en månad. Du kan identifiera det här problemet genom att kontrollera tjänstloggarna i C:\programdata\mochostagent\logs för att se om loggarna uppdateras. |
Kör följande kommando för att starta om mochostagent-tjänsten: restart-service mochostagent. |
||||||||||||||||||
| Uppgradera | När du uppgraderar stämpeln från 2311 eller tidigare versioner till 2408 eller senare kan tillägg av nod och reparation av nod misslyckas. Du kan till exempel se ett fel: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
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. | ||||||||||||||||||
| Uppdatera | När du visar resultatet av beredskapskontrollen för en lokal Azure-instans 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 för att visa specifik information om beredskapskontrollen. | ||||||||||||||||||
| Driftsättning | I vissa fall kan det här felet visas i felsökningsloggarna under registreringen av lokala Azure-datorer: Påträffade interna 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-portalen felaktigt rapporterar uppdateringsstatusen som Det gick inte att uppdatera eller Pågår även om uppdateringen är klar. |
Anslut till din lokala Azure-instans via en powershell-fjärrsession. 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 Installeradkrä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 dessa steg på en av noderna. 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. För att verifiera det här problemet samlar du in uppdateringsloggarna med hjälp av felsökningslösningen för Azure Local 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 till den MOC-versionen. Ange $targetMocVersion genom att hitta den Azure Local-version som du uppdaterar till och hämta den matchande MOC-versionen från följande tabell. 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, då $initialMocVersion = "1.0.24.10106" och om du uppdaterar till 2405.0.23, då $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 versionen till den aktuella MOC-versionen före uppdateringen och ställ in statusen till att uppdateringen har misslyckats 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. |
||||||||||||||||||
| AKS på Azure Local | 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 Local. | ||||||||||||||||||
| Reparera server | I sällsynta fall misslyckas Repair-Server-åtgärden med felet HealthServiceWaitForDriveFW. 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 med hjälp av Suspend-ClusterNode -Drain PowerShell-cmdlet innan du börjar Repair-Server. Om problemet uppstår kontaktar du Microsoft Support för nästa steg. |
||||||||||||||||||
| Reparera server | Det här problemet uppstår när Azure Local-instansen med enstaka nod uppdateras från 2311 till 2402 och sedan utförs Repair-Server. 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 Datorer segment till rot-OU. Kör följande kommando: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Distribution | Om du förbereder Active Directory på egen hand (inte med hjälp av skriptet och proceduren som tillhandahålls av Microsoft) kan valideringen av Active Directory misslyckas om behörigheten Generic All saknas. 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-skriptmetoden eller om du använder din egen metod, se till att tilldela den specifika behörigheten msFVE-RecoverInformationobjects – General – Permissions Full control. |
||||||||||||||||||
| Distribution | Det finns ett sällsynt problem i den här versionen där DNS-posten tas bort under den lokala Azure-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 noderna saknas. Använd följande åtgärder på noderna där deras DNS-post 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" |
||||||||||||||||||
| Distribution | 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 för att mildra problemet är att starta om ECE-agenten på den berörda noden. Öppna en PowerShell-session på datorn och kör följande kommando:Restart-Service ECEAgent. |
||||||||||||||||||
| Lägg till server | I den här versionen och tidigare versioner, när du lägger till en dator i systemet, går det inte att uppdatera proxyns liststräng för förbikoppling så att den innehåller den nya datorn. Uppdatering av listan över förbikoppling av miljövariabler på värdarna uppdaterar inte listan över förbikoppling av proxy på Azure Resource Bridge eller AKS. | 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. | ||||||||||||||||||
| Lägg till/reparera server | I den här versionen, när du lägger till eller reparerar en dator, 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. | ||||||||||||||||||
| Distribution | 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 hur du köra distributionen igen. | ||||||||||||||||||
| Distribution | 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 Inte obligatoriskt och resulterar i distributionsfel i Azure Resource Manager-mallar. | Använd exempelparametrar i Distribuera Azure Local, version 23H2 via Azure Resource Manager-mallen för att säkerställa att alla indata anges i det format som krävs och prova sedan 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ätverk | 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ösningar: 1. Rensa proxyns förbikopplingslista före hälsokontroll och innan du startar distributionen eller uppdateringen. 2. När kontrollen är slutförd, vänta på att distributionen eller uppdateringen ska 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 egenskapen resourcename. 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 dator läggs till i en lokal Azure-instans 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-portalen. 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 var Lyckades vid tiden när nätverket förberetts, 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-portalen för alla uppdateringsåtgärder för virtuella datorer. 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 lokala Azure-instans: Type 'UpdateArbAndExtensions' of Role 'MocArb' raised an exception: Exception Upgrading ARB and Extension in step [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ätverk | Det finns ett ovanligt DNS-klientproblem i den här versionen som gör att distributionen misslyckas på ett system 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 datorn. Den här åtgärden registrerar DNS-posten, vilket förhindrar att den tas bort. | ||||||||||||||||||
| Azure-portalen | I vissa fall kan det ta en stund att uppdatera Azure-portalen 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-portalen 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. | ||||||||||||||||||
| Utplacering | Att ange organisationsenhetens namn i en felaktig syntax identifieras inte i Azure-portalen. Den felaktiga syntaxen innehåller tecken som inte stöds, till exempel &,",',<,>. Den felaktiga syntaxen identifieras i ett senare steg under systemverifieringen. |
Kontrollera att OU-sökvägssyntaxen är korrekt och inte innehåller tecken som inte stöds. | ||||||||||||||||||
| Utplacering | Implementeringar via Azure Resource Manager avbryts på grund av tidsgräns efter 2 timmar. Driftsättningar som överskrider 2 timmar visas som misslyckade i resursgruppen, även om systemet har skapats. | Om du vill övervaka distributionen i Azure-portalen går du till den lokala Azure-instansresursen och går sedan till den nya Distributioner posten. | ||||||||||||||||||
| Azure Site Recovery | Azure Site Recovery kan inte installeras på en lokal Azure-instans i den här versionen. | Det finns ingen känd lösning i den här versionen. | ||||||||||||||||||
| Uppdatera | När du uppdaterar den lokala Azure-instansen via Azure Update Manager kanske uppdateringsförloppet och resultaten inte visas i Azure-portalen. | Om du vill undvika det här problemet lägger du till följande registernyckel på varje nod (inget värde behövs):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceStarta sedan om molnhanteringsklustergruppen på en av noderna. 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. Om du vill få den senaste uppdateringsinformationen kan du Hämta uppdateringsstatusen med PowerShell. |
||||||||||||||||||
| Uppdatera | Om en misslyckad uppdatering i sällsynta fall har fastnat i ett Pågår tillstånd i Azure Update Manager inaktiveras knappen Försök igen. | Kör följande PowerShell-kommando för att återuppta uppdateringen:Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| Uppdatera | I vissa fall kan SolutionUpdate kommandon misslyckas om de körs efter kommandot Send-DiagnosticData. |
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, vid tillämpning av en uppdatering från 2311.0.24 till 2311.2.4, rapporterar systemstatus Pågår istället för förväntade 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 eller Cluster IP Address resurserna inte startar efter en nodomstart och är mest typiskt i ett litet 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 Azure Local-resurserna manuellt och återuppta uppdateringen efter behov. | ||||||||||||||||||
| Uppdatera | När du tillämpar en systemuppdatering 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. |
Använd cmdletarna Start-ClusterGroup 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 starta uppdateringstjänsten. |
||||||||||||||||||
| Klustermedveten uppdatering av | Det gick inte att återuppta nodens drift. | 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 av | Å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. |