Bekende problemen in de release van Azure Local 2411
Van toepassing op: Azure Local 2311.2 en hoger
In dit artikel worden kritieke bekende problemen en hun tijdelijke oplossingen in de Azure Local 2411-release geïdentificeerd.
Deze releaseopmerkingen worden continu bijgewerkt. Zodra kritieke problemen worden ontdekt waarvoor een tijdelijke oplossing vereist is, worden ze toegevoegd. Voordat u uw Lokale Azure-exemplaar implementeert, moet u de informatie hier zorgvuldig bekijken.
Belangrijk
Zie Release-informatievoor informatie over ondersteunde updatepaden voor deze release.
Zie Wat is er nieuw in 23H2voor meer informatie over nieuwe functies in deze release.
Bekende problemen voor versie 2411
Deze softwarerelease komt overeen met softwareversienummer 2411.0.24.
Belangrijk
De nieuwe implementaties van deze software gebruiken de build 2411.0.22, terwijl als u updatet vanaf 2408.2, de build 2411.0.24 krijgt. Er is geen actie vereist als u al hebt bijgewerkt van 2408.2 tot 2411.0.22.
Releaseopmerkingen voor deze versie omvatten de problemen die zijn opgelost in deze release, bekende problemen in deze release en releaseopmerkingen die zijn overgedragen van eerdere versies.
Notitie
Zie de Azure Local Supportability GitHub-opslagplaats voor gedetailleerde herstelmogelijkheden voor veelvoorkomende bekende problemen.
Problemen opgelost
De volgende problemen zijn opgelost in deze release:
| Kenmerk | Probleem | Tijdelijke oplossing/opmerkingen |
|---|---|---|
| Arc VM-beheer | Als u gastbeheer probeert in te schakelen op een gemigreerde VM, mislukt de bewerking met de volgende fout: (InternalError) toegangswebhook 'createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com' geweigerd de aanvraag: OsProfile kan niet worden gewijzigd nadat de resource is gemaakt |
Bekende problemen in deze release
De volgende tabel bevat de bekende problemen in deze release:
| Kenmerk | Probleem | Tijdelijke oplossing |
|---|---|---|
| Beveiligingsproblemen | Microsoft heeft een beveiligingsprobleem geïdentificeerd dat de lokale beheerdersreferenties die worden gebruikt tijdens het maken van Arc-VM's in Azure Local beschikbaar kan maken voor niet-beheerders op de VIRTUELE machine en op de hosts. Arc-VM's die worden uitgevoerd op releases voorafgaand aan azure Local 2411-release, zijn kwetsbaar. |
Zie gedetailleerde instructies in: Beveiligingsprobleem voor Arc-VM's op lokale Azure-om de Arc-VM's te identificeren waarvoor deze wijziging is vereist en om de accountwachtwoorden te wijzigen. |
| Uitrol Opwaarderen |
Als de tijdzone niet is ingesteld op UTC voordat u Azure Local implementeert, treedt er een ArcOperationTimeOut fout op tijdens de validatie. Het volgende foutbericht wordt weergegeven: OperationTimeOut, geen updates ontvangen van het apparaat voor bewerking. | Kies, afhankelijk van uw scenario, een van de volgende tijdelijke oplossingen voor dit probleem: Scenario 1. Voordat u de implementatie start, moet u ervoor zorgen dat de tijdzone is ingesteld op UTC. Maak verbinding met elk van de lokale Azure-knooppunten en wijzig de tijdzone in UTC. Voer de volgende opdracht uit: Set-TimeZone -Id "UTC". Scenario 2. Als u de implementatie hebt gestart zonder de UTC-tijdzone in te stellen en de fout hebt ontvangen die in de validatiefase wordt vermeld, voert u de volgende stappen uit: 1. Maak verbinding met elk lokaal Azure-knooppunt. Wijzig de tijdzone in UTC met Set-TimeZone -Id "UTC". Start de knooppunten opnieuw op.2. Nadat de knooppunten opnieuw zijn opgestart, gaat u naar de lokale Azure-resource in Azure Portal. Start de validatie opnieuw om het probleem op te lossen en door te gaan met de implementatie of upgrade. Zie de gids voor probleemoplossing in de Lokale ondersteuningsmogelijkheid van Azure GitHub-opslagplaats voor gedetailleerde herstelstappen. |
| bijwerken | Bij het bijwerken van versie 2408.2.7 naar 2411.0.24, kan het updateproces mislukken met het volgende foutbericht: 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.' |
Voor gedetailleerde stappen over hoe u dit probleem kunt verhelpen, zie Azure lokale handleiding voor probleemoplossing voor update. |
| bijwerken | Met de 2411-release worden oplossings- en Solution Builder-extensie-update niet gecombineerd in één updateuitvoering. | Als u een Solution Builder-extensiepakket wilt toepassen, hebt u een afzonderlijke updateuitvoering nodig. |
| bijwerken | Bij het toepassen van oplossingsupdates in deze release kan de update mislukken. Dit gebeurt alleen als de update vóór 26 november is gestart. Het probleem dat de fout veroorzaakt, kan leiden tot een van de volgende foutberichten: fout 1 - De stap "update ARB en extensie" fout "Clear-AzContext mislukte met 0 en een uitzondering bij het aanroepen van "Initialize" met "1" argument(en): "Objectverwijzing is niet ingesteld op een exemplaar van een object." bij "Clear-AzPowerShellCache". Fout 2 - De stap 'EvalTVMFlow' fout 'CloudEngine.Actions.InterfaceInvocationFailedException: Type 'EvalTVMFlow' van rol 'ArcIntegration' heeft een uitzondering gegenereerd: deze module vereist Az.Accounts versie 3.0.5. Een eerdere versie van Az.Accounts wordt geïmporteerd in de huidige PowerShell-sessie. Open een nieuwe sessie voordat u deze module importeert. Deze fout kan erop wijzen dat er meerdere niet-compatibele versies van de Azure PowerShell-cmdlets op uw systeem zijn geïnstalleerd. Zie https://aka.ms/azps-version-error voor informatie over probleemoplossing. Afhankelijk van de versie van PowerShell-modules kan de bovenstaande fout worden gerapporteerd voor beide versies 3.0.4 en 3.0.5. |
Ga naar: https://aka.ms/azloc-update-30221399voor gedetailleerde stappen voor het oplossen van dit probleem. |
Bekende problemen uit eerdere releases
De volgende tabel bevat de bekende problemen uit eerdere releases:
| Kenmerk | Probleem | Tijdelijke oplossing | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Serverherstelserver | Nadat u een knooppunt hebt hersteld en de opdracht Set-AzureStackLCMUserPasswordhebt uitgevoerd, kan de volgende fout optreden: 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 |
Volg deze stappen om het probleem te verhelpen: $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. Importeer de benodigde module: Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Controleer de status van de ECE-clustergroep: $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. Werk de ECE bij met het nieuwe wachtwoord: 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. Werk het wachtwoord bij in Active Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Arc VM-beheer | Het gebruik van een geëxporteerde besturingssysteemschijf van Azure-VM als een VHD om een galerie-afbeelding te maken voor het voorzien van een Arc-VM wordt niet ondersteund. | Voer de opdracht restart-service mochostagent uit om de mochostagent-service opnieuw op te starten. |
||||||||||||||||||
| Netwerken | Wanneer een knooppunt is geconfigureerd met een proxyserver met hoofdletters in het adres, zoals HTTPS://10.100.000.00:8080, kunnen Arc-extensies niet worden geïnstalleerd of bijgewerkt op het knooppunt in bestaande builds, inclusief versie 2408.1. Het knooppunt blijft echter verbonden met Arc. | Volg deze stappen om het probleem te verhelpen: 1. Stel de omgevingswaarden in kleine letters in. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Controleer of de waarden zijn ingesteld. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine").
3. Start Arc-services opnieuw. Restart-Service himds
Restart-Service ExtensionService
Restart-Service GCArcService
4. Signaler de AzcmaAgent met de proxygegevens in kleine letters. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080
& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| Netwerken | Wanneer Arc-machines uitvallen, toont de pagina 'Alle clusters' in de nieuwe portalervaring de status 'Gedeeltelijk Verbonden' of 'Niet Recent Verbonden'. Zelfs wanneer de Arc-machines in orde zijn, geven ze mogelijk niet de status 'Verbonden' weer. | Er is geen bekende tijdelijke oplossing voor dit probleem. Als u de connectiviteitsstatus wilt controleren, gebruikt u de oude ervaring om te zien of deze wordt weergegeven als 'Verbonden'. | ||||||||||||||||||
| Beveiliging | De beveiligingsfunctie SideChannelMitigation toont mogelijk geen ingeschakelde status, zelfs niet als deze is ingeschakeld. | Er is geen tijdelijke oplossing in deze release. Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning om de volgende stappen te bepalen. | ||||||||||||||||||
| Arc VM-beheer | De Mochostagent-service lijkt mogelijk actief te zijn, maar kan vastlopen zonder logboeken meer dan een maand bij te werken. U kunt dit probleem identificeren door de servicelogboeken in C:\programdata\mochostagent\logs te controleren of er logboeken worden bijgewerkt. |
Voer de volgende opdracht uit om de mochostagent-service opnieuw op te starten: restart-service mochostagent. |
||||||||||||||||||
| Upgrade | Wanneer u de versie bijwerkt van 2311 of eerdere builds naar 2408 of hoger, kan het toevoegen en herstellen van knooppunten mislukken. U kunt bijvoorbeeld een fout zien: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
Er is geen tijdelijke oplossing in deze release. Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning om de volgende stappen te bepalen. | ||||||||||||||||||
| Bijwerken | Wanneer u de resultaten van de gereedheidscontrole voor een lokaal Azure-exemplaar bekijkt via Azure Update Manager, zijn er mogelijk meerdere gereedheidscontroles met dezelfde naam. | Er is geen bekende tijdelijke oplossing in deze release. Selecteer Details weergeven om specifieke informatie over de gereedheidscontrole weer te geven. | ||||||||||||||||||
| Uitrol | In sommige gevallen kan deze fout tijdens de registratie van lokale Azure-machines worden weergegeven in de foutopsporingslogboeken: Interne serverfout is opgetreden. Een van de verplichte extensies voor apparaatimplementatie is mogelijk niet geïnstalleerd. | Volg deze stappen om het probleem te verhelpen: $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 |
||||||||||||||||||
| Bijwerken | Er is een onregelmatig probleem in deze release wanneer de Azure-portal de updatestatus onjuist rapporteert als Niet gelukt bijwerken of In uitvoering hoewel de update is voltooid. |
Verbinding maken met uw lokale Azure-exemplaar via een externe PowerShell-sessie. Voer de volgende PowerShell-cmdlets uit om de updatestatus te bevestigen: $Update = get-solutionupdate| ? version -eq "<version string>"Vervang de versie door de versie die u gebruikt. Bijvoorbeeld '10.2405.0.23'. $Update.stateAls de updatestatus geïnstalleerdis, is er geen verdere actie vereist van uw kant. Azure portal vernieuwt de status correct binnen 24 uur. Als u de status eerder wilt vernieuwen, volgt u deze stappen op een van de knooppunten. Start de cloudbeheerclustergroep opnieuw op. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| bijwerken | Tijdens een eerste MOC-update treedt er een fout op omdat de doel-MOC-versie niet in de cataloguscache wordt gevonden. De opvolgende updates en nieuwe pogingen tonen MOC in de doelversie, zonder de update te voltooien, en als gevolg hiervan mislukt de update van Arc Resource Bridge. Als u dit probleem wilt valideren, verzamelt u de update-logboeken met behulp van oplossingsupdates oplossen voor Azure Local, versie 23H2. In de logboekbestanden moet een vergelijkbaar foutbericht worden weergegeven (de huidige versie kan verschillen in het foutbericht): [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}" }] |
Volg deze stappen om het probleem te verhelpen: 1. Voer de volgende opdracht uit om de MOC-agentversie te vinden: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Gebruik de uitvoer van de opdracht om de MOC-versie te vinden uit de onderstaande tabel die overeenkomt met de agentversie en stel $initialMocVersion in op die MOC-versie. Stel de $targetMocVersion in door de lokale Azure-build te vinden waarnaar u bijwerkt en de overeenkomende MOC-versie op te halen uit de volgende tabel. Gebruik deze waarden in het onderstaande beperkingsscript:
Als de agentversie bijvoorbeeld v0.13.0-6-gf13a73f7, v0.11.0-alpha.38,01/06/2024 is, dan $initialMocVersion = "1.0.24.10106"; en als u bijwerkt naar 2405.0.23, dan $targetMocVersion = "1.3.0.10418".3. Voer de volgende PowerShell-opdrachten uit op het eerste knooppunt: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# MOC-module twee keer importeren import-module mocimport-module moc$verbosePreference = "Continue"# Wis de SFS-cataloguscache: Remove-Item (Get-MocConfig).manifestCache# Versie instellen op de huidige MOC-versie voorafgaand aan de update en de status instellen als update is mislukt Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Voer de MOC-update opnieuw uit naar de gewenste versie Update-Moc -version $targetMocVersionHervat de update. |
||||||||||||||||||
| AKS op Azure Local | Het maken van een AKS-cluster mislukt met de Error: Invalid AKS network resource id. Dit probleem kan optreden wanneer de naam van het gekoppelde logische netwerk een onderstrepingsteken heeft. |
Onderstrepingstekens worden niet ondersteund in namen van logische netwerken. Zorg ervoor dat u geen onderstrepingsteken gebruikt in de namen voor logische netwerken die zijn geïmplementeerd op uw lokale Azure-locatie. | ||||||||||||||||||
| Serverherstelserver | In zeldzame gevallen mislukt de Repair-Server-bewerking met de fout HealthServiceWaitForDriveFW. In deze gevallen worden de oude stations van een hersteld knooppunt niet verwijderd en blijven nieuwe schijven steken in de onderhoudsmodus. |
Om dit probleem te voorkomen, moet u ervoor zorgen dat u het knooppunt niet leegloopt via het Windows-beheercentrum of met behulp van de Suspend-ClusterNode -Drain PowerShell-cmdlet voordat u begint Repair-Server. Als het probleem zich voordoet, neemt u contact op met Microsoft Ondersteuning voor de volgende stappen. |
||||||||||||||||||
| Serverherstelserver | Dit probleem treedt op wanneer het Azure Local-exemplaar met één knooppunt wordt bijgewerkt van 2311 naar 2402 en vervolgens de Repair-Server wordt uitgevoerd. De herstelbewerking mislukt. |
Voer de volgende stappen uit voordat u het ene knooppunt herstelt: 1. Voer versie 2402 uit voor de ADPrepTool. Volg de stappen in Active Directory-voorbereiden. Deze actie is snel en voegt de vereiste machtigingen toe aan de organisatie-eenheid (OE). 2. Verplaats het computerobject van het segment Computers naar de hoofd-OE. Voer de volgende opdracht uit: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Uitrol | Als u de Active Directory zelf voorbereidt (niet het script en de procedure van Microsoft gebruikt), kan uw Active Directory-validatie mislukken met ontbrekende Generic All machtiging. Dit komt door een probleem in de validatiecontrole die controleert op een toegewezen machtigingsvermelding voor msFVE-RecoverInformationobjects – General – Permissions Full control, wat vereist is voor BitLocker-herstel. |
Gebruik de methode 'Prepare AD script', of als u uw eigen methode gebruikt, zorg ervoor dat u de specifieke machtiging msFVE-RecoverInformationobjects – General – Permissions Full controltoewijst. |
||||||||||||||||||
| Uitrol | Er is een zeldzaam probleem in deze release waarbij de DNS-record wordt verwijderd tijdens de lokale Implementatie van Azure. Wanneer dat gebeurt, wordt de volgende uitzondering gezien: 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. |
Controleer de DNS-server om te zien of er DNS-records van de knooppunten ontbreken. Pas de volgende beperking toe op de knooppunten waar de DNS-record ontbreekt. Start de DNS-clientservice opnieuw op. Open een PowerShell-sessie en voer de volgende cmdlet uit op het betreffende knooppunt: Taskkill /f /fi "SERVICES eq dnscache" |
||||||||||||||||||
| Uitrol | In deze release is er een fout opgetreden bij een op afstand uitgevoerde taak in een multi-node-implementatie, wat resulteert in de volgende uitzondering:ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
De oplossing is het opnieuw opstarten van de ECE-agent op het betreffende knooppunt. Open een PowerShell-sessie op uw computer en voer de volgende opdracht uit:Restart-Service ECEAgent. |
||||||||||||||||||
| Server toevoegen | Bij het toevoegen van een computer aan het systeem in deze release en eerdere versies is het niet mogelijk om de lijstreeks voor het overslaan van de proxy bij te werken om de nieuwe computer op te nemen. Het bijwerken van de lijst met proxy-bypasses voor omgevingsvariabelen op de hosts zal de proxy-bypasslijst op Azure Resource Bridge of AKS niet bijwerken. | Er is geen tijdelijke oplossing in deze release. Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning om de volgende stappen te bepalen. | ||||||||||||||||||
| Server toevoegen/herstellen | In deze release wordt bij het toevoegen of herstellen van een machine een fout weergegeven wanneer de software load balancer of netwerkcontroller-VM-certificaten worden gekopieerd van de bestaande knooppunten. De fout komt doordat deze certificaten niet zijn gegenereerd tijdens de implementatie/update. | Er is geen tijdelijke oplossing in deze release. Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning om de volgende stappen te bepalen. | ||||||||||||||||||
| Uitrol | In deze release is er een tijdelijk probleem dat resulteert in de implementatiefout met de volgende uitzondering: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. |
Omdat dit een tijdelijk probleem is, zou het opnieuw uitrollen van de implementatie het moeten oplossen. Zie voor meer informatie hoe u de implementatie opnieuw kunt uitvoeren. | ||||||||||||||||||
| Uitrol | In deze release is er een probleem met het veld Geheimen-URI/locatie. Dit is een verplicht veld dat is gemarkeerd als Niet verplicht en resulteert in implementatiefouten in Azure Resource Manager-sjablonen. | Gebruik het bestand met voorbeeldparameters in het Azure Local implementeren, versie 23H2 via de Azure Resource Manager-sjabloon om ervoor te zorgen dat alle invoer wordt opgegeven in de vereiste indeling en probeer de implementatie uit te voeren. Als er een mislukte implementatie is, dient u ook de volgende resources op te schonen voordat u de implementatie opnieuw : 1. Verwijder C:\EceStore. 2. Verwijder C:\CloudDeployment. 3. Verwijder C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| Beveiliging | Voor nieuwe implementaties zijn voor apparaten die geschikt zijn voor beveiligde kernen standaard geen DRTM (Dynamic Root of Measurement) ingeschakeld. Als u probeert in te schakelen (DRTM) met behulp van de Enable-AzSSecurity-cmdlet, ziet u een foutmelding dat de DRTM-instelling niet wordt ondersteund in de huidige release. Microsoft raadt diepgaande verdediging aan en UEFI Secure Boot beveiligt de onderdelen in de SRT-opstartketen (Static Root of Trust) nog steeds door ervoor te zorgen dat ze alleen worden geladen wanneer ze zijn ondertekend en geverifieerd. |
DRTM wordt niet ondersteund in deze release. | ||||||||||||||||||
| Netwerken | Een omgevingscontrole mislukt wanneer een proxyserver wordt gebruikt. De bypasslijst is standaard anders voor winhttp en wininet, waardoor de validatiecontrole mislukt. | Volg deze tijdelijke stappen: 1. Wis de proxy-bypasslijst vóór de statuscontrole en voordat u de implementatie of de update start. 2. Wacht na het doorgeven van de controle totdat de implementatie of update mislukt. 3. Stel de lijst voor het overslaan van de proxy opnieuw in. |
||||||||||||||||||
| Arc VM-beheer | De implementatie of update van Arc Resource Bridge kan mislukken wanneer het automatisch gegenereerde tijdelijke SPN-geheim tijdens deze bewerking begint met een afbreekstreepje. | Voer de implementatie/update opnieuw uit. Tijdens het opnieuw proberen wordt het SPN-geheim opnieuw gegenereerd en slaagt de bewerking waarschijnlijk. | ||||||||||||||||||
| Arc VM-beheer | Arc-extensies op Arc VMs blijven voor onbepaalde tijd in de status "Aan het maken". | Meld u aan bij de virtuele machine, open een opdrachtprompt en typ het volgende: Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Zoek vervolgens de eigenschap resourcename. Verwijder de GUID die is toegevoegd aan het einde van de resourcenaam, zodat deze eigenschap overeenkomt met de naam van de virtuele machine. Start vervolgens de VIRTUELE machine opnieuw op. |
||||||||||||||||||
| Arc VM-beheer | Wanneer een nieuwe machine wordt toegevoegd aan een lokaal Azure-exemplaar, wordt het opslagpad niet automatisch gemaakt voor het zojuist gemaakte volume. | U kunt handmatig een opslagpad maken voor nieuwe volumes. Zie Een opslagpad makenvoor meer informatie. | ||||||||||||||||||
| Arc VM-beheer | Het opnieuw opstarten van de Arc-VM-bewerking wordt na ongeveer 20 minuten voltooid, hoewel de VIRTUELE machine binnen ongeveer een minuut opnieuw wordt opgestart. | Er is geen bekende tijdelijke oplossing in deze release. | ||||||||||||||||||
| Arc VM-beheer | In sommige gevallen wordt de status van het logische netwerk weergegeven als Mislukt in Azure Portal. Dit gebeurt wanneer u het logische netwerk probeert te verwijderen zonder eerst resources te verwijderen, zoals netwerkinterfaces die aan dat logische netwerk zijn gekoppeld. Je moet nog resources in dit logische netwerk kunnen maken. De status is misleidend in dit geval. |
Als de status van dit logische netwerk geslaagd was op het moment dat dit netwerk werd aangelegd, kunt u resources op dit netwerk blijven opzetten. | ||||||||||||||||||
| Arc VM-beheer | Wanneer u in deze release een virtuele machine bijwerkt met een gegevensschijf die eraan is gekoppeld met behulp van de Azure CLI, mislukt de bewerking met het volgende foutbericht: Kan een virtuele harde schijf met de naamniet vinden. |
Gebruik Azure Portal voor alle VM-updatebewerkingen. Zie Arc-VM's beheren en Arc VM-resources beherenvoor meer informatie. | ||||||||||||||||||
| bijwerken | In zeldzame gevallen kan deze fout optreden tijdens het bijwerken van uw lokale Azure-exemplaar: 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]. |
Als u dit probleem ziet, neemt u contact op met Microsoft Ondersteuning om u te helpen met de volgende stappen. | ||||||||||||||||||
| Netwerken | Er is een onregelmatig DNS-clientprobleem in deze release waardoor de implementatie mislukt op een systeem met twee knooppunten met een DNS-omzettingsfout: A WebException is opgetreden tijdens het verzenden van een RestRequest. WebException.Status: NameResolutionFailure. Als gevolg van de fout wordt de DNS-record van het tweede knooppunt verwijderd kort nadat het is gemaakt, wat resulteert in een DNS-fout. | Start de computer opnieuw op. Met deze bewerking wordt de DNS-record geregistreerd, waardoor deze niet kan worden verwijderd. | ||||||||||||||||||
| Azure Portal | In sommige gevallen kan het even duren voordat Azure Portal is bijgewerkt en de weergave mogelijk niet actueel is. | Mogelijk moet u 30 minuten of langer wachten om de bijgewerkte weergave te zien. | ||||||||||||||||||
| Arc VM-beheer | Het verwijderen van een netwerkinterface op een Arc-VM vanuit Azure Portal werkt niet in deze release. | Gebruik de Azure CLI om eerst de netwerkinterface te ontkoppelen en vervolgens te wissen. Zie De netwerkinterface verwijderen en zie De netwerkinterface verwijderenvoor meer informatie. | ||||||||||||||||||
| Implementatie | Het opgeven van de OE-naam in een onjuiste syntaxis wordt niet gedetecteerd in Azure Portal. De onjuiste syntaxis bevat niet-ondersteunde tekens, zoals &,",',<,>. De onjuiste syntaxis wordt tijdens de systeemvalidatie in een latere stap gedetecteerd. |
Zorg ervoor dat de syntaxis van het OE-pad juist is en geen niet-ondersteunde tekens bevat. | ||||||||||||||||||
| Implementatie | Implementaties via Azure Resource Manager lopen na 2 uur vast. Implementaties die langer dan 2 uur duren, worden als mislukt weergegeven in de resourcegroep, hoewel het systeem succesvol is gecreëerd. | Als u de implementatie in de Azure-portal wilt bewaken, gaat u naar de resource van het lokale Azure-exemplaar en gaat u vervolgens naar nieuwe Implementaties invoer. | ||||||||||||||||||
| Azure Site Recovery | Azure Site Recovery kan niet worden geïnstalleerd op een lokaal Azure-exemplaar in deze release. | Er is geen bekende tijdelijke oplossing in deze release. | ||||||||||||||||||
| Bijwerken | Wanneer u de lokale Instantie van Azure bijwerkt via Azure Update Manager, zijn de voortgang en resultaten van de update mogelijk niet zichtbaar in Azure Portal. | U kunt dit probleem omzeilen door op elk knooppunt de volgende registersleutel toe te voegen (geen waarde nodig):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceStart vervolgens op een van de knooppunten de cloudbeheerclustergroep opnieuw op. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Hiermee wordt het probleem niet volledig opgelost, omdat de voortgangsgegevens mogelijk nog steeds niet worden weergegeven voor een duur van het updateproces. Als u de meest recente updategegevens wilt ophalen, kunt u de voortgang van de update ophalen met PowerShell. |
||||||||||||||||||
| bijwerken | Als een mislukte update in zeldzame gevallen vastloopt in een In uitvoering status in Azure Update Manager, wordt de knop Probeer het opnieuw uitgeschakeld. | Voer de volgende PowerShell-opdracht uit om de update te hervatten:Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| bijwerken | In sommige gevallen kunnen SolutionUpdate opdrachten mislukken als deze worden uitgevoerd na de opdracht Send-DiagnosticData. |
Zorg ervoor dat u de PowerShell-sessie sluit die wordt gebruikt voor Send-DiagnosticData. Open een nieuwe PowerShell-sessie en gebruik deze voor SolutionUpdate opdrachten. |
||||||||||||||||||
| bijwerken | In zeldzame gevallen, bij het toepassen van een update van 2311.0.24 op 2311.2.4, wordt de systeemstatus gerapporteerd Wordt uitgevoerd, in plaats van het verwachte Mislukt bijwerken,. | Voer de update opnieuw uit. Neem contact op met Microsoft Ondersteuning als het probleem zich blijft voordoen. | ||||||||||||||||||
| bijwerken | Pogingen om oplossingsupdates te installeren, kunnen mislukken aan het einde van de CAU-stappen met:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on.
Dit zeldzame probleem treedt op als de Cluster Name of Cluster IP Address resources niet kunnen worden gestart nadat een knooppunt opnieuw is opgestart en het meest gebruikelijk is in kleine implementaties. |
Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning voor de volgende stappen. Ze kunnen met u samenwerken om de lokale Azure-resources handmatig opnieuw op te starten en de update indien nodig te hervatten. | ||||||||||||||||||
| bijwerken | Wanneer u een systeemupdate toepast op 10.2402.3.11, reageert de Get-SolutionUpdate cmdlet mogelijk niet en mislukt uiteindelijk met een RequestTimeoutException na ongeveer 10 minuten. Dit gebeurt waarschijnlijk na een scenario voor het toevoegen of herstellen van de server. |
Gebruik de Start-ClusterGroup en Stop-ClusterGroup cmdlets om de updateservice opnieuw op te starten. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Stop-ClusterGroup
Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group"
|
Start-ClusterGroup
Een geslaagde uitvoering van deze cmdlets moet de updateservice online brengen. |
||||||||||||||||||
| Clusterbewust bijwerken | Het hervatten van de knooppuntbewerking is mislukt. | Dit is een tijdelijk probleem en kan zelfstandig worden opgelost. Wacht enkele minuten en voer de bewerking opnieuw uit. Neem contact op met Microsoft Ondersteuning als het probleem zich blijft voordoen. | ||||||||||||||||||
| Clusterbewust bijwerken | De knooppuntbewerking is langer dan 90 minuten vastgelopen. | Dit is een tijdelijk probleem en kan zelfstandig worden opgelost. Wacht enkele minuten en voer de bewerking opnieuw uit. Neem contact op met Microsoft Ondersteuning als het probleem zich blijft voordoen. |
Volgende stappen
- Lees het implementatieoverzicht.