Problèmes connus dans la version 2411.2 d’Azure Local
Cet article identifie les problèmes connus critiques et leurs solutions de contournement dans la version 2411.2 d’Azure Local.
Ces notes de publication sont mises à jour en continu. Lorsqu'un problème critique nécessitant une solution de contournement est découvert, il est ajouté. Avant de déployer votre instance Azure Local, examinez attentivement les informations contenues ici.
Important
Pour plus d’informations sur les chemins de mise à jour pris en charge pour cette version, consultez informations de publication.
Pour plus d’informations sur les nouvelles fonctionnalités de cette version, consultez Nouveautés d’Azure Local.
Problèmes connus pour la version 2411.2
Cette version logicielle correspond au numéro de version du logiciel 2411.2.10.
Important
Les nouveaux déploiements de ce logiciel utilisent la build 2411.2.10. Vous pouvez également effectuer une mise à jour à partir de la version 2411.1.10.
Les notes de publication de cette version incluent les problèmes résolus dans cette version, les problèmes connus dans cette version et les problèmes de note de publication transférés à partir des versions précédentes.
Note
Pour obtenir une correction détaillée des problèmes connus courants, consultez le référentiel GitHub Azure supportabilité locale.
Problèmes résolus
Les problèmes suivants sont résolus dans cette version :
| Caractéristique | Problème | Solution de contournement/commentaires |
|---|---|---|
| Gestion des machines virtuelles Arc | Le chemin de stockage n’a pas pu être supprimé en raison des images requises par AKS qui ont été pré-téléchargées. | |
| Gestion des machines virtuelles Arc | La nouvelle tentative de suppression d’image échoue après le redémarrage du nœud. | Lorsque le nœud tombe en panne et si vous essayez de supprimer une image, la suppression expire. Lorsque le nœud redémarre et retente la suppression, la suppression échoue à nouveau. |
| Mettre à jour | Un package d’extension de solution a été involontairement appliqué à une mise à jour de solution. |
Problèmes connus dans cette version
Microsoft ne connaît aucun problème connu dans cette version.
Problèmes connus des versions précédentes
Le tableau suivant répertorie les problèmes connus des versions précédentes :
| Caractéristique | Problème | Solution de contournement | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Déploiement | La validation échoue en raison de la désérialisation de l'horodatage. | Lors du déploiement du système d’exploitation, sélectionnez anglais (États-Unis) comme langue d’installation, ainsi que le format heure et devise. Pour obtenir des étapes de correction détaillées, consultez le guide de résolution des problèmes dans la dépôt Azure Local Supportability GitHub. |
||||||||||||||||||
| Mettre à jour | Lors de la mise à jour de la version 2408.2.7 vers la version 2411.0.24, le processus de mise à jour peut échouer avec le message d’erreur suivant : 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.' |
Pour plus de détails sur la façon d’atténuer ce problème, consultez le Guide de Résolution des Problèmes Locaux Azure pour la mise à jour. | ||||||||||||||||||
| Mettre à jour | Avec la version 2411, la mise à jour de la solution et de l’extension Du Générateur de solutions ne sont pas combinées dans une seule exécution de mise à jour. | Pour appliquer un package d’extension Solution Builder, vous avez besoin d’une exécution de mise à jour distincte. | ||||||||||||||||||
| Mettre à jour | Lors de l’application de la mise à jour de solution dans cette version, la mise à jour peut échouer. Cela se produit uniquement si la mise à jour a été démarrée avant le 26 novembre. Le problème qui provoque l’échec peut entraîner l’un des messages d’erreur suivants : Erreur 1 - L’étape « update ARB and extension » error «Clear-AzContext a échoué avec 0 et exception appelant « Initialize » avec « 1 » argument(s) : « Référence d’objet non définie sur une instance d’un objet ». dans « Clear-AzPowerShellCache ». Erreur 2 - L’étape « EvalTVMFlow » erreur « CloudEngine.Actions.InterfaceInvocationFailedException : Type « EvalTVMFlow » du rôle « ArcIntegration » a déclenché une exception : ce module nécessite Az.Accounts version 3.0.5. Une version antérieure de Az.Accounts est importée dans la session PowerShell actuelle. Ouvrez une nouvelle session avant d’importer ce module. Cette erreur peut indiquer que plusieurs versions incompatibles des applets de commande Azure PowerShell sont installées sur votre système. Consultez https://aka.ms/azps-version-error pour plus d’informations sur la résolution des problèmes. » Selon la version des modules PowerShell, l’erreur ci-dessus peut être signalée pour les versions 3.0.4 et 3.0.5. |
Pour obtenir des instructions détaillées sur la façon d’atténuer ce problème, accédez à : https://aka.ms/azloc-update-30221399. | ||||||||||||||||||
| Réparer le serveur | Après avoir réparé un nœud et exécuté la commande Set-AzureStackLCMUserPassword, vous pouvez rencontrer l’erreur suivante : 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 |
Procédez comme suit pour atténuer le problème : $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. Importez le module nécessaire : Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Vérifiez l’état du groupe de cluster ECE : $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. Mettez à jour l'ECE avec le nouveau mot de passe : 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. Mettez à jour le mot de passe dans Active Directory : Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Gestion des machines virtuelles Arc | L’utilisation d’un disque système d’une VM Azure exporté en tant que disque dur virtuel (VHD) pour créer une image de galerie pour l’approvisionnement d’une machine virtuelle Arc n’est pas prise en charge. | Exécutez la commande restart-service mochostagent pour redémarrer le service mochostagent. |
||||||||||||||||||
| Réseautage | Lorsqu’un nœud est configuré avec un serveur proxy qui a des lettres majuscules dans son adresse, telles que HTTPS://10.100.000.00:8080, les extensions Arc ne parviennent pas à installer ou à mettre à jour sur le nœud dans les builds existantes, y compris la version 2408.1. Toutefois, le nœud reste connecté à Arc. | Procédez comme suit pour atténuer le problème : 1. Définissez les valeurs d’environnement en minuscules. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Vérifiez que les valeurs ont été définies. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine").
3. Redémarrez les services Arc. Restart-Service himds
Restart-Service ExtensionService
Restart-Service GCArcService
4. Envoyez un signal à l'AzcmaAgent avec les informations du proxy en minuscules. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080
& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| mise en réseau | Lorsque les machines Arc tombent en panne, la page «Tous les clusters», dans la nouvelle expérience du portail, affiche un «PartiallyConnected» ou un «Not Connected Recently » comme état. Même lorsque les machines Arc deviennent saines, elles peuvent ne pas afficher l’état «Connecté». | Il n’existe aucune solution de contournement connue pour ce problème. Pour vérifier l’état de la connectivité, utilisez l’ancienne expérience pour voir s’il s’affiche comme «connecté». | ||||||||||||||||||
| Gestion des machines virtuelles Arc | Le service Mochostagent peut sembler être en cours d’exécution, mais il peut se figer sans mettre à jour les journaux pendant plus d’un mois. Vous pouvez identifier ce problème en vérifiant les journaux de service dans C:\programdata\mochostagent\logs pour voir si les journaux sont mis à jour. |
Exécutez la commande suivante pour redémarrer le service mochostagent : restart-service mochostagent. |
||||||||||||||||||
| Mettre à niveau | Lors de la mise à niveau de la version 2311 ou antérieure vers la version 2408 ou ultérieure, les opérations d'ajout et de réparation de nœud peuvent échouer. Par exemple, vous pouvez voir une erreur : Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
Il n’existe aucune solution de contournement dans cette version. Si vous rencontrez ce problème, contactez le support Microsoft pour déterminer les étapes suivantes. | ||||||||||||||||||
| Mettre à jour | Lorsque vous affichez les résultats de la vérification de préparation pour une instance locale Azure 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. | ||||||||||||||||||
| Mettre à jour | Il existe un problème intermittent dans cette version lorsque le portail Azure signale incorrectement l’état de la mise à jour comme Échec de la mise à jour ou En cours bien que la mise à jour soit terminée. |
connectez-vous à votre instance locale Azure 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 de votre part. Le 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. 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 affichent le MOC dans la version cible, sans que la mise à jour ne réussisse, 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 pour la résolution des problèmes de mises à jour de solution pour Azure Local. 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 $initialMocVersion sur cette version MOC. Définissez le $targetMocVersion en recherchant la build Locale Azure vers laquelle vous effectuez la mise à jour et en obtenant la version MOC correspondante dans le tableau suivant. 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" et si vous effectuez la mise à 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. |
||||||||||||||||||
| Déploiement | Dans certains cas, lors de l’inscription des machines locales Azure, 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 |
||||||||||||||||||
| AKS sur Azure Local | 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 local Azure. | ||||||||||||||||||
| Réparer le serveur | Dans de rares cas, l’opération de 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 de commande PowerShell Suspend-ClusterNode -Drain avant de commencer Repair-Server. Si le problème se produit, contactez le support Microsoft pour connaître les étapes suivantes. |
||||||||||||||||||
| Réparer le serveur | Ce problème se produit lorsque l’instance locale Azure à nœud unique est mise à jour de 2311 à 2402, puis que le 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 le ADPrepTool. Suivez les étapes décrites dans Préparer l'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 Active Directory en vous-même (sans utiliser le script et la procédure fournis par Microsoft), votre validation Active Directory peut échouer avec l’autorisation Generic All manquante. Cela est dû à un problème dans la vérification de validation qui vérifie la présence d’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 spécifique msFVE-RecoverInformationobjects – General – Permissions Full control. |
||||||||||||||||||
| Déploiement | Il existe un problème rare dans cette version où l’enregistrement DNS est supprimé pendant le déploiement local Azure. 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 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 ECE sur le nœud concerné. Sur votre ordinateur, ouvrez une session PowerShell et exécutez la commande suivante :Restart-Service ECEAgent. |
||||||||||||||||||
| Ajouter un serveur | Dans cette version et les versions précédentes, lors de l’ajout d’une machine au système, n’est pas possible de mettre à jour la chaîne de liste de contournement du proxy pour inclure la nouvelle machine. La mise à jour de la liste de contournement de proxy des variables d’environnement sur les hôtes ne met pas à jour la liste de contournement du proxy sur Azure Resource Bridge ou AKS. | Il n’existe aucune solution de contournement dans cette version. Si vous rencontrez ce problème, contactez le support Microsoft pour déterminer les étapes suivantes. | ||||||||||||||||||
| Ajouter/réparer un serveur | Dans cette version, lors de l’ajout ou de la réparation d’une machine, une défaillance est observée lorsque l’équilibreur de charge logiciel ou les certificats de machine virtuelle du contrôleur 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 le 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, voir 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 requis 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 la Déployer Azure Local 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. |
||||||||||||||||||
| de sécurité | Pour les nouveaux déploiements, les appareils compatibles avec Secured-core n’ont pas le Dynamic Root of Measurement (DRTM) activé 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éseau | 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 la vérification de l'état de santé 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. Reconfigurez à nouveau votre liste d'exclusion 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 : Fenêtres: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Ensuite, recherchez la propriété resourcename. Supprimez le GUID ajouté à la fin du nom de la ressource. Cette propriété correspond donc au nom de la machine virtuelle. Redémarrez ensuite la machine virtuelle. |
||||||||||||||||||
| Gestion des machines virtuelles Arc | Lorsqu’une nouvelle machine est ajoutée à une instance locale Azure, 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 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 le 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. Le statut est trompeur dans ce cas. |
Si l’état de ce réseau logique était Réussi au moment où ce réseau a été provisionné, 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 locale Azure : 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]. |
Si vous voyez ce problème, contactez le support Microsoft pour vous aider à suivre les étapes suivantes. | ||||||||||||||||||
| Mise en réseau | Il existe un problème de client DNS peu fréquent dans cette version qui provoque l’échec du déploiement sur un système à deux nœuds avec une erreur de résolution DNS : A WebException s’est produite lors de l’envoi d’une requête RestRequest. WebException.Status : NameResolutionFailure. Suite au 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 l’ordinateur. 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 à partir du 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 voir 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 système. |
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 système soit correctement créé. | Pour surveiller le déploiement dans le portail Azure, accédez à la ressource d’instance locale Azure, puis accédez à la nouvelle entrée Déploiements. | ||||||||||||||||||
| Azure Site Recovery | Azure Site Recovery ne peut pas être installé sur une instance locale Azure dans cette version. | Il n’existe aucune solution de contournement connue dans cette version. | ||||||||||||||||||
| Mettre à jour | Lors de la mise à jour de l’instance locale Azure 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, 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, redémarrez le groupe de cluster de gestion du 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 en cours'état dans Azure Update Manager, le bouton Réessayez est désactivé. | Pour reprendre la mise à jour, exécutez la commande PowerShell suivante :Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| Mettre à jour | Dans certains cas, SolutionUpdate commandes peuvent échouer si elles sont exécutées après la commande Send-DiagnosticData. |
Veillez à fermer la session PowerShell utilisée pour Send-DiagnosticData. Ouvrez une nouvelle session PowerShell et utilisez-la pour SolutionUpdate 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 système indiquent En cours au lieu de Échec de la mise à jourattendu. | Réessayez la mise à jour. Si le problème persiste, contactez le support 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 ressources Cluster Name ou Cluster IP Address ne démarrent pas après le redémarrage d’un nœud et sont les plus courantes dans les petits déploiements. |
Si vous rencontrez ce problème, contactez le support Microsoft pour connaître les étapes suivantes. Ils peuvent travailler avec vous pour redémarrer manuellement les ressources locales Azure et reprendre la mise à jour si nécessaire. | ||||||||||||||||||
| Mettre à jour | Lors de l’application d’une mise à jour système à la version 10.2402.3.11, l’applet de commande Get-SolutionUpdate peut ne pas répondre et éventuellement échouer avec une exception RequestTimeoutException après environ 10 minutes. Cela est susceptible de se produire après un scénario d'ajout ou de réparation de serveur. |
Utilisez les applets de commande Start-ClusterGroup et Stop-ClusterGroup 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 du cluster consciente | Échec de l'opération de reprise du nœud pour le redémarrage du 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 Microsoft. | ||||||||||||||||||
| Mise à jour sensible au 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 Microsoft. |