Anzeigen bekannter Probleme in der Azure Stack HCI 2405-Version
Gilt für: Azure Local 2311.2 und höher
In diesem Artikel werden die kritischen bekannten Probleme und ihre Problemumgehungen in der Azure Stack HCI 2405-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.
Wichtig
Informationen zu den unterstützten aktualisierten Pfaden für diese Version finden Sie unter Versionsinformationen.
Weitere Informationen über die neuen Funktionen in dieser Version finden Sie unter Neuheiten in 23H2.
Probleme mit Version 2405
Diese Softwareversion wird der Softwareversionsnummer 2405.0.24 zugeordnet.
Die Versionshinweise zu dieser Version umfassen die in dieser Version behobenen Probleme, bekannte Probleme dieser Version und aus früheren Versionen übernommene Probleme.
Behobene Probleme
Hier sind die behobenen Probleme in dieser Version:
| Funktion | Problem | Lösungsweg/Kommentare |
|---|---|---|
| Active Directory | Bei Clusterbereitstellungen, die ein großes Active Directory verwenden, wird ein Problem behoben, das timeouts beim Hinzufügen von Benutzern zur lokalen Administratorgruppe verursachen kann. | |
| Bereitstellung | Neue ARM-Vorlagen werden für die Clustererstellung veröffentlicht, die die Erstellung von Abhängigkeitsressourcen vereinfachen. Diese Vorlagen enthalten einige Korrekturen, mit denen die fehlenden Pflichtfelder behoben wurden. | |
| Bereitstellung | Der Secret Rotation PowerShell-Befehl Set-AzureStackLCMUserPassword unterstützt einen neuen Parameter zum Überspringen der Bestätigungsnachricht. |
|
| Bereitstellung | Die Zuverlässigkeit der Secret Rotation wurde verbessert, wenn die Dienste nicht rechtzeitig neu gestartet werden. | |
| Bereitstellung | Ein Problem wurde behoben, sodass die Bereitstellung aktiviert wird, wenn ein disjoint Namespace verwendet wird. | |
| Bereitstellung | Es wurde ein Problem bei der Bereitstellung behoben, wenn die Diagnosestufe in Azure und dem Gerät eingestellt wurde. | |
| SBE | Es gibt einen neuen PowerShell-Befehl, mit dem Sie die bei der Bereitstellung bereitgestellten SBE-Partner-Eigenschaftswerte aktualisieren können. | |
| SBE | Es wurde ein Problem behoben, das dazu führte, dass der Aktualisierungsdienst nach einem reinen SBE-Aktualisierungslauf nicht auf Anforderungen reagieren konnte. | |
| Server hinzufügen Server reparieren |
Es wurde ein Problem behoben, das verhindert, dass ein Knoten während eines Vorgangs zum Hinzufügen eines Servers Active Directory beitritt. | |
| Netzwerk | Die Zuverlässigkeit von Network ATC beim Einrichten der Host-Netzwerkkonfiguration mit bestimmten Netzwerkadaptertypen wurde verbessert. | |
| Netzwerk | Verbesserte Zuverlässigkeit beim Erkennen von Firmwareversionen für Datenträgerlaufwerke. | |
| Updates | Die Zuverlässigkeit der Update-Benachrichtigungen für Ergebnisse von Systemdiagnosen, die vom Gerät an AUM (Azure Update Manager) gesendet werden, wurde verbessert. In bestimmten Fällen könnte die Nachrichtengröße zu groß sein und bewirken, dass keine Ergebnisse in AUM angezeigt werden. | |
| Updates | Es wurde ein Problem mit der Dateisperre behoben, das zu Aktualisierungsfehlern für den vertrauenswürdigen Start-VM-Agenten (IGVM) führen kann. | |
| Updates | Es wurde ein Problem behoben, durch das verhindert wurde, dass der Orchestrator-Agent während eines Update-Durchlaufs neu gestartet wird. | |
| Updates | Es wurde eine seltene Bedingung behoben, bei der es lange dauerte, bis der Updatedienst ein Update entdeckt oder gestartet hat. | |
| Updates | Es wurde ein Problem bei der Interaktion von Cluster-Aware Updating (CAU) mit dem Orchestrator behoben, wenn eine laufende Aktualisierung von CAU gemeldet wird. | |
| Updates | Das Benennungsschema für Updates wurde angepasst, um die Identifizierung von Features im Vergleich zu kumulativen Updates zu ermöglichen. | |
| Updates | Die Zuverlässigkeit der Meldung des Fortschritts der Cluster-Aktualisierung an den Orchestrator wurde verbessert. | |
| Azure Arc | Es wurde ein Problem behoben, bei dem die Azure Arc-Verbindung verloren ging, wenn der Hybrid Instance Metadata Service (HIMDS) neu gestartet wurde, wodurch die Funktionalität des Azure-Portals unterbrochen wurde. Das Gerät wird jetzt automatisch die Azure Arc-Verbindung in diesen Fällen erneut starten. |
Bekannte Probleme in dieser Version
Hier sind die bekannten Probleme in dieser Version:
| Funktion | Problem | Problemumgehung/Kommentare | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Arc-VM-Verwaltung | In großen Bereitstellungsszenarien, wie umfangreiche AVD-Hostpoolbereitstellungen oder VM-Bereitstellung im großen Stil, treten möglicherweise Zuverlässigkeitsprobleme auf, die durch ein Problem mit einer externen Hyper-V-Socketbibliothek verursacht werden. | Führen Sie die folgenden Schritte aus, um das Problem zu beheben: 1. Führen Sie den Befehl Get-service mochostagent (\) get-process (\) killaus. Überprüfen Sie die Ausgabe des Befehls, und überprüfen Sie, ob sich die Ziehpunktanzahl in den Tausenden befindet. 2. Führen Sie den Befehl Get-service mochostagent (\) get-process aus, um die Prozesse zu beenden. 3. Führen Sie den Befehl restart-service mochostagent aus, um den Mochostagent-Dienst neu zu starten. |
||||||||||||||||||
| Bereitstellung | Bei der Bereitstellung von Azure Stack HCI, Version 23H2 über das Azure-Portal, treten möglicherweise die folgenden Überprüfungsfehler bei der Bereitstellung auf: 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}]. Wenn Sie in der Azure-Portalbereitstellung zur Registerkarte Netzwerknetzwerk wechseln, wird in der Konfiguration Netzwerkabsicht der folgende Fehler angezeigt: Der ausgewählte physische Netzwerkadapter ist nicht an den virtuellen Switch für die Verwaltung gebunden. |
Befolgen Sie das Verfahren in Problembehandlung von Bereitstellungsüberprüfungsfehlern im Azure-Portal. | ||||||||||||||||||
| Bereitstellung | Die Bereitstellung über das Azure-Portal schlägt mit diesem Fehler fehl: Fehler beim Abrufen des geheimen LocalAdminCredential aus dem Azure Key Vault. | Für dieses Problem gibt es in dieser Version keine Abhilfe. Wenn das Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte auszuführen. | ||||||||||||||||||
| Bereitstellung | Das neue ISO-Image für das Betriebssystem Azure Stack HCI, Version 23H2 wurde aufgrund von Kompatibilitätsproblemen mit einigen Hardwarekonfigurationen auf eine frühere Version zurückgesetzt. | Wenn Probleme bei der Arc-Registrierung auftreten, führen Sie ein Rollback zur vorherigen Version durch. Sie müssen nichts unternehmen, wenn Sie das neuere Image bereits erfolgreich bereitgestellt haben. Beide ISO-Images sind dieselbe Betriebssystem-Buildversion. | ||||||||||||||||||
| Aktualisieren | Wenn Sie die Ergebnisse der Bereitschaftsprüfung für einen Azure Stack HCI-Cluster über den Azure Update Manager anzeigen, gibt es möglicherweise mehrere Bereitschaftsprüfungen mit demselben Namen. | In dieser Version gibt es keine bekannte Behelfslösung. Wählen Sie Details anzeigen, um spezifische Informationen über die Readiness-Prüfung anzuzeigen. | ||||||||||||||||||
| Bereitstellung | In einigen Fällen kann dieser Fehler während der Registrierung von Azure Stack HCI-Servern in den Debug-Protokollen angezeigt werden: Encountered internal server error (Interner Serverfehler aufgetreten). Eine der obligatorischen Erweiterungen für die Bereitstellung von Geräten wurde möglicherweise nicht installiert. | Führen Sie die folgenden Schritte aus, um das Problem zu beheben: $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 |
||||||||||||||||||
| Aktualisieren | In dieser Version gibt es ein gelegentliches Problem, bei dem das Azure-Portal den Update-Status fälschlicherweise als Aktualisierung fehlgeschlagen oder In Bearbeitung liefert, obwohl das Update abgeschlossen ist. | Verbinden Sie sich mit Ihrem Azure Local über eine Remote PowerShell-Sitzung. Führen Sie die folgenden PowerShell-Cmdlets aus, um den Updatestatus zu bestätigen: $Update = get-solutionupdate| ? version -eq "<version string>"Ersetzen Sie die Versionszeichenfolge durch die Version, die Sie verwenden. Beispiel: "10.2405.0.23". $Update.stateWenn der Updatestatus Installiertist, ist keine weitere Aktion erforderlich. Das Azure-Portal aktualisiert den Status innerhalb von 24 Stunden ordnungsgemäß. Führen Sie diese Schritte auf einem der Clusterknoten aus, um den Status früher zu aktualisieren. Starten Sie die Cloudverwaltungsclustergruppe neu. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Aktualisieren von | Während eines anfänglichen MOC-Updates tritt ein Fehler auf, da die MOC-Zielversion nicht im Katalogcache gefunden wird. Die Nachverfolgungs-Updates und -Wiederholungsversuche zeigen MOC in der Zielversion an, ohne dass das Update erfolgreich war. Infolgedessen schlägt das Update der Arc-Ressourcenbrücke fehl. Um dieses Problem zu überprüfen, sammeln Sie die Updateprotokolle mit Fehlerbehebung bei Lösungsupdates für Azure Stack HCI, Version 23H2. Die Protokolldateien sollten eine ähnliche Fehlermeldung anzeigen (die aktuelle Version kann sich in der Fehlermeldung unterscheiden): [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ühren Sie die folgenden Schritte aus, um das Problem zu beheben: 1. Um die MOC-Agentversion zu finden, führen Sie den folgenden Befehl aus: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Verwenden Sie die Ausgabe des Befehls, um die MOC-Version in der unten stehenden Tabelle zu finden, die mit der Agent-Version übereinstimmt, und legen Sie $initialMocVersion auf diese MOC-Version fest. Legen Sie die $targetMocVersion fest, indem Sie den Azure Stack HCI-Build suchen, auf den Sie aktualisieren möchten, und die passende MOC-Version aus der Tabelle unten entnehmen. Verwenden Sie diese Werte im unten angegebenen Risikominderungsskript:
Wenn die Agentversion beispielsweise v0.13.0-6-gf13a73f7, v0.11.0-alpha.38, 01/06/2024 ist, dann $initialMocVersion = "1.0.24.10106", und wenn wir auf 2405.0.23 aktualisieren, dann $targetMocVersion = "1.3.0.10418".3. Führen Sie die folgenden PowerShell-Befehle auf dem ersten Knoten aus: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# MoC-Modul zweimal importieren import-module mocimport-module moc$verbosePreference = "Continue"# Löschen des SFS-Katalogcaches Remove-Item (Get-MocConfig).manifestCache# Setzen der Version auf die aktuelle MOC-Version vor dem Update und Setzen des Status auf "Update fehlgeschlagen" Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Führen Sie das MOC-Update auf die gewünschte Version erneut aus. Update-Moc -version $targetMocVersion4. Setzen Sie das Update fort. |
||||||||||||||||||
| Sicherheit | Die SideChannelMitigation-Sicherheitsfunktion zeigt möglicherweise keinen aktivierten Status an, selbst wenn sie aktiviert ist. Dies geschieht, wenn Sie Windows Admin Center (Clustersicherheitsansicht) verwenden oder wenn das folgende Cmdlet False zurückgibt: Get-AzSSecurity -FeatureName SideChannelMitigation. |
In dieser Version gibt es keine Problemumgehung, um die Ausgabe dieser Anwendungen zu ändern. Führen Sie zum Überprüfen des erwarteten Werts das folgende Cmdlet aus: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*"Die erwartete Ausgabe lautet: FeatureSettingsOverride: 83886152 FeatureSettingsOverrideMask: 3 Wenn Ihre Ausgabe mit der erwarteten Ausgabe übereinstimmt, können Sie die Ausgaben von Windows Admin Center und Get-AzSSecurity-Cmdlet sicher ignorieren. |
Bekannte Probleme aus früheren Versionen
Hier sind die bekannten Probleme aus früheren Versionen:
| Funktion | Problem | Problemumgehung |
|---|---|---|
| AKS auf HCI | Bei der Erstellung von AKS-Clustern tritt der Fehler Error: Invalid AKS network resource id auf. 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. |
| Server reparieren | In seltenen Fällen tritt beim Repair-Server-Vorgang der Fehler HealthServiceWaitForDriveFW auf. 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 entleeren, bevor Sie Repair-Serverstarten. Wenn das Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte auszuführen. |
| Server reparieren | Dieses Problem tritt auf, wenn die einzelne Server Azure Stack HCI von 2311 auf 2402 aktualisiert wird und dann die 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 ADPrepTool aus. Folgen Sie den Schritten unter Vorbereiten von Active Directory. Diese Aktion ist schnell und fügt der Organisationseinheit (OE) die erforderlichen Berechtigungen hinzu. 2. Verschieben Sie das Computerobjekt aus dem Segment Computer in die Stamm-OE. 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 Prozedur nutzen), kann die Active Directory-Überprüfung mit fehlender Generic All-Berechtigung fehlschlagen. Dies liegt an einem Problem in der Validierungsüberprüfung, die einen dedizierten Berechtigungseintrag für msFVE-RecoverInformationobjects – General – Permissions Full controlüberprüft, der für die 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 controlerteilen. |
| Bereitstellung | In dieser Version gibt es ein seltenes Problem, bei dem der DNS-Eintrag während der Azure Stack HCI-Bereitstellung gelöscht wird. Wenn dies geschieht, 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 Behebung auf die Knoten an, deren 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 Remotetaskfehler bei einer Bereitstellung mit mehreren Knoten, der 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 Behebung 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. |
| Server hinzufügen/reparieren | In dieser Version tritt beim Hinzufügen oder Reparieren eines Servers ein Fehler auf, wenn die Zertifikate der Softwarelastenausgleichs- oder Netzwerkcontroller-VMs von 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 den Microsoft-Support, um die nächsten Schritte zu ermitteln. |
| Bereitstellung | In dieser Version tritt ein vorübergehendes Problem auf, bei dem die Bereitstellung mit der folgenden Ausnahme fehlschlägt: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 zeitweiliges Problem handelt, sollte ein erneuter Versuch der Bereitstellung das Problem beheben. Weitere Informationen finden Sie unter Erneutes Ausführen der Bereitstellung. |
| Bereitstellung | In dieser Version gibt es ein Problem mit dem Feld "Geheimnis-URI/Standort". Dies ist ein erforderliches Feld, das mit Nicht obligatorisch markiert ist. Es führt dazu, dass bei der Bereitstellung der Azure Resource Manager-Vorlage ein Fehler auftritt. | Verwenden Sie die Beispielparameterdatei unter Bereitstellen von Azure Stack HCI, Version 23H2 über die Azure Resource Manager-Bereitstellungsvorlage, um sicherzustellen, dass alle Eingaben im erforderlichen Format erfolgen. Wiederholen Sie dann die Bereitstellung. Wenn die Bereitstellung fehlgeschlagen ist, müssen Sie auch die folgenden Ressourcen bereinigen, bevor Sie die Bereitstellung erneut ausführen: 1. Löschen Sie C:\EceStore. 2. Löschen Sie C:\CloudDeployment. 3. Löschen Sie C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
| Sicherheit | Bei neuen Bereitstellungen ist bei Secured-Core-fähigen Geräten DRTM (Dynamic Root of Measurement) standardmäßig nicht aktiviert. Wenn Sie versuchen, DRTM mit dem Cmdlet Enable-AzSSecurity zu aktivieren, erhalten Sie eine Fehlermeldung, dass die DRTM-Einstellung in der aktuellen Version nicht unterstützt wird. Microsoft empfiehlt eine tiefgreifende Verteidigung, und UEFI Secure Boot schützt die Komponenten in der SRT-Startkette (Static Root of Trust), indem sichergestellt wird, dass sie nur geladen werden, wenn sie signiert und verifiziert sind. |
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. | Befolgen Sie diese Schritte zur Umgehung: 1. Löschen Sie die Proxyumgehungsliste vor der Integritätsprüfung und vor dem Starten der Bereitstellung oder des Updates. 2. Warten Sie nach bestandener Prüfung, bis die Bereitstellung oder Aktualisierung fehlschlägt. 3. Legen Sie Ihre Proxy-Umgehungsliste erneut fest. |
| Arc-VM-Verwaltung | Die Bereitstellung oder Aktualisierung von Arc Resource Bridge kann fehlschlagen, wenn das während dieses Vorgangs automatisch generierte temporäre SPN-Geheimnis mit einem Bindestrich beginnt. | Versuchen Sie die Bereitstellung/Aktualisierung erneut. 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 auf unbestimmte Zeit im Status "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 Als Nächstes suchen Sie die Eigenschaft resourcename. Löschen Sie die GUID, die am Ende des Ressourcennamens angefügt wird, sodass diese Eigenschaft mit dem Namen der VM übereinstimmt. Starten Sie dann den virtuellen Computer 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 im 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 diesem Fall 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: Es konnte keine virtuelle Festplatte mit dem Namengefunden werden. |
Verwenden Sie das Azure-Portal für alle VM-Updatevorgänge. Weitere Informationen finden Sie unter Verwalten von Arc-VMs und Verwalten von Arc-VM-Ressourcen. |
| Aktualisieren von | In seltenen Fällen können Sie auf diesen Fehler stoßen, wenn Sie Ihr Azure Stack HCI aktualisieren: Der Typ "UpdateArbAndExtensions" der Rolle "MocArb" hat eine Ausnahme ausgelöst: Ausnahme beim Upgrade von ARB und Erweiterung in Schritt [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Ungültiges applianceyaml = [C:\AksHci\hci-appliance.yaml]. | Wenn dieses Problem angezeigt wird, wenden Sie sich an den 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 dauert das Aktualisieren des Azure-Portals möglicherweise eine Weile, und die Ansicht ist möglicherweise nicht aktuell. | Möglicherweise müssen Sie 30 Minuten oder mehr warten, bis die aktualisierte Ansicht sichtbar ist. |
| Arc-VM-Verwaltung | Das Löschen einer Netzwerkschnittstelle auf einer Arc-VM aus dem 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. |
| Einsatz | Die Angabe des OE-Namens in einer falschen Syntax wird im Azure-Portal nicht erkannt. Die falsche Syntax enthält nicht unterstützte Zeichen wie &,",',<,>. 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. |
| Einsatz | Bereitstellungen über Azure Resource Manager werden nach 2 Stunden abgebrochen. Bereitstellungen, die länger als 2 Stunden dauern, werden in der Ressourcengruppe als fehlerhaft angezeigt, obwohl der Cluster erfolgreich erstellt wurde. | Um die Bereitstellung im Azure-Portal zu überwachen, gehen Sie zur Azure Stack HCI-Clusterressource und dann zum neuen Eintrag 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" -forceStarten 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 Fortschrittsdetails möglicherweise während des Aktualisierungsprozesses noch nicht angezeigt werden. Um die neuesten Update-Details zu erhalten, können Sie den Update-Fortschritt mit PowerShell abrufen. |
| Aktualisieren von | In seltenen Fällen, wenn ein fehlgeschlagenes Update im Azure Update Manager in einem Laufenden-Status festhängt, ist die Schaltfläche Erneut versuchen deaktiviert. | Führen Sie den folgenden PowerShell-Befehl aus, um das Update fortzusetzen:Get-SolutionUpdate | Start-SolutionUpdate. |
| Updates | In einigen Fällen können SolutionUpdate Befehle fehlschlagen, wenn sie nach dem befehl Send-DiagnosticData ausgeführt werden. |
Stellen Sie sicher, dass Sie die für Send-DiagnosticData verwendete PowerShell-Sitzung schließen. Öffnen Sie eine neue PowerShell-Sitzung und verwenden Sie diese für SolutionUpdate Befehle. |
| Aktualisieren von | In seltenen Fällen ist als Clusterstatus bei der Anwendung eines Updates von 2311.0.24 auf 2311.2.4 In Bearbeitung anstelle des erwarteten Status Fehler beim Aktualisieren angegeben. | Wiederholen Sie das Update. Wenn das Problem weiterhin besteht, wenden Sie sich an den Microsoft-Support. |
| Aktualisieren von | Beim Versuch, Lösungsupdates zu installieren, kann am Ende der CAU-Schritte der folgende Fehler auftreten: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- oder Cluster IP Address-Ressourcen nach einem Knotenneustart nicht gestartet werden und in kleinen Clustern am häufigsten auftreten. |
Wenn dieses Problem auftritt, wenden Sie sich an den 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 cmdlet Get-SolutionUpdate möglicherweise nicht und schlägt schließlich nach ungefähr 10 Minuten mit einer RequestTimeoutException fehl. Dies tritt wahrscheinlich nach einem Szenarion zum Hinzufügen oder Reparieren eines Servers auf. |
Verwenden Sie die Cmdlets Start-ClusterGroup und Stop-ClusterGroup, um den Updatedienst neu zu starten. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Stop-ClusterGroupGet-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Start-ClusterGroupDurch eine erfolgreiche Ausführung dieser Cmdlets sollte der Updatedienst online geschaltet werden. |
| Clusterabhängige Aktualisierung | Der Knoten konnte mithilfe des Vorgangs „Knoten fortsetzen“ nicht fortgesetzt werden. | 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. |
| Clusterabhängige Aktualisierung | Der Vorgang „Knoten anhalten“ blieb für mehr 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 Bereitstellungsübersicht.