Afficher les problèmes connus dans la version d’Azure Stack HCI 2405
S’applique à : Azure Local, version 23H2
Cet article identifie les problèmes connus critiques et leurs solutions de contournement dans la version d’Azure Stack HCI 2405.
Les notes de publication sont régulièrement mises à jour ; les problèmes critiques nécessitant une solution de contournement sont ajoutés au fur et à mesure de leur découverte. Avant de déployer votre instance Azure Stack HCI, examinez attentivement les informations contenues dans les notes de publication.
Important
Pour plus d’informations sur les chemins mis à jour pris en charge pour cette version, consultez les informations de publication.
Pour plus d’informations sur les nouvelles fonctionnalités de cette version, consultez Nouveautés de la version 23H2.
Problèmes liés à la version 2405
Cette version logicielle est mappée au numéro de version logicielle 2405.0.24.
Les notes de publication de cette version incluent les problèmes résolus dans cette version, les problèmes connus de cette version et les problèmes signalés par les versions précédentes.
Problèmes résolus
Voici les problèmes résolus dans cette version :
| Fonctionnalité | Problème | Solution de contournement/Commentaires |
|---|---|---|
| Active Directory | Pendant les déploiements de cluster qui utilisent une grande instance Active Directory, un problème qui peut entraîner des délais d’expiration lors de l’ajout d’utilisateurs au groupe d’administrateurs local est résolu. | |
| Déploiement | Les nouveaux modèles ARM sont publiés pour la création de cluster qui simplifient la création de ressources de dépendance. Ces modèles incluent des correctifs qui ont traité les champs obligatoires manquants. | |
| Déploiement | La commande Set-AzureStackLCMUserPassword PowerShell de rotation des secrets prend en charge un nouveau paramètre pour ignorer le message de confirmation. |
|
| Déploiement | Amélioration de la fiabilité de la rotation des secrets lorsque les services ne redémarrent pas en temps voulu. | |
| Déploiement | Correction d’un problème afin que le déploiement soit activé lorsqu’un espace de noms disjoint est utilisé. | |
| Déploiement | Correction d’un problème lors du déploiement lors de la définition du niveau de diagnostic dans Azure et l’appareil. | |
| SBE | Une nouvelle commande PowerShell est publiée qui peut être utilisée pour mettre à jour les valeurs de propriété du partenaire SBE fournies au moment du déploiement. | |
| SBE | Correction d’un problème qui empêche le service de mise à jour de répondre aux demandes après une exécution de mise à jour SBE uniquement. | |
| Ajouter un serveur Réparer le serveur |
Un problème est résolu qui empêche un nœud de joindre Active Directory lors d’une opération d’ajout de serveur. | |
| Réseautage | Amélioration de la fiabilité de Network ATC lors de la configuration de la mise en réseau de l’hôte avec certains types de cartes réseau. | |
| Réseautage | Fiabilité améliorée lors de la détection des versions de microprogramme pour les lecteurs de disque. | |
| Mises à jour | Amélioration de la fiabilité des notifications de mise à jour pour les résultats de vérification d’intégrité envoyés de l’appareil à AUM (Azure Update Manager). Dans certains cas, la taille du message peut être trop grande et aucun résultat n’est affiché dans AUM. | |
| Mises à jour | Correction d’un problème de verrouillage de fichier pouvant entraîner des échecs de mise à jour pour l’agent de machine virtuelle de lancement approuvé (IGVM). | |
| Mises à jour | Correction d’un problème qui empêchait l’agent d’orchestrateur d’être redémarré lors d’une exécution de mise à jour. | |
| Mises à jour | Correction d’une condition rare où il a fallu beaucoup de temps pour que le service de mise à jour découvre ou démarre une mise à jour. | |
| Mises à jour | Correction d’un problème lié à l’interaction de mise à jour prenant en charge le cluster (CAU) avec l’orchestrateur lorsqu’une mise à jour en cours est signalée par la mise à jour CAU. | |
| Mises à jour | Le schéma de nommage des mises à jour a été ajusté pour permettre l’identification des fonctionnalités et des mises à jour cumulatives. | |
| Mises à jour | Amélioration de la fiabilité du signalement de la progression de la mise à jour du cluster à l’orchestrateur. | |
| Azure Arc | Résolution d’un problème où la connexion Azure Arc a été perdue lorsque le service de métadonnées d’instance hybride (HIMDS) a redémarré, cassant Portail Azure fonctionnalité. L’appareil réinitialit désormais automatiquement la connexion Azure Arc dans ces cas. |
Problèmes connus dans cette version
Voici les problèmes connus dans cette version :
| Fonctionnalité | Problème | Solution de contournement/Commentaires | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Gestion des machines virtuelles Arc | Dans les scénarios de déploiement volumineux, tels que les déploiements de pools d’hôtes AVD étendus ou l’approvisionnement de machines virtuelles à grande échelle, vous pouvez rencontrer des problèmes de fiabilité causés par un problème de bibliothèque externe de socket Hyper-V. | Procédez comme suit pour atténuer le problème : 1. Exécutez la commande Get-service mochostagent (\) get-process (\) kill. Vérifiez la sortie de la commande et vérifiez si le nombre de handles se trouve dans les milliers. 2. Exécutez la commande Get-service mochostagent (\) get-process pour arrêter les processus. 3. Exécutez la commande restart-service mochostagent pour redémarrer le service mochostagent. |
||||||||||||||||||
| Déploiement | Lors du déploiement d’Azure Stack HCI, version 23H2 via le Portail Azure, vous pouvez rencontrer l’échec de validation de déploiement suivant :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}]. Si vous accédez à l’onglet Mise en réseau dans Portail Azure déploiement, dans la configuration de l’intention réseau, vous pouvez voir l’erreur suivante : la carte réseau physique sélectionnée n’est pas liée au commutateur virtuel de gestion. |
Suivez la procédure de résolution des problèmes liés aux échecs de validation de déploiement dans Portail Azure. | ||||||||||||||||||
| Déploiement | Le déploiement via le Portail Azure échoue avec cette erreur : échec de la récupération du secret LocalAdminCredential à partir du coffre de clés. | Il n’existe aucune solution de contournement pour ce problème dans cette version. Si le problème se produit, contactez Support Microsoft pour connaître les étapes suivantes. | ||||||||||||||||||
| Déploiement | La nouvelle image ISO pour le système d’exploitation Azure Stack HCI version 23H2 a été restaurée vers une version précédente en raison de problèmes de compatibilité avec certaines configurations matérielles. | Si vous rencontrez des problèmes dans l’inscription Arc, revenez à la version précédente. Aucune action n’est requise pour vous si vous avez déjà déployé l’image la plus récente. Les deux images ISO sont la même version de build du système d’exploitation. | ||||||||||||||||||
| Mise à jour | Lorsque vous affichez les résultats de la vérification de préparation pour un cluster Azure Stack HCI via Azure Update Manager, plusieurs vérifications de préparation peuvent avoir le même nom. | Il n’existe aucune solution de contournement connue dans cette version. Sélectionnez Afficher les détails pour afficher des informations spécifiques sur la vérification de préparation. | ||||||||||||||||||
| Déploiement | Dans certains cas, lors de l’inscription des serveurs Azure Stack HCI, cette erreur peut s’afficher dans les journaux de débogage : erreur de serveur interne rencontrée. L’une des extensions obligatoires pour le déploiement d’appareils peut ne pas être installée. | Procédez comme suit pour atténuer le problème : $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 |
||||||||||||||||||
| Mise à jour | Il existe un problème intermittent dans cette version lorsque l’Portail Azure signale de manière incorrecte l’état de la mise à jour comme Ayant échoué à mettre à jour ou en cours même si la mise à jour est terminée. | Connectez-vous à votre instance Azure Local via une session PowerShell distante. Pour confirmer l’état de la mise à jour, exécutez les applets de commande PowerShell suivantes : $Update = get-solutionupdate| ? version -eq "<version string>"Remplacez la chaîne de version par la version que vous exécutez. Par exemple, « 10.2405.0.23 ». $Update.stateSi l’état de la mise à jour est installé, aucune autre action n’est requise en votre partie. Portail Azure actualise correctement l’état dans les 24 heures. Pour actualiser l’état plus tôt, suivez ces étapes sur l’un des nœuds du cluster. Redémarrez le groupe de cluster Gestion cloud. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Mettre à jour | Lors d’une mise à jour MOC initiale, une défaillance se produit en raison de la version MOC cible introuvable dans le cache du catalogue. Les mises à jour et nouvelles tentatives de suivi affichent le MOC dans la version cible, sans la réussite de la mise à jour et, par conséquent, la mise à jour Arc Resource Bridge échoue. Pour valider ce problème, collectez les journaux de mise à jour à l’aide de la résolution des problèmes liés aux mises à jour de solution pour Azure Stack HCI, version 23H2. Les fichiers journaux doivent afficher un message d’erreur similaire (la version actuelle peut différer dans le message d’erreur) : [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}" }] |
Procédez comme suit pour atténuer le problème : 1. Pour rechercher la version de l’agent MOC, exécutez la commande suivante : 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Utilisez la sortie de la commande pour rechercher la version MOC dans le tableau ci-dessous qui correspond à la version de l’agent et définissez-la $initialMocVersion sur cette version MOC. Définissez le $targetMocVersion code en recherchant la build Azure Stack HCI que vous mettez à jour et obtenez la version MOC correspondante dans le tableau ci-dessous. Utilisez ces valeurs dans le script d’atténuation fourni ci-dessous :
Par exemple, si la version de l’agent est v0.13.0-6-gf13a73f7, v0.11.0-alpha.38,01/06/2024, puis $initialMocVersion = "1.0.24.10106" si nous mettons à jour vers 2405.0.23, puis $targetMocVersion = "1.3.0.10418".3. Exécutez les commandes PowerShell suivantes sur le premier nœud : $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# Importer le module MOC deux fois import-module mocimport-module moc$verbosePreference = "Continue"# Effacer le cache du catalogue SFS Remove-Item (Get-MocConfig).manifestCache# Définir la version sur la version MOC actuelle avant la mise à jour et définir l’état en cas d’échec de la mise à jour Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Réexécuter la mise à jour MOC vers la version souhaitée Update-Moc -version $targetMocVersion4. Reprendre la mise à jour. |
||||||||||||||||||
| Sécurité | La fonctionnalité de sécurité SideChannelMitigation peut ne pas afficher un état activé même s’il est activé. Cela se produit lors de l’utilisation de Windows Admin Center (vue sécurité du cluster) ou lorsque cette applet de commande retourne False : Get-AzSSecurity -FeatureName SideChannelMitigation. |
Il n’existe aucune solution de contournement dans cette version pour corriger la sortie de ces applications. Pour valider la valeur attendue, exécutez l’applet de commande suivante : Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*"La sortie attendue est la suivante : FeatureSettingsOverride : 83886152 FeatureSettingsOverrideMask : 3 Si votre sortie correspond à la sortie attendue, vous pouvez ignorer en toute sécurité la sortie à partir de Windows Admin Center et Get-AzSSecurity de l’applet de commande. |
Problèmes connus issus des versions précédentes
Voici les problèmes connus des versions précédentes :
| Fonctionnalité | Problème | Solution de contournement |
|---|---|---|
| AKS sur HCI | La création du cluster AKS échoue avec le Error: Invalid AKS network resource id. Ce problème peut se produire lorsque le nom de réseau logique associé a un trait de soulignement. |
Les traits de soulignement ne sont pas pris en charge dans les noms de réseau logique. Veillez à ne pas utiliser de trait de soulignement dans les noms des réseaux logiques déployés sur votre instance Azure Stack HCI. |
| Réparer le serveur | Dans de rares cas, l’opération Repair-Server échoue avec l’erreur HealthServiceWaitForDriveFW . Dans ce cas, les anciens lecteurs du nœud réparé ne sont pas supprimés et les nouveaux disques sont bloqués en mode maintenance. |
Pour éviter ce problème, veillez à ne pas vider le nœud via Windows Admin Center ou à l’aide de l’applet Suspend-ClusterNode -Drain de commande PowerShell avant de commencer Repair-Server. Si le problème se produit, contactez Support Microsoft pour connaître les étapes suivantes. |
| Réparer le serveur | Ce problème s’affiche lorsque le serveur unique Azure Stack HCI est mis à jour de 2311 à 2402, puis que celui-ci Repair-Server est effectué. L’opération de réparation échoue. |
Avant de réparer le nœud unique, procédez comme suit : 1. Exécutez la version 2402 pour ADPrepTool. Suivez les étapes de préparation d’Active Directory. Cette action est rapide et ajoute les autorisations requises à l’unité d’organisation (UO). 2. Déplacez l’objet ordinateur du segment Ordinateurs vers l’unité d’organisation racine. Exécutez la commande suivante : Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
| Déploiement | Si vous préparez l’annuaire Active Directory seul (sans utiliser le script et la procédure fournis par Microsoft), votre validation Active Directory peut échouer avec l’autorisation manquante Generic All . Cela est dû à un problème dans la vérification de validation qui vérifie une entrée d’autorisation dédiée pour msFVE-RecoverInformationobjects – General – Permissions Full control, ce qui est requis pour la récupération BitLocker. |
Utilisez la méthode de script Prepare AD ou si vous utilisez votre propre méthode, veillez à affecter l’autorisation msFVE-RecoverInformationobjects – General – Permissions Full controlspécifique. |
| Déploiement | Il existe un problème rare dans cette version où l’enregistrement DNS est supprimé pendant le déploiement d’Azure Stack HCI. Lorsque cela se produit, l’exception suivante s’affiche : 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. |
Vérifiez le serveur DNS pour voir si des enregistrements DNS des nœuds de cluster sont manquants. Appliquez l’atténuation suivante sur les nœuds où son enregistrement DNS est manquant. Redémarrez le service client DNS. Ouvrez une session PowerShell et exécutez l’applet de commande suivante sur le nœud concerné : Taskkill /f /fi "SERVICES eq dnscache" |
| Déploiement | Dans cette version, il existe une défaillance de tâche distante sur un déploiement à plusieurs nœuds qui entraîne l’exception suivante :ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
L’atténuation consiste à redémarrer l’agent EAE sur le nœud concerné. Sur votre serveur, ouvrez une session PowerShell et exécutez la commande suivante :Restart-Service ECEAgent. |
| Ajouter/réparer un serveur | Dans cette version, lors de l’ajout ou de la réparation d’un serveur, une défaillance est observée lorsque l’équilibreur de charge logiciel ou les certificats de machine virtuelle du contrôleur de réseau sont copiés à partir des nœuds existants. L’échec est dû au fait que ces certificats n’ont pas été générés pendant le déploiement/la mise à jour. | Il n’existe aucune solution de contournement dans cette version. Si vous rencontrez ce problème, contactez Support Microsoft pour déterminer les étapes suivantes. |
| Déploiement | Dans cette version, il existe un problème temporaire entraînant l’échec du déploiement à l’exception suivante :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. |
Comme il s’agit d’un problème temporaire, une nouvelle tentative du déploiement doit résoudre ce problème. Pour plus d’informations, consultez comment réexécuter le déploiement. |
| Déploiement | Dans cette version, il existe un problème avec le champ URI/emplacement secrets. Il s’agit d’un champ obligatoire qui est marqué Non obligatoire et entraîne des échecs de déploiement de modèles Azure Resource Manager. | Utilisez l’exemple de fichier de paramètres dans Déployer Azure Stack HCI, version 23H2 via le modèle Azure Resource Manager pour vous assurer que toutes les entrées sont fournies dans le format requis, puis essayez le déploiement. En cas d’échec du déploiement, vous devez également nettoyer les ressources suivantes avant de réexécuter le déploiement : 1. Supprimer C:\EceStore. 2. Supprimer C:\CloudDeployment. 3. Supprimer C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
| Sécurité | Pour les nouveaux déploiements, les appareils compatibles avec le cœur sécurisé n’ont pas la racine dynamique de mesure (DRTM) activée par défaut. Si vous essayez d’activer (DRTM) à l’aide de l’applet de commande Enable-AzSSecurity, vous voyez une erreur indiquant que le paramètre DRTM n’est pas pris en charge dans la version actuelle. Microsoft recommande la défense en profondeur et le démarrage sécurisé UEFI protège toujours les composants de la chaîne de démarrage SRT (Static Root of Trust) en s’assurant qu’ils sont chargés uniquement lorsqu’ils sont signés et vérifiés. |
DRTM n’est pas pris en charge dans cette version. |
| Réseaux | Une vérification de l’environnement échoue lorsqu’un serveur proxy est utilisé. Par conception, la liste de contournement est différente pour winhttp et wininet, ce qui entraîne l’échec de la vérification de validation. | Suivez ces étapes de contournement : 1. Effacez la liste de contournement du proxy avant le contrôle d’intégrité et avant de démarrer le déploiement ou la mise à jour. 2. Après avoir passé la vérification, attendez que le déploiement ou la mise à jour échoue. 3. Définissez à nouveau votre liste de contournement de proxy. |
| Gestion des machines virtuelles Arc | Le déploiement ou la mise à jour d’Arc Resource Bridge peut échouer lorsque le secret SPN temporaire généré automatiquement pendant cette opération commence par un trait d’union. | Réessayez le déploiement/la mise à jour. La nouvelle tentative doit régénérer le secret SPN et l’opération réussit probablement. |
| Gestion des machines virtuelles Arc | Les extensions Arc sur les machines virtuelles Arc restent dans l’état « Création » indéfiniment. | Connectez-vous à la machine virtuelle, ouvrez une invite de commandes et tapez ce qui suit : Windows : notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux : sudo vi /var/opt/azcmagent/agentconfig.json Ensuite, recherchez la resourcename propriété. Supprimez le GUID ajouté à la fin du nom de la ressource. Cette propriété correspond donc au nom de la machine virtuelle. Ensuite, redémarrez la machine virtuelle. |
| Gestion des machines virtuelles Arc | Lorsqu’un nouveau serveur est ajouté à un cluster Azure Stack HCI, le chemin de stockage n’est pas créé automatiquement pour le volume nouvellement créé. | Vous pouvez créer manuellement un chemin de stockage pour tous les nouveaux volumes. Pour plus d’informations, consultez Créer un chemin d’accès de stockage. |
| Gestion des machines virtuelles Arc | Le redémarrage de l’opération de machine virtuelle Arc se termine après environ 20 minutes, bien que la machine virtuelle elle-même redémarre en environ une minute. | Il n’existe aucune solution de contournement connue dans cette version. |
| Gestion des machines virtuelles Arc | Dans certains cas, l’état du réseau logique s’affiche comme Ayant échoué dans Portail Azure. Cela se produit lorsque vous essayez de supprimer le réseau logique sans d’abord supprimer de ressources telles que les interfaces réseau associées à ce réseau logique. Vous devez toujours être en mesure de créer des ressources sur ce réseau logique. L’état est trompeur dans cette instance. |
Si l’état de ce réseau logique a été réussi au moment de l’approvisionnement de ce réseau, vous pouvez continuer à créer des ressources sur ce réseau. |
| Gestion des machines virtuelles Arc | Dans cette version, lorsque vous mettez à jour une machine virtuelle avec un disque de données attaché à celui-ci à l’aide d’Azure CLI, l’opération échoue avec le message d’erreur suivant : Impossible de trouver un disque dur virtuel portant le nom. |
Utilisez le Portail Azure pour toutes les opérations de mise à jour de machine virtuelle. Pour plus d’informations, consultez Gérer les machines virtuelles Arc et gérer les ressources de machine virtuelle Arc. |
| Mettre à jour | Dans de rares cas, vous pouvez rencontrer cette erreur lors de la mise à jour de votre instance Azure Stack HCI : type « UpdateArbAndExtensions » du rôle « MocArb » a déclenché une exception : Exception upgrade ARB and Extension in step [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb : Invalid applianceyaml = [C :\AksHci\hci-appliance.yaml]. | Si vous voyez ce problème, contactez Support Microsoft pour vous aider à suivre les étapes suivantes. |
| Réseaux | Il existe un problème de client DNS peu fréquent dans cette version qui provoque l’échec du déploiement sur un cluster à deux nœuds avec une erreur de résolution DNS : Une WebException s’est produite lors de l’envoi d’une requête RestRequest. WebException.Status : NameResolutionFailure. En raison du bogue, l’enregistrement DNS du deuxième nœud est supprimé peu après sa création, ce qui entraîne une erreur DNS. | Redémarrez le serveur. Cette opération inscrit l’enregistrement DNS, ce qui l’empêche d’être supprimé. |
| Portail Azure | Dans certains cas, le Portail Azure peut prendre un certain temps pour mettre à jour et l’affichage n’est peut-être pas actif. | Vous devrez peut-être attendre 30 minutes ou plus pour afficher la vue mise à jour. |
| Gestion des machines virtuelles Arc | La suppression d’une interface réseau sur une machine virtuelle Arc de Portail Azure ne fonctionne pas dans cette version. | Utilisez Azure CLI pour commencer par supprimer l’interface réseau, puis supprimez-la. Pour plus d’informations, consultez Supprimer l’interface réseau et supprimer l’interface réseau. |
| Déploiement | La fourniture du nom de l’unité d’organisation dans une syntaxe incorrecte n’est pas détectée dans le Portail Azure. La syntaxe incorrecte inclut des caractères non pris en charge tels que &,",',<,>. La syntaxe incorrecte est détectée à une étape ultérieure lors de la validation du cluster. |
Vérifiez que la syntaxe du chemin d’organisation est correcte et n’inclut pas de caractères non pris en charge. |
| Déploiement | Les déploiements via Azure Resource Manager expirent après 2 heures. Les déploiements qui dépassent 2 heures s’affichent comme ayant échoué dans le groupe de ressources bien que le cluster soit créé avec succès. | Pour surveiller le déploiement dans le Portail Azure, accédez à la ressource de cluster Azure Stack HCI, puis accédez à la nouvelle entrée Déploiements. |
| Azure Site Recovery | Azure Site Recovery ne peut pas être installé sur un cluster Azure Stack HCI dans cette version. | Il n’existe aucune solution de contournement connue dans cette version. |
| Mettre à jour | Lors de la mise à jour du cluster Azure Stack HCI via Azure Update Manager, la progression et les résultats de la mise à jour peuvent ne pas être visibles dans le Portail Azure. | Pour contourner ce problème, sur chaque nœud de cluster, ajoutez la clé de Registre suivante (aucune valeur nécessaire) :New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceEnsuite, sur l’un des nœuds de cluster, redémarrez le groupe de cluster De gestion cloud. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Cela ne résout pas entièrement le problème, car les détails de progression peuvent toujours ne pas être affichés pendant une durée du processus de mise à jour. Pour obtenir les derniers détails de la mise à jour, vous pouvez récupérer la progression de la mise à jour avec PowerShell. |
| Mettre à jour | Dans de rares cas, si une mise à jour ayant échoué est bloquée dans un état en cours dans Azure Update Manager, le bouton Réessayer est désactivé. | Pour reprendre la mise à jour, exécutez la commande PowerShell suivante :Get-SolutionUpdate|Start-SolutionUpdate. |
| Mises à jour | Dans certains cas, SolutionUpdate les commandes peuvent échouer si elles sont exécutées après la Send-DiagnosticData commande. |
Veillez à fermer la session PowerShell utilisée pour Send-DiagnosticData. Ouvrez une nouvelle session PowerShell et utilisez-la pour SolutionUpdate les commandes. |
| Mettre à jour | Dans de rares cas, lors de l’application d’une mise à jour de 2311.0.24 à 2311.2.4, les rapports d’état du cluster sont en cours au lieu de l’échec attendu de la mise à jour. | Réessayez la mise à jour. Si le problème persiste, contactez le support technique Microsoft. |
| Mettre à jour | Les tentatives d’installation des mises à jour de solution peuvent échouer à la fin des étapes de la mise à jour de la solution avec :There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on. Ce problème rare se produit si les Cluster Name Cluster IP Address ressources ne parviennent pas à démarrer après un redémarrage du nœud et sont les plus courantes dans les petits clusters. |
Si vous rencontrez ce problème, contactez Support Microsoft pour connaître les étapes suivantes. Ils peuvent travailler avec vous pour redémarrer manuellement les ressources du cluster et reprendre la mise à jour si nécessaire. |
| Mettre à jour | Lors de l’application d’une mise à jour de cluster à la version 10.2402.3.11, l’applet Get-SolutionUpdate de commande peut ne pas répondre et échouer avec une exception RequestTimeoutException après environ 10 minutes. Cela se produit probablement après un scénario de serveur d’ajout ou de réparation. |
Utilisez les applets de commande et Stop-ClusterGroup les Start-ClusterGroup applets de commande pour redémarrer le service de mise à jour. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Stop-ClusterGroup Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Start-ClusterGroup Une exécution réussie de ces applets de commande doit mettre en ligne le service de mise à jour. |
| Mise à jour prenant en charge le cluster | Échec de la reprise de l’opération de nœud. | Il s’agit d’un problème temporaire et peut être résolu par lui-même. Attendez quelques minutes et réessayez l’opération. Si le problème persiste, contactez le support technique Microsoft. |
| Mise à jour prenant en charge le cluster | L’opération de suspension du nœud a été bloquée pendant plus de 90 minutes. | Il s’agit d’un problème temporaire et peut être résolu par lui-même. Attendez quelques minutes et réessayez l’opération. Si le problème persiste, contactez le support technique Microsoft. |
Étapes suivantes
- Lisez la vue d’ensemble du déploiement.