Anzeigen bekannter Probleme in der Azure Stack HCI 2402.3-Version

Artikel
11/23/2024

Gilt für: Azure Local, Version 23H2

In diesem Artikel werden die kritischen bekannten Probleme und ihre Problemumgehungen in der Azure Stack HCI 2402.3-Version beschrieben.

Die Versionshinweise werden fortlaufend aktualisiert, und wenn schwerwiegende Probleme festgestellt werden, die eine Problemumgehung erfordern, werden sie hinzugefügt. Bevor Sie Ihren Azure Stack HCI bereitstellen, überprüfen Sie sorgfältig die in den Versionshinweisen enthaltenen Informationen.

Hinweis

Informationen zu den unterstützten Updatepfaden für diese Version finden Sie unter Azure Stack HCI, Version 23H2-Versionen.

Weitere Informationen zu den neuen Features in dieser Version finden Sie unter Neuigkeiten in 23H2.

Probleme mit Version 2402.3

Diese Softwareversion ist der Softwareversion 2402.3.10 zugeordnet.

Versionshinweise für diese Version umfassen die in dieser Version behobenen Probleme, bekannte Probleme in dieser Version und die version festgestellten Probleme, die von früheren Versionen übernommen wurden.

Behobene Probleme

Microsoft kennt in dieser Version keine behobenen Probleme.

Bekannte Probleme in dieser Version

Microsoft kennt in dieser Version keine bekannten Probleme.

Bekannte Probleme aus vorherigen Releases

Hier sind die bekannten Probleme aus früheren Versionen:

Funktion	Problem	Problemumgehung
AKS auf HCI	Die AKS-Clustererstellung schlägt mit der `Error: Invalid AKS network resource id`. Dieses Problem kann auftreten, wenn der zugeordnete logische Netzwerkname einen Unterstrich aufweist.	Unterstriche werden in logischen Netzwerknamen nicht unterstützt. Stellen Sie sicher, dass Sie keinen Unterstrich in den Namen für logische Netzwerke verwenden, die in Ihrem Azure Stack HCI bereitgestellt werden.
Reparaturserver	In seltenen Fällen schlägt der `Repair-Server` Vorgang mit dem `HealthServiceWaitForDriveFW` Fehler fehl. In diesen Fällen werden die alten Laufwerke aus dem reparierten Knoten nicht entfernt, und neue Datenträger bleiben im Wartungsmodus hängen.	Um dieses Problem zu verhindern, stellen Sie sicher, dass Sie den Knoten nicht über das Windows Admin Center oder das `Suspend-ClusterNode -Drain` PowerShell-Cmdlet entwässern, bevor Sie beginnen `Repair-Server`. Wenn das Problem auftritt, wenden Sie sich an Microsoft-Support, um die nächsten Schritte auszuführen.
Reparaturserver	Dieses Problem wird angezeigt, wenn azure Stack HCI vom 2311 auf 2402 aktualisiert und dann `Repair-Server` ausgeführt wird. Der Reparaturvorgang schlägt fehl.	Führen Sie vor der Reparatur des einzelnen Knotens die folgenden Schritte aus: 1. Führen Sie Version 2402 für das ADPrepTool aus. Führen Sie die Schritte in "Active Directory vorbereiten" aus. Diese Aktion ist schnell und fügt der Organisationseinheit (OU) die erforderlichen Berechtigungen hinzu. 2. Verschieben Sie das Computerobjekt aus dem Computersegment in die Stamm-OU. Führen Sie den folgenden Befehl aus: `Get-ADComputer <HOSTNAME>` \| `Move-ADObject -TargetPath "<OU path>"`
Bereitstellung	Wenn Sie das Active Directory eigenständig vorbereiten (nicht das von Microsoft bereitgestellte Skript und die von Microsoft bereitgestellte Prozedur), kann die Active Directory-Überprüfung mit fehlender `Generic All` Berechtigung fehlschlagen. Dies ist auf ein Problem in der Überprüfungsprüfung zurückzuführen, das auf einen dedizierten Berechtigungseintrag überprüft, für `msFVE-RecoverInformationobjects – General – Permissions Full control`den bitLocker-Wiederherstellung erforderlich ist.	Verwenden Sie die Prepare AD-Skriptmethode oder wenn Sie Ihre eigene Methode verwenden, stellen Sie sicher, dass Sie die spezifische Berechtigung `msFVE-RecoverInformationobjects – General – Permissions Full control`zuweisen.
Bereitstellung	In dieser Version gibt es ein seltenes Problem, bei dem der DNS-Eintrag während der Azure Stack HCI-Bereitstellung gelöscht wird. In diesem Fall wird die folgende Ausnahme angezeigt: 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.	Überprüfen Sie den DNS-Server, um festzustellen, ob DNS-Einträge der Clusterknoten fehlen. Wenden Sie die folgende Entschärfung auf die Knoten an, in denen ihr DNS-Eintrag fehlt. Starten Sie den DNS-Clientdienst neu. Öffnen Sie eine PowerShell-Sitzung, und führen Sie das folgende Cmdlet auf dem betroffenen Knoten aus: `Taskkill /f /fi "SERVICES eq dnscache"`
Bereitstellung	In dieser Version gibt es einen Remoteaufgabenfehler bei einer Bereitstellung mit mehreren Knoten, die zu der folgenden Ausnahme führt: `ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>).`	Die Entschärfung besteht darin, den ECE-Agent auf dem betroffenen Knoten neu zu starten. Öffnen Sie auf Ihrem Server eine PowerShell-Sitzung, und führen Sie den folgenden Befehl aus: `Restart-Service ECEAgent`.
Hinzufügen/Reparieren des Servers	In dieser Version wird beim Hinzufügen oder Reparieren eines Servers ein Fehler angezeigt, wenn die VM-Zertifikate des Softwaregeräts oder der Netzwerkcontroller-VM aus den vorhandenen Knoten kopiert werden. Der Fehler liegt daran, dass diese Zertifikate während der Bereitstellung/Aktualisierung nicht generiert wurden.	In dieser Version gibt es keine Problemumgehung. Wenn dieses Problem auftritt, wenden Sie sich an Microsoft-Support, um die nächsten Schritte zu ermitteln.
Bereitstellung	In dieser Version gibt es ein vorübergehendes Problem, das zu einem Bereitstellungsfehler mit der folgenden Ausnahme führt: `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.`	Da es sich um ein vorübergehendes Problem handelt, sollte dies durch erneutes Wiederholen der Bereitstellung behoben werden. Weitere Informationen finden Sie unter "Erneutes Ausführen der Bereitstellung".
Bereitstellung	In dieser Version gibt es ein Problem mit dem Feld "Geheimer Schlüssel-URI/Speicherort". Dies ist ein erforderliches Feld, das als nicht obligatorisch gekennzeichnet ist, und führt zu Bereitstellungsfehlern in Azure Resource Manager-Vorlagen.	Verwenden Sie die Beispielparameterdatei in der Vorlage "Bereitstellen von Azure Stack HCI, Version 23H2 über Azure Resource Manager" , um sicherzustellen, dass alle Eingaben im erforderlichen Format bereitgestellt werden, und versuchen Sie dann die Bereitstellung. Wenn es eine fehlgeschlagene Bereitstellung gibt, müssen Sie auch die folgenden Ressourcen bereinigen, bevor Sie die Bereitstellung erneut ausführen: 1. Löschen `C:\EceStore`. 2. Löschen `C:\CloudDeployment`. 3. Löschen `C:\nugetstore`. 4. `Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation`.
Sicherheit	Bei neuen Bereitstellungen sind gesicherte Core-fähige Geräte standardmäßig nicht mit dynamic Root of Measurement (DRTM) aktiviert. Wenn Sie versuchen, das Cmdlet Enable-AzSSecurity (DRTM) zu aktivieren, wird ein Fehler angezeigt, dass die DRTM-Einstellung in der aktuellen Version nicht unterstützt wird. Microsoft empfiehlt die Verteidigung im Detail, und der sichere UEFI-Start schützt weiterhin die Komponenten in der statischen SRT-Startkette (Static Root of Trust), indem sichergestellt wird, dass sie nur geladen werden, wenn sie signiert und überprüft werden.	DRTM wird in dieser Version nicht unterstützt.
Networking	Eine Umgebungsprüfung schlägt fehl, wenn ein Proxyserver verwendet wird. Standardmäßig unterscheidet sich die Umgehungsliste für winhttp und wininet, was dazu führt, dass die Überprüfung fehlschlägt.	Führen Sie die folgenden Schritte zur Problemumgehung aus: 1. Löschen Sie die Proxyumgehungsliste vor der Integritätsprüfung und vor dem Starten der Bereitstellung oder des Updates. 2. Warten Sie nach der Übergabe der Überprüfung, bis die Bereitstellung oder das Update fehlschlägt. 3. Legen Sie ihre Proxyumgehungsliste erneut fest.
Arc VM-Verwaltung	Die Bereitstellung oder Aktualisierung von Arc Resource Bridge konnte fehlschlagen, wenn der automatisch generierte temporäre SPN-Schlüssel während dieses Vorgangs mit einem Bindestrich beginnt.	Wiederholen Sie die Bereitstellung/Aktualisierung. Der Wiederholungsvorgang sollte den geheimen SPN-Schlüssel neu generieren, und der Vorgang wird wahrscheinlich erfolgreich ausgeführt.
Arc VM-Verwaltung	Arc-Erweiterungen auf Arc-VMs bleiben unbegrenzt im Zustand "Erstellen".	Melden Sie sich bei der VM an, öffnen Sie eine Eingabeaufforderung, und geben Sie Folgendes ein: Windows: `notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json` Linux: `sudo vi /var/opt/azcmagent/agentconfig.json` Suchen Sie als Nächstes die `resourcename` Eigenschaft. Löschen Sie die GUID, die am Ende des Ressourcennamens angefügt wird, sodass diese Eigenschaft mit dem Namen der VM übereinstimmt. Starten Sie die VM anschließend neu.
Arc VM-Verwaltung	Wenn einem Azure Stack HCI-Cluster ein neuer Server hinzugefügt wird, wird der Speicherpfad nicht automatisch für das neu erstellte Volume erstellt.	Sie können manuell einen Speicherpfad für alle neuen Volumes erstellen. Weitere Informationen finden Sie unter Erstellen eines Speicherpfads.
Arc VM-Verwaltung	Der Neustart des Arc-VM-Vorgangs wird nach ungefähr 20 Minuten abgeschlossen, obwohl die VM selbst in etwa einer Minute neu gestartet wird.	In dieser Version gibt es keine bekannte Problemumgehung.
Arc VM-Verwaltung	In einigen Fällen wird der Status des logischen Netzwerks in Azure-Portal als fehlgeschlagen angezeigt. Dies tritt auf, wenn Sie versuchen, das logische Netzwerk zu löschen, ohne zuerst Ressourcen wie Netzwerkschnittstellen zu löschen, die diesem logischen Netzwerk zugeordnet sind. Sie sollten weiterhin in der Lage sein, Ressourcen in diesem logischen Netzwerk zu erstellen. Der Status ist in dieser Instanz irreführend.	Wenn der Status dieses logischen Netzwerks zum Zeitpunkt der Bereitstellung dieses Netzwerks erfolgreich war, können Sie weiterhin Ressourcen in diesem Netzwerk erstellen.
Arc VM-Verwaltung	Wenn Sie in dieser Version einen virtuellen Computer mit einem mit der Azure CLI verbundenen Datenträger aktualisieren, schlägt der Vorgang mit der folgenden Fehlermeldung fehl: Eine virtuelle Festplatte mit dem Namen konnte nicht gefunden werden.	Verwenden Sie die Azure-Portal für alle VM-Updatevorgänge. Weitere Informationen finden Sie unter Manage Arc VMs and Manage Arc VM resources.
Aktualisieren von	In seltenen Fällen tritt dieser Fehler beim Aktualisieren Ihres Azure Stack HCI auf: Typ "UpdateArbAndExtensions" der Rolle "MocArb" hat eine Ausnahme ausgelöst: Ausnahmeupgradet ARB und Erweiterung in Schritt [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml].	Wenn dieses Problem angezeigt wird, wenden Sie sich an Microsoft-Support, um Sie bei den nächsten Schritten zu unterstützen.
Networking	In dieser Version gibt es ein seltenes DNS-Clientproblem, das dazu führt, dass die Bereitstellung auf einem Zwei-Knoten-Cluster mit einem DNS-Auflösungsfehler fehlschlägt: Beim Senden einer RestRequest ist eine WebException aufgetreten. WebException.Status: NameResolutionFailure. Aufgrund des Fehlers wird der DNS-Eintrag des zweiten Knotens bald gelöscht, nachdem er erstellt wurde, was zu einem DNS-Fehler führt.	Starten Sie den Server neu. Dieser Vorgang registriert den DNS-Eintrag, der verhindert, dass er gelöscht wird.
Azure-Portal	In einigen Fällen kann das Azure-Portal eine Weile dauern, bis die Ansicht aktualisiert wird, und die Ansicht ist möglicherweise nicht aktuell.	Möglicherweise müssen Sie 30 Minuten oder mehr warten, um die aktualisierte Ansicht anzuzeigen.
Arc VM-Verwaltung	Das Löschen einer Netzwerkschnittstelle auf einer Arc-VM aus Azure-Portal funktioniert in dieser Version nicht.	Verwenden Sie die Azure CLI, um zuerst die Netzwerkschnittstelle zu entfernen und dann zu löschen. Weitere Informationen finden Sie unter Entfernen der Netzwerkschnittstelle und siehe Löschen der Netzwerkschnittstelle.
Bereitstellung	Das Bereitstellen des OU-Namens in einer falschen Syntax wird im Azure-Portal nicht erkannt. Die falsche Syntax enthält nicht unterstützte Zeichen wie `&,",',<,>`z. B. . Die falsche Syntax wird bei einem späteren Schritt während der Clusterüberprüfung erkannt.	Stellen Sie sicher, dass die Syntax des OU-Pfads korrekt ist und keine nicht unterstützten Zeichen enthält.
Bereitstellung	Bereitstellungen über Azure Resource Manager timeout nach 2 Stunden. Bereitstellungen, die 2 Stunden überschreiten, werden in der Ressourcengruppe als fehlgeschlagen angezeigt, obwohl der Cluster erfolgreich erstellt wurde.	Um die Bereitstellung im Azure-Portal zu überwachen, wechseln Sie zur Azure Stack HCI-Clusterressource, und wechseln Sie dann zum neuen Eintrag für Bereitstellungen.
Azure Site Recovery	Azure Site Recovery kann in dieser Version nicht auf einem Azure Stack HCI-Cluster installiert werden.	In dieser Version gibt es keine bekannte Problemumgehung.
Aktualisieren von	Beim Aktualisieren des Azure Stack HCI-Clusters über den Azure Update Manager sind der Updatefortschritt und die Ergebnisse möglicherweise nicht im Azure-Portal sichtbar.	Um dieses Problem zu umgehen, fügen Sie auf jedem Clusterknoten den folgenden Registrierungsschlüssel hinzu (kein Wert erforderlich): `New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -force` Starten Sie dann auf einem der Clusterknoten die Cloud Management-Clustergruppe neu. `Stop-ClusterGroup "Cloud Management"` `Start-ClusterGroup "Cloud Management"` Dadurch wird das Problem nicht vollständig behoben, da die Statusdetails möglicherweise noch nicht für eine Dauer des Aktualisierungsprozesses angezeigt werden. Um die neuesten Updatedetails abzurufen, können Sie den Updatefortschritt mit PowerShell abrufen.
Aktualisieren von	Wenn ein fehlerhaftes Update in seltenen Fällen in einem Status "In Bearbeitung " im Azure Update-Manager hängen bleibt, ist die Schaltfläche "Wiederholen " deaktiviert.	Führen Sie den folgenden PowerShell-Befehl aus, um das Update fortzusetzen: `Get-SolutionUpdate`\|`Start-SolutionUpdate`.
Aktualisierungen	In einigen Fällen können Befehle fehlschlagen, `SolutionUpdate` wenn sie nach dem `Send-DiagnosticData` Befehl ausgeführt werden.	Stellen Sie sicher, dass Sie die powerShell-Sitzung schließen, die für `Send-DiagnosticData`. Öffnen Sie eine neue PowerShell-Sitzung, und verwenden Sie sie für `SolutionUpdate` Befehle.
Aktualisieren von	In seltenen Fällen meldet der Clusterstatus beim Anwenden eines Updates von 2311.0.24 auf 2311.2.4 anstelle der erwarteten Aktualisierung fehlgeschlagen.	Wiederholen Sie das Update. Wenn das Problem weiterhin besteht, wenden Sie sich an den Microsoft Support.
Aktualisieren von	Versuche zum Installieren von Lösungsupdates können am Ende der CAU-Schritte fehlschlagen mit: `There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on.` Dieses seltene Problem tritt auf, wenn die `Cluster Name` Ressourcen `Cluster IP Address` nach einem Knotenneustart nicht gestartet werden und in kleinen Clustern am häufigsten typisch sind.	Wenn dieses Problem auftritt, wenden Sie sich an Microsoft-Support, um die nächsten Schritte auszuführen. Sie können mit Ihnen zusammenarbeiten, um die Clusterressourcen manuell neu zu starten und das Update nach Bedarf fortzusetzen.
Aktualisieren von	Beim Anwenden eines Clusterupdates auf 10.2402.3.11 reagiert das `Get-SolutionUpdate` Cmdlet möglicherweise nicht und schlägt schließlich nach ungefähr 10 Minuten mit einer RequestTimeoutException fehl. Dies tritt wahrscheinlich nach einem Add- oder Reparaturserverszenario auf.	Verwenden Sie die `Start-ClusterGroup` Cmdlets `Stop-ClusterGroup` , um den Updatedienst neu zu 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` Eine erfolgreiche Ausführung dieser Cmdlets sollte den Updatedienst online schalten.
Clusterfähige Aktualisierung	Fehler beim Fortsetzen des Knotenvorgangs.	Dies ist ein vorübergehendes Problem, das allein behoben werden kann. Warten Sie einige Minuten, und wiederholen Sie den Vorgang. Wenn das Problem weiterhin besteht, wenden Sie sich an den Microsoft Support.
Clusterfähige Aktualisierung	Der Vorgang "Knoten anhalten" blieb länger als 90 Minuten hängen.	Dies ist ein vorübergehendes Problem, das allein behoben werden kann. Warten Sie einige Minuten, und wiederholen Sie den Vorgang. Wenn das Problem weiterhin besteht, wenden Sie sich an den Microsoft Support.

Nächste Schritte

Lesen Sie die Übersicht über die Bereitstellung.

Freigeben über