Bekende problemen weergeven in azure Stack HCI 2405-release
Van toepassing op: Azure Local, versie 23H2
In dit artikel worden de kritieke bekende problemen en hun tijdelijke oplossingen in azure Stack HCI 2405-release geïdentificeerd.
De releaseopmerkingen worden continu bijgewerkt, en zodra kritieke problemen worden ontdekt die een tijdelijke oplossing vereisen, worden die toegevoegd. Bekijk de informatie in de releaseopmerkingen zorgvuldig voordat u uw Azure Stack HCI implementeert.
Belangrijk
Zie voor informatie over ondersteunde updatepaden voor deze release Release-informatie.
Zie Wat is er nieuw in 23H2voor meer informatie over de nieuwe functies in deze release.
Problemen met versie 2405
Deze softwarerelease wordt toegewezen aan het softwareversienummer 2405.0.24.
Releaseopmerkingen voor deze versie omvatten de problemen die zijn opgelost in deze release, bekende problemen in deze release en opmerkingen bij de release die zijn overgedragen uit eerdere versies.
Problemen opgelost
Dit zijn de opgeloste problemen in deze release:
| Functie | Kwestie | Tijdelijke oplossing/opmerkingen |
|---|---|---|
| Active Directory | Tijdens clusterimplementaties die gebruikmaken van een grote Active Directory, is een probleem opgelost dat time-outs kan veroorzaken bij het toevoegen van gebruikers aan de lokale beheerdersgroep. | |
| Uitrol | Er worden nieuwe ARM-sjablonen uitgebracht voor het maken van clusters die de creatie van afhankelijkheidsbronnen vereenvoudigen. Deze sjablonen bevatten enkele oplossingen die betrekking hebben op de ontbrekende verplichte velden. | |
| Uitrol | De PowerShell-opdracht voor geheimrotatie Set-AzureStackLCMUserPassword ondersteunt een nieuwe parameter om het bevestigingsbericht over te slaan. |
|
| Implementatie | Verbeterde betrouwbaarheid van geheimrotatie wanneer services niet tijdig opnieuw worden opgestart. | |
| Uitrol | Er is een probleem opgelost, zodat de implementatie is ingeschakeld wanneer een niet-aaneengesloten naamruimte wordt gebruikt. | |
| Uitrol | Er is een probleem opgelost bij de implementatie bij het instellen van het diagnostische niveau in Azure en het apparaat. | |
| SBE- | Er wordt een nieuwe PowerShell-opdracht uitgebracht die kan worden gebruikt om de eigenschapswaarden van de SBE-partner bij te werken die tijdens de implementatie zijn opgegeven. | |
| SBE | Er is een probleem opgelost waardoor de updateservice niet kon reageren op aanvragen nadat een SBE-update alleen is uitgevoerd. | |
| Server toevoegen Serverherstelserver |
Er is een probleem opgelost dat verhindert dat een knooppunt lid wordt van Active Directory tijdens een bewerking van een add-server. | |
| Netwerken | Verbeterde betrouwbaarheid van Network ATC bij het instellen van de hostnetwerkconfiguratie met bepaalde netwerkadaptertypen. | |
| Netwerken | Verbeterde betrouwbaarheid bij het detecteren van firmwareversies voor schijfstations. | |
| Bijwerkingen | Verbeterde betrouwbaarheid van updatemeldingen voor statuscontroleresultaten die van het apparaat naar AUM (Azure Update Manager) worden verzonden. In bepaalde gevallen kan de berichtgrootte te groot zijn en worden er geen resultaten weergegeven in AUM. | |
| Bijwerkingen | Er is een probleem opgelost met bestandsvergrendeling dat kan leiden tot updatefouten voor de trusted launch VM-agent (IGVM). | |
| Bijwerkingen | Er is een probleem opgelost waardoor de orchestratoragent niet opnieuw werd opgestart tijdens een updateuitvoering. | |
| Bijwerkingen | Er is een zeldzame situatie opgelost waarbij het lang duurde voordat de updateservice een update ontdekte of startte. | |
| Bijwerkingen | Er is een probleem opgelost voor de Cluster-Aware Updating (CAU)-interactie met de orchestrator wanneer een update in uitvoering is, zoals gerapporteerd door CAU. | |
| Updates | Het naamgevingsschema voor updates is aangepast om de identificatie van functies versus cumulatieve updates mogelijk te maken. | |
| Updates | Verbeterde betrouwbaarheid van het rapporteren van de voortgang van de clusterupdate aan de orchestrator. | |
| Azure Arc | Er is een probleem opgelost waarbij de Azure Arc-verbinding is verbroken toen de Hybrid Instance Metadata Service (HIMDS) opnieuw werd opgestart, waardoor de functionaliteit van De Azure-portal wordt verbroken. In deze gevallen wordt de Azure Arc-verbinding automatisch opnieuw gestart op het apparaat. |
Bekende problemen in deze release
Dit zijn de bekende problemen in deze release:
| Kenmerk | Probleem | Tijdelijke oplossing/opmerkingen | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Arc VM-beheer | In grote implementatiescenario's, zoals uitgebreide AVD-hostgroepimplementaties of grootschalige VM-inrichting, kunnen er betrouwbaarheidsproblemen optreden die worden veroorzaakt door een probleem met de externe bibliotheek van Hyper-V socket. | Volg deze stappen om het probleem te verhelpen: 1. Voer de opdracht Get-service mochostagent (\) get-process (\) killuit. Controleer de uitvoer van het commando en controleer of het aantal handvatten in de duizenden ligt. 2. Voer de opdracht Get-service mochostagent (\) get-process uit om de processen te beëindigen. 3. Voer de opdracht restart-service mochostagent uit om de mochostagent-service opnieuw op te starten. |
||||||||||||||||||
| Uitrol | Bij het implementeren van Azure Stack HCI, versie 23H2 via Azure Portal, kan het zijn dat de volgende implementatievalidatiefout optreedt: 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}]. Als u naar het tabblad Netwerken in het Azure-portaal gaat, ziet u binnen de Netwerkintentie configuratie de volgende fout: de geselecteerde fysieke netwerkadapter is niet gekoppeld aan de virtuele beheerswitch. |
Volg de procedure in Problemen met implementatievalidatiefouten in Azure Portal oplossen. | ||||||||||||||||||
| Uitrol | De implementatie via Azure Portal mislukt met deze fout: Kan geen geheim LocalAdminCredential ophalen uit de sleutelkluis. | Er is geen tijdelijke oplossing voor dit probleem in deze release. Als het probleem zich voordoet, neemt u contact op met Microsoft Ondersteuning voor de volgende stappen. | ||||||||||||||||||
| Uitrol | De nieuwe ISO-installatiekopieën voor het Besturingssysteem Azure Stack HCI, versie 23H2, zijn teruggedraaid naar een eerdere versie vanwege compatibiliteitsproblemen met sommige hardwareconfiguraties. | Als u problemen ondervindt bij het registreren van Arc, gaat u terug naar de vorige versie. Er is geen actie van u vereist als u de nieuwere versie van de installatiekopie al hebt geïmplementeerd. Beide ISO-installatiekopieën zijn dezelfde buildversie van het besturingssysteem. | ||||||||||||||||||
| bijwerken | Wanneer u de resultaten van de gereedheidscontrole voor een Azure Stack HCI-cluster 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. | ||||||||||||||||||
| Implementatie | In sommige gevallen kan deze fout tijdens de registratie van Azure Stack HCI-servers worden weergegeven in de foutopsporingslogboeken: Er is een interne serverfout 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 onterecht rapporteert als Mislukt bij te werken of In uitvoering, hoewel de update voltooid is. |
Verbinding maken met uw lokale Azure- 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 versiecode 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 ververst de status correct binnen 24 uur. Als u de status eerder wilt vernieuwen, volgt u deze stappen op een van de clusterknooppunten. 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. Om dit probleem te valideren, verzamelt u de updatelogboeken door gebruik te maken van Problemen met oplossingsupdates voor Azure Stack HCI, versie 23H2 oplossen. 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 Azure Stack HCI-build te vinden waarnaar u bijwerkt en de overeenkomende MOC-versie op te halen uit de onderstaande 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, $initialMocVersion = "1.0.24.10106" en als we bijwerken 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 $targetMocVersionDe update voortzetten. |
||||||||||||||||||
| Beveiliging | De beveiligingsfunctie SideChannelMitigation toont mogelijk geen ingeschakelde status, zelfs niet als deze is ingeschakeld. Dit gebeurt wanneer u Windows Admin Center (clusterbeveiligingsweergave) gebruikt of wanneer deze cmdlet Falseretourneert: Get-AzSSecurity -FeatureName SideChannelMitigation. |
Er is geen tijdelijke oplossing in deze release om de uitvoer van deze toepassingen te herstellen. Voer de volgende cmdlet uit om de verwachte waarde te valideren: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*"De verwachte uitvoer is: FeatureSettingsOverride: 83886152 FeatureSettingsOverrideMask: 3 Als uw uitvoer overeenkomt met de verwachte uitvoer, kunt u de uitvoer van het Windows-beheercentrum en Get-AzSSecurity cmdlet veilig negeren. |
Bekende problemen uit eerdere releases
Dit zijn de bekende problemen uit eerdere releases:
| Kenmerk | Probleem | Tijdelijke oplossing |
|---|---|---|
| AKS op HCI | 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 in uw Azure Stack HCI. |
| Serverherstelserver | In zeldzame gevallen mislukt de Repair-Server-bewerking met de fout HealthServiceWaitForDriveFW. In deze gevallen worden de oude schijven van het herstelde knooppunt niet verwijderd en blijven de nieuwe schijven in de onderhoudsmodus hangen. |
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 Azure Stack HCI met één server 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 Computers segment naar de hoofd-OE. Voer de volgende opdracht uit: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
| Implementatie | 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 AD-script voorbereiden of als u uw eigen methode gebruikt, zorg ervoor dat u de specifieke machtiging msFVE-RecoverInformationobjects – General – Permissions Full controltoewijst. |
| Implementatie | Er is een zeldzaam probleem in deze release waarbij de DNS-record wordt verwijderd tijdens de Azure Stack HCI-implementatie. 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 clusterknooppunten 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 bij een externe taakuitvoering in een implementatie met meerdere knooppunten, wat leidt tot 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>). |
Je kunt dit oplossen door de ECE-agent opnieuw op te starten op het betreffende knooppunt. Open een PowerShell-sessie op uw server en voer de volgende opdracht uit:Restart-Service ECEAgent. |
| Server toevoegen/herstellen | In deze release wordt bij het toevoegen of herstellen van een server 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. |
| Inzet | 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 helpen om de implementatie opnieuw te proberen. Zie voor meer informatie hoe u de implementatie opnieuw kunt uitvoeren. |
| Implementatie | 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 voorbeeldparametersbestand in de Azure Stack HCI implementeren, versie 23H2 via de Azure Resource Manager-sjabloon om ervoor te zorgen dat alle invoer in de vereiste indeling is opgegeven en probeer de implementatie uit te voeren. Als er een mislukte implementatie is, moet u ook de volgende resources opschonen 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-VM's blijven voor onbepaalde tijd hangen in de status "Aanmaken". | 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 server wordt toegevoegd aan een Azure Stack HCI-cluster, 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. U moet nog steeds 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 van de provisioning van dit netwerk, kunt u middelen in dit netwerk blijven aanmaken. |
| 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 Azure Stack HCI: Type 'UpdateArbAndExtensions' van rol 'MocArb' heeft een uitzondering opgeworpen: Uitzondering bij het upgraden van ARB en extensie in stap [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Ongeldig 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 incidenteel PROBLEEM met de DNS-client in deze release waardoor de implementatie mislukt op een cluster 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 server 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 los te koppelen en vervolgens te verwijderen. 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 clustervalidatie 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 verlopen na 2 uur. Implementaties die langer duren dan 2 uur worden weergegeven als mislukt in de resourcegroep, hoewel het cluster succesvol is aangemaakt. | Als u de implementatie in de Azure portal wilt monitoren, gaat u naar de Azure Stack HCI-clusterresource en vervolgens naar de nieuwe vermelding van Implementaties. |
| Azure Site Recovery | Azure Site Recovery kan niet worden geïnstalleerd op een Azure Stack HCI-cluster in deze release. | Er is geen bekende tijdelijke oplossing in deze release. |
| bijwerken | Wanneer u het Azure Stack HCI-cluster 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 clusterknooppunt de volgende registersleutel toe te voegen (geen waarde nodig):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceStart vervolgens op een van de clusterknooppunten de clustergroep Cloudbeheer opnieuw. 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 | In zeldzame gevallen wordt de knop Probeer het opnieuw uitgeschakeld als een mislukte update vastloopt in een Bezig status in Azure Update Manager. | Voer de volgende PowerShell-opdracht uit om de update te hervatten:Get-SolutionUpdate
|
Start-SolutionUpdate. |
| Bijwerkingen | 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 | Bij zeldzame gevallen, wanneer een update van 2311.0.24 naar 2311.2.4 wordt toegepast, rapporteert de clusterstatus In Progress in plaats van de verwachte Failed to update. | 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 clusters. |
Als u dit probleem ondervindt, neemt u contact op met Microsoft Ondersteuning voor de volgende stappen. Ze kunnen met u samenwerken om de clusterbronnen handmatig opnieuw op te starten en de update indien nodig te hervatten. |
| bijwerken | Wanneer u een clusterupdate toepast op 10.2402.3.11, reageert de Get-SolutionUpdate cmdlet mogelijk niet en mislukt het 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 | Hervatten van knooppuntbewerking kan knooppunt niet hervatten. | 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.