Bekannte Probleme in der Version Azure Local 2411.1
Gilt für: Azure Local 2311.2 und höher
In diesem Artikel werden kritische bekannte Probleme und deren Umgehungsmöglichkeiten in Azure Local 2411.1 beschrieben.
Diese Versionshinweise werden laufend aktualisiert. Sobald kritische Probleme ermittelt werden, die eine Umgehung erfordern, werden sie hinzugefügt. Bevor Sie Ihre Azure Local-Instanz bereitstellen, sollten Sie die hier enthaltenen Informationen sorgfältig prüfen.
Wichtig
Informationen zu den unterstützten Update-Pfaden für diese Version finden Sie unter Versionsinformationen.
Weitere Informationen über neue Funktionen in dieser Version finden Sie unter Neuheiten in 23H2.
Bekannte Probleme für Version 2411.1
Diese Softwareversion wird der Softwareversionsnummer 2411.1.10 zugeordnet.
Wichtig
Die neuen Bereitstellungen dieser Software verwenden den Build 2411.1.10. Wenn Sie von 2408.2 aktualisiert haben, haben Sie entweder den Build 2411.0.22 oder 2411.0.24 erhalten. Beide Builds können auf 2411.1.10 aktualisiert werden.
Die Versionshinweise für diese Version enthalten die in dieser Version behobenen Probleme, bekannte Probleme in dieser Version und Probleme, die in den Versionshinweisen von früheren Versionen übernommen wurden.
Hinweis
Detaillierte Korrekturen für allgemein bekannte Probleme finden Sie im Azure Local Supportability-GitHub-Repository.
Behobene Probleme
Die folgenden Probleme werden in dieser Version behoben:
| Funktion | Problem | Problemumgehung/Kommentare |
|---|---|---|
| Arc-VM-Verwaltung | Die Neubereitstellung einer Arc-VM führt zu Verbindungsproblemen mit dieser Arc-VM und der Agent trennt die Verbindung. | |
| Upgrade | Ein Konflikt mit PowerShell-Modulen von Drittanbietern wurde behoben. | |
| Upgrade | Die unbegrenzte Protokollierung von vernachlässigbaren Fehlerereignissen wurde beendet. | |
| Upgrade | Eine Validierung wurde hinzugefügt, um den freien Arbeitsspeicher zu überprüfen. | |
| Aktualisieren von | Es wurde eine Prüfung hinzugefügt, um sicherzustellen, dass der Inhalt der Lösungserweiterung korrekt kopiert wurde. | |
| Bereitstellung Upgrade |
Wenn die Zeitzone nicht auf UTC festgelegt ist, bevor Sie Azure Local bereitstellen, tritt bei der Validierung ein ArcOperationTimeOut-Fehler auf. Es wird die folgende Fehlermeldung angezeigt: *OperationTimeOut, No updates received from device for operation. | |
| Sicherheitsschwachstelle | Microsoft hat eine Sicherheitsschwachstelle identifiziert, durch die die lokalen Anmeldeinformationen, die bei der Erstellung von Arc-VMs auf Azure Local verwendet werden, für Benutzer, die keine Administratoren sind, auf der VM und auf den Hosts offengelegt werden können. Arc-VMs, die auf Versionen vor Azure Local 2411 ausgeführt werden, sind anfällig. |
Bekannte Probleme in dieser Version
In der folgenden Tabelle sind die bekannten Probleme in dieser Version aufgeführt:
| Funktion | Problem | Problemumgehung |
|---|---|---|
| Bereitstellung | Zeitüberschreitung bei der Validierung aufgrund der Deserialisierung von Zeitstempeln. | Wenn Sie das Betriebssystem bereitstellen, wählen Sie Englisch (Vereinigte Staaten) als Installationssprache sowie das Zeit- und Währungsformat. Ausführliche Schritte zur Fehlerbehebung finden Sie im Leitfaden zur Problembehandlung im Azure Local Supportability GitHub-Repository. |
Bekannte Probleme aus vorherigen Releases
In der folgenden Tabelle sind die bekannten Probleme aus früheren Versionen aufgeführt:
| Funktion | Problem | Problemumgehung | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Aktualisieren von | Bei der Aktualisierung von Version 2408.2.7 auf 2411.0.24 konnte der Aktualisierungsprozess mit der folgenden Fehlermeldung fehlschlagen: 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.' |
Detaillierte Schritte zur Behebung dieses Problems finden Sie unter Azure Local Problemlösungsanleitung für Update. | ||||||||||||||||||
| Aktualisieren von | Mit der Version 2411 werden die Lösung und die Solution Builder-Erweiterung nicht in einem einzigen Updatevorgang kombiniert. | Um ein Solution-Builder-Erweiterungspaket anzuwenden, benötigen Sie einen separaten Update-Lauf. | ||||||||||||||||||
| Aktualisieren von | Bei der Anwendung des Lösungsupdates in dieser Version kann das Update fehlschlagen. Dies tritt nur auf, wenn das Update vor dem 26. November gestartet wurde. Das Problem, das den Fehler verursacht, kann zu einer der folgenden Fehlermeldungen führen: Fehler 1 – Der Schritt "ARB und Erweiterung aktualisieren" hat den Fehler "Clear-AzContext failed with 0 and Exception calling "Initialize" with "1" argument(s): " Object reference not set to an instance of an object." bei "Clear-AzPowerShellCache". Fehler 2 – Der Schritt "EvalTVMFlow" verursacht den Fehler "CloudEngine.Actions.InterfaceInvocationFailedException: Type 'EvalTVMFlow' of Role 'ArcIntegration' raised an exception: This module requires Az.Accounts version 3.0.5. In der aktuellen PowerShell-Sitzung wird eine frühere Version von Az.Accounts importiert. Öffnen Sie eine neue Sitzung, bevor Sie dieses Modul importieren. Dieser Fehler kann ein Hinweis darauf sein, dass mehrere inkompatible Versionen der Azure PowerShell-Cmdlets auf Ihrem System installiert sind. Please see https://aka.ms/azps-version-error for troubleshooting information." Abhängig von der Version der PowerShell-Module kann der obige Fehler sowohl für die Versionen 3.0.4 als auch 3.0.5 geliefert werden. |
Detaillierte Schritte zur Behebung dieses Problems finden Sie unter: https://aka.ms/azloc-update-30221399. | ||||||||||||||||||
| Server reparieren | Nachdem Sie einen Knoten repariert und den Befehl Set-AzureStackLCMUserPassword ausgeführt haben, kann der folgende Fehler auftreten: CloudEngine.Actions.InterfaceInvocationFailedException: Type 'ValidateCredentials' of Role 'SecretRotation' raised an exception: Cannot load encryption certificate. The certificate setting 'CN=DscEncryptionCert' does not represent a valid base-64 encoded certificate, nor does it represent a valid certificate by file, directory, thumbprint, or subject name. at Validate-Credentials |
Führen Sie die folgenden Schritte zur Behebung des Problems aus: $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. Importieren Sie das erforderliche Modul: Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Überprüfen Sie den Status der ECE-Cluster-Gruppe: $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. Aktualisieren Sie die ECE mit dem neuen Kennwort: 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. Aktualisieren Sie das Kennwort im Active Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Arc-VM-Verwaltung | Die Verwendung eines exportierten Azure VM-Betriebssystem-Datenträgers als VHD, um ein Katalog-Image für die Bereitstellung einer Arc-VM zu erstellen, wird nicht unterstützt. | Führen Sie den Befehl restart-service mochostagent aus, um den Mochostagent-Dienst neu zu starten. |
||||||||||||||||||
| Networking | Wenn ein Knoten mit einem Proxy-Server konfiguriert ist, dessen Adresse Großbuchstaben enthält, wie z. B. HTTPS://10.100.000.00:8080, lassen sich Arc-Erweiterungen in bestehenden Builds, einschließlich Version 2408.1, nicht auf dem Knoten installieren oder aktualisieren. Der Knoten bleibt jedoch mit Arc verbunden. | Führen Sie die folgenden Schritte aus, um das Problem zu beheben: 1. Legen Sie die Umgebungswerte in Kleinbuchstaben fest. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Bestätigen Sie, dass die Werte festgelegt wurden. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine").3. Starten Sie die Arc-Dienste neu. Restart-Service himdsRestart-Service ExtensionServiceRestart-Service GCArcService4. Signalisieren Sie dem AzcmaAgent die Proxy-Informationen in Kleinbuchstaben. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| Networking | Wenn Arc-Maschinen ausfallen, wird auf der Seite "Alle Cluster" im neuen Portal der Status "Teilweise verbunden" oder "Kürzlich nicht verbunden" angezeigt. Selbst wenn die Arc-Maschinen funktionieren, kann es sein, dass sie nicht den Status "Verbunden" anzeigen. | Es gibt keinen bekannten Workaround für dieses Problem. Um den Konnektivitätsstatus zu überprüfen, verwenden Sie die alte Erfahrung, um zu sehen, ob er als "Verbunden" angezeigt wird. | ||||||||||||||||||
| Sicherheit | Die Sicherheitsfunktion SideChannelMitigation zeigt möglicherweise keinen aktivierten Status an, selbst wenn sie aktiviert ist. | In dieser Version gibt es keinen Workaround. Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte zu klären. | ||||||||||||||||||
| Arc-VM-Verwaltung | Der Dienst Mochostagent scheint zwar ausgeführt zu werden, kann aber über einen Monat lang ohne Aktualisierung der Protokolle stecken bleiben. Sie können dieses Problem erkennen, indem Sie die Dienstprotokolle in C:\programdata\mochostagent\logs daraufhin überprüfen, ob die Protokolle aktualisiert werden. |
Führen Sie den folgenden Befehl aus, um den Dienst mochostagent neu zu starten: restart-service mochostagent. |
||||||||||||||||||
| Upgrade | Beim Upgrade des Stempels von 2311 oder früheren Builds auf 2408 oder später können die Vorgänge Knoten hinzufügen und Knoten reparieren fehlschlagen. Beispielsweise wird der folgende Fehler angezeigt: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
In dieser Version gibt es keinen Workaround. Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte zu klären. | ||||||||||||||||||
| Aktualisieren | Wenn Sie die Ergebnisse der Readiness-Prüfung für eine Azure Local-Instanz über den Azure Update Management anzeigen, gibt es möglicherweise mehrere Readiness-Prüfungen mit demselben Namen. | In dieser Version gibt es keine bekannte Abhilfe. Wählen Sie Details anzeigen aus, um spezifische Informationen zur Bereitschaftsprüfung anzuzeigen. | ||||||||||||||||||
| 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 Ihrer Azure Local Instanz über eine Remote PowerShell-Sitzung. Um den Update-Status zu bestätigen, führen Sie die folgenden PowerShell-Cmdlets aus: $Update = get-solutionupdate| ? version -eq "<version string>"Ersetzen Sie die Versionszeichenfolge durch die Version, die Sie verwenden. Zum Beispiel: "10.2405.0.23". $Update.stateWenn der Update-Status Installiert lautet, ist keine weitere Aktion Ihrerseits erforderlich. Das Azure-Portal aktualisiert den Status korrekt innerhalb von 24 Stunden. Um den Status früher zu aktualisieren, führen Sie diese Schritte auf einem der Knoten aus. Starten Sie die Cloud Management Cluster-Gruppe neu. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Aktualisieren von | Während einer ersten MOC-Aktualisierung tritt ein Fehler auf, weil die Ziel-MOC-Version nicht im Katalog-Cache gefunden wird. Die Folge-Updates und -Wiederholungen 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 Update-Protokolle mit Fehlerbehebung bei Lösungsupdates für Azure Local, 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 Version des MOC-Agenten zu ermitteln, führen Sie 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 $targetMocVersion fest, indem Sie den Azure Local-Build suchen, auf den Sie aktualisieren, und die passende MOC-Version in der folgenden Tabelle suchen. Verwenden Sie diese Werte in dem unten angegebenen Skript zur Behebung des Problems:
Wenn die Agentversion beispielsweise v0.13.0-6-gf13a73f7, v0.11.0-alpha.38,01/06/2024 ist, heißt es dann $initialMocVersion = "1.0.24.10106", und wenn Sie auf 2405.0.23 aktualisieren, heißt es 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 Sie den SFS-Katalog-Cache. Remove-Item (Get-MocConfig).manifestCache# Setze die Version auf die aktuelle MOC-Version vor dem Update und lege den Status auf "Update fehlgeschlagen" fest. 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 die Aktualisierung fort. |
||||||||||||||||||
| Bereitstellung | In einigen Instanzen kann während der Registrierung von Azure Local-Maschinen dieser Fehler in den Debug-Protokollen angezeigt werden: Ein interner Serverfehler wurde festgestellt. Eine der obligatorischen Erweiterungen für die Bereitstellung von Geräten ist möglicherweise nicht installiert. | Führen Sie die folgenden Schritte zur Behebung des Problems aus: $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 |
||||||||||||||||||
| AKS auf Azure Local | Bei der Erstellung von AKS-Clustern tritt der Fehler Error: Invalid AKS network resource id auf. Dieses Problem kann auftreten, wenn der zugehörige logische Netzwerkname einen Unterstrich enthält. |
Unterstriche werden in logischen Netzwerknamen nicht unterstützt. Achten Sie darauf, keine Unterstriche in den Namen für logische Netzwerke zu verwenden, die auf Azure Local bereitgestellt werden. | ||||||||||||||||||
| Server reparieren | In seltenen Fällen schlägt der Repair-Server-Vorgang mit dem HealthServiceWaitForDriveFW-Fehler fehl. In diesen Fällen werden die alten Laufwerke des reparierten Knotens nicht entfernt und die neuen Datenträger bleiben im Wartungsmodus stecken. |
Um das Problem zu vermeiden, 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 weitere Schritte zu unternehmen. |
||||||||||||||||||
| Server reparieren | Dieses Problem tritt auf, wenn ein einzelner Knoten einer Azure Local-Instanz von 2311 auf 2402 aktualisiert wird und dann die Repair-Server ausgeführt wird. Der Reparaturvorgang schlägt fehl. |
Bevor Sie den einzelnen Knoten reparieren, führen Sie diese Schritte aus: 1. Führen Sie Version 2402 für das ADPrepTool aus. Folgen Sie den Schritten unter Vorbereiten von Active Directory. Diese Aktion ist schnell und fügt der Organisationseinheit (OU) 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 der fehlenden Generic All Berechtigung fehlschlagen. Dies liegt an einem Problem in der Validierungsprüfung, die nach einem dedizierten Berechtigungseintrag für msFVE-RecoverInformationobjects – General – Permissions Full controlsucht, der für die BitLocker-Wiederherstellung erforderlich ist. |
Verwenden Sie die Methode AD-Skript vorbereiten 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 Bereitstellung von Azure Local 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 zu prüfen, ob DNS-Einträge der Knoten fehlen. Wenden Sie die folgende Behebung auf die Knoten an, deren DNS-Eintrag fehlt. Starten Sie den DNS-Client-Dienst 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 Remote-Task-Fehler 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 Ihrer Maschine eine PowerShell-Sitzung und führen Sie den folgenden Befehl aus:Restart-Service ECEAgent. |
||||||||||||||||||
| Server hinzufügen | In dieser Version und in früheren Versionen ist es nicht möglich, die Zeichenfolge der Proxy-Bypass-Liste zu aktualisieren, wenn eine Maschine zum System hinzugefügt wird, um die neue Maschine einzubeziehen. Die Aktualisierung der Umgebungsvariablen Proxy-Bypass-Liste auf den Hosts führt nicht zur Aktualisierung der Proxy-Bypass-Liste auf Azure-Ressourcenbrücke oder AKS. | In dieser Version gibt es keinen Workaround. Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte zu klären. | ||||||||||||||||||
| Server hinzufügen/reparieren | In dieser Version tritt beim Hinzufügen oder Reparieren einer Maschine ein Fehler auf, wenn die Software Load-Balancer oder Network Controller VM-Zertifikate von den vorhandenen Knoten kopiert werden. Der Fehler liegt darin, dass diese Zertifikate während der Bereitstellung/Aktualisierung nicht generiert wurden. | In dieser Version gibt es keinen Workaround. Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft-Support, um die nächsten Schritte zu klären. | ||||||||||||||||||
| 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 „URI/Speicherort für Geheimnisse“. Dies ist ein Pflichtfeld, das als Nicht erforderlich gekennzeichnet ist und zu Bereitstellungsfehlern bei Azure Resource Manager-Templates führt. | Verwenden Sie die Beispiel-Parameterdatei in der Bereitstellung von Azure Local, Version 23H2 über die Azure Resource Manager-Vorlage, um sicherzustellen, dass alle Eingaben im erforderlichen Format erfolgen und versuchen Sie dann die Bereitstellung. Wenn die Bereitstellung fehlgeschlagen ist, müssen Sie auch die folgenden Ressourcen bereinigen, bevor Sie die Bereitstellung erneut starten: 1. Löschen Sie C:\EceStore. 2. Löschen Sie die 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 mithilfe des Cmdlets Enable-AzSSecurity zu aktivieren, wird ein Fehler angezeigt, 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 Überprüfung der Umgebung schlägt fehl, wenn ein Proxy-Server verwendet wird. Das Design sieht vor, dass die Bypass-Liste für winhttp und wininet unterschiedlich ist, was dazu führt, dass die Validierungsprüfung fehlschlägt. | Befolgen Sie diese Schritte zur Abhilfe: 1. Löschen Sie die Proxy-Bypass-Liste vor dem Status-Check und bevor Sie die Bereitstellung oder das Update starten. 2. Warten Sie nach bestandener Prüfung, bis die Bereitstellung oder Aktualisierung fehlschlägt. 3. Legen Sie Ihre Proxy-Bypass-Liste erneut fest. |
||||||||||||||||||
| Arc-VM-Verwaltung | Die Bereitstellung oder Aktualisierung von Arc Resource Bridge kann fehlschlagen, wenn das automatisch generierte temporäre SPN-Geheimnis während dieses Vorgangs mit einem Bindestrich beginnt. | Versuchen Sie die Bereitstellung/das Update erneut. Der erneute Versuch sollte das SPN-Secret regenerieren und der Vorgang wird wahrscheinlich erfolgreich sein. | ||||||||||||||||||
| Arc-VM-Verwaltung | Arc-Erweiterungen auf Arc-VMs bleiben auf unbestimmte Zeit im Status „Wird erstellt“. | 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 an das Ende des Ressourcennamens angehängt ist, damit diese Eigenschaft mit dem Namen der VM übereinstimmt. Starten Sie die VM anschließend neu. |
||||||||||||||||||
| Arc-VM-Verwaltung | Wenn eine neue Maschine zu einer Azure Local-Instanz hinzugefügt wird, wird der Storage-Pfad für das neu erstellte Volume nicht automatisch erstellt. | Sie können manuell einen Storage-Pfad für jedes neue Volume erstellen. Weitere Informationen finden Sie unter Erstellen eines Storage-Pfads. | ||||||||||||||||||
| Arc-VM-Verwaltung | Der Vorgang "Neustart der Arc-VM" wird nach etwa 20 Minuten abgeschlossen, obwohl die VM selbst in etwa einer Minute neu startet. | In dieser Version gibt es keine bekannte Abhilfe. | ||||||||||||||||||
| Arc-VM-Verwaltung | In einigen Instanzen 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 zuvor alle Ressourcen wie z. B. Netzwerkschnittstellen zu löschen, die mit diesem logischen Netzwerk verbunden 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 eine VM, der ein Datenträger zugeordnet ist, mit Hilfe des Azure CLI aktualisieren, schlägt der Vorgang mit der folgenden Fehlermeldung fehl Konnte keine virtuelle Festplatte mit dem Namen finden. |
Verwenden Sie das Azure-Portal für alle VM-Aktualisierungsvorgänge. Weitere Informationen finden Sie unter Verwalten von Arc-VMs und Verwalten von Arc VM Ressourcen. | ||||||||||||||||||
| Aktualisieren von | In seltenen Fällen kann dieser Fehler beim Aktualisieren Ihrer Azure Local-Instanz auftreten: 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]. |
Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft-Support, der Sie bei den nächsten Schritten unterstützt. | ||||||||||||||||||
| Networking | In dieser Version gibt es ein seltenes Problem mit dem DNS-Client, das dazu führt, dass die Bereitstellung auf einem System mit zwei Knoten mit einem DNS-Auflösungsfehler fehlschlägt: Eine WebException ist beim Senden einer RestRequest aufgetreten. WebException.Status: NameResolutionFailure. Als Folge des Fehlers wird der DNS-Eintrag des zweiten Knotens kurz nach dem Erstellen gelöscht, was zu einem DNS-Fehler führt. | Starten Sie den Computer neu. Mit diesem Vorgang wird der DNS-Eintrag registriert, was verhindert, dass er gelöscht wird. | ||||||||||||||||||
| Azure-Portal | In einigen Instanzen kann es eine Weile dauern, bis das Azure-Portal aktualisiert wird und die Ansicht ist möglicherweise nicht aktuell. | Möglicherweise müssen Sie 30 Minuten oder mehr warten, um die aktualisierte Ansicht zu sehen. | ||||||||||||||||||
| Arc-VM-Verwaltung | Das Löschen einer Netzwerkschnittstelle auf einer Arc-VM vom Azure-Portal aus funktioniert in dieser Version nicht. | Verwenden Sie das Azure CLI, um die Netzwerkschnittstelle zunächst zu entfernen und sie dann zu löschen. Weitere Informationen finden Sie unter Entfernen der Netzwerkschnittstelle und unter Löschen der Netzwerkschnittstelle. | ||||||||||||||||||
| Bereitstellung | Das Angeben 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 in einem späteren Schritt während der Systemvalidierung erkannt. |
Stellen Sie sicher, dass die Syntax des OU-Pfads korrekt ist und keine nicht unterstützten Zeichen enthält. | ||||||||||||||||||
| Bereitstellung | Bereitstellungen über den Azure Resource Manager werden nach 2 Stunden abgebrochen. Obwohl das System erfolgreich erstellt wurde, werden Bereitstellungen, die 2 Stunden überschreiten, in der Ressourcengruppe als fehlgeschlagen angezeigt. | Um die Bereitstellung im Azure-Portal zu überwachen, gehen Sie zur Ressource Azure Local Instanz und dann zum neuen Eintrag Deployments. | ||||||||||||||||||
| Azure Site Recovery | Azure Site Recovery kann in dieser Version nicht auf einer Azure Local-Instanz installiert werden. | In dieser Version gibt es keine bekannte Abhilfe. | ||||||||||||||||||
| Aktualisieren | Wenn Sie die Azure Local-Instanz über den Azure Update Management aktualisieren, sind der Aktualisierungsfortschritt und die Ergebnisse möglicherweise nicht im Azure-Portal sichtbar. | Um dieses Problem zu umgehen, fügen Sie auf jedem Knoten den folgenden Registrierungsschlüssel hinzu (kein Wert erforderlich):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceStarten Sie dann auf einem der Knoten die Cloud Management Cluster-Gruppe neu. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Dadurch wird das Problem nicht vollständig behoben, da die Fortschrittsdetails möglicherweise während eines Teils des Aktualisierungsprozesses nicht angezeigt werden. Um die neuesten Aktualisierungsdetails zu erhalten, können Sie den Aktualisierungsfortschritt mit PowerShell abrufen. |
||||||||||||||||||
| Aktualisieren von | In seltenen Fällen, wenn ein fehlgeschlagenes Update im Azure Update Manager im Status In Bearbeitung stecken bleibt, ist die Schaltfläche Erneut versuchen deaktiviert. | Um die Aktualisierung fortzusetzen, führen Sie den folgenden PowerShell-Befehl aus:Get-SolutionUpdate | Start-SolutionUpdate. |
||||||||||||||||||
| Aktualisieren von | In einigen Fällen können SolutionUpdate-Befehle fehlschlagen, wenn sie nach dem Send-DiagnosticData-Befehl 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 sie für die SolutionUpdate-Befehle. |
||||||||||||||||||
| Aktualisieren von | In seltenen Instanzen liefert der Systemstatus bei der Anwendung eines Updates von 2311.0.24 auf 2311.2.4 die Meldung Laufend anstelle der erwarteten Meldung Fehlgeschlagenes Update. | Wiederholen Sie das Update. Wenden Sie sich an den Microsoft Support, wenn das Problem weiterhin besteht. | ||||||||||||||||||
| 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 Neustart des Knotens nicht gestartet werden, und ist vor allem bei kleinen Bereitstellungen typisch. |
Wenn dieses Problem auftritt, wenden Sie sich an den Microsoft Support. Dieser kann mit Ihnen zusammenarbeiten, um die Azure Local-Ressourcen manuell neu zu starten und die Aktualisierung bei Bedarf fortzusetzen. | ||||||||||||||||||
| Aktualisieren von | Bei der Anwendung eines Systemupdates auf 10.2402.3.11 reagiert das Cmdlet Get-SolutionUpdate möglicherweise nicht und schlägt nach etwa 10 Minuten mit einer RequestTimeoutException fehl. Dies tritt wahrscheinlich nach einem Server hinzufügen oder reparieren Szenario auf. |
Verwenden Sie die Cmdlets Start-ClusterGroup und Stop-ClusterGroup, um den Update-Dienst 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 Vorgang "Knoten fortsetzen" konnte den Knoten nicht fortsetzen. | Dies ist ein vorübergehendes Problem, das sich von selbst beheben könnte. Warten Sie ein paar Minuten und versuchen Sie den Vorgang erneut. Wenden Sie sich an den Microsoft Support, wenn das Problem weiterhin besteht. | ||||||||||||||||||
| Clusterabhängige Aktualisierung | Der Vorgang "Knoten aussetzen" blieb für mehr als 90 Minuten hängen. | Dies ist ein vorübergehendes Problem, das sich von selbst beheben könnte. Warten Sie ein paar Minuten und versuchen Sie den Vorgang erneut. Wenden Sie sich an den Microsoft Support, wenn das Problem weiterhin besteht. |
Nächste Schritte
- Lesen Sie die Übersicht zur Bereitstellung.