Bekannte Probleme in der Version Azure Local 2408
Gilt für: Azure Local 2311.2 und höher
In diesem Artikel werden wichtige bekannte Probleme und ihre Problemumgehungen in der Version Azure Local 2408 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, lesen Sie die hier enthaltenen Informationen sorgfältig durch.
Wichtig
Informationen zu den unterstützten Updatepfaden für diese Version finden Sie unter Versionsinformationen.
Weitere Informationen zu neuen Funktionen in dieser Version finden Sie unter Neues in 23H2.
Bekannte Probleme in Version 2408
Diese Softwareveröffentlichung ist der Softwareversionsnummer 2408.0.29zugeordnet.
Die Versionshinweise umfassen die in dieser Version behobenen Probleme, bekannte Probleme in dieser Version und aus früheren Versionen übernommene Versionshinweise.
Hinweis
Ausführliche Informationen zur Behebung bekannter Probleme finden Sie im GitHub-Repository Unterstützungsmöglichkeiten für Azure Local.
Behobene Probleme
In dieser Version wurden die folgenden Probleme behoben:
| Funktion | Problem | Problemumgehung/Kommentare |
|---|---|---|
| Updates | Ein Aktualisierungsproblem im Zusammenhang mit dem fehlenden Feld für die Ressourcentyp-ID in den Integritätsprüfungen wurde behoben. | |
| Updates | Ein Updateproblem bei verschiedenen Gesundheitsüberprüfungen mit demselben Namen wurde behoben. | |
| 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. |
Bekannte Probleme in dieser Version
In der folgenden Tabelle sind die bekannten Probleme in dieser Version aufgeführt:
| Funktion | Problem | Problemumgehung |
|---|---|---|
| Server reparieren | Nachdem Sie einen Knoten repariert und den Befehl Set-AzureStackLCMUserPassword ausgeführt haben, tritt möglicherweise folgender Fehler auf: 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 |
Gehen Sie folgendermaßen vor, um das Problem zu beheben: $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-Clustergruppe: $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-Clustergruppe 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 in 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 Katalogimage 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. |
| Arc-VM-Verwaltung | Wenn Sie versuchen, die Gastverwaltung auf einer migrierten VM zu aktivieren, schlägt der Vorgang mit dem folgenden Fehler fehl: (InternalError) Der Zugangswebhook "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com" hat die Anforderung verweigert: OsProfile kann nach der Ressourcenerstellung nicht geändert werden. | |
| Networking | Wenn ein Knoten mit einem Proxyserver konfiguriert ist, der Großbuchstaben in seiner Adresse hat, wie z. B. HTTPS://10.100.000.00:8080, können Arc-Erweiterungen in bestehenden Builds, einschließlich Version 2408, nicht auf dem Knoten installiert oder aktualisiert werden. Der Knoten bleibt jedoch mit Arc verbunden. | Gehen Sie folgendermaßen vor, um das Problem zu beheben: 1. Legen Sie als Umgebungswerte Kleinbuchstaben fest. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Überprüfen Sie, ob 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 AzcmaAgent die Proxyinformationen 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-Computer ausfallen, wird auf der Seite Alle Cluster im neuen Portal der Status Teilweise verbunden oder Kürzlich nicht verbunden angezeigt. Selbst wenn die Arc-Computer fehlerfrei sind, zeigen sie möglicherweise nicht den Status „Verbunden“ an. | Für dieses Problem gibt es keine bekannte Problemumgehung. Um den Verbindungsstatus zu überprüfen, verwenden Sie die alte Umgebung, um zu sehen, ob Verbunden angezeigt wird. |
| 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. Um den erwarteten Wert zu überprüfen, führen Sie 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 das Ergebnis Ihrer Ausgabe mit dem erwarteten Ergebnis übereinstimmt, können Sie die Ausgabe des Windows Admin Centers und des Get-AzSSecurity-Cmdlets sicher ignorieren. |
| 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 identifizieren, indem Sie die Dienstprotokolle unter C:\programdata\mochostagent\logs auf Aktualisierung der Protokolle überprüfen. |
Führen Sie folgenden Befehl aus, um den Mochostagent-Dienst 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 zum Hinzufügen und Reparieren von Knoten fehlschlagen. Beispielsweise wird der folgende Fehler angezeigt: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
Es gibt keinen Workaround in dieser Version. Wenden Sie sich bei diesem Problem an den Microsoft-Support, um Anweisungen zu weiteren Maßnahmen zu erhalten. |
| Aktualisieren | Bei der Installation eines SBE-Updates für Ihr Azure Local-System werden einige SBE-Schnittstellen nicht auf allen Rechnern ausgeführt, wenn der Hostname im Cluster eine Teilmenge eines anderen Hostnamens ist. Zum Beispiel ist Host-1 eine Untermenge von Host-10. Dies kann zu Fehlern bei der CAU-Überprüfung oder CAU-Ausführung führen. | Microsoft empfiehlt die Verwendung von mindestens 2 Ziffern für die Anzahl der Hostnamen-Instanzen in Ihren Host-Namenskonventionen. Weitere Informationen finden Sie unter Definieren der Namenskonvention. |
Bekannte Probleme aus vorherigen Releases
In der folgenden Tabelle sind die bekannten Probleme aus früheren Versionen aufgeführt:
| Funktion | Problem | Problemumgehung | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Aktualisieren | Wenn Sie die Ergebnisse der Bereitschaftsprüfung für eine Azure Local-Instanz über den Azure Update Manager anzeigen, gibt es möglicherweise mehrere Bereitschaftsprüfungen mit demselben Namen. | In dieser Version gibt es keine bekannte Problemumgehung. Wählen Sie Details anzeigen aus, um spezifische Informationen zur Bereitschaftsprüfung anzuzeigen. | ||||||||||||||||||
| Bereitstellung | In einigen Fällen kann beim Registrieren von Azure-Lokalmachinen dieser Fehler in den Debugprotokollen angezeigt werden: Ein interner Serverfehler ist aufgetreten. Eine der obligatorischen Erweiterungen für die Bereitstellung von Geräten ist möglicherweise nicht installiert. | Gehen Sie folgendermaßen vor, 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 zeitweiliges Problem, bei dem das Azure-Portal den Updatestatus fälschlicherweise als Fehler beim Aktualisieren oder Wird ausgeführt meldet, obwohl das Update abgeschlossen ist. | Stellen Sie über eine Remote-PowerShell-Sitzung eine Verbindung zu Ihrer lokalen Azure-Instanz her. Führen Sie folgende 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 ausführen. Beispiel: „10.2405.0.23“. $Update.stateLautet der Updatestatus Installiert, ist keine weitere Aktion Ihrerseits erforderlich. Das Azure-Portal aktualisiert den Status innerhalb von 24 Stunden ordnungsgemäß. Um den Status früher zu aktualisieren, führen Sie diese Schritte auf einem der Clusterknoten aus. Starten Sie die Clustergruppe für Cloud Management. 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 wurde. Die Nachverfolgungsupdates und -wiederholungsversuche zeigen MOC in der Zielversion an, ohne dass das Update erfolgreich war. Infolgedessen ist die Aktualisierung der Arc-Ressourcenbrücke nicht erfolgreich. Um dieses Problem zu überprüfen, sammeln Sie die Updateprotokolle 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}" }] |
Gehen Sie folgendermaßen vor, um das Problem zu beheben: 1. Um die MOC-Agentversion zu finden, 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 im unten angegebenen Abhilfeskript:
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 Sie auf 2405.0.23 aktualisieren, dann $targetMocVersion = "1.3.0.10418".3. Führen Sie folgende 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"# SFS-Katalogcache löschen Remove-Item (Get-MocConfig).manifestCache# Setzen Sie die Version auf die aktuelle MOC-Version vor dem Update und setzen Sie den Status auf "Update fehlgeschlagen". Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# MOC-Update als gewünschte Version erneut ausführen Update-Moc -version $targetMocVersion4. Fahren Sie mit dem Update fort. |
||||||||||||||||||
| AKS in HCI | Bei der Erstellung von AKS-Clustern tritt der Fehler Error: Invalid AKS network resource id auf. Dieses Problem kann auftreten, wenn der Name des zugeordneten logischen Netzwerks einen Unterstrich aufweist. |
Unterstriche werden in Namen logischer Netzwerke nicht unterstützt. Achten Sie darauf, keine Unterstriche in den Namen für logische Netzwerke zu verwenden, die auf Ihrer Azure Local-Instanz 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 vermeiden, stellen Sie sicher, dass Sie den Knoten NICHT über Windows Admin Center oder mit dem PowerShell-Cmdlet Suspend-ClusterNode -Drain leeren, bevor Sie Repair-Server starten. Wenn das Problem weiterhin auftritt, wenden Sie sich an den Microsoft-Support, um Informationen zu den nächsten Schritten zu erhalten. |
||||||||||||||||||
| Server reparieren | Dieses Problem tritt auf, wenn die Azure Local-Instanz mit einem Knoten von 2311 auf 2402 aktualisiert wird und dann Repair-Server ausgeführt wird. Der Reparaturvorgang schlägt fehl. |
Führen Sie vor der Reparatur des Einzelknotens folgende 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 Active Directory selbst vorbereiten (und nicht das von Microsoft bereitgestellte Skript und Verfahren verwenden), könnte Ihre Active Directory-Validierung wegen fehlender Generic All-Berechtigung fehlschlagen. Dies liegt an einem Problem in der Überprüfung, die nach einem dedizierten Berechtigungseintrag für msFVE-RecoverInformationobjects – General – Permissions Full control sucht, der für die BitLocker-Wiederherstellung erforderlich ist. |
Verwenden Sie die Methode Vorbereiten des AD-Skripts, oder stellen Sie bei Verwendung einer eigenen Methode 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 Local-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 Computer eine PowerShell-Sitzung, und führen Sie folgenden Befehl aus:Restart-Service ECEAgent. |
||||||||||||||||||
| Server hinzufügen | In dieser Version und in früheren Versionen ist es beim Hinzufügen einer Maschine zum Cluster nicht möglich, die Proxy-Umgehungsliste so zu aktualisieren, dass sie die neue Maschine enthält. Die Aktualisierung der Proxyumgehungsliste mit Umgebungsvariablen auf den Hosts führt nicht zur Aktualisierung der Proxyumgehungsliste für die Azure-Ressourcenbrücke oder AKS. | Es gibt keinen Workaround in dieser Version. Wenden Sie sich bei diesem Problem an den Microsoft-Support, um Anweisungen zu weiteren Maßnahmen zu erhalten. | ||||||||||||||||||
| Server hinzufügen/reparieren | In dieser Version tritt beim Hinzufügen oder Reparieren eines Computers 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 bzw. während des Updates nicht generiert wurden. | Es gibt keinen Workaround in dieser Version. Wenden Sie sich bei diesem Problem an den Microsoft-Support, um Anweisungen zu weiteren Maßnahmen zu erhalten. | ||||||||||||||||||
| 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 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 Local, 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 verwenden, 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 | Umgebungsprüfungen schlagen bei Verwendung eines Proxyservers fehl. Die Umgehungslisten für winhttp und wininet sind unterschiedlich, wodurch 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 automatisch generierte temporäre SPN-Geheimnis bei diesem Vorgang mit einem Bindestrich beginnt. | Versuchen Sie die Bereitstellung/das Update erneut. Durch den Wiederholungsvorgang wird der SPN-Schlüssel neu generiert, und der Vorgang wird wahrscheinlich erfolgreich ausgeführt. | ||||||||||||||||||
| 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 am Ende des Ressourcennamens, sodass diese Eigenschaft mit dem Namen der VM übereinstimmt. Starten Sie die VM anschließend neu. |
||||||||||||||||||
| Arc-VM-Verwaltung | Wenn einer Azure Local-Instanz ein neuer Computer hinzugefügt wird, wird der Speicherpfad nicht automatisch für das neu generierte Volume erstellt. | Sie können manuell einen Speicherpfad für alle neuen Volumes erstellen. Weitere Informationen finden Sie unter Erstellen eines Speicherpfads für Azure Local. | ||||||||||||||||||
| 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 für das logische Netzwerk im Azure-Portal der Status „Fehler“ 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 eine VM mithilfe eines mit Azure CLI verbundenen Datenträgers aktualisieren, schlägt der Vorgang mit folgender Fehlermeldung fehl: Unter diesem Namen konnte keine virtuelle Festplatte gefunden werden. |
Verwenden Sie das Azure-Portal für alle VM-Updatevorgänge. Weitere Informationen finden Sie unter Arc-VMs verwalten und Arc-VM-Ressourcen verwalten. | ||||||||||||||||||
| 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]. |
Wenden Sie sich bei diesem Problem an den Microsoft-Support, um Unterstützung bei den nächsten Schritten zu erhalten. | ||||||||||||||||||
| Networking | In dieser Version gibt es ein seltenes DNS-Clientproblem, wodurch die Bereitstellung auf einem Zwei-Knoten-Cluster durch eine DNS-Auflösungsfehler fehlschlägt: Beim Senden von „RestRequest“ wurde „WebException“ gemeldet. WebException.Status: NameResolutionFailure. Aufgrund des Fehlers wird der DNS-Eintrag des zweiten Knotens gleich nach dem Erstellen gelöscht, was zu einem DNS-Fehler führt. | Starten Sie den Computer neu. Dieser Vorgang registriert den DNS-Eintrag und verhindert somit, dass dieser gelöscht wird. | ||||||||||||||||||
| Azure-Portal | In einigen Fällen kann das Aktualisieren des Azure-Portals möglicherweise etwas dauern, und die Ansicht ist möglicherweise nicht aktuell. | Möglicherweise müssen Sie 30 Minuten oder mehr warten, bis Ihnen die aktualisierte Ansicht angezeigt wird. | ||||||||||||||||||
| Arc-VM-Verwaltung | Das Löschen einer Netzwerkschnittstelle auf einer Arc-VM aus dem Azure-Portal funktioniert in dieser Version nicht. | Verwenden Sie Azure CLI, um zuerst die Netzwerkschnittstelle zu entfernen und dann zu löschen. Weitere Informationen finden Sie unter Entfernen der Netzwerkschnittstelle und Löschen der Netzwerkschnittstelle. | ||||||||||||||||||
| Bereitstellung | 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 später während der Clustervalidierung erkannt. |
Die Syntax des OU-Pfads muss korrekt sein und ausschließlich unterstützte Zeichen enthalten. | ||||||||||||||||||
| Bereitstellung | Bei Bereitstellungen über Azure Resource Manager tritt nach 2 Stunden ein Timeout auf. 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 Local-Instanzressource und dann zum neuen Eintrag Bereitstellungen. | ||||||||||||||||||
| Azure Site Recovery | Azure Site Recovery kann in dieser Version nicht in einer Azure Local-Instanz installiert werden. | In dieser Version gibt es keine bekannte Problemumgehung. | ||||||||||||||||||
| Aktualisieren | Beim Aktualisieren der Azure Local-Instanz über den Azure Update Manager sind der Updatestatus und die Updateergebnisse 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 Clustergruppe Cloud Management neu. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Dies wird das Problem nicht vollständig beheben, da die Fortschrittsdetails möglicherweise für eine gewisse Zeit des Aktualisierungsprozesses nicht angezeigt werden. Um die neuesten Updatedetails zu erhalten, können Sie den Updatestatus mit PowerShell abrufen. |
||||||||||||||||||
| Aktualisieren von | In seltenen Fällen, wenn ein fehlerhaftes Update im Status In Bearbeitung im Azure Update Manager hängen bleibt, ist die Schaltfläche Erneut versuchen deaktiviert. | Führen Sie folgenden PowerShell-Befehl aus, um mit dem Update fortzufahren:Get-SolutionUpdate | Start-SolutionUpdate. |
||||||||||||||||||
| Updates | In einigen Fällen kann der Befehl SolutionUpdate fehlschlagen, wenn er nach dem Befehl Send-DiagnosticData ausgeführt wird. |
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 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. 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 Ressourcen Cluster Name oder Cluster IP Address nach dem Neustart des Knotens nicht gestartet werden, und ist typisch für kleine Cluster. |
Wenden Sie sich bei diesem Problem an den Microsoft Support, um Informationen zu den nächsten Schritten zu erhalten. Zusammen können Sie die Clusterressourcen manuell neu starten und das Update nach Bedarf fortsetzen. | ||||||||||||||||||
| 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 zehn Minuten mit „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 möglicher von alleine behoben wird. Warten Sie ein paar Minuten, bevor Sie den Vorgang wiederholen. Wenden Sie sich an den Microsoft Support, wenn das Problem weiterhin besteht. | ||||||||||||||||||
| Clusterabhängige Aktualisierung | Der Vorgang „Knoten anhalten“ blieb für mehr als 90 Minuten hängen. | Dies ist ein vorübergehendes Problem, das möglicher von alleine behoben wird. Warten Sie ein paar Minuten, bevor Sie den Vorgang wiederholen. Wenden Sie sich an den Microsoft Support, wenn das Problem weiterhin besteht. |
Nächste Schritte
- Lesen Sie die Bereitstellungsübersicht.