Notes de publication archivées pour Azure Stack Hub

Article
10/30/2024

Cet article décrit le contenu des mises à jour d’Azure Stack Hub. La mise à jour inclut des améliorations et correctifs logiciels pour cette mise en production d’Azure Stack Hub.

Pour accéder aux notes de publication pour une autre version archivée, utilisez le menu déroulant du sélecteur de version, au-dessus à gauche de la table des matières.

Informations de référence sur la build 2306

Le numéro de build de mise à jour d’Azure Stack Hub 2306 est 1.2306.2.47.

Type de mise à jour

Le type de build de mise à jour d’Azure Stack Hub 2306 est Complet. Cette build contient uniquement les mises à jour de sécurité importantes.

La mise à jour 2306 comporte les runtimes attendus suivants en fonction de nos tests internes :

4 nœuds : 8 à 28 heures
8 nœuds : 11 à 30 heures
12 nœuds : 14 à 34 heures
16 nœuds : 17 à 40 heures

Les durées de mise à jour exactes dépendent généralement de la capacité de votre système qu’utilisent les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des spécifications matérielles de votre système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette approximation du runtime est spécifique à la mise à jour 2306 et ne doit pas être comparée à d’autres mises à jour Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Cette build contient des mises à jour de sécurité importantes. Il n’existe pas d’autres ajouts de fonctionnalités majeurs.

Modifications

La version 2306 d’Azure Stack Hub est la dernière mise à jour majeure qui peut être installée sur des systèmes intégrés basés sur la plateforme de processeur Broadwell d’Intel. Les versions 2311 (et ultérieures) sont basées sur une base de code Windows Server 2022 qui n’est pas prise en charge sur la plateforme Broadwell par Intel. Pour toute famille de processeurs processeur ou questions matérielles, contactez votre partenaire OEM matériel.
Cette build contient ces mises à jour de sécurité importantes.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. À compter de la version 2005, quand vous mettez à jour vers une nouvelle version majeure (par exemple 1.2008.x vers 1.2102.x), les derniers correctifs (le cas échéant) de la nouvelle version majeure sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Remarque

Les versions des correctifs logiciels Azure Stack Hub sont cumulatives. Il vous suffit d’installer le dernier correctif logiciel afin d’obtenir l’ensemble des correctifs logiciels inclus dans les versions précédentes de correctifs logiciels pour cette version.

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Prérequis du correctif logiciel : avant d’appliquer la mise à jour 2306

La version 2306 d’Azure Stack Hub doit être appliquée à la version 2301 avec le correctif logiciel suivant installé :

Correctif logiciel Azure Stack Hub 1.2301.3.97

Après avoir appliqué la mise à jour 2306

Lorsque vous effectuez une mise à jour vers une nouvelle version majeure (par exemple, 1.2108.x vers 1.2206.x), les derniers correctifs logiciels (le cas échéant) dans la nouvelle version principale sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Après l’installation de 2306, si des correctifs logiciels pour 2306 sont ensuite publiés, vous devez les installer :

Correctif logiciel Azure Stack Hub 1.2306.4.98

Informations de référence sur la build 2301

Le numéro de build de mise à jour d’Azure Stack Hub 2301 est 1.2301.2.58.

Type de mise à jour

Le type de build de mise à jour d’Azure Stack Hub 2301 est complet.

La mise à jour 2301 comporte les runtimes attendus suivants en fonction de nos tests internes :

4 nœuds : 8 à 28 heures
8 nœuds : 11 à 30 heures
12 nœuds : 14 à 34 heures
16 nœuds : 17 à 40 heures

Les durées de mise à jour exactes dépendent généralement de la capacité de votre système qu’utilisent les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des spécifications matérielles de votre système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette approximation du runtime est spécifique à la mise à jour 2301 et ne doit pas être comparée à d’autres mises à jour Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Préversion publique du fournisseur de ressources Azure Site Recovery pour Azure Stack Hub.
Version préliminaire publique de VPN Fast Path avec de nouvelles références SKU passerelle VPN.
Nouvelle documentation sur le chemin d’accès rapide VPN pour les opérateurs Azure Stack Hub et les utilisateurs d’Azure Stack Hub.
Ajout de la nouvelle taille de machine virtuelle Standard_E20_v3 pour prendre en charge des charges de travail de base de données plus volumineuses nécessitant plus de 112 Go de mémoire.
Ajout de la prise en charge de NVIDIA A100 Tensor GPU. Validez avec votre OEM si votre matériel peut prendre en charge la configuration gpu requise.
Ajout de la nouvelle série de machines virtuelles pour A100. Pour plus d’informations, consultez les GPU sur Azure Stack Hub.
Cette mise à jour inclut toutes les exigences de plateforme pour ajouter Azure Site Recovery sur Azure Stack Hub. Le premier scénario que nous activons est axé sur la réplication de machines virtuelles dans deux régions Azure Stack Hub. ASR sur Azure Stack Hub est un fournisseur de ressources complémentaire qui devra être ajouté via la gestion de la Place de marché.
Ajout de la possibilité pour les opérateurs d’afficher les informations d’état des machines virtuelles sur tous les abonnements utilisateur dans le portail d’administration Azure Stack Hub.

Modifications

Le fournisseur de ressources SQL 2.0.13 et le fournisseur de ressources MySQL 2.0.13 sont publiés pour prendre en charge certaines modifications cassants d’interface utilisateur introduites dans Azure Stack Hub 2301. Mettez à jour le fournisseur de ressources SQL et le fournisseur de ressources MySQL vers la dernière version avant de mettre à jour Azure Stack Hub. Vous devrez peut-être actualiser le cache du navigateur pour que les nouvelles modifications de l’interface utilisateur prennent effet.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Remarque

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Prérequis du correctif logiciel : avant d’appliquer la mise à jour 2301

La version 2301 d’Azure Stack Hub doit être appliquée à la version 2206 avec le correctif logiciel suivant installé :

Correctif logiciel Azure Stack Hub 1.2206.2.77

Après avoir appliqué la mise à jour 2301

Après l’installation de 2301, si des correctifs logiciels pour 2301 sont ensuite publiés, vous devez les installer :

Correctif logiciel Azure Stack Hub 1.2301.3.72

Informations de référence sur la build 2206

Le numéro de build de la mise à jour 2206 d’Azure Stack Hub est 1.2206.1.24.

Type de mise à jour

Le type de build de la mise à jour 2206 d’Azure Stack Hub est Complète.

La mise à jour 2206 a les temps d’exécution attendus suivants d’après nos tests internes :

4 nœuds : 8 à 28 heures
8 nœuds : 11 à 30 heures
12 nœuds : 14 à 34 heures
16 nœuds : 17 à 40 heures

Les durées de mise à jour exactes dépendent généralement de la capacité de votre système qu’utilisent les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des spécifications matérielles de votre système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette approximation autour de la durée d’exécution est propre à la mise à jour 2206 : elle ne doit pas être comparée à d’autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Les clients basés dans l’Union européenne peuvent désormais choisir d’avoir toutes leurs données stockées et traitées à l’intérieur des frontières de l’Union européenne. Pour plus d’informations, consultez Initiative Schrems II de l’Union européenne pour Azure Stack Hub.
Azure Stack Hub prend désormais en charge la récupération des clés BitLocker pour le chiffrement des données au repos. Pour plus d’informations, consultez Récupération des clés de récupération BitLocker.

Modifications

SQL RP V2 et MySQL RP V2 sont disponibles seulement pour les abonnements auxquels l’accès a été accordé. Si vous utilisez toujours SQL RP V1 et MySQL RP V1, il est vivement recommandé d’ouvrir un cas de support pour passer par le processus de mise à niveau avant de procéder à la mise à niveau vers Azure Stack Hub 2206.
Cette version prend en charge la rotation des certificats racines Azure Stack Hub. Auparavant, la rotation des secrets n’effectuait pas la rotation de la racine. Vous pourrez effectuer la rotation du certificat racine après l’installation de la mise à jour. Pour ce faire, effectuez une rotation du secret interne au plus tard la prochaine fois que vous serez averti par des alertes d’expiration. Si vous n’effectuez pas la rotation du certificat racine et/ou du secret interne, votre empreinte risque de devenir irrécupérable.

Correctifs

Correctif pour améliorer le débit SLB
Correction d’un problème qui empêchait l’accès au sous-système de stockage quand les nœuds d’unité d’échelle sont redémarrés.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Remarque

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Prérequis pour les correctifs logiciels : avant d’appliquer la mise à jour 2206

La version 2206 d’Azure Stack Hub doit être appliquée sur la version 2108 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack Hub 1.2108.2.130

Après l’application réussie de la mise à jour 2206

Quand vous mettez à jour vers une nouvelle version principale (par exemple, 1.2102.x vers 1.2108.x), les derniers correctifs (le cas échéant) de la nouvelle version principale sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Après l’installation de la version 2206, si des correctifs logiciels pour cette version sont publiés par la suite, vous devez les installer :

Correctif logiciel Azure Stack Hub 1.2206.2.77

Référence de la build 2102

Le dernier numéro de build de la mise à jour 2102 d’Azure Stack Hub est 1.2102.30.97. Pour obtenir des informations mises à jour sur les builds et les correctifs, consultez la section Correctifs.

Type de mise à jour

Le type de build de la mise à jour 2102 d’Azure Stack Hub est Complète.

La mise à jour 2102 a les temps d’exécution attendus suivants dans nos tests internes :

4 nœuds : 8 à 20 heures
8 nœuds : 11 à 26 heures
12 nœuds : 14 à 32 heures
16 nœuds : 17 à 38 heures

Les durées de mise à jour exactes dépendent généralement de la capacité de votre système qu’utilisent les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des spécifications matérielles de votre système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette approximation autour de la durée d’exécution est propre à la mise à jour 2102. Il ne faut pas la comparer à d’autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Cette version comprend une préversion publique du support à distance, qui permet à un professionnel du support Microsoft de résoudre plus rapidement votre cas de support en autorisant l’accès à distance à votre appareil et en effectuant des opérations de dépannage et de réparation limitées. Vous pouvez activer cette fonctionnalité en donnant votre consentement, mais vous contrôlez le niveau d’accès et la durée d’accès. Le support peut accéder à votre appareil seulement après l’envoi d’une demande de support. Pour plus d’informations, consultez Support à distance pour Azure Stack Hub.
Le service de sauvegarde d’infrastructure Azure Stack Hub prend désormais en charge la sauvegarde progressive. Cette fonctionnalité permet de réduire les besoins de stockage sur l’emplacement de sauvegarde externe, et modifie la façon dont les fichiers sont organisés dans le magasin de sauvegarde externe. Nous vous recommandons de ne pas manipuler les fichiers sous le répertoire racine de sauvegarde.
Les disques managés Azure Stack Hub prennent désormais en charge la version 2019-07-01 des API Azure Disk, avec un sous-ensemble des fonctionnalités disponibles.
Le stockage Azure Stack Hub prend désormais en charge la version 2019-06-01 des API de management des services Stockage Azure, avec un sous-ensemble des fonctionnalités totales disponibles.
Le portail d’administration Azure Stack Hub affiche désormais des informations relatives au GPU, dont des données de capacité. Cela exige qu’un GPU soit installé dans le système.
Les utilisateurs peuvent désormais déployer toutes les tailles de machine virtuelle prises en charge, en utilisant Nvidia T4 via le portail utilisateur Azure Stack Hub.
Les opérateurs Azure Stack Hub peuvent désormais configurer une architecture multilocataire dans Azure Stack Hub via le portail d’administration. Pour plus d’informations, consultez Configurer une architecture multilocataire.
Les opérateurs Azure Stack Hub peuvent désormais configurer une mention légale en utilisant le point de terminaison privilégié. Pour plus d’informations, consultez Configurer les contrôles de sécurité d’Azure Stack Hub.
Pendant le processus de mise à jour, la récupération précise des bitmaps (Granular Bitmap Repair, GBR), une optimisation du processus de réparation du stockage, est introduite pour réparer les données hors synchronisation. Par rapport au processus précédent, des segments plus petits sont réparés, ce qui raccourcit le temps de réparation et la durée de mise à jour globale. La GBR est activée par défaut pour tous les nouveaux déploiements de la version 2102. Pour une mise à jour vers la version 2102 à partir d’une version antérieure (2008), la GBR est activée au cours de la mise à jour. La GBR nécessitant que tous les disques physiques soient dans un état sain, une validation supplémentaire a été ajoutée dans la vérification UpdateReadiness. Si la validation échoue, une mise à jour corrective échouera précocement. À ce stade, un administrateur de cloud doit prendre des mesures pour résoudre le problème de disque avant de reprendre la mise à jour. Pour suivre le fabricant OEM, consultez les Informations de contact OEM.
Azure Stack Hub prend désormais en charge les nouvelles tailles de machine virtuelle des séries Dv3, Ev3 et D spécifique de SQL.
Azure Stack Hub prend désormais en charge l’ajout de GPU à tout système existant. Pour ajouter un GPU, exécutez la commande stop-azurestack, suivez le processus de stop-azurestack, ajoutez le GPU, puis exécutez la commande start-azurestack jusqu’au bout. Si le système contenait déjà des GPU, toutes les machines virtuelles GPU créées précédemment devront être arrêtées-libérées, puis redémarrées.
Réduction du temps de mise à jour OEM à l’aide du processus de mises à jour dynamiques.
Le moteur AKS sur Azure Stack Hub a ajouté les nouvelles fonctionnalités suivantes. Pour plus d’informations, consultez les notes de publication dans la documentation du moteur AKS :
- Disponibilité générale d’Ubuntu 18.04.
- Support pour Kubernetes 1.17.17 et 1.18.15.
- Préversion publique de la commande de rotation de certificat.
- Préversion publique du pilote CSI Azure Disk.
- Préversion publique du pilote CSI NFS.
- Préversion privée du pilote CSI pour blobs Azure.
- Préversion privée de la prise en charge de GPU T4 Nvidia.
- Préversion privée de l’intégration d’Azure Active Directory.

Améliorations

Allongement de la période de rétention du journal du contrôleur de réseau, de sorte que les journaux seront disponibles plus longtemps pour aider les ingénieurs à résoudre efficacement des problèmes, même après la résolution d’un problème.
Améliorations visant à préserver le contrôleur de réseau, la machine virtuelle passerelle, l’équilibrer la charge et les journaux de l’agent hôte pendant une mise à jour.
Amélioration de la logique de suppression pour les ressources réseau qui sont bloquées par un état d’approvisionnement défaillant.
Réduction de la mémoire XRP à 14 Go par machine virtuelle, et de la mémoire WAS à 10 Go par machine virtuelle. Éviter l’augmentation de l’empreinte mémoire totale de machine virtuelle permet de déployer davantage de machines virtuelles.
Le rapport HTML de collection de journaux, qui fournit un instantané des fichiers sur l’empreinte et le partage de diagnostic, dispose désormais d’une vue récapitulative des fichiers, rôles, fournisseurs de ressources et informations d’événement collectés pour faciliter la compréhension du taux de réussite et d’échec du processus de collection de journaux.
Ajout des cmdlets PowerShell Set-AzSLegalNotice et Get-AzSLegalNotice au point de terminaison privilégié (PEP) pour récupérer et mettre à jour le contenu du texte de la bannière de connexion après déploiement.
Suppression totale des services de certificats Active Directory (ADCS) et de la machine virtuelle de l’autorité de certification d’Azure Stack Hub. Cela réduit l’empreinte de l’infrastructure et permet d’économiser jusqu’à 2 heures de temps de mise à jour.

Modifications

Les API de fournisseur de ressources d’infrastructure exposent désormais des informations sur les GPU si elles sont disponibles dans l’unité d’échelle.
Les opérateurs Azure Stack Hub peuvent désormais modifier le ratio de partitionnement du GPU via PowerShell (AMD uniquement). Cela nécessite que toutes les machines virtuelles soient libérées.
Cette build inclut une nouvelle version d’Azure Resource Manager.
Le portail utilisateur Azure Stack Hub utilise désormais l’expérience plein écran pour les équilibrages de charge, les groupes de sécurité réseau, les zones DNS et la création de disques et de machines virtuelles.
Dans la version 2102, le Windows Admin Center (WAC) est activé à la demande à partir d’une session PEP déverrouillée. Par défaut, le WAC n’est pas activé. Pour l’activer, spécifiez l’indicateur -EnableWac, par exemple unlock-supportsession -EnableWac.
La collection de journaux proactive utilise un algorithme amélioré qui capture des journaux dans des situations d’erreur non visibles d’un opérateur. Cet algorithme garantit que les informations de diagnostic appropriées sont collectées au bon moment sans nécessiter l’intervention d’un opérateur. Dans certain cas, le Support Microsoft peut commencer à détecter et résoudre des problèmes plus tôt. Les améliorations initiales des algorithmes se concentrent sur les opérations de correction et de mise à jour. Il est recommandé d’activer la collection de journaux proactive, car davantage d’opérations sont optimisées, et les avantages augmentent.
La mémoire que l’infrastructure Azure Stack Hub utilise augmente temporairement de 10 Go.

Correctifs

Correction d’un problème qui avait pour effet que des zones DNS internes n’étaient plus synchronisées lors de la mise à jour et que celle-ci échouait. Ce correctif a été rétro-porté vers les versions 2008 et 2005.
Correction d’un problème qui avait pour effet que l’espace disque était saturé par les journaux sur les hôtes physiques, les contrôleurs de réseau, les passerelles et les équilibreurs de charge. Ce correctif a été rétro-porté vers la version 2008.
Correction d’un problème qui avait pour effet que la suppression de groupes de ressources ou de réseaux virtuels échouait en raison d’une ressource orpheline dans la couche du contrôleur de réseau.
Suppression de la taille ND6s_dev du sélecteur de taille de machine virtuelle, car cette taille de machine virtuelle n’est pas prise en charge.
Correction d’un problème qui avait pour effet que l’exécution de la commande Stop-Deallocate sur une machine virtuelle entraînait une configuration MTU de la machine virtuelle à supprimer. Ce comportement était incohérent avec Azure.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. À partir de la version 2005, lorsque vous mettez à jour vers une nouvelle version principale (par exemple, 1.2005.x vers 1.2008.x), les derniers correctifs (le cas échéant) de la nouvelle version principale sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Remarque

Prérequis des correctifs logiciels : avant d’appliquer la mise à jour 2102

La version 2102 d’Azure Stack Hub doit être appliquée sur la version 2008 avec les correctifs logiciels suivants :

Correctif Azure Stack Hub 1.2008.41.161

Après application correcte de la mise à jour 2102

Lorsque vous mettez à jour vers une nouvelle version principale (par exemple, 1.2008.x vers 1.2102.x), les derniers correctifs (le cas échéant) de la nouvelle version principale sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Après l’installation de la version 2102, si des correctifs logiciels pour cette version sont publiés par la suite, vous devez les installer :

Correctif Azure Stack Hub 1.2102.30.148

Notes de publication pour les versions prises en charge

Vous trouverez les notes de publication pour les versions prises en charge d’Azure Stack Hub dans Vue d’ensemble > Notes de publication

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack Hub. N’appliquez pas cette mise à jour au Kit de développement Azure Stack (ASDK).

Important

Si votre instance Azure Stack Hub présente plus de deux mises à jour de retard, elle est considérée comme non conforme. Pour bénéficier de la prise en charge, vous devez mettre à jour avec au moins la version minimale prise en charge.

Référence de la build 2108

Le numéro de la build de la dernière mise à jour 2108 d’Azure Stack Hub est 1.2108.2.65. Pour obtenir des informations mises à jour sur les builds et les correctifs, consultez la section Correctifs.

Type de mise à jour

Le type de build de la mise à jour 2108 d’Azure Stack Hub est Complète.

La mise à jour 2108 a les temps d’exécution attendus suivants dans nos tests internes :

4 nœuds : 8 à 28 heures
8 nœuds : 11 à 30 heures
12 nœuds : 14 à 34 heures
16 nœuds : 17 à 40 heures

Les durées de mise à jour exactes dépendent généralement de la capacité de votre système qu’utilisent les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des spécifications matérielles de votre système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette approximation autour de la durée d’exécution est propre à la mise à jour 2108. Il ne faut pas la comparer à d’autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Les opérateurs Azure Stack Hub peuvent désormais configurer des quotas de GPU pour les machines virtuelles.
L’accès à la machine virtuelle d’urgence est désormais disponible dans Azure Stack Hub sans qu’il soit nécessaire de contacter le support Microsoft.
Windows Server 2022 est désormais pris en charge comme système d’exploitation invité. Les machines virtuelles Windows Server 2022 doivent être activées manuellement en utilisant l’activation automatique des machines virtuelles dans Windows Server sur Azure Stack Hub exécutant la version 2108 ou ultérieure. Elles ne peuvent pas être activées sur les versions précédentes.
À partir de cette version, si la collecte proactive des journaux est désactivée, les journaux sont capturés et stockés localement pour les événements d’échec proactifs. Les journaux locaux sont accessibles à Microsoft uniquement dans le cadre d’un cas de support. De nouvelles alertes ont été ajoutées à la bibliothèque d’alertes de la collecte proactive des journaux.
Deux nouveaux services, Azure Kubernetes Service et Azure Container Registry, sont disponibles en préversion publique avec cette version.
Le module AzureStack 2.2.0 est publié pour l’alignement sur Azure Stack Hub version 2108. La mise à jour de la version comprend des modifications du module administrateur de calcul et les nouveaux modules Azs.ContainerRegistry.Admin et Azs.ContainerService.Admin. Pour plus d’informations, consultez le journal des modifications.
Avec cette version, les données de télémétrie sont chargées vers un compte de stockage Azure managé et contrôlé par Microsoft. Le service de télémétrie d’Azure Stack Hub se connecte à https://*.blob.core.windows.net/ et à https://azsdiagprdwestusfrontend.westus.cloudapp.azure.com/ pour charger correctement les données de télémétrie vers Microsoft. Le port 443 (HTTPS) doit être ouvert. Pour plus d’informations, consultez Télémétrie Azure Stack Hub.
Cette version comprend une préversion publique du support à distance, qui permet à un professionnel du support Microsoft de résoudre plus rapidement votre cas de support en autorisant l’accès à distance à votre appareil et en effectuant des opérations de dépannage et de réparation limitées. Vous pouvez activer cette fonctionnalité en donnant votre consentement, mais vous contrôlez le niveau d’accès et la durée d’accès. Le support peut accéder à votre appareil seulement après l’envoi d’une demande de support. Pour plus d’informations, consultez Support à distance pour Azure Stack Hub.

Améliorations

La description de l’alerte, quand le partage SMB externe est presque plein, a été ajustée pour s’aligner sur la sauvegarde progressive.
Pour éviter les échecs de chargement, le nombre de chargements de référentiels de sauvegarde d’infrastructure parallèles vers le partage SMB externe est maintenant limité.
L’alerte Node-Inaccessible-for-vm-placement a été remplacée par des alertes permettant de faire la distinction entre les scénarios host-unresponsive et hostagent-service-on-node-unresponsive.
App Service a désormais la possibilité de découvrir l’IP NAT par défaut pour les connexions sortantes.

Modifications

Pour garantir la réussite de la mise à jour 2108, vous devez préalablement arrêter (libérer) toutes les machines virtuelles qui utilisent un GPU. Ceci s’applique aux GPU AMD et NVIDIA, car l’implémentation sous-jacente bascule vers une approche sans ressources groupées.
Les fournisseurs de ressources SQL et MySQL sont disponibles uniquement pour les abonnements auxquels l’accès a été accordé. Si vous souhaitez commencer à utiliser ces fournisseurs de ressources ou si vous devez effectuer une mise à niveau à partir d’une version précédente, ouvrez un cas de support. Les ingénieurs du support Microsoft vous assisteront dans le processus de déploiement ou de mise à niveau.
Set-AzSLegalNotice déclenche maintenant l’apparence d’un nouvel écran qui contient la légende et le texte qui ont été définis pendant l’exécution de la commande. Cet écran apparaît chaque fois qu’une nouvelle instance du portail est créée.

Correctifs

Résolution d’un problème dans le cadre duquel l’échec d’un seul référentiel durant le chargement vers le partage SMB externe entraînait l’échec de l’ensemble de la sauvegarde de l’infrastructure.
Résolution d’un problème qui entraînait l’échec de la création de machines virtuelles de série N avec plusieurs GPU.
Résolution d’un problème dans le cadre duquel la désinstallation d’une extension de machine virtuelle annule les paramètres protégés des extensions de machine virtuelle existantes.
Résolution d’un problème entraînant l’utilisation d’IP externes par les équilibreurs de charge internes.
Résolution d’un problème de téléchargement des journaux série à partir du portail.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Remarque

Pour plus d’informations sur les correctifs logiciels, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Prérequis des correctifs logiciels : avant d’appliquer la mise à jour 2108

La version 2108 d’Azure Stack Hub doit être appliquée sur la version 2102 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack Hub 1.2102.31.153

Après application correcte de la mise à jour 2108

Après l’installation de la version 2108, si des correctifs logiciels pour cette version sont publiés par la suite, vous devez les installer :

Correctif logiciel Azure Stack Hub 1.2108.2.130

Référence de la build 2008

Le dernier numéro de build de la mise à jour 2008 d’Azure Stack Hub est 1.2008.40.149. Pour obtenir des informations mises à jour sur les builds et les correctifs, consultez la section Correctifs.

Type de mise à jour

Le type de build de la mise à jour 2008 d’Azure Stack Hub est Complète.

La taille du package de mise à jour 2008 est supérieure à celle des mises à jour précédentes. Cette augmentation de taille allonge les temps de téléchargement. La mise à jour reste à l’état de préparation pendant une longue période, et les opérateurs peuvent s’attendre à ce que ce processus prenne plus de temps qu’avec les mises à jour précédentes. La mise à jour 2008 a eu les runtimes attendus suivants dans nos tests internes - 4 nœuds : 13-20 heures, 8 nœuds : 16-26 heures, 12 nœuds : 19-32 heures, 16 nœuds : 22 à 38 heures. La durée d’exécution exacte de la mise à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des caractéristiques de vos composants matériels système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette durée d’exécution approximative est propre à la mise à jour 2008. Elle ne doit pas être comparée aux autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Azure Stack Hub prend à présent en charge la fonctionnalité VNET Peering, ce qui permet de connecter des réseaux virtuels sans appliance virtuelle réseau. Pour plus d’informations, consultez la documentation sur la nouvelle fonctionnalité VNET Peering.
Le stockage d’objets blob Azure Stack Hub permet à présent aux utilisateurs d’utiliser un objet blob immuable. En définissant des stratégies immuables sur un conteneur, vous pouvez stocker les objets de données vitaux pour l’entreprise dans un état WORM (Write Once, Read Many). Dans cette version, les stratégies immuables ne peuvent être définies qu’à l’aide de l’API REST ou des SDK clients. Les écritures d’objets blob d’ajout ne sont pas non plus possibles dans cette version. Pour plus d’informations sur les objets blob immuables, consultez Stocker des données blob critiques pour l’entreprise avec un stockage immuable.
Le stockage Azure Stack Hub prend désormais en charge les API des services de stockage Azure version 2019-07-07. Pour les bibliothèques clientes Azure, compatibles avec la nouvelle version de l’API REST, consultez Outils de développement de stockage Azure Stack Hub. Pour les API de gestion des services de stockage Azure, la version 2018-02-01 a été ajoutée à la prise en charge, avec un sous-ensemble de fonctionnalités totales disponibles.
Le service de calcul Azure Stack Hub prend désormais en charge les API Azure Compute version 2020-06-01, avec un sous-ensemble des fonctionnalités totales disponibles.
Les disques managés Azure Stack Hub prennent désormais en charge les API Azure Disk version 2019-03-01, avec un sous-ensemble des fonctionnalités disponibles.
Préversion de Windows Admin Center qui peut maintenant se connecter à Azure Stack Hub pour fournir des insights approfondis sur l’infrastructure pendant les opérations de support (arrêt requis).
Possibilité d’ajouter une bannière de connexion au point de terminaison privilégié au moment du déploiement.
Publication de nouvelles bannières Opérations exclusives, qui améliorent la visibilité des opérations en cours sur le système, et qui permettent aux utilisateurs de lancer (et de faire échouer ultérieurement) toute autre opération exclusive.
Introduction de deux nouvelles bannières dans chaque page produit de l’élément de la Place de marché Azure Stack Hub. En cas de défaillance du téléchargement de la Place de marché, les opérateurs peuvent afficher les détails de l’erreur et tenter d’effectuer les étapes recommandées pour résoudre le problème.
Publication d’un outil de notation permettant aux clients de fournir des commentaires. Cela permet à l’équipe Azure Stack Hub de mesurer et d’optimiser l’expérience utilisateur.
Cette version d’Azure Stack Hub comprend une préversion privée d’Azure Kubernetes service (AKS) et d’Azure Container Registry (ACR). L’objectif de la préversion privée consiste à recueillir des commentaires en termes de qualité, de fonctionnalités et d’expérience utilisateur de AKS et ACR sur Azure Stack Hub.
Cette version comprend une préversion publique des conteneurs Azure CNI et Windows utilisant le moteur AKS v0.55.4. Pour un exemple sur la manière de les utiliser dans votre modèle d’API, consultez cet exemple sur GitHub.
Il existe désormais une prise en charge du déploiement Istio 1.3 sur les clusters déployés par le moteur AKS v0.55.4. Pour plus d’informations, consultez ces instructions.
Il existe désormais une prise en charge du déploiement des clusters privés utilisant le moteur AKS v0.55.4.
Cette version prend en charge l’approvisionnement des secrets de configuration Kubernetes depuis Azure et Key Vault Azure Stack Hub Key.

Améliorations

Mise en œuvre de la surveillance interne pour le contrôleur de réseau et les agents hôtes SLB. Les services sont donc corrigés automatiquement s’ils entrent dans un état arrêté.
Les services de fédération Active Directory (AD FS) récupèrent désormais le nouveau certificat de signature de jetons après que le client a effectué sa rotation sur son propre serveur AD FS. Pour tirer parti de cette nouvelle fonctionnalité pour les systèmes déjà configurés, l’intégration de AD FS doit être reconfigurée. Pour plus d’informations, consultez Intégrer l’identité AD FS avec votre centre de données Azure Stack Hub.
Modifications apportées au processus de démarrage et d’arrêt sur les instances de rôle d’infrastructure et leurs dépendances sur les nœuds d’unité d’échelle. Ces modifications augmentent la fiabilité du démarrage et de l’arrêt d’Azure Stack Hub.
La suite AzSScenarios de l’outil de validation Test-AzureStack a été mise à jour pour permettre aux fournisseurs de services cloud d’exécuter correctement cette suite avec l’authentification multifacteur appliquée à tous les comptes clients.
Amélioration de la fiabilité des alertes en ajoutant une logique de suppression pour 29 alertes côté client pendant les opérations de cycle de vie.
Vous pouvez désormais afficher un rapport HTML de collection de journaux qui fournit des détails sur les rôles, la durée et l’état de la collection de journaux. Ce rapport a pour objectif d’aider les utilisateurs à fournir un résumé des journaux collectés. Les services de support technique Microsoft peuvent ensuite rapidement examiner le rapport pour évaluer les données de journal et faciliter l’atténuation et la résolution des problèmes système.
La couverture de détection des défaillances d’infrastructure a été améliorée moyennant l’ajout de 7 nouvelles analyses dans des scénarios utilisateur, tels que l’utilisation du processeur et la consommation de mémoire, pour plus de fiabilité en matière de détection des défaillances.

Modifications

La propriété de type de ressource de compte de stockage supportHttpsTrafficOnly dans la version de l’API SRP 2016-01-01 et 2016-05-01 a été activée, mais cette propriété n’est pas prise en charge dans Azure Stack Hub.
Augmentation du seuil d’alerte d’utilisation de la capacité du volume de 80 % (avertissement) et 90 % (critique) à 90 % (avertissement) et 95 % (critique). Pour plus d’informations, consultez la page Alertes de l’espace de stockage.
Les étapes de configuration d’AD Graph changent avec cette version. Pour plus d’informations, consultez Intégrer l’identité AD FS avec votre centre de données Azure Stack Hub.
Pour s’aligner sur les meilleures pratiques actuelles définies pour Windows Server 2019, Azure Stack Hub change de façon à utiliser une classe de trafic ou une priorité supplémentaires afin de séparer davantage la communication de serveur à serveur à l’appui de la communication de contrôle du clustering de basculement. Le résultat de ces modifications offre une meilleure résilience pour la communication des clusters de basculement. Cette configuration de réservation de bande passante et de classe de trafic est opérée par une modification des commutateurs ToR (top-of-rack) de la solution Azure Stack Hub, ainsi que sur l’ordinateur hôte ou les serveurs d’Azure Stack Hub.

Ces modifications sont ajoutées au niveau de l’hôte d’un système Azure Stack Hub. Contactez votre fabricant OEM pour effectuer le changement au niveau des commutateurs réseau ToR (top-of-rack). Cette modification des commutateurs ToR peut être effectuée tant avant qu’après la mise à jour vers la version 2008. Pour plus d’informations, consultez la documentation relative à l’intégration réseau.
Les tailles de machines virtuelles compatibles GPU NCas_v4 (NVIDIA T4) ont été remplacées dans cette version par les tailles de machines virtuelles NCasT4_v3, à des fins de mise en cohérence avec Azure. Celles-ci ne sont pas encore visibles sur le portail et ne peuvent être utilisées que via des modèles Azure Resource Manager.

Correctifs

Correction d’un problème où la suppression d’un groupe de sécurité réseau d’une carte réseau qui n’est pas attachée à une machine virtuelle en cours d’exécution échouait.
Correction d’un problème où la modification de la valeur IdleTimeoutInMinutes pour une adresse IP publique associée à un équilibreur de charge plaçait l’adresse IP publique dans un état d’échec.
Correction de l’applet de commande Get-AzsDisk pour qu’elle retourne l’état Attaché approprié, au lieu de OnlineMigration, pour les disques managés attachés.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. Avant d’effectuer la mise à jour vers la version 2008, veillez à installer le dernier correctif de la version 2005. De plus, depuis la version 2005, lorsque vous effectuez une mise à jour vers une nouvelle version principale (par exemple, 1.2005.x vers 1.2008.x), les derniers correctifs (s’il y en a au moment du téléchargement du package) de la nouvelle version principale sont installés automatiquement. Votre installation de la version 2008 est alors à jour de tous les correctifs logiciels. À partir de là, si un correctif est publié pour la version 2008, vous devez l’installer.

Remarque

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Conseil

Si vous souhaitez être averti de chaque mise en production de correctif logiciel, abonnez-vous au flux RSS.

Après l’application réussie de la mise à jour 2008

Étant donné que les correctifs Azure Stack Hub sont cumulatifs, il est recommandé d’installer tous les correctifs publiés pour votre build afin de garantir la meilleure expérience de mise à jour possible entre les versions majeures. Lorsque vous effectuez une mise à jour vers une nouvelle version principale (par exemple, 1.2005.x vers 1.2008.x), les derniers correctifs (s’il y en a au moment du téléchargement du package) de la nouvelle version principale sont installés automatiquement.

Après l’installation de 2008, si des correctifs 2008 sont mis en production par la suite, vous devez les installer :

Correctif Azure Stack Hub 1.2008.40.154

Notes de publication archivées 2005

Le numéro de build de la mise à jour 2005 d’Azure Stack Hub est 1.2005.6.53.

Type de mise à jour

Le type de build de la mise à jour 2005 d’Azure Stack Hub est Complète.

La taille du package de mise à jour 2005 est supérieure à celle des mises à jour précédentes. Cette augmentation de taille allonge les temps de téléchargement. La mise à jour reste à l’état de préparation pendant une longue période, et les opérateurs peuvent s’attendre à ce que ce processus prenne plus de temps qu’avec les mises à jour précédentes. La mise à jour 2005 a eu les runtimes attendus suivants dans nos tests internes - 4 nœuds : 13-20 heures, 8 nœuds : 16-26 heures, 12 nœuds : 19-32 heures, 16 nœuds : 22 à 38 heures. La durée d’exécution exacte de la mise à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des caractéristiques de vos composants matériels système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette durée d’exécution approximative est propre à la mise à jour 2005. Elle ne doit pas être comparée aux autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Cette build offre la prise en charge de 3 nouveaux types de machines virtuelles GPU : NCv3 (Nvidia V100), NVv4 (AMD MI25) et NCas_v4 (NVIDIA T4) tailles de machine virtuelle. Les déploiements de machines virtuelles seront réussis pour ceux qui disposent du matériel approprié et sont intégrés au programme de préversion du GPU Azure Stack Hub. Si vous êtes intéressé, inscrivez-vous au programme de préversion du GPU sur https://aka.ms/azurestackhubgpupreview. Pour plus d’informations, consultez .
Cette version fournit une nouvelle fonctionnalité qui permet une capacité de réparation autonome, qui détecte les défaillances, évalue l’impact et atténue en toute sécurité les problèmes système. Avec cette fonctionnalité, nous travaillons à l’augmentation de la disponibilité du système sans intervention manuelle. Avec la version 2005 et les versions ultérieures, les clients subissent une réduction du nombre d’alertes. L’intervention des opérateurs d’Azure Stack Hub n’est pas nécessaire pour chaque défaillance de ce pipeline, sauf notification.
Il existe une nouvelle option dans le portail d’administration Azure Stack Hub pour les clients disposant d’une connexion orientée vers l’air et déconnectée Azure Stack Hub, afin d’enregistrer les journaux localement. Vous pouvez stocker les journaux dans un partage SMB local lorsque Azure Stack Hub est déconnecté d’Azure.
Le portail d’administration Azure Stack Hub bloque désormais certaines opérations si une opération système est déjà en cours. Par exemple, si une mise à jour est en cours, il n’est pas possible d’ajouter un nouveau nœud d’unité d’échelle.
Cette version offre une plus grande cohérence des structures avec Azure sur les machines virtuelles créées avant la version 1910. Pour la version 1910, Microsoft a annoncé que toutes les machines virtuelles nouvellement créées utiliseront le protocole wireserver, ce qui permettra aux clients d’utiliser le même agent WALA et l’agent invité Windows comme Azure, facilitant ainsi l’utilisation des images Azure sur Azure Stack Hub. Avec cette version, toutes les machines virtuelles créées avant le 1910 sont automatiquement migrées pour utiliser le protocole wireserver. Cela permet également d’améliorer la fiabilité de la création de machines virtuelles, le déploiement d’extension de machines virtuelles et l’amélioration du temps de bon fonctionnement.
Le stockage Azure Stack Hub prend désormais en charge les API des services de stockage Azure version 2019-02-02. Pour les bibliothèques clientes Azure, compatibles avec la nouvelle version de l’API REST. Pour plus d’informations, consultez outils de développement du stockage Azure Stack Hub.
Azure Stack Hub prend maintenant en charge la dernière version de CreateUiDefinition (version 2).
Nouvelle aide pour les déploiements de machines virtuelles par lot. Pour plus d’informations, consultez cet article.
L’élément Conteneur de système d’exploitation principal Linux de la Place de marché Azure Stack Hub approche de sa fin de vie. Pour plus d’informations, consultez Migration à partir du conteneur de système d’exploitation principal Linux.

Améliorations

Améliorations apportées aux journaux et aux événements du service de cluster d’infrastructure de stockage. Les journaux et les événements du service de cluster de l’infrastructure de stockage sont conservés pendant jusqu’à 14 jours, afin d’améliorer les diagnostics et la résolution des problèmes.
Améliorations qui augmentent la fiabilité du démarrage et de l’arrêt d’Azure Stack Hub.
Améliorations qui réduisent le runtime des mises à jour à l’aide de la décentralisation et de la suppression des dépendances. Comparée à la mise à jour 2002, le temps de mise à jour de l’empreinte de 4 nœuds est réduit de 15 à 42 heures à 13 à 20 heures. 8 nœuds sont réduits de 20 à 50 heures à 16 à 26 heures. 12 nœuds sont réduits de 20 à 60 heures à 19 à 32 heures. 16 nœuds sont réduits de 25 à 70 heures à 22 à 38 heures. La durée d’exécution exacte de la mise à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des caractéristiques de vos composants matériels système.
La mise à jour échoue à l’heure actuelle en cas d’erreurs irrécupérables.
Résilience améliorée du package de mise à jour lors du téléchargement à partir d’Internet.
Résilience améliorée de l’arrêt de la désallocation d’une machine virtuelle.
Résilience améliorée de l’agent hôte du contrôleur de réseau.
Ajout de champs à la charge utile CEF des messages syslog pour signaler l’adresse IP source et le compte utilisé pour se connecter au point de terminaison privilégié et au point de terminaison de récupération. Consultez Intégrer Azure Stack Hub à des solutions de supervision avec le transfert Syslog pour plus d’informations.
Ajout des événements Windows Defender (ID d’événement 5001, 5010, 5012) à la liste des événements émis par le biais du client syslog.
Ajout d’alertes dans le portail d’administration Azure Stack pour les événements liés à Windows Defender, pour signaler les incohérences de version de la plateforme et des signatures Defender et ne pas prendre des mesures sur les programmes malveillants détectés.
Ajout de la prise en charge de 4 appareils de bordure lors de l’intégration d’Azure Stack Hub dans votre centre de données.

Modifications

Suppression des actions pour arrêter, interrompre et redémarrer une instance de rôle d’infrastructure à partir du portail d’administration. Les API correspondantes ont également été supprimées dans le fournisseur de ressources d’infrastructure. Les applets de commande PowerShell suivantes dans le module RM d’administration et la préversion AZ pour Azure Stack Hub ne fonctionnent plus : Stop-AzsInfrastructureRoleInstance, Disable-InfrastructureRoleInstance et Restart-InfrastructureRoleInstance. Ces cmdlets seront supprimées de la prochaine version du module AZ administrateur pour Azure Stack Hub.
Azure Stack Hub 2005 prend désormais en charge uniquement App Service sur Azure Stack Hub 2020 (versions 87. x).
Le paramètre de chiffrement des utilisateurs requis pour la surveillance du matériel est passé de DES à AES afin de renforcer la sécurité. Contactez votre fournisseur de matériel pour savoir comment modifier le paramètre dans le contrôleur de gestion de la carte de base (BMC). Une fois la modification apportée dans le BMC, vous devrez peut-être réexécuter la commande Set-BmcCredential en utilisant le point de terminaison privilégié. Pour plus de détails, consultez Effectuer la rotation des secrets dans Azure Stack Hub.

Correctifs

Correction d’un problème qui pouvait entraîner l’échec d’un nœud d’unité d’échelle de réparation, car il n’a pas pu trouver le chemin d’accès à l’image du système d’exploitation de base.
Résolution d’un problème avec un scale-out et un scale-in pour le rôle d’infrastructure de support qui a un effet en cascade sur la réparation des nœuds d’unité d’échelle.
Correction d’un problème dans lequel l’extension .VHD (au lieu de .vhd) n’était pas autorisée lorsque les opérateurs ajoutaient leurs propres images au portail d’administration Azure Stack Hub sur Tous les services> Capacité de calcul > Images de machine virtuelle > Ajouter.
Correction d’un problème dans lequel une précédente opération de redémarrage de la machine virtuelle provoquait un redémarrage inattendu suivant après une autre opération de mise à jour de machines virtuelles (ajout de disques, de balises, etc.).
Correction d’un problème entraînant le blocage du portail lors de la création d’une zone DNS dupliquée. Il doit maintenant afficher une erreur appropriée.
Correction d’un problème dans lequel Get-AzureStackLogs n’a pas collecté les journaux requis pour résoudre les problèmes de mise en réseau.
Correction d’un problème dans lequel le portail permettait l’attachement de moins d’adaptateurs réseau que ce qu’il autorise réellement.
Correction de la stratégie d’intégrité du code pour ne pas émettre d’événements de violation pour certains logiciels internes. Cela réduit le bruit dans les événements de violation d’intégrité du code émis par le client syslog.
Correction de la cmdlet Set-TLSPolicy pour appliquer une nouvelle stratégie sans redémarrage du service https ni de l’hôte.
Correction d’un problème dans lequel l’utilisation d’un serveur NTP Linux génère de façon erronée des alertes dans le portail d’administration.
Correction d’un problème où le basculement de l’instance de service de contrôleur de sauvegarde entraînait la désactivation des sauvegardes automatiques.
Correction d’un problème où la rotation du secret interne échoue lorsque les services d’infrastructure n’ont pas de connectivité Internet.
Correction d’un problème empêchant les utilisateurs d’afficher les autorisations d’abonnement à l’aide des portails Azure Stack Hub.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. À partir de la version 2005, lorsque vous mettez à jour vers une nouvelle version principale (par exemple, 1.2002.x vers 1.2005.x), les derniers correctifs (le cas échéant) de la nouvelle version principale sont installés automatiquement. À partir de là, si un correctif est mis en production pour votre build, vous devez l’installer.

Remarque

Pour plus d’informations, consultez notre stratégie de maintenance.

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Conditions préalables : avant d’appliquer la mise à jour 2005

La version 2005 d’Azure Stack Hub doit être appliquée sur la version 2002 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack Hub 1.2002.66.173

Après l’application réussie de la mise à jour 2005

À partir de la version 2005, lorsque vous mettez à jour vers une nouvelle version principale (par exemple, 1.2002.x vers 1.2005.x), les derniers correctifs (le cas échéant) de la nouvelle version principale sont installés automatiquement.

Après l’installation de 2005, si des correctifs 2005 sont mis en production par la suite, vous devez les installer :

Correctif logiciel Azure Stack Hub 1.2005.35.112

Notes de publication archivées 2002

Cet article décrit le contenu des mises à jour d’Azure Stack Hub. La mise à jour inclut les améliorations et les correctifs logiciels de la dernière version d’Azure Stack Hub.

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack Hub. N’appliquez pas cette mise à jour au Kit de développement Azure Stack (ASDK).

Important

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Pour obtenir de l’aide sur la résolution des problèmes liés aux mises à jour et au processus de mise à jour, consultez Résoudre les problèmes liés aux correctifs logiciels et aux mises à jour pour Azure Stack Hub.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour d’Azure Stack Hub à l’aide de l’outil téléchargeur des mises à jour d’Azure Stack Hub.

Référence de la build 2002

Le numéro de build de la mise à jour 2002 d’Azure Stack Hub est 1.2002.0.35.

Important

Avec la mise à jour Azure Stack Hub 2002, Microsoft prolonge provisoirement nos conditions de politique de support d’Azure Stack Hub. Nous travaillons avec des clients du monde entier qui sont confrontés au virus COVID-19 et qui peuvent prendre des décisions importantes sur leurs systèmes Azure Stack Hub et sur la façon dont ils sont mis à jour et gérés, afin que les opérations commerciales de leur centre de données continuent de fonctionner normalement. Pour aider nos clients, Microsoft propose de reporter provisoirement le changement de politique de support pour inclure trois versions de mise à jour précédentes. Ainsi, la nouvelle mise à jour 2002 et les trois versions de mise à jour précédentes (par exemple, 1910, 1908 et 1907) sont prises en charge.

Type de mise à jour

Le type de build de la mise à jour 2002 d’Azure Stack Hub est Complète.

La taille du package de mise à jour 2002 est supérieure à celle des mises à jour précédentes. Cette augmentation de taille allonge les temps de téléchargement. La mise à jour reste à l’état de préparation pendant une longue période, et les opérateurs peuvent s’attendre à ce que ce processus prenne plus de temps qu’avec les mises à jour précédentes. La mise à jour 2002 a eu les runtimes attendus suivants dans nos tests internes - 4 nœuds : 15-42 heures, 8 nœuds : 20 à 50 heures, 12 nœuds : 20-60 heures, 16 nœuds : 25 à 70 heures. La durée d’exécution exacte de la mise à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des caractéristiques de vos composants matériels système. Les durées d’exécution plus courtes ou plus longues que la valeur attendue ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette durée d’exécution approximative est propre à la mise à jour 2002. Elle ne doit pas être comparée aux autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Une nouvelle version (1.8.1) des modules PowerShell d’administration d’Azure Stack Hub basés sur AzureRM est disponible.
Une nouvelle version de l’API REST d’administration d’Azure Stack Hub est disponible. Vous trouverez plus d’informations sur les points de terminaison et les modifications cassantes dans les Informations de référence sur l’API.
Les nouveaux modules de locataire Azure PowerShell seront publiés pour Azure Stack Hub le 15 avril 2020. Les modules Azure RM utilisés continuent de fonctionner, mais ne seront plus mis à jour après la build 2002.
Ajout d’une nouvelle alerte d’avertissement sur le portail administrateur Azure Stack Hub pour signaler les problèmes de connectivité avec le serveur syslog configuré. Le titre de l’alerte indique que le client Syslog a rencontré un problème de réseau lors de l’envoi d’un message Syslog.
Ajout d’une nouvelle alerte d’avertissement sur le portail administrateur Azure Stack Hub pour signaler les problèmes de connectivité avec le serveur NTP (Network Time Protocol). Le titre de l’alerte indique que la source de temps n’est pas valide sur [nom du nœud].
Le SDK Java a publié de nouveaux packages en raison d’un changement cassant dans la version 2002 lié aux restrictions TLS. Vous devez installer la nouvelle dépendance du SDK Java. Vous trouverez les instructions à la section Java et les profils de version d’API.
Une nouvelle version (1.0.5.10) du pack d’administration de System Center Operations Manager - Azure Stack Hub est disponible et est nécessaire pour tous les systèmes exécutant 2002 en raison des la rupture des changements cassants apportées aux API. Les changements apportés aux API impactent les tableaux de bord des performances de sauvegarde et de stockage, et nous vous recommandons de commencer par mettre à jour tous les systèmes vers la version 2002 avant de mettre à jour le pack d’administration.

Améliorations

Cette mise à jour contient des modifications du processus de mise à jour qui améliorent considérablement les performances des futures mises à jour complètes. Ces modifications prennent effet avec la prochaine mise à jour complète après la version 2002, et visent spécifiquement à améliorer les performances de la phase d’une mise à jour complète dans laquelle les systèmes d’exploitation hôtes sont mis à jour. L’amélioration des performances des mises à jour des systèmes d’exploitation hôtes réduit considérablement la durée pendant laquelle les charges de travail des locataires sont impactées pendant les mises à jour complètes.
L’outil de vérification de la disponibilité d’Azure Stack Hub valide désormais l’intégration d’AD Graph à l’aide de tous les ports TCP IP alloués à AD Graph.
L’outil de syndication hors connexion a été mis à jour avec des améliorations de la fiabilité. L’outil n’est plus disponible sur GitHub et a été déplacé vers PowerShell Gallery. Pour plus d’informations, consultez Télécharger des éléments de la Place de marché vers Azure Stack Hub.
Une nouvelle fonctionnalité de supervision est sur le point d’être ajoutée. L’alerte concernant un espace disque insuffisant pour les hôtes physiques et les machines virtuelles d’infrastructure sera corrigée automatiquement par la plateforme. Si cette action échoue, l’alerte s’affichera dans le portail d’administration Azure Stack Hub pour que l’opérateur corrige le problème.
Améliorations apportées à la collecte des journaux de diagnostic. La nouvelle expérience rationalise et simplifie la collecte des journaux de diagnostic en éliminant la nécessité de configurer un compte de stockage d’objets blob à l’avance. L’environnement de stockage est préconfiguré afin que vous puissiez envoyer des journaux avant d’ouvrir un cas de support et consacrer moins de temps à un appel de support.
Le temps nécessaire à la collecte proactive des journaux et à la collecte des journaux à la demande a été réduit de 80 %. La collecte des journaux peut prendre plus de temps que cette valeur attendue, mais elle ne nécessite aucune action de la part des opérateurs Azure Stack Hub, sauf si la collecte des journaux échoue.
La progression du téléchargement d’un package de mise à jour Azure Stack Hub est désormais visible dans le panneau de mise à jour après le lancement d’une mise à jour. Seuls sont concernés les systèmes connectés Azure Stack Hub qui choisissent de préparer les packages de mise à jour par le biais du téléchargement automatique.
Améliorations de la fiabilité de l’agent hôte du contrôleur de réseau.
Introduction d’un nouveau micro-service nommé DNS Orchestrator qui améliore la logique de résilience pour les services DNS internes au cours des mises à jour et des correctifs.
Ajout d’une nouvelle validation de demande visant à faire échouer les URI d’objet blob non valides pour le paramètre de compte de stockage de diagnostics de démarrage lors de la création de machines virtuelles.
Améliorations de la correction automatique et de la journalisation pour Rdagent et l’agent Host, deux services sur l’hôte qui facilitent les opérations CRUD de machine virtuelle.
Ajout d’une nouvelle fonctionnalité à la gestion de la Place de marché qui permet à Microsoft d’ajouter des attributs qui empêchent les administrateurs de télécharger des produits de la Place de marché qui ne sont pas compatibles avec leurs environnements Azure Stack, en raison de différents propriétés, comme la version Azure Stack ou le modèle de facturation. Seul Microsoft peut ajouter ces attributs. Pour plus d’informations, consultez Utiliser le portail pour télécharger les éléments de la Place de marché.

Modifications

Le portail administrateur indique à présent si une opération est en cours, avec une icône en regard de la région Azure Stack. Quand vous pointez sur l’icône, le nom de l’opération s’affiche. Cela vous permet d’identifier les opérations système en cours d’exécution en arrière-plan, telles qu’un travail de sauvegarde ou une extension de stockage pouvant s’exécuter pendant plusieurs heures.

Les API d’administration suivantes ont été dépréciées :

Fournisseur de ressources	Ressource	Version
Microsoft.Storage.Admin	exploitations agricoles	2015-12-01-preview
Microsoft.Storage.Admin	farms/acquisitions	2015-12-01-preview
Microsoft.Storage.Admin	farms/shares	2015-12-01-preview
Microsoft.Storage.Admin	farms/storageaccounts	2015-12-01-preview

Les API d’administration suivantes ont été remplacées par une version plus récente (2018-09-01) :

Fournisseur de ressources Ressource Version

Microsoft.Backup.Admin backupLocation 2016-05-01

Microsoft.Backup.Admin sauvegardes 2016-05-01

Microsoft.Backup.Admin Opérations 2016-05-01
Quand vous créez une machine virtuelle Windows à l’aide de PowerShell, veillez à ajouter l’indicateur provisionvmagent si vous souhaitez que la machine virtuelle déploie des extensions. Sans cet indicateur, la machine virtuelle est créée sans l’agent invité, ce qui supprime la possibilité de déployer les extensions de machine virtuelle :
```
$VirtualMachine = Set-AzureRmVMOperatingSystem `
   -VM $VirtualMachine `
   -Windows `
   -ComputerName "MainComputer" `
   -Credential $Credential -ProvisionVMAgent
```

Fournisseur de ressources	Ressource	Version
Microsoft.Backup.Admin	backupLocation	2016-05-01
Microsoft.Backup.Admin	sauvegardes	2016-05-01
Microsoft.Backup.Admin	Opérations	2016-05-01

Correctifs

Correction d’un problème où l’ajout de plusieurs adresses IP publiques sur la même carte réseau d’une machine virtuelle provoquait des problèmes de connectivité Internet. À présent, une carte réseau avec deux adresses IP publiques fonctionne comme prévu.
Résolution d’un problème qui provoquait la génération d’une alerte par le système, indiquant que le répertoire de démarrage d’Azure AD devait être configuré.
Résolution d’un problème qui provoquait l’échec de la fermeture automatique d’une alerte. L’alerte indiquait que le répertoire de démarrage d’Azure AD devait être configuré, mais ne se fermait pas même après l’atténuation du problème.
Résolution d’un problème qui provoquait l’échec des mises à jour pendant la phase de leur préparation à la suite de défaillances internes du fournisseur de ressources de mise à jour.
Résolution d’un problème provoquant l’échec des opérations du fournisseur de ressources de module complémentaire après l’exécution de la rotation des secrets Azure Stack Hub.
Résolution d’un problème qui était une cause courante des échecs de mise à jour d’Azure Stack Hub en raison de la sollicitation de la mémoire sur le rôle ERCS.
Correction d’un bogue dans le panneau de mise à jour lié au fait que l’état de la mise à jour indiquait Installation au lieu de Préparation pendant la phase de préparation d’une mise à jour d’Azure Stack Hub.
Résolution d’un problème lié au fait que la fonctionnalité RSC sur les commutateurs virtuels créait des incohérences et abandonnait le trafic circulant via un équilibreur de charge. La fonctionnalité RSC est désormais désactivée par défaut.
Résolution d’un problème lié au fait que plusieurs configurations IP sur une carte réseau entraînaient un routage incorrect et empêchaient la connectivité sortante.
Résolution d’un problème lié au fait que l’adresse MAC d’une carte réseau était mise en cache et que l’affectation de cette adresse à une autre ressource provoquait des échecs de déploiement de machine virtuelle.
Résolution d’un problème lié au fait que la licence des images de machine virtuelle Windows du canal de vente au détail n’a pas pu être activée par AVMA.
Résolution d’un problème qui entraînait l’échec de la création de machines virtuelles si le nombre de cœurs virtuels demandés par la machine virtuelle était égal au nombre de cœurs physiques du nœud. Nous autorisons maintenant les machines virtuelles à avoir un nombre de cœurs virtuels égal ou inférieur au nombre de cœurs physiques du nœud.
Résolution d’un problème lié au fait que nous n’autorisons pas la définition du type de licence sur « null » pour basculer les images avec paiement à l’utilisation vers BYOL.
Résolution d’un problème empêchant l’ajout d’extensions à un groupe de machines virtuelles identiques.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. Veillez à installer le dernier correctif logiciel Azure Stack Hub pour la version 1910 avant de mettre à jour Azure Stack Hub vers la version 2002.

Remarque

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Pour plus d’informations sur les correctifs, consultez la stratégie de maintenance Azure Stack Hub.

Conditions préalables : avant d’appliquer la mise à jour 2002

La version 2002 d’Azure Stack Hub doit être appliquée sur la version 1910 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack Hub 1.1910.84.230

Après l’application de la mise à jour 2002

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables.

Correctif logiciel Azure Stack Hub 1.2002.68.177

Notes de publication archivées 1910

Cet article décrit le contenu des mises à jour d’Azure Stack Hub. La mise à jour inclut les améliorations et les correctifs logiciels de la dernière version d’Azure Stack Hub.

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack Hub. N’appliquez pas cette mise à jour au Kit de développement Azure Stack (ASDK).

Important

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour d’Azure Stack Hub à l’aide de l’outil téléchargeur des mises à jour d’Azure Stack Hub.

Référence de la build 1910

Le numéro de build de la mise à jour 1910 d’Azure Stack Hub est 1.1910.0.58.

Type de mise à jour

Depuis la version 1908, le système d’exploitation sous-jacent sur lequel Azure Stack Hub s’exécute a été mis à jour vers Windows Server 2019. Cette mise à jour apporte des améliorations fondamentales et permet l’ajout de fonctionnalités supplémentaires dans Azure Stack Hub.

Le type de build de la mise à jour 1910 d’Azure Stack Hub est Express.

Le package de la mise à jour 1910 étant d’une taille supérieure à celle des mises à jour précédentes, les temps de téléchargement sont plus longs. La mise à jour reste à l’état de préparation pendant une longue période, et les opérateurs peuvent s’attendre à ce que ce processus prenne plus de temps que les mises à jour précédentes. Le temps prévu pour la mise à jour 1910 est d’environ 10 heures, quel que soit le nombre de nœuds physiques dans votre environnement Azure Stack Hub. La durée d’exécution exacte de la mise à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail de locataire, de la connectivité réseau de votre système (s’il est connecté à Internet) et des caractéristiques de vos composants matériels système. Il n’est pas rare d’observer des durées d’exécution plus longues que la durée prévue, mais cela ne nécessite aucune action de la part des opérateurs Azure Stack Hub, sauf en cas d’échec de la mise à jour. Cette durée d’exécution approximative est propre à la mise à jour 1910. Elle ne doit pas être comparée aux autres mises à jour d’Azure Stack Hub.

Pour plus d’informations sur les types de build de mise à jour, consultez Gérer les mises à jour dans Azure Stack Hub.

Nouveautés

Le portail administrateur montre désormais les adresses IP des points de terminaison privilégiés dans le menu des propriétés de région pour faciliter leur découverte. Il montre aussi le serveur de temps et les redirecteurs DNS actuellement configurés. Pour plus d’informations, consultez Utiliser le point de terminaison privilégié dans Azure Stack Hub.
Le système de contrôle d’intégrité et de supervision d’Azure Stack Hub peut désormais déclencher des alertes pour divers composants matériels en cas d’erreur. Ces alertes nécessitent une configuration supplémentaire. Pour plus d’informations, consultez Superviser les composants matériels d’Azure Stack Hub.
Prise en charge cloud-init pour Azure Stack Hub : Cloud-init est une approche largement utilisée pour personnaliser une machine virtuelle Linux au démarrage pour la première fois. Vous pouvez utiliser cloud-init pour installer des packages et écrire des fichiers, ou encore pour configurer des utilisateurs ou des paramètres de sécurité. cloud-init étant appelé pendant le processus de démarrage initial, aucune autre étape ni aucun agent ne sont nécessaires pour appliquer votre configuration. Les images Ubuntu de la Place de marché ont été mises à jour pour prendre en charge cloud-init pour le provisionnement.
Azure Stack Hub prend désormais en charge toutes les versions de l’agent Windows Azure Linux en tant qu’Azure.
Une nouvelle version des modules PowerShell d’administration d’Azure Stack Hub est disponible.
Les nouveaux modules d’abonnés Azure PowerShell ont été mis en production pour Azure Stack Hub le 15 avril 2020. Les modules Azure RM utilisés continuent de fonctionner, mais ne seront plus mis à jour après la build 2002.
Ajout de l’applet de commande Set-AzSDefenderManualUpdate dans le point de terminaison privilégié (PEP) pour configurer la mise à jour manuelle des définitions Windows Defender dans l’infrastructure Azure Stack Hub. Pour plus d’informations, consultez Mettre à jour l’antivirus Windows Defender sur Azure Stack Hub.
Ajout de l’applet de commande Set-AzSDnsForwarder dans le point de terminaison privilégié (PEP) pour changer les paramètres de redirecteur des serveurs DNS dans Azure Stack Hub. Pour plus d’informations sur la configuration DNS, consultez Intégration des services DNS au centre de données Azure Stack Hub.
Ajout de la prise en charge de la gestion des clusters Kubernetes à l’aide du moteur AKS. À partir de cette mise à jour, les clients peuvent déployer des clusters Kubernetes de production. Le moteur AKS permet aux utilisateurs d’effectuer les opérations suivantes :
- Gérer le cycle de vie de leurs clusters Kubernetes. Ils peuvent créer, mettre à jour et mettre à l’échelle des clusters.
- Gérer leurs clusters à l’aide d’images managées produites par AKS et les équipes Azure Stack Hub.
- Tirer parti d’un fournisseur de cloud Kubernetes intégré à Azure Resource Manager, qui crée des clusters à l’aide de ressources Azure natives.
- Déployer et gérer leurs clusters dans des empreintes Azure Stack Hub connectées ou déconnectées.
- Utilisez les fonctionnalités hybrides Azure :
  - Intégration avec Azure Arc.
  - Intégration avec Azure Monitor pour conteneurs.
- Utiliser des conteneurs Windows avec le moteur AKS.
- Bénéficier du support Microsoft et d’ingénierie pour leurs déploiements.

Améliorations

Azure Stack Hub a amélioré sa capacité à corriger automatiquement certains problèmes liés aux correctifs logiciels et aux mises à jour, qui entraînaient des échecs de mise à jour ou empêchaient les opérateurs de lancer une mise à jour d’Azure Stack Hub. Par conséquent, le groupe Test-AzureStack -UpdateReadiness comprend moins de tests. Pour plus d’informations, consultez Valider l’état du système Azure Stack Hub. Les trois tests suivants font encore partie du groupe UpdateReadiness :
- AzSInfraFileValidation
- AzSActionPlanStatus
- AzsStampBMCSummary
Ajout d’une règle d’audit pour signaler le moment où un périphérique externe (par exemple une clé USB) est monté sur un nœud de l’infrastructure Azure Stack Hub. Le journal d’audit est émis via syslog et s’affiche en tant que Microsoft-Windows-Security-Audit : 6416|Plug-and-Play Événements. Pour plus d’informations sur la façon de configurer le client syslog, consultez Transfert Syslog.
Azure Stack Hub utilise maintenant des clés RSA 4096 bits pour les certificats internes. La rotation des secrets internes remplace les anciens certificats 2048 bits par des certificats d’une longueur de 4096 bits. Pour plus d’informations sur la rotation des secrets dans Azure Stack Hub, consultez Effectuer une rotation des secrets dans Azure Stack Hub.
Mises à niveau vers la complexité des algorithmes de chiffrement et la robustesse des clés pour plusieurs composants internes afin de se conformer à la stratégie CNSSP-15 (Committee on National Security Systems - Policy 15), qui fournit les bonnes pratiques d’utilisation des normes publiques pour assurer la sécurité du partage des informations. Parmi les améliorations, citons l’AES256 pour l’authentification Kerberos et le SHA384 pour le chiffrement VPN. Pour plus d’informations sur la stratégie CNSSP-15, reportez-vous à la page Policies du Committee on National Security Systems.

En raison de la mise à niveau ci-dessus, Azure Stack Hub utilise de nouvelles valeurs par défaut pour les configurations IPsec/IKEv2. Les nouvelles valeurs par défaut utilisées du côté d’Azure Stack Hub sont les suivantes :

Paramètres IKE Phase 1 (Mode principal)

Propriété	Valeur
Version IKE	IKEv2
Groupe Diffie-Hellman	ECP384
Méthode d'authentification	Clé prépartagée
Chiffrement et algorithmes de hachage	AES256, SHA384
Durée de vie de l’AS (durée)	28 800 secondes

Paramètres IKE Phase 2 (Mode rapide)

Propriété	Valeur
Version IKE	IKEv2
Chiffrement et algorithmes de hachage (Chiffrement)	GCMAES256
Chiffrement et algorithmes de hachage (Authentification)	GCMAES256
Durée de vie de l’AS (durée)	27 000 secondes
Durée de vie de l’AS (kilo-octets)	33 553 408
PFS (Perfect Forward Secrecy)	ECP384
Détection d’homologue mort	Pris en charge

Ces changements sont également reflétés dans la documentation sur la proposition IPsec/IKE par défaut.

Le service Infrastructure Backup améliore la logique qui calcule l’espace disponible souhaité pour les sauvegardes au lieu de s’appuyer sur un seuil fixe. Le service se base sur la taille d’une sauvegarde, une stratégie de conservation, une réserve et l’utilisation actuelle de l’emplacement de stockage externe pour déterminer si un avertissement doit être adressé à l’opérateur.

Modifications

Quand vous téléchargez des éléments de la Place de marché d’Azure vers Azure Stack Hub, une nouvelle interface utilisateur vous permet de spécifier une version de l’élément, au cas où il en existerait plusieurs. La nouvelle interface utilisateur est disponible dans les deux scénarios, connecté et déconnecté. Pour plus d’informations, consultez Télécharger des éléments de la Place de marché d’Azure vers Azure Stack Hub.
Depuis la version 1910, le système Azure Stack Hub nécessite un espace IP interne privé /20 supplémentaire. Pour plus d’informations, consultez Planification de l’intégration réseau pour Azure Stack.
Le service Infrastructure Backup supprime partiellement les données de sauvegarde chargées si l’emplacement de stockage externe manque d’espace disponible pendant la procédure de chargement.
Le service Infrastructure Backup ajoute le service d’identité à la charge utile de sauvegarde pour les déploiements AAD.
Le module PowerShell Azure Stack Hub a été mis à jour vers la version 1.8.0 pour la version 1910.
Les changements sont notamment :
- Nouveau module DRP Admin : Le DRP (fournisseur de ressources de déploiement) permet des déploiements orchestrés de fournisseurs de ressources sur Azure Stack Hub. Ces commandes interagissent avec la couche Azure Resource Manager pour interagir avec le fournisseur DRP.
- BRP :
  - Prise en charge de la restauration de rôle unique pour la sauvegarde d’infrastructure Azure Stack.
  - Ajout du paramètre RoleName à l’applet de commande Restore-AzsBackup.
- FRP : Changements cassants pour les ressources de lecteur et de volume avec la version d’API 2019-05-01. Les fonctionnalités sont prises en charge par Azure Stack Hub 1910 et versions ultérieures :
  – Les valeurs de ID, Name, HealthStatus et OperationalStatus ont été changées.
  – Nouvelles propriétés prises en charge FirmwareVersion, IsIndicationEnabled, Manufactureret StoragePool pour les ressources de lecteur.
  – Les propriétés CanPool et CannotPoolReason des ressources de lecteur sont désormais déconseillées. Utilisez OperationalStatus à la place.

Correctifs

Correction d’un problème qui empêchait d’appliquer la stratégie TLS 1.2 dans les environnements déployés avant la version 1904 d’Azure Stack Hub.
Correction d’un problème où une machine virtuelle Ubuntu 18.04 créée avec une autorisation SSH activée ne vous permettait pas d’utiliser les clés SSH pour vous connecter.
Suppression de la réinitialisation du mot de passe de l’interface utilisateur du groupe de machines virtuelles identiques.
Correction d’un problème où la suppression de l’équilibreur de charge à partir du portail n’aboutissait pas à la suppression de l’objet dans la couche d’infrastructure.
Correction d’un problème qui entraînait l’affichage d’un pourcentage inexact de l’alerte d’utilisation du pool de passerelle sur le portail d’administration.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack Hub, consultez Mises à jour de sécurité Azure Stack Hub.

Le rapport de vulnérabilité Qualys pour cette version peut être téléchargé à partir du site web Qualys.

Correctifs logiciels

Azure Stack Hub publie régulièrement des correctifs logiciels. Veillez à installer le dernier correctif logiciel Azure Stack Hub pour la version 1908 avant de mettre à jour Azure Stack Hub vers la version 1910.

Remarque

Les correctifs logiciels Azure Stack Hub s’appliquent uniquement aux systèmes intégrés Azure Stack Hub. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Conditions préalables : avant d’appliquer la mise à jour 1910

La version 1910 d’Azure Stack Hub doit être appliquée sur la version 1908 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack Hub 1.1908.51.133

Après l’application de la mise à jour 1910

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Correctif logiciel Azure Stack Hub 1.1910.63.186

Notes de publication archivées 1908

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu des packages de mise à jour d’Azure Stack. La mise à jour inclut des améliorations, nouveautés et correctifs pour cette version d’Azure Stack.

Pour accéder aux notes de publication d'une autre version, utilisez le menu déroulant de sélection de la version, situé au-dessus de la table des matières à gauche.

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Important

Si votre instance Azure Stack est en retard de plus de deux mises à jour, elle est considérée comme non conforme. Pour bénéficier de la prise en charge, vous devez mettre à jour avec au moins la version minimale prise en charge.

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Pour obtenir de l'aide sur le dépannage des mises à jour et le processus de mise à jour, voir Résolution des problèmes liés aux correctifs et aux mises à jour pour Azure Stack.

Référence de build 1908

Le numéro de build de la mise à jour 1908 d’Azure Stack est 1.1908.4.33.

Type de mise à jour

Pour la version 1908, le système d’exploitation sous-jacent sur lequel Azure Stack s’exécute a été mis à jour vers Windows Server 2019. Cela apporte des améliorations fondamentales, ainsi que la possibilité d’ajouter des fonctionnalités supplémentaires à Azure Stack dans un avenir proche.

Le type de build de la mise à jour 1908 d’Azure Stack est Complète. Par conséquent, la mise à jour 1908 prend plus de temps que les mises à jour Express telles que 1906 et 1907. Les runtimes exacts des mises à jour complètes dépendent généralement du nombre de nœuds que votre instance Azure Stack contient, de la capacité utilisée sur votre système par les charges de travail clientes, de la connectivité réseau de votre système (s’il est connecté à Internet) et de la configuration de votre matériel système. La mise à jour 1908 a eu les runtimes attendus suivants dans nos tests internes : 4 nœuds - 42 heures, 8 nœuds - 50 heures, 12 nœuds - 60 heures, 16 nœuds - 70 heures. Il n’est pas rare de constater des durées d’exécution des mises à jour plus longues que ces durées prévues, mais cela ne nécessite aucune action de la part des opérateurs Azure Stack, sauf si la mise à jour échoue.

Pour plus d’informations sur les types de build de mise à jour, voir Gérer les mises à jour dans Azure Stack.

La durée d’exécution exacte des mises à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail client, de la connectivité réseau de votre système (s’il est connecté à Internet) et de la configuration de votre matériel système.
Les durées d’exécution plus longues que prévu ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack, sauf si la mise à jour échoue.
Cette approximation d’exécution est propre à la mise à jour 1908 et n’est pas comparable aux autres mises à jour d’Azure Stack.

Nouveautés

Pour la version 1908, le système d’exploitation sous-jacent sur lequel Azure Stack s’exécute a été mis à jour vers Windows Server 2019. Cela apporte des améliorations fondamentales, ainsi que la possibilité d’ajouter des fonctionnalités supplémentaires à Azure Stack dans un avenir proche.
Tous les composants de l’infrastructure Azure Stack fonctionnent désormais en mode FIPS 140-2.
Les opérateurs Azure Stack peuvent désormais supprimer les données utilisateur du portail. Pour plus d’informations, consultez Effacer les données utilisateur du portail dans Azure Stack.

Améliorations

Le chiffrement des données au repos dans Azure Stack a été amélioré afin de rendre les secrets persistants dans le module matériel TPM des nœuds physiques.

Modifications

Les fournisseurs de matériel publieront le package d’extension OEM version 2.1 ou ultérieure en même temps qu’Azure Stack version 1908. Le package d’extension OEM version 2.1 ou ultérieure est requis pour la version 1908 d’Azure Stack. Pour plus d’informations sur le téléchargement du package d’extension OEM version 2.1 ou ultérieure, contactez le fournisseur de matériel pour votre système, et consultez l’article sur les mises à jour OEM.

Correctifs

Résolution d’un problème de compatibilité avec les futures mises à jour OEM d’Azure Stack et d’un problème de déploiement de machine virtuelle à l’aide d’images utilisateur client. Ce problème a été détecté dans la version 1907 et résolu avec le correctif logiciel KB4517473
Résolution d’un problème avec la mise à jour des microprogrammes OEM et correction du diagnostic incorrect dans Test-AzureStack pour Fabric Ring Health. Ce problème a été détecté dans la version 1907 et résolu avec le correctif logiciel KB4515310
Correction d’un problème avec le processus de mise à jour des microprogrammes OEM. Ce problème a été détecté dans la version 1907 et résolu avec le correctif logiciel KB4515650

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack, consultez Mises à jour de sécurité Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1908 d’Azure Stack sur la page de téléchargement d’Azure Stack.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1908 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1907.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Conditions préalables : avant d’appliquer la mise à jour 1908

La version 1908 d’Azure Stack doit être appliquée sur la version 1907 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack 1.1907.17.54

La mise à jour 1908 d’Azure Stack nécessite la version 2.1 ou ultérieure d’OEM pour Azure Stack du fournisseur de matériel de votre système. Les mises à jour OEM appliquent les mises à jour des pilotes et des microprogrammes aux composants matériels de votre système Azure Stack. Pour plus d’informations sur l’application des mises à jour OEM, consultez Appliquer des mises à jour de fabricants d’ordinateurs à Azure Stack

Après l’application de la mise à jour 1908

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Correctif logiciel Azure Stack 1.1908.6.37

Notes de publication archivées 1907

Cet article décrit le contenu des packages de mise à jour d’Azure Stack. La mise à jour inclut des améliorations, nouveautés et correctifs pour cette version d’Azure Stack.

Pour accéder aux notes de publication d'une autre version, utilisez le menu déroulant de sélection de la version, situé au-dessus de la table des matières à gauche.

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Important

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Pour obtenir de l'aide sur le dépannage des mises à jour et le processus de mise à jour, voir Résolution des problèmes liés aux correctifs et aux mises à jour pour Azure Stack.

Référence de build 1907

Le numéro de build de la mise à jour 1907 d’Azure Stack est 1.1907.0.20.

Type de mise à jour

Le type de build de la mise à jour 1907 d’Azure Stack est Express. Pour plus d’informations sur les types de build de mise à jour, consultez l’article Gérer les mises à jour dans Azure Stack. D'après des tests internes, la mise à jour 1907 prend environ 13 heures.

La durée d’exécution exacte des mises à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail client, de la connectivité réseau de votre système (s’il est connecté à Internet) et de la configuration de votre matériel système.
Les durées d’exécution plus longues que prévu ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack, sauf si la mise à jour échoue.
Cette approximation d’exécution est propre à la mise à jour 1907 et n’est pas comparable aux autres mises à jour d’Azure Stack.

Éléments de cette mise à jour

Nouveautés

Mise à la disposition générale du service de collecte des journaux de diagnostic Azure Stack pour faciliter et améliorer la collecte des journaux de diagnostic. Le service de collecte des journaux de diagnostic Azure Stack propose un moyen simplifié de collecter et de partager des journaux de diagnostic avec les services de support technique Microsoft. Ce service de collecte des journaux de diagnostic offre une nouvelle expérience utilisateur dans le portail d’administration Azure Stack, qui permet aux opérateurs de configurer le chargement automatique des journaux de diagnostic sur un objet blob de stockage lorsque certaines alertes critiques sont générées, ou d’effectuer la même opération à la demande. Pour plus d’informations, consultez l'article Collecte des journaux de diagnostic.
Mise à la disposition générale de la validation de l’infrastructure réseau Azure Stack dans le cadre de l'outil de validation Azure Stack Test-AzureStack. L'infrastructure réseau Azure Stack fera partie de Test-AzureStack pour identifier toute défaillance sur l'infrastructure. Le test vérifie la connectivité de l’infrastructure réseau en contournant le réseau à définition logicielle Azure Stack. Il démontre la connectivité d’une adresse IP virtuelle publique aux redirecteurs DNS, serveurs NTP et points de terminaison d'identité configurés. En outre, il vérifie la connectivité à Azure quand Azure AD est utilisé en tant que fournisseur d’identité ou au serveur fédéré quand ADFS est utilisé. Pour plus d’informations, consultez l'article Outil de validation Azure Stack.
Ajout d’une procédure de rotation des secrets internes pour faire tourner les certificats TLS SQL internes en fonction des besoins pendant une mise à jour du système.

Améliorations

Le panneau de mise à jour Azure Stack affiche désormais une heure Dernière étape terminée pour les mises à jour actives. Pour la consulter, accédez au panneau de mise à jour et cliquez sur une mise à jour en cours d’exécution. Dernière étape terminée est ensuite disponible dans la section Détails de l'exécution de la mise à jour.
Améliorations apportées aux actions de l’opérateur Start-AzureStack et Stop-AzureStack. Le temps de démarrage d'Azure Stack a été réduit d'environ 50 %. Le temps d’arrêt d'Azure Stack a été réduit d'environ 30 %. Les temps de démarrage et d’arrêt moyens sont les mêmes lorsque le nombre de nœuds augmente dans une unité d’échelle.
Amélioration de la gestion des erreurs pour l’outil Place de marché déconnecté. Si un téléchargement échoue ou réussit partiellement lors de l'utilisation de Export-AzSOfflineMarketplaceItem, un message s'affiche avec plus de détails sur l'erreur et la procédure d’atténuation, le cas échéant.
Amélioration des performances de création de disques managés à partir d’un objet blob de pages/instantané de grande taille. Auparavant, cela déclenchait un délai d’expiration lors de la création d’un disque de grande taille.

Amélioration de la vérification d'intégrité du disque virtuel avant l’arrêt d’un nœud pour éviter le détachement inattendu du disque.
Amélioration du stockage des journaux internes pour les opérations de l’administrateur. Cela permet d’améliorer les performances et la fiabilité lors des opérations de l’administrateur en limitant la consommation de mémoire et de stockage des processus de journalisation interne. Vous remarquerez peut-être une amélioration des délais de chargement des pages du panneau de mise à jour dans le portail administrateur. Dans le cadre de cette amélioration, les journaux des mises à jour datant de plus de 6 mois ne seront plus disponibles dans le système. Si vous avez besoin de ces journaux, veillez à Télécharger le résumé de toutes les exécutions de mises à jour datant de plus de 6 mois avant d’effectuer la mise à jour 1907.

Modifications

Azure Stack version 1907 contient une alerte d’avertissement qui indique aux opérateurs de bien mettre à jour le package OEM de leur système vers la version 2.1 ou ultérieure avant d’effectuer la mise à jour vers la version 1908. Pour plus d’informations sur l’application de mises à jour OEM dans Azure Stack, consultez Appliquer des mises à jour de fabricants d’ordinateurs à Azure Stack.
Ajout d’une nouvelle règle de trafic sortant (HTTPS) afin d'activer la communication pour le service de collecte des journaux de diagnostic Azure Stack. Pour plus d’informations, consultez Intégration au centre de données Azure Stack - Publier des points de terminaison.
Désormais, le service de sauvegarde d’infrastructure supprime partiellement les sauvegardes téléchargées si la capacité de l’emplacement de stockage externe est insuffisante.
Les sauvegardes d’infrastructure n’incluent plus la sauvegarde des données des services de domaine. Cela s'applique uniquement aux systèmes utilisant Azure Active Directory en tant que fournisseur d'identité.
Nous vérifions désormais que l'ingestion d'une image dans le panneau Calcul -> Images de machine virtuelle est de type objet blob de pages.

Correctifs

Résolution d’un problème lié au fait que le serveur de publication, l'offre et la référence SKU d'un modèle Resource Manager étaient considérés comme sensibles à la casse : l’image n'était pas extraite pour le déploiement, sauf si la casse de ses paramètres était identique à celle du serveur de publication, de l'offre et de la référence SKU.

Résolution d'un problème lié à l'échec des sauvegardes avec un message d'erreur PartialSucceeded, en raison des délais d'expiration lors de la sauvegarde des métadonnées du service de stockage.
Résolution d'un problème lié au fait que la suppression d’abonnements utilisateur aboutissait à des ressources orphelines.
Résolution d’un problème lié au fait que le champ de description n'était pas enregistré lors de la création d’une offre.
Correction d'un problème dans lequel un utilisateur avec des autorisations Lecture seule pouvait créer, modifier et supprimer des ressources. Désormais, l'utilisateur ne peut créer des ressources que lorsque l'autorisation Contributeur lui est attribuée.

Résolution d’un problème lié à l'échec de la mise à jour en raison d'un fichier DLL verrouillé par l’hôte du fournisseur WMI.
Résolution d’un problème lié au service de mise à jour qui empêchait l’affichage des mises à jour disponibles dans la vignette de mise à jour ou le fournisseur de ressources. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4511282.
Résolution d’un problème lié à l'échec des mises à jour en raison de la non-intégrité du plan de gestion suite à une mauvaise configuration. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4512794.
Résolution d’un problème qui empêchait les utilisateurs de mener à bien le déploiement d’images tierces à partir de la Place de marché. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4511259.
Résolution d’un problème lié à l'impossibilité de créer une machine virtuelle à partir d'images managées en raison du blocage du service de gestion des images utilisateur. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4512794.
Résolution d’un problème lié à l'échec des opérations CRUD de machine virtuelle en raison de la non-actualisation comme prévu du cache de la passerelle d'application. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4513119.
Résolution d’un problème lié au fournisseur de ressources d'intégrité qui affectait la disponibilité des panneaux de région et d'alerte dans le portail administrateur. Ce problème a été détecté dans la version 1906 et résolu avec le correctif logiciel KB4512794.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack, consultez Mises à jour de sécurité Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1907 d’Azure Stack sur la page de téléchargement d’Azure Stack.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1907 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1906.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Avant d’appliquer la mise à jour 1907

La version 1907 d’Azure Stack doit être appliquée à la version 1906 avec les correctifs logiciels suivants :

Correctif logiciel Azure Stack 1.1906.15.60

Une fois la mise à jour 1907 correctement appliquée

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Correctif logiciel Azure Stack 1.1907.17.54

Notes de publication archivées 1906

Cet article décrit le contenu des packages de mise à jour d’Azure Stack. La mise à jour inclut des améliorations, nouveautés et correctifs pour cette version d’Azure Stack.

Pour accéder aux notes de publication d'une autre version, utilisez le menu déroulant de sélection de la version, situé au-dessus de la table des matières à gauche.

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Important

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Pour obtenir de l'aide sur le dépannage des mises à jour et le processus de mise à jour, voir Résolution des problèmes liés aux correctifs et aux mises à jour pour Azure Stack.

Référence de build 1906

Le numéro de build de la mise à jour 1906 d’Azure Stack est 1.1906.0.30.

Type de mise à jour

Le type de build de la mise à jour 1906 d’Azure Stack est Express. Pour plus d’informations sur les types de build de mise à jour, consultez l’article Gérer les mises à jour dans Azure Stack. La durée nécessaire pour effectuer la mise à jour 1906 terminer est estimée à environ 10 heures, quel que soit le nombre de nœuds physiques dans votre environnement Azure Stack. La durée d’exécution exacte des mises à jour dépend généralement de la capacité utilisée sur votre système par les charges de travail client, de la connectivité réseau de votre système (s’il est connecté à Internet) et les caractéristiques de votre matériel système. Les durées d’exécution plus longues que les valeurs attendues ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack, sauf si la mise à jour échoue. Cette approximation d’exécution est propre à la mise à jour 1906 et n’est pas comparable aux autres mises à jour d’Azure Stack.

Éléments de cette mise à jour

Ajouter un cmdlet Set-TLSPolicy dans le point de terminaison privilégié (PEP) pour forcer le TLS 1.2 sur tous les points de terminaison. Pour plus d’informations, consultez Contrôles de sécurité Azure Stack.
Ajout d’un cmdlet Get-TLSPolicy dans le point de terminaison privilégié (PEP) pour récupérer la stratégie TLS appliquée. Pour plus d’informations, consultez Contrôles de sécurité Azure Stack.
Ajout d’une procédure de rotation des secrets internes pour faire tourner les certificats TLS internes en fonction des besoins pendant une mise à jour du système.
Ajout d’un dispositif de protection pour empêcher l’expiration des secrets internes en forçant la rotation des secrets internes au cas où une alerte critique sur les secrets arrivant à expiration est ignorée. Ceci ne doit pas être considéré comme une procédure de fonctionnement normale. La rotation des secrets doit être planifiée pour se produire pendant une fenêtre de maintenance. Pour plus d’informations, consultez Rotation des secrets Azure Stack.
Visual Studio Code est désormais pris en charge avec le déploiement Azure Stack avec AD FS.

Améliorations

Le cmdlet Get-GraphApplication dans le point de terminaison privilégié affiche désormais l’empreinte du certificat actuellement utilisé. Ceci améliore la gestion des certificats pour les principaux de service quand Azure Stack est déployé avec AD FS.
De nouvelles règles de surveillance d’intégrité ont été ajoutées pour valider la disponibilité d’AD Graph et AD FS, y compris la possibilité de déclencher les alertes.
Améliorations de la fiabilité du fournisseur de ressources de sauvegarde lorsque le service de sauvegarde d’infrastructure est déplacé vers une autre instance.
Optimisation des performances de la procédure de rotation des secrets externes pour fournir une durée d’exécution uniforme afin de faciliter la planification de la fenêtre de maintenance.
Le cmdlet Test-AzureStack signale désormais les secrets internes qui sont sur le point d’expirer (alertes critiques).
Un nouveau paramètre est disponible pour le cmdlet Register-CustomAdfs dans le point de terminaison privilégié qui permet d’ignorer la vérification de la liste de révocation des certificats lors de la configuration de l’approbation de fédération pour AD FS.
La version 1906 bénéficie d’une meilleure visibilité sur la progression en cours de mise à jour : vous êtes donc certain que les mises à jour ne sont pas suspendues. Cela entraîne une augmentation du nombre total d’étapes de mise à jour présentées aux opérateurs dans le panneau Mise à jour. Vous pourrez également remarquer plus d’étapes de mise à jour en parallèle que dans les mises à jour précédentes.

Mises à jour en réseau

Mise à jour de la durée de bail définie dans le répondeur DHCP pour être cohérent avec Azure.
Amélioration des taux de nouvelles tentatives auprès du fournisseur de ressources en cas d’échec du déploiement de ressources.
Suppression de l’option de référence SKU Standard de l’équilibreur de charge et de l’adresse IP publique, car ce n’est actuellement pas pris en charge.

Modifications

La création des comptes de stockage est désormais cohérente avec celle d’Azure.
Modification des déclencheurs d’alertes à l’expiration des secrets internes :
- Les alertes d’avertissement sont maintenant déclenchées 90 jours avant l’expiration des secrets.
- Les alertes critiques sont maintenant déclenchées 30 jours avant l’expiration des secrets.
Mise à jour des chaînes dans le fournisseur de ressources de sauvegarde d’infrastructure pour rendre la terminologie plus cohérente.

Correctifs

Correction d’un problème où le redimensionnement d’une machine virtuelle avec disque managé a échoué avec une erreur interne de l’opération.
Correction d’un problème où la création d’une image utilisateur ayant échoué provoque un état incorrect du service, ce qui bloque la création de nouvelles images et la suppression de l’image a échoué. Ceci est également corrigé dans le correctif logiciel 1905.
Les alertes actives sur les secrets internes arrivant à expiration sont désormais automatiquement fermées après l’exécution réussie de la rotation interne des secrets.
Correction d’un problème dans lequel la durée de mise à jour dans l’onglet de l’historique des mises à jour coupait le premier chiffre si la mise à jour était exécutée pendant plus de 99 heures.
Le panneau Mise à jour comprend une option de reprise pour les mises à jour ayant échoué.
Dans les portails d’administrateur et d’utilisateur, résolution du problème de la place de marché dans lequel l’extension Docker a été correctement retournée par recherche, mais aucune action supplémentaire n’a pu être prise en compte, car elle n’est pas disponible dans Azure Stack.
Résolution d’un problème dans l’interface utilisateur de déploiement du modèle qui ne remplit pas les paramètres si le nom du modèle commence par un trait de soulignement « _ ».
Résolution d’un problème qui survient quand vous créez un groupe identique de machines virtuelles et que l’option CentOS 7.2 est proposée pour le déploiement. CentOS 7.2 n’est pas disponible dans Azure Stack. Nous proposons maintenant CentOS 7.5 comme option de déploiement
Vous pouvez désormais supprimer un groupe identique à partir du panneau Groupes de machines virtuelles identiques.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack, consultez Mises à jour de sécurité Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1906 d’Azure Stack sur la page de téléchargement d’Azure Stack.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1906 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1905. Après la mise à jour, installez tous les correctifs logiciels disponibles pour 1906.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Avant d’appliquer la mise à jour 1906

La version 1906 d’Azure Stack doit être appliquée à la version 1905 avec les correctifs logiciels suivants :

Azure Stack hotfix 1.1905.3.48

Une fois la mise à jour 1906 correctement appliquée

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Correctif logiciel Azure Stack 1.1906.15.60

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1905

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu du package de mise à jour 1905. La mise à jour inclut des améliorations, nouveautés et correctifs pour cette version d’Azure Stack. Cet article contient les informations suivantes :

Description des nouveautés, améliorations, correctifs et mises à jour de sécurité
Planification des mises à jour

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1905 d’Azure Stack est 1.1905.0.40.

Type de mise à jour

Le type de build de la mise à jour 1905 d’Azure Stack est Complet. Par conséquent, la mise à jour 1905 a un runtime plus long que les mises à jour rapides, telles que 1903 et 1904. Les runtimes exacts des mises à jour complètes dépendent généralement du nombre de nœuds que votre instance Azure Stack contient, de la capacité utilisée sur votre système par les charges de travail clientes, de la connectivité réseau de votre système (s’il est connecté à Internet) et de la configuration de votre matériel système. La mise à jour 1905 a eu les runtimes attendus suivants dans nos tests internes : 4 nœuds - 35 heures, 8 nœuds - 45 heures, 12 nœuds - 55 heures, 16 nœuds - 70 heures. Les runtimes de la mise à jour 1905 plus longs que ces valeurs attendues ne sont pas rares et ne nécessitent aucune action de la part des opérateurs Azure Stack, sauf si la mise à jour échoue. Pour plus d’informations sur les types de build de mise à jour, voir Gérer les mises à jour dans Azure Stack.

Éléments de cette mise à jour

Avec cette mise à jour, le moteur de mise à jour dans Azure Stack peut mettre à jour le microprogramme des nœuds d’unité d’échelle. Cela nécessite un package de mise à jour compatible des partenaires fournisseurs de matériel. Contactez votre fournisseur de matériel pour en savoir plus sur la disponibilité.
Windows Server 2019 est désormais pris en charge et disponible pour la syndication par le biais de la Place de marché Azure Stack. Avec cette mise à jour, Windows Server 2019 peut être activé correctement sur un hôte 2016.
Avec la nouvelle extension Azure Account Visual Studio Code, les développeurs peuvent cibler Azure Stack en se connectant et accédant aux abonnements, ainsi que divers autres services. L’extension Azure fonctionne aussi bien sur les environnements Azure Active Directory (Azure AD) et AD FS, et ne nécessite qu’une petite modification des paramètres utilisateur de Visual Studio Code. Visual Studio Code exige que le principal de service reçoive une autorisation à s’exécuter sur cet environnement. Pour ce faire, importez le script d’identité et exécutez les cmdlets spécifiées dans Architecture mutualisée dans Azure Stack. Ceci nécessite une mise à jour du répertoire de base et l’inscription du répertoire du locataire invité pour chaque annuaire. Une alerte s’affiche après la mise à jour vers la version 1905 ou une version ultérieure, pour mettre à jour le locataire du répertoire de base pour lequel le principal de service Visual Studio Code est inclus.

Améliorations

Dans le cadre de l’application de TLS 1.2 sur Azure Stack, les extensions suivantes ont été mises à jour avec ces versions :
- microsoft.customscriptextension-arm-1.9.3
- microsoft.iaasdiagnostics-1.12.2.2
- microsoft.antimalware-windows-arm-1.5.5.9
- microsoft.dsc-arm-2.77.0.0
- microsoft.vmaccessforlinux-1.5.2
Téléchargez ces nouvelles versions d’extensions immédiatement afin d’éviter l’échec des nouveaux déploiements de l’extension quand TLS 1.2 sera appliqué dans une version ultérieure. Définissez toujours autoUpgradeMinorVersion=true pour que les mises à jour de version mineure des extensions (par exemple, version 1.8 à 1.9) soient effectuées automatiquement.
La nouvelle fonctionnalité Aide et support - Vue d’ensemble du portail Azure Stack permet aux opérateurs de se renseigner sur leurs options de support, de bénéficier d’une aide spécialisée et d’en savoir plus sur Azure Stack plus facilement. Sur les systèmes intégrés, la création d’une demande de support présélectionne le service Azure Stack. Nous recommandons fortement aux clients d’utiliser ce moyen pour envoyer des tickets de support, plutôt que d’utiliser le portail Azure général. Pour plus d’informations, consultez Aide et support de Microsoft Azure Stack.
Quand plusieurs annuaires Azure Active Directory sont intégrés (par le biais de ce processus), il est possible de ne pas réexécuter le script lors de certaines mises à jour, ou lorsque des droits sont insuffisants en raison des modifications apportées à l’autorisation du principal de Service Azure AD. Ceci peut entraîner divers problèmes, d’un blocage de l’accès à certaines fonctionnalités à des erreurs plus discrètes qui sont difficiles à tracer jusqu’au problème d’origine. Pour éviter ce problème, la version 1905 introduit une nouvelle fonctionnalité qui vérifie les autorisations et déclenche une alerte en présence de certains problèmes de configuration. Cette validation s’exécute toutes les heures et affiche les actions de correction requises pour corriger le problème. L’alerte est fermée quand tous les locataires présentent un état sain.
Plus grande fiabilité des opérations de sauvegarde de l’infrastructure pendant le basculement du service.
Une nouvelle version du plug-in Nagios pour Azure Stack est disponible. Elle utilise les Bibliothèques d’authentification Azure Active Directory (ADAL) pour l’authentification. Désormais, le plug-in prend également en charge les déploiements Azure AD et Active Directory Federation Services (AD FS) d’Azure Stack. Pour plus d’informations, consultez le site Nagios Exchange pour les plug-ins.
Un nouveau profil hybride 2019-03-01-Hybrid a été publié. Il prend en charge toutes les dernières fonctionnalités disponibles dans Azure Stack. Azure PowerShell et Azure CLI prennent tous les deux en charge le profil 2019-03-01-Hybrid. Les SDK .NET, Ruby, Node.js, Go et Python ont publié des packages qui prennent en charge le profil 2019-03-01-Hybrid. La documentation respective et certains exemples ont été mis à jour pour refléter les modifications.
Le SDK Node.js prend désormais en charge les profils d’API. Les packages qui prennent en charge le profil 2019-03-01-Hybrid sont publiés.

La mise à jour Azure Stack 1905 ajoute deux nouveaux rôles d’infrastructure pour améliorer la fiabilité et la capacité de prise en charge de la plateforme :

Anneau d’infrastructure : à l’avenir, l’anneau d’infrastructure hébergera des versions conteneurisées des rôles d’infrastructure existants , par exemple xrp, qui nécessitent actuellement leurs propres machines virtuelles d’infrastructure désignées. Cela va améliorer la fiabilité de la plateforme et réduire le nombre de machines virtuelles d’infrastructure nécessaires à Azure Stack. Cela réduira ensuite la future consommation globale des ressources des rôles d’infrastructure Azure Stack.
Anneau de support : à l’avenir, l’anneau de support sera utilisé pour gérer des scénarios de support améliorés pour les clients.

En outre, nous avons ajouté une instance supplémentaire de la machine virtuelle du contrôleur de domaine pour améliorer la disponibilité de ce rôle.

Ces modifications vont augmenter la consommation des ressources de l’infrastructure Azure Stack de la manière suivante :

Référence SKU Azure Stack	Augmentation de la consommation des capacités de calcul	Augmentation de la consommation de mémoire
4 nœuds	22 processeurs virtuels	28 Go
8 nœuds	38 processeurs virtuels	44 Go
12 nœuds	54 processeurs virtuels	60 Go
16 nœuds	70 processeurs virtuels	76 Go

Modifications

Pour améliorer la fiabilité et la disponibilité durant les scénarios de maintenance planifiée et non planifiée, Azure Stack fournit une instance de rôle d’infrastructure supplémentaire pour les services de domaine.
Avec cette mise à jour, pendant les opérations de réparation et d’ajout de nœuds, le matériel est validé pour garantir l’homogénéité des nœuds d’unité d’échelle au sein d’une unité d’échelle.
Si des sauvegardes planifiées échouent et que la période de rétention définie est dépassée, le contrôleur de sauvegarde de l’infrastructure s’assure qu’au moins une sauvegarde réussie est conservée.

Correctifs

Correction d’un problème qui provoquait l’affichage d’un avertissement d’agent hôte de calcul après le redémarrage d’un nœud dans l’unité d’échelle.
Correction des problèmes dans la gestion de la Place de marché dans le portail administrateur qui provoquaient l’affichage de résultats incorrects après l’application de filtres et l’affichage de noms d’éditeurs en double dans la liste filtrée des éditeurs. Les performances ont également été améliorées pour afficher les résultats plus rapidement.
Correction d’un problème dans le panneau des sauvegardes disponibles qui montrait une nouvelle sauvegarde comme disponible avant qu’elle ait été chargée à l’emplacement de stockage externe. La sauvegarde disponible est désormais listée seulement après son chargement à l’emplacement de stockage.

Correction d’un problème avec l’obtention des clés de récupération pendant une opération de sauvegarde.

Correction d’un problème avec la mise à jour OEM qui affichait la version comme étant « non définie » dans le portail de l’opérateur.

Mises à jour de sécurité

Pour plus d’informations sur les mises à jour de sécurité dans cette mise à jour d’Azure Stack, consultez Mises à jour de sécurité Azure Stack.

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1905 d’Azure Stack à partir de la page de téléchargement d’Azure Stack. Lorsque vous utilisez l’outil de téléchargement, veillez à utiliser la version la plus récente et pas une copie mise en cache à partir de votre répertoire de téléchargements.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1905 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1904.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Avant d’appliquer la mise à jour 1905

La version 1905 d’Azure Stack doit être appliquée à la version 1904 avec les correctifs suivants :

Correctif Azure Stack 1.1904.4.45

Une fois la mise à jour 1905 correctement appliquée

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Azure Stack hotfix 1.1905.3.48

Notifications de mise à jour automatique

Les clients utilisant des systèmes qui peuvent accéder à Internet à partir du réseau d’infrastructure voient le message Mise à jour disponible dans le portail opérateur. Les systèmes sans accès à Internet peuvent télécharger et importer le fichier .zip avec le fichier .xml correspondant.

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1904

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1904. La mise à jour inclut des améliorations, nouveautés et correctifs pour cette version d’Azure Stack. Cet article contient les informations suivantes :

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1904 d’Azure Stack est 1.1904.0.36.

Type de mise à jour

Le type de build de la mise à jour 1904 d’Azure Stack est Express. Pour plus d’informations sur les types de build de mise à jour, consultez l’article Gérer les mises à jour dans Azure Stack. La mise à jour 1904 prend environ 16 heures, mais la durée exacte peut varier. Cette approximation d’exécution est propre à la mise à jour 1904 et n’est pas comparable aux autres mises à jour d’Azure Stack.

Éléments de cette mise à jour

Améliorations

Des améliorations significatives ont été apportées à la pile Mise en réseau à définition logicielle (SDN, Software Defined Networking) dans la version 1904. Ces améliorations augmentent la maintenance globale et la fiabilité de la pile SDN dans Azure Stack.
Ajout d’une notification dans le portail administrateur, lorsque l’utilisateur actuellement connecté n’a pas les autorisations nécessaires, qui permet de charger correctement le tableau de bord. Elle contient également un lien vers la documentation qui explique les comptes qui ont des autorisations appropriées, selon le fournisseur d’identité utilisé pendant le déploiement.
Ajout d’améliorations de la résilience et du temps d’activité des machines virtuelles, ce qui résout le scénario dans lequel toutes les machines virtuelles sont mises hors connexion si le volume de stockage contenant les fichiers de configuration des machines virtuelles est mis hors connexion.

Ajout de l’optimisation du nombre de machines virtuelles évacuées simultanément et ajout d’un plafond sur la bande passante consommée, pour répondre aux baisses de tension ou pannes des machines virtuelles si le réseau est surchargé. Cette modification améliore la durée de fonctionnement des machines virtuelles lors de la mise à jour du système.

Amélioration de la limitation de ressources lorsqu’un système est en cours d’exécution à grande échelle pour offrir une protection contre les processus internes qui épuisent les ressources de la plateforme, ce qui entraîne des échecs d’opérations dans le portail.
Amélioration des fonctionnalités de filtrage permettant aux opérateurs d’appliquer plusieurs filtres en même temps. Vous pouvez effectuer un tri seulement sur la colonne Nom dans la nouvelle interface utilisateur.
Améliorations apportées au processus de suppression d’offres, de plans, de quotas et d’abonnements. Vous pouvez maintenant correctement supprimer des offres, des quotas, des plans et des abonnements à partir du portail administrateur si l’objet que vous souhaitez supprimer n’a aucune dépendance. Pour plus d’informations, consultez cet article.

Amélioration du volume de messages Syslog en filtrant les événements inutiles et en fournissant un paramètre de configuration pour sélectionner le niveau de gravité souhaité pour les messages transférés. Pour plus d’informations sur la façon de configurer le niveau de gravité, consultez Intégration au centre de données Azure Stack - transfert syslog.

Ajout d’une nouvelle fonctionnalité à l’applet de commande Get-AzureStackLog en incorporant le paramètre supplémentaire -OutputSASUri. Vous pouvez maintenant collecter des journaux Azure Stack à partir de votre environnement et les stocker dans le conteneur d’objets blob Stockage Azure spécifié. Pour plus d’informations, consultez Diagnostics Azure Stack.
Ajout d’un nouveau contrôle de mémoire dans le groupe Test-AzureStackUpdateReadiness, qui vérifie si vous avez suffisamment de mémoire disponible sur la pile pour que la mise à jour se termine correctement.

Améliorations apportées à la commande Test-AzureStack pour l’évaluation de l’intégrité de Service Fabric.

Améliorations apportées aux mises à jour du matériel, ce qui réduit le temps nécessaire pour effectuer la mise à jour du microprogramme des lecteurs à 2 à 4 heures. Le moteur de mise à jour détermine dynamiquement les portions de la mise à jour qui doivent s’exécuter, en fonction de contenu du package.

Ajout de vérifications préalables de la fiabilité des opérations pour empêcher les opérations d’instance de rôle d’infrastructure perturbatrices qui affectent la disponibilité.

Améliorations de l’idempotence du plan d’action de sauvegarde de l’infrastructure.

Améliorations apportées à la collecte des journaux Azure Stack. Ces améliorations réduisent le temps nécessaire pour récupérer l’ensemble des journaux. De plus, l’applet de commande Get-AzureStackLog ne génère plus de journaux par défaut pour le rôle OEM. Vous devez exécuter l’applet de commande Invoke-AzureStackOnDemandLog, en spécifiant le rôle pour récupérer les journaux OEM. Pour plus d’informations, consultez Diagnostics Azure Stack.
Azure Stack surveille à présent l’URL de données de fédération fournie pour l’intégration de centre de données avec ADFS. Cela améliore la fiabilité au cours de la rotation des secrets de l’instance ADFS cliente ou de la batterie de serveurs.

Modifications

Suppression de l’option qui permet aux opérateurs Azure Stack d’arrêter les instances de rôle d’infrastructure dans le portail d’administration. La fonctionnalité de redémarrage garantit une tentative d’arrêt propre avant le redémarrage de l’instance de rôle d’infrastructure. Pour les scénarios avancés, la fonctionnalité d’API et PowerShell reste disponible.

Il existe une nouvelle expérience de gestion de la Place de marché, avec des écrans distincts pour les images de la Place de marché et les fournisseurs de ressources. Pour l’instant, la fenêtre Fournisseurs de ressources est vide, mais dans les futures versions, de nouvelles offres de services PaaS s’afficheront et seront gérées dans la fenêtre Fournisseurs de ressources.

Modifications de l’expérience de mise à jour dans le portail des opérateurs. Il existe une nouvelle grille pour les mises à jour pour les fournisseur de ressources. La possibilité de mettre à jour des fournisseurs de ressources n’est pas encore disponible.

Modifications de l’expérience d’installation des mises à jour dans le portail des opérateurs. Pour aider les opérateurs Azure Stack à réagir de façon appropriée à un problème de mise à jour, le portail fournit à présent des recommandations plus spécifiques basées sur l’intégrité de l’unité d’échelle, dérivées automatiquement en exécutant Test-AzureStack et en analysant les résultats. En fonction du résultat, il demande à l’opérateur d’effectuer l’une des deux actions suivantes :
- Une alerte d’avertissement « soft » s’affiche dans le portail. Elle indique « La mise à jour la plus récente nécessite votre attention. Microsoft recommande l’ouverture d’une demande de service pendant les heures ouvrées normales. Dans le cadre du processus de mise à jour, la commande Test-AzureStack est exécutée et en fonction de la sortie, nous générons l’alerte la plus appropriée. Dans ce cas, « Test-AzureStack a réussi ».
- Une alerte critique « hard » s’affiche dans le portail qui indique « Échec de la mise à jour la plus récente. Microsoft recommande l’ouverture d’une demande de service dès que possible. Dans le cadre du processus de mise à jour, la commande Test-AzureStack est exécutée et en fonction de la sortie, nous générons l’alerte la plus appropriée. Dans ce cas, Test-AzureStack a également échoué ».
Mise à jour de l’agent Azure Linux version 2.2.38.0. Cette prise en charge permet aux clients de maintenir la cohérence des images Linux entre Azure et Azure Stack.
Modifications des journaux d’activité de mise à jour dans le portail des opérateurs. Les demandes de récupération de journaux d’activité des mises à jour réussies ne sont plus disponibles. Les journaux d’activité des mises à jour ayant échoué sont toujours téléchargeables, car ils sont exploitables à des fins de diagnostics.

Correctifs

Correction du problème suivant : la configuration syslog n’était pas conservée lors d’un cycle de mise à jour et, par conséquent, le client perdait sa configuration et les messages syslog n’étaient plus transférés. La configuration Syslog est à présent conservée.
Correction du problème suivant : CRP bloquait la libération de machines virtuelles. Précédemment, si une machine virtuelle contenait plusieurs disques managés volumineux, la libération de la machine virtuelle pouvait échouer avec une erreur de délai d’attente.
Correction du problème suivant : le moteur Windows Defender avait un impact sur l’accès au stockage d’unité d’échelle.
Correction du problème suivant : dans le portail utilisateur, la fenêtre Stratégie d’accès pour les comptes de stockage blob ne se chargeait pas.
Correction du problème suivant : dans les portails administrateur et utilisateur, des notifications erronées au sujet du portail Azure mondial s’affichaient.
Correction du problème suivant : dans le portail utilisateur, la sélection de la vignette Commentaires ouvrait un onglet de navigateur vide.
Correction du problème suivant : dans le portail, la modification d’une adresse IP statique pour une configuration IP qui était liée à une carte réseau attachée à une instance de machine virtuelle entraînant l’affichage d’un message d’erreur.
Correction du problème suivant : dans le portail utilisateur, une tentative de connexion d’une interface réseau à une machine virtuelle existante via la fenêtre Mise en réseau échouait avec un message d’erreur.
Correction du problème suivant : Azure Stack ne permettait pas d’attacher plus de 4 interfaces réseau à une instance de machine virtuelle.
Correction du problème suivant : dans le portail, l’ajout d’une règle de sécurité de trafic entrant et la sélection d’une balise de service en tant que source avait pour conséquence l’affichage de plusieurs options qui n’étaient pas disponibles pour Azure Stack.
Correction du problème suivant : les groupes de sécurité réseau (NSG) ne fonctionnaient pas de la même manière dans Azure Stack que dans le reste d’Azure.
Correction du problème suivant dans la gestion de la Place de marché : tous les produits téléchargés étaient masqués si l’inscription expirait ou était supprimée.
Correction du problème suivant : l’émission d’une commande Set-AzureRmVirtualNetworkGatewayConnection dans PowerShell en direction d’une connexion de passerelle de réseau virtuel existante échouait avec le message d’erreur La clé partagée configurée n’est pas valide....
Correction du problème suivant : le fournisseur de ressources réseau (NRP) n’était pas synchronisé avec le contrôleur de réseau, ce qui entraînait des ressources en double demandées. Dans certains cas, cela avait pour conséquence qu’une ressource parente était dans un état d’erreur.
Correction du problème suivant : quand un utilisateur avait reçu le rôle de contributeur à un abonnement, mais n’avait pas reçu explicitement des autorisations de lecture, l’erreur ... Le client « somelogonaccount@domain.com » avec l’ID d’objet {GUID} n’est pas autorisé à effectuer l’action... était générée lors de la tentative d’enregistrement d’une modification de ressource.
Correction du problème suivant : l’écran de gestion de la Place de marché était vide si l’outil de syndication hors connexion était utilisé pour charger des images et qu’aucune d’elles n’avait un URI d’icône.
Correction d’un problème qui empêchait de supprimer de la gestion de la Place de marché les produits dont le téléchargement avait échoué.

Mises à jour de sécurité

Cette mise à jour d’Azure Stack n’inclut pas les mises à jour de sécurité pour le système d’exploitation sous-jacent qui héberge Azure Stack.

Planification des mises à jour

Avant d’appliquer la mise à jour, veillez à consulter les informations suivantes :

Remarque

Veillez à utiliser la dernière version de l’outil Azure Stack Capacity Planner pour planifier et dimensionner votre charge de travail. La dernière version contient des corrections de bogues et fournit de nouvelles fonctionnalités publiées à chaque mise à jour d’Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1904 d’Azure Stack à partir de la page de téléchargement d’Azure Stack.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1904 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1903.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Avant d’appliquer la mise à jour 1904

La version 1904 d’Azure Stack doit être appliquée à la version 1903 avec les correctifs suivants :

Correctif Azure Stack 1.1903.2.39

Une fois la mise à jour 1904 correctement appliquée

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez notre stratégie de maintenance.

Correctif Azure Stack 1.1904.4.45

Notifications de mise à jour automatique

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1903

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1903. La mise à jour inclut des améliorations, des corrections de bogues et de nouvelles fonctionnalités pour cette version d’Azure Stack. Cet article décrit également les problèmes connus dans cette version, et contient un lien permettant de télécharger la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et problèmes propres à la build (après installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1903 d’Azure Stack est 1.1903.0.35.

Type de mise à jour

Le type de build de la mise à jour 1903 d’Azure Stack est Express. Pour plus d’informations sur les types de build de mise à jour, consultez l’article Gérer les mises à jour dans Azure Stack. La mise à jour 1903 devrait prendre environ 16 heures, mais la durée exacte peut varier. Cette approximation d’exécution est spécifique à la mise à jour 1903 et ne doit pas être comparée à d’autres mises à jour Azure Stack.

Important

La charge utile 1903 n’inclut aucune version ASDK.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1903 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1902.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Correctifs logiciels d’Azure Stack

1902 : Kb 4500637 - Correctif logiciel Azure Stack 1.1902.3.75
1903 : Kb 4500638 - Correctif logiciel Azure Stack 1.1903.2.39

Améliorations

Correction d’un bogue sur le réseau qui empêchait l’application des modifications apportées à la valeur Délai d’inactivité (minutes) d’une adresse IP publique. Auparavant, les modifications apportées à cette valeur étaient ignorées, de sorte que, quelles que soient ces modifications, la valeur par défaut était de 4 minutes. Ce paramètre contrôle la durée (en minutes) de maintien d’une connexion TCP ouverte sans utiliser les clients pour envoyer des messages keep-alive. Notez que ce bogue n’affectait que les adresses IP publiques au niveau de l’instance, et non les adresses IP publiques attribuées à un équilibreur de charge.
Améliorations apportées à la fiabilité du moteur de mise à jour, notamment la mise à jour automatique des problèmes courants afin d’appliquer les mises à jour sans interruption.
Améliorations apportées à la détection et à la correction des conditions d’espace disque faible.
Azure Stack prend à présent en charge les agents Windows Azure Linux dont la version est supérieure à 2.2.35. Cette prise en charge permet aux clients de maintenir la cohérence des images Linux entre Azure et Azure Stack. Elle a été ajoutée dans le cadre des correctifs 1901 et 1902.

Gestion des secrets

Azure Stack prend désormais en charge la rotation du certificat racine utilisé par des certificats pour la rotation des secrets externe. Pour plus d’informations, consultez cet article.
Les performances de la build 1903 ont été améliorées pour la rotation des secrets afin de réduire le temps nécessaire à l’exécution de cette rotation.

Prérequis

Important

Avant d’installer la mise à jour 1903, installez le dernier correctif logiciel d’Azure Stack pour la build 1902.

Veillez à utiliser la dernière version de l’outil Azure Stack Capacity Planner pour planifier et dimensionner votre charge de travail. La dernière version contient des corrections de bogues et fournit de nouvelles fonctionnalités publiées à chaque mise à jour d’Azure Stack.
Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec le paramètre suivant pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une action :
```
Test-AzureStack -Group UpdateReadiness
```
Lorsqu’Azure Stack est géré par System Center Operations Manager, veillez à mettre à jour le Pack d’administration pour Microsoft Azure Stack vers la version 1.0.3.11 avant d’appliquer la version 1903.
Le format de package pour la mise à jour d’Azure Stack est passé de .bin/.exe/.xml à .zip/.xml depuis la version 1902. Les clients avec des unités d’échelle Azure Stack connectées verront le message Mise à jour disponible dans le portail. Les clients qui ne sont pas connectés peuvent désormais simplement télécharger et importer le fichier .zip qui contient le fichier .xml correspondant.

Problèmes connus avec le processus de mise à jour

Lorsque vous tentez d’installer une mise à jour Azure Stack, l’état de la mise à jour peut échouer et définir l’état sur PreparationFailed. Cela est dû au fait que le fournisseur de ressources de mise à jour est dans l’impossibilité de transférer correctement les fichiers du conteneur de stockage vers un partage d’infrastructure interne à des fins de traitement. À compter de la version 1901 (1.1901.0.95), vous pouvez contourner ce problème en cliquant sur Mettre à jour maintenant à nouveau (et pas sur Reprendre). Le fournisseur de ressources de mise à jour nettoie les fichiers de la tentative précédente, puis redémarre le téléchargement.
Quand vous exécutez la commande Test-AzureStack, un message d’avertissement du contrôleur de gestion de la carte de base (BMC) s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.

Pendant l’installation de cette mise à jour, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles disparaîtront automatiquement une fois l’installation de cette mise à jour terminée.

Étapes après la mise à jour

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, voir Correctifs logiciels ainsi que notre Stratégie de maintenance.
Récupérez les clés de chiffrement de données au repos et stockez-les en toute sécurité hors de votre déploiement Azure Stack. Suivez les instructions sur la façon de récupérer les clés.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

Dans le tableau de bord du portail utilisateur, lorsque vous essayez de cliquer sur la vignette Commentaires, un onglet de navigateur vide s’ouvre. Pour résoudre ce problème, vous pouvez utiliser Azure Stack User Voice pour déposer une demande User Voice.

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Dans le portail de l’utilisateur, lorsque vous accédez à un objet blob au sein d’un compte de stockage et essayez d’ouvrir la rubrique Stratégie d'accès dans l’arborescence de navigation, la fenêtre suivante ne s’ouvre pas. Pour contourner ce problème, les applets de commande PowerShell suivantes permettent de créer, récupérer, définir et supprimer des stratégies d’accès, respectivement :

Dans le portail de l’utilisateur, lorsque vous essayez de charger un objet blob à l’aide de l’option OAuth (préversion), la tâche échoue avec un message d’erreur. Pour contourner ce problème, chargez l’objet blob à l’aide de l’option SAS.
Lorsque vous êtes connecté aux portails Azure Stack, il se peut que vous voyiez des notifications concernant le portail Azure global. Vous pouvez ignorer ces notifications en toute sécurité, car elles ne s’appliquent pas actuellement à Azure Stack (par exemple, « 1 nouvelle mise à jour – Les mises à jour suivantes sont désormais disponibles : Portail Azure mise à jour d’avril 2019 »).
Dans le tableau de bord du portail utilisateur, lorsque vous sélectionnez la vignette Commentaires, un onglet de navigateur vide s’ouvre. Pour résoudre ce problème, vous pouvez utiliser Azure Stack User Voice pour déposer une demande User Voice.

Compute

Lors de la création d'une machine virtuelle Windows, l’erreur suivante peut s’afficher :

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Cette erreur se produit si vous activez les diagnostics de démarrage sur une machine virtuelle alors que vous avez supprimé votre compte de stockage des diagnostics de démarrage. Pour contourner ce problème, recréez le compte de stockage avec le même nom que celui utilisé précédemment.

Quand vous créez un groupe de machines virtuelles identiques, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur la Place de marché Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement, ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

Après avoir appliqué la mise à jour 1903, vous rencontrerez peut-être les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
- Si l’abonnement a été créé avant la mise à jour 1808, le déploiement d’une machine virtuelle avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Sélectionnez Fournisseurs de ressources, Microsoft.Compute, puis Réinscrire.
  2. Sous le même abonnement, accédez à Contrôle d’accès (IAM) et vérifiez que l’élément Azure Stack – Managed Disks est répertorié.
- Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre le problème, effectuez les étapes décrites dans cet article afin de reconfigurer chacun de vos annuaires invités.
Une machine virtuelle 18.04 Ubuntu créée avec une autorisation SSH activée ne vous permet pas d’utiliser les clés SSH pour vous connecter. Pour contourner ce problème, utilisez un accès à la machine virtuelle pour l’extension Linux afin d’implémenter des clés SSH après l’approvisionnement, ou utilisez une authentification par mot de passe.

Si vous n’avez pas d’hôte de cycle de vie du matériel (HLH) : avant la build 1902, vous deviez définir la stratégie de groupe Configuration de l’ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies Locales\Options de sécurité sur Envoyer LM et NTLM – utiliser la sécurité de session NTLMv2 si négociée. Depuis la build 1902, vous devez la laisser en tant que Non définie ou la définir sur Envoyer une réponse NTLMv2 uniquement (qui est la valeur par défaut). Sinon, vous ne pourrez pas établir de session PowerShell à distance et vous verrez un message d’erreur L’accès est refusé :

$Session = New-PSSession -ComputerName x.x.x.x -ConfigurationName PrivilegedEndpoint -Credential $Cred
New-PSSession : [x.x.x.x] Connecting to remote server x.x.x.x failed with the following error message : Access is denied. For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $Session = New-PSSession -ComputerName x.x.x.x -ConfigurationNa ...
+            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

Vous ne pouvez pas supprimer un groupe identique à partir du panneau Virtual Machine Scale Sets. Pour résoudre ce problème, sélectionnez le groupe identique que vous souhaitez supprimer, puis cliquez sur le bouton Supprimer dans le volet Vue d’ensemble.
La création de machines virtuelles dans un groupe à haute disponibilité de 3 domaines d’erreur et la création d’une instance de groupe identique de machines virtuelles échouent avec une erreur FabricVmPlacementErrorUnsupportedFaultDomainSize pendant le processus de mise à jour sur un environnement Azure Stack à 4 nœuds. Vous pouvez réussir à créer des machines virtuelles uniques dans un groupe à haute disponibilité comprenant 2 domaines d’erreur. En revanche, la création d’instances de groupe identique n’est toujours pas disponible pendant le processus de mise à jour sur un environnement Azure Stack à 4 nœuds.

Mise en réseau

Dans le portail Azure Stack, lorsque vous modifiez une adresse IP statique pour une configuration IP liée à une carte réseau connectée à une instance de machine virtuelle, le message d’avertissement suivant s’affiche :

The virtual machine associated with this network interface will be restarted to utilize the new private IP address...

Vous pouvez ignorer ce message. L’adresse IP changera même si l’instance de machine virtuelle ne redémarre pas.

Dans le portail, si vous ajoutez une règle de sécurité de trafic entrant et sélectionnez Balise du service en tant que source, plusieurs options s’affichent dans la liste Balise source, qui ne sont pas disponibles pour Azure Stack. Les seules options valides dans Azure Stack sont les suivantes :
- Internet
- VirtualNetwork
- AzureLoadBalancer
Les autres options ne sont pas pris en charge en tant que balises sources dans Azure Stack. De même, si vous ajoutez une règle de sécurité de trafic sortant et sélectionnez Balise du service en tant que destination, la même liste d’options s’affiche pour Balise source. Les seules options valides sont les mêmes que pour Balise source, comme décrit dans la liste précédente.
Les Groupes de sécurité réseau (NSG) ne fonctionnent pas de la même manière dans Azure Stack que dans le reste d'Azure. Dans Azure, vous pouvez définir plusieurs ports sur une règle NSG (en utilisant les modèles du portail, de PowerShell et de Resource Manager). Dans Azure Stack, cependant, vous ne pouvez définir qu’un seul port sur une règle NSG via la portail. Pour contourner ce problème, utilisez un modèle Resource Manager ou PowerShell qui vous permettra de définir ces autres règles.

Azure Stack ne permet pas d’attacher plus de quatre interfaces réseau à une instance de machine virtuelle, quelle que soit la taille de cette instance.

App Service

Les locataires doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.
Certaines expériences utilisateur du portail de locataire sont interrompues en raison d’une incompatibilité avec le framework du portail dans la version 1903, principalement l’expérience utilisateur pour les emplacements de déploiement, les tests en production et les extensions de site. Pour contourner ce problème, utilisez le module PowerShell Azure App Service ou Azure CLI. L’expérience du portail sera restaurée dans la prochaine version d’Azure App Service sur Azure Stack 1.6 (mise à jour 6).

Syslog

La configuration syslog n’est pas conservée lors d’un cycle de mise à jour et, par conséquent, le client perd sa configuration et les messages syslog ne sont plus transférés. Ce problème s’applique à toutes les versions d’Azure Stack depuis la disponibilité générale du client syslog (1809). Pour contourner ce problème, reconfigurez le client syslog après avoir appliqué une mise à jour Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1903 d’Azure Stack à partir de cet emplacement.

Dans les scénarios connectés, et uniquement dans ceux-ci, les déploiements Azure Stack consultent régulièrement un point de terminaison sécurisé et vous avertissent automatiquement si une mise à jour est disponible pour votre cloud. Pour plus d’informations, voir la documentation sur la gestion des mises à jour pour Azure Stack.

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1902

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1902. La mise à jour inclut des améliorations, des corrections de bogues et de nouvelles fonctionnalités pour cette version d’Azure Stack. Cet article décrit également les problèmes connus dans cette version, et contient un lien permettant de télécharger la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et problèmes propres à la build (après installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1902 d’Azure Stack est 1.1902.0.69.

Type de mise à jour

Le type de build de la mise à jour 1902 d’Azure Stack est Complet. Pour plus d’informations sur les types de build de mise à jour, consultez l’article Gérer les mises à jour dans Azure Stack.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1902 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1901.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Correctifs logiciels d’Azure Stack

1901 : Kb 4500636 - Correctif logiciel Azure Stack 1.1901.5.109
1902 : Kb 4500637 - Correctif logiciel Azure Stack 1.1902.3.75

Prérequis

Important

Vous pouvez installer la mise à jour 1902 directement à partir de la version 1.1901.0.95 ou 1.1901.0.99, sans installer au préalable un correctif logiciel 1901. Mais si vous avez installé l’ancien correctif logiciel 1901.2.103, vous devez installer le nouveau correctif logiciel 1901.3.105 avant de passer à la mise à jour 1902.

Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une action :
```
Test-AzureStack -Include AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Si le paramètre AzsControlPlane est inclus lors de l’exécution de Test-AzureStack, l’erreur suivante apparaît dans la sortie Test-AzureStack : FAIL Azure Stack Control Plane Websites Summary. Vous pouvez ignorer sans problème cette erreur spécifique.
Quand Azure Stack est géré par System Center Operations Manager, veillez à mettre à jour le Pack d’administration pour Microsoft Azure Stack vers la version 1.0.3.11 avant d’appliquer la mise à jour 1902.
Le format de package pour la mise à jour d’Azure Stack est passé de .bin/.exe/.xml à .zip/.xml depuis la version 1902. Les clients avec des unités d’échelle Azure Stack connectées verront le message Mise à jour disponible dans le portail. Les clients qui ne sont pas connectés peuvent désormais simplement télécharger et importer le fichier .zip qui contient le fichier .xml correspondant.

Améliorations

La build 1902 introduit une nouvelle interface utilisateur sur le portail Administrateur Azure Stack pour la création de plans, d’offres, de quotas et de plans complémentaires. Pour plus d’informations, y compris des captures d’écran, consultez Créer des plans, des offres et des quotas.

Améliorations de la fiabilité de l’extension de capacité pendant une opération d’ajout de nœuds lors du passage de l’état de l’unité d’échelle de « Développement du stockage » à « Exécution ».

Pour améliorer l’intégrité et la sécurité du package et faciliter la gestion pour l’ingestion de données hors connexion, Microsoft a modifié le format du package de mise à jour en transformant les fichiers .exe et .bin en un fichier .zip. Le nouveau augmente encore la fiabilité du processus de décompression qui, dans certains cas, peut bloquer la préparation de la mise à jour. Le même format de package s’applique également aux packages de mise à jour de votre OEM.
Pour améliorer l’expérience des opérateurs Azure Stack lors de l’exécution de la commande Test-AzureStack, les opérateurs peuvent maintenant simplement utiliser « Test-AzureStack -Group UpdateReadiness » au lieu de passer dix paramètres supplémentaires après une instruction Include.
```
  Test-AzureStack -Group UpdateReadiness  
```
Afin d’améliorer la fiabilité et la disponibilité globales des principaux services d’infrastructure pendant le processus de mise à jour, le fournisseur de ressources de mise à jour natif, en tant que partie prenante du plan d’action de mise à jour, détecte et appelle des corrections globales automatiques si nécessaire. Le flux de travail de correction globale « Réparer » inclut les opérations suivantes :
- Rechercher les machines virtuelles de l’infrastructure dont l’état n’est pas optimal et tenter de les réparer si nécessaire.
- Rechercher les problèmes de service SQL dans le cadre du plan de contrôle et tenter d’y remédier si nécessaire.
- Vérifier l’état du service d’équilibrage de charge logicielle (SLB) dans le contrôleur de réseau (NC) et tenter de le réparer si nécessaire.
- Vérifier l’état du service de contrôleur de réseau (NC) et tenter de le réparer si nécessaire
- Vérifier l’état des nœuds de la structure du service de console de récupération d’urgence (ERCS) et les réparer si nécessaire.
- Vérifier l’état du rôle d’infrastructure et le réparer si nécessaire.
- Vérifier l’état des nœuds de la structure du service de stockage cohérent Azure (ACS) et les réparer si nécessaire.

Améliorations apportées aux outils de diagnostic d’Azure Stack pour renforcer la fiabilité et les performances de la collection de journaux. Une journalisation supplémentaire pour les services de mise en réseau et d’identité.

Améliorations de la fiabilité de Test-AzureStack pour le test de préparation à la rotation des secrets.

Améliorations visant à accroître la fiabilité d’AD Graph lors de la communication avec l’environnement Active Directory du client

Améliorations de la collection d’inventaire matériel dans Get-AzureStackStampInformation.
Pour améliorer la fiabilité des opérations en cours d’exécution sur l’infrastructure ERCS, la mémoire pour chaque instance ERCS passe de 8 Go à 12 Go. Sur une installation de systèmes intégrés Azure Stack, cela entraîne une augmentation globale de 12 Go.

La version 1902 résout un problème rencontré dans le service Network Controllers VSwitch, où toutes les machines virtuelles d’un nœud spécifique basculaient hors connexion. À cause de ce problème, le service était bloqué dans un état de perte du composant principal, où le composant principal ne pouvait pas être contacté, mais où le rôle n’avait pas été basculé vers une autre instance saine et où la seule solution était de contacter les services de support Microsoft.

Important

Pour vous assurer que le processus de correctif et de mise à jour entraîne le moins de temps d’arrêt possible du client, vérifiez que votre tampon Azure Stack a plus de 12 Go d’espace disponible dans le panneau Capacité. Vous pouvez voir cette augmentation de mémoire reflétée dans le panneau Capacité panneau après une installation réussie de la mise à jour.

Vulnérabilités et menaces courantes

Cette mise à jour installe les mises à jour de sécurité suivantes :

Pour plus d’informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez l’article 4487006 de la Base de connaissances Microsoft.

Problèmes connus avec le processus de mise à jour

Lorsque vous tentez d’installer une mise à jour Azure Stack, l’état de la mise à jour peut échouer et définir l’état sur PreparationFailed. Cela est dû au fait que le fournisseur de ressources de mise à jour est dans l’impossibilité de transférer correctement les fichiers du conteneur de stockage vers un partage d’infrastructure interne à des fins de traitement. À compter de la version 1901 (1.1901.0.95), vous pouvez contourner ce problème en cliquant sur Mettre à jour maintenant à nouveau (et pas sur Reprendre). Le fournisseur de ressources de mise à jour nettoie les fichiers de la tentative précédente, puis redémarre le téléchargement.
Quand vous exécutez la commande Test-AzureStack, un message d’avertissement du contrôleur de gestion de la carte de base (BMC) s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.
Pendant l’installation de cette mise à jour, des alertes avec le titre « Erreur - Le modèle de FaultType UserAccounts.New est manquant » peuvent s’afficher. Vous pouvez les ignorer. Elles disparaîtront automatiquement une fois l’installation de cette mise à jour terminée.

Étapes après la mise à jour

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, voir Correctifs logiciels ainsi que notre Stratégie de maintenance.
Récupérez les clés de chiffrement de données au repos et stockez-les en toute sécurité hors de votre déploiement Azure Stack. Suivez les instructions sur la façon de récupérer les clés.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Dans le portail de l’utilisateur, lorsque vous accédez à un objet blob au sein d’un compte de stockage et essayez d’ouvrir la rubrique Stratégie d'accès dans l’arborescence de navigation, la fenêtre suivante ne s’ouvre pas. Pour contourner ce problème, les applets de commande PowerShell suivantes permettent de créer, récupérer, définir et supprimer des stratégies d’accès, respectivement :

Compute

Lors de la création d'une machine virtuelle Windows, l’erreur suivante peut s’afficher :

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Cette erreur se produit si vous activez les diagnostics de démarrage sur une machine virtuelle alors que vous avez supprimé votre compte de stockage des diagnostics de démarrage. Pour contourner ce problème, recréez le compte de stockage avec le même nom que celui utilisé précédemment.

Quand vous créez un groupe identique de machines virtuelles, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement, ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

Après avoir appliqué la mise à jour 1902, vous rencontrerez peut-être les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
- Si l’abonnement a été créé avant la mise à jour 1808, le déploiement d’une machine virtuelle avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Sélectionnez Fournisseurs de ressources, Microsoft.Compute, puis Réinscrire.
  2. Sous le même abonnement, accédez à Contrôle d’accès (IAM) et vérifiez que l’élément Azure Stack – Managed Disks est répertorié.
- Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre le problème, effectuez les étapes décrites dans cet article afin de reconfigurer chacun de vos annuaires invités.
Une machine virtuelle 18.04 Ubuntu créée avec une autorisation SSH activée ne vous permet pas d’utiliser les clés SSH pour vous connecter. Pour contourner ce problème, utilisez un accès à la machine virtuelle pour l’extension Linux afin d’implémenter des clés SSH après l’approvisionnement, ou utilisez une authentification par mot de passe.
Vous ne pouvez pas supprimer un groupe identique à partir du panneau Virtual Machine Scale Sets. Pour résoudre ce problème, sélectionnez le groupe identique que vous souhaitez supprimer, puis cliquez sur le bouton Supprimer dans le volet Vue d’ensemble.
La création de machines virtuelles dans un groupe à haute disponibilité de 3 domaines d’erreur et la création d’une instance de groupe identique de machines virtuelles échouent avec une erreur FabricVmPlacementErrorUnsupportedFaultDomainSize pendant le processus de mise à jour sur un environnement Azure Stack à 4 nœuds. Vous pouvez réussir à créer des machines virtuelles uniques dans un groupe à haute disponibilité comprenant 2 domaines d’erreur. En revanche, la création d’instances de groupe identique n’est toujours pas disponible pendant le processus de mise à jour sur un environnement Azure Stack à 4 nœuds.

Mise en réseau

Dans le portail Azure Stack, lorsque vous modifiez une adresse IP statique pour une configuration IP liée à une carte réseau connectée à une instance de machine virtuelle, le message d’avertissement suivant s’affiche :

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Vous pouvez ignorer ce message. L’adresse IP changera même si l’instance de machine virtuelle ne redémarre pas.

Dans le portail, si vous ajoutez une règle de sécurité de trafic entrant et sélectionnez Balise du service en tant que source, plusieurs options s’affichent dans la liste Balise source, qui ne sont pas disponibles pour Azure Stack. Les seules options valides dans Azure Stack sont les suivantes :
- Internet
- VirtualNetwork
- AzureLoadBalancer
Les autres options ne sont pas pris en charge en tant que balises sources dans Azure Stack. De même, si vous ajoutez une règle de sécurité de trafic sortant et sélectionnez Balise du service en tant que destination, la même liste d’options s’affiche pour Balise source. Les seules options valides sont les mêmes que pour Balise source, comme décrit dans la liste précédente.
Les Groupes de sécurité réseau (NSG) ne fonctionnent pas de la même manière dans Azure Stack que dans le reste d'Azure. Dans Azure, vous pouvez définir plusieurs ports sur une règle NSG (en utilisant les modèles du portail, de PowerShell et de Resource Manager). Dans Azure Stack, cependant, vous ne pouvez définir qu’un seul port sur une règle NSG via la portail. Pour contourner ce problème, utilisez un modèle Resource Manager ou PowerShell qui vous permettra de définir ces autres règles.

Azure Stack ne permet pas d’attacher plus de quatre interfaces réseau à une instance de machine virtuelle, quelle que soit la taille de cette instance.
Dans le portail utilisateur, si vous essayez d’ajouter un pool back-end à un équilibreur de charge, l’opération échoue avec le message d’erreur Échec de la mise à jour de l’équilibreur de charge... Pour contourner ce problème, utilisez PowerShell, CLI ou un modèle Azure Resource Manager afin d’associer le pool back-end à une ressource d’équilibreur de charge.
Dans le portail utilisateur, si vous essayez de créer une règle NAT de trafic entrant pour un équilibreur de charge, l’opération échoue avec le message d’erreur Échec de la mise à jour de l’équilibreur de charge... Pour contourner ce problème, utilisez PowerShell, CLI ou un modèle Azure Resource Manager afin d’associer le pool back-end à une ressource d’équilibreur de charge.
Dans le portail utilisateur, la fenêtre Créer un équilibreur de charge affiche une option pour créer une référence SKU d’équilibreur de charge Standard. Cette option n’est pas prise en charge dans Azure Stack.

App Service

Avant de créer votre première fonction Azure dans l’abonnement, vous devez inscrire le fournisseur de ressources de stockage.

Syslog

La configuration syslog n’est pas conservée lors d’un cycle de mise à jour et, par conséquent, le client perd sa configuration et les messages syslog ne sont plus transférés. Ce problème s’applique à toutes les versions d’Azure Stack depuis la disponibilité générale du client syslog (1809). Pour contourner ce problème, reconfigurez le client syslog après avoir appliqué une mise à jour Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1902 d’Azure Stack à partir de cet emplacement.

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1901

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1901. La mise à jour inclut des améliorations, des corrections de bogues et de nouvelles fonctionnalités pour cette version d’Azure Stack. Cet article décrit également les problèmes connus dans cette version, et contient un lien permettant de télécharger la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et problèmes propres à la build (après installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

La numéro de build de mise à jour d’Azure Stack 1901 est 1.1901.0.95 ou 1.1901.0.99 après le 26 février 2019. Voir la remarque suivante :

Important

Microsoft a détecté un problème qui peut impacter la mise à jour des clients de 1811 (1.1811.0.101) à 1901 et a publié un package 1901 mis à jour pour résoudre ce problème : build 1.1901.0.99, mis à jour à partir de 1.1901.0.95. Les clients qui ont déjà mis à jour vers 1.1901.0.95 n’ont rien à faire.

Les clients connectés qui utilisent 1811 verront automatiquement le nouveau package 1901 (1.1901.0.99) disponible dans le portail d’administration et doivent l’installer lorsqu’ils sont prêts. Les clients déconnectés peuvent télécharger et importer le nouveau package 1901 en utilisant le même processus que celui décrit ici.

Les clients avec des versions de 1901 ne seront pas impactés par l’installation du package intégral ou du correctif logiciel suivant.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1901 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1811.

Les correctifs logiciels Azure Stack sont uniquement applicables aux systèmes intégrés Azure Stack. N’essayez pas d’installer des correctifs logiciels sur l’ASDK.

Correctifs logiciels d’Azure Stack

Si vous utilisez déjà la mise à jour 1901 et n’avez pas encore installé les correctifs logiciels, vous pouvez installer directement la mise à jour 1902, sans installer au préalable le correctif logiciel 1901.

1811 : Aucun correctif logiciel actuel n’est disponible.
1901 : Kb 4500636 - Correctif logiciel Azure Stack 1.1901.5.109

Prérequis

Important

Avant d’installer la mise à jour 1901, installez le dernier correctif logiciel d’Azure Stack pour la build 1811. Si vous utilisez déjà la mise à jour 1901 et n’avez pas encore installé les correctifs logiciels, vous pouvez installer directement la mise à jour 1902, sans installer au préalable le correctif logiciel 1901.

Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une action :
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Quand Azure Stack est géré par System Center Operations Manager, veillez à mettre à jour le Pack d’administration pour Microsoft Azure Stack vers la version 1.0.3.11 avant d’appliquer la mise à jour 1901.

Nouvelles fonctionnalités

Cette mise à jour inclut les nouvelles fonctionnalités et améliorations suivantes pour Azure Stack :

Dans Azure Stack, les images managées vous permettent de créer un objet d’image managée sur une machine virtuelle généralisée (à la fois managée et non managée) qui ne pourra ensuite créer que des machines virtuelles à disque managé. Pour plus d’informations, consultez Disques managés d’Azure Stack.
AzureRm 2.4.0
- AzureRm.Profile
  Résolution de bogue - Import-AzureRmContext pour désérialiser correctement le jeton enregistré.
- AzureRm.Resources
  Résolution de bogue - Get-AzureRmResource pour exécuter des requêtes sans tenir compte de la casse, par type de ressource.
- Azure.Storage
  Le module de correctif cumulatif AzureRm inclut désormais la version 4.5.0 déjà publiée qui prend en charge api-version 2017-07-29.
- AzureRm.Storage
  Le module de correctif cumulatif AzureRm inclut désormais la version 5.0.4 déjà publiée qui prend en charge api-version 2017-10-01.
- AzureRm.Compute
  Ajout d’un jeu de paramètres simples dans New-AzureRmVM et New-AzureRmVmss, -Image pour prendre en charge la spécification des images utilisateur.
- AzureRm.Insights
  Le module de correctif cumulatif AzureRm inclut désormais la version 5.1.5 déjà publiée qui prend en charge api-version 2018-01-01 pour les métriques, les définitions de métriques et les types de ressources.
AzureStack 1.7.1 Il s’agit d’une modification critique. Pour plus d’informations sur les modifications critiques, reportez-vous à https://aka.ms/azspshmigration171.
- Module Azs.Backup.Admin
  Modification critique : modifications concernant les sauvegardes dans le mode de chiffrement basé sur le certificat. La prise en charge des clés symétriques est dépréciée.
- Module Azs.Fabric.Admin
  Get-AzsInfrastructureVolume a été déprécié. Utilisez la nouvelle applet de commande Get-AzsVolume.
  Get-AzsStorageSystem a été déprécié. Utilisez la nouvelle applet de commande Get-AzsStorageSubSystem.
  Get-AzsStoragePool a été déprécié. L’objet StorageSubSystem contient la propriété de capacité.
- Module Azs.Compute.Admin
  Correctif de bogue - Add-AzsPlatformImage, : Get-AzsPlatformImageappel ConvertTo-PlatformImageObject uniquement dans le chemin de réussite.
  BugFix - Add-AzsVmExtension, Get-AzsVmExtension: appel de ConvertTo-VmExtensionObject uniquement dans le chemin de réussite.
- Module Azs.Storage.Admin
  Résolution de bogue - Le nouveau quota de stockage utilise les valeurs par défaut si aucune n’est spécifiée.

Pour consulter la référence des modules mis à jour, lisez Référence du module Azure Stack.

Problèmes résolus

Correction d’un problème avec lequel le portail affichait une option permettant de créer des passerelles VPN basées sur les stratégies, alors qu’elles ne sont pas prises en charge dans Azure Stack. Cette option a été supprimée du portail.

Correction d’un problème où, après avoir modifié les paramètres DNS de votre réseau virtuel en remplaçant l’option Utiliser le DNS Azure Stack par l’option DNS personnalisé, les instances n’étaient pas mises à jour avec le nouveau paramètre.
Correction d’un problème où, pour déployer des machines virtuelles dont les tailles contenaient le suffixe v2 (par exemple, Standard_A2_v2), vous deviez spécifier le suffixe avec un « v » minuscule (Standard_A2_v2). Comme dans l’ensemble des produits Azure, vous pouvez désormais utiliser la forme Standard_A2_V2 (avec un « V » majuscule).

Correction d’un problème qui affichait un avertissement quand vous utilisiez le portail pour créer des machines virtuelles de taille Premium (DS, Ds_v2, FS, FSv2). Celles-ci étaient créées dans un compte de stockage standard. Même si cela n’avait pas d’impact sur sa fonctionnalité, sur les IOPS ou sur la facturation, l’avertissement a été supprimé.

Correction d’un problème lié au composant Contrôleur d’intégrité qui générait les alertes suivantes. Ces alertes pouvaient être ignorées sans que cela pose un problème :
- Alerte 1 :
  - NOM : Rôle d’infrastructure défectueux
  - GRAVITÉ : Avertissement
  - COMPOSANT : Contrôleur d’intégrité
  - DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
- Alerte 2 :
  - NOM : Rôle d’infrastructure défectueux
  - GRAVITÉ : Avertissement
  - COMPOSANT : Contrôleur d’intégrité
  - DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.

Correction d’un problème où, lorsque vous définissiez la valeur des quotas de disques managés sur 0 sous Types de quotas de calcul, la valeur par défaut de 2 048 Gio était utilisée. La valeur de zéro est désormais respectée.

Correction d’un problème où, lorsque vous utilisiez les applets de commande PowerShell StartAzsScaleUnitNode ou StopAzsScaleUnitNode pour gérer les unités d’échelle, la première tentative de démarrage ou d’arrêt de l’unité d’échelle échouait.

Correction d’un problème où, lorsque vous inscriviez le fournisseur de ressources Microsoft.Insight dans les paramètres d’abonnement, puis créiez une machine virtuelle Windows en ayant activé les diagnostics du système d’exploitation invité, le graphique Pourcentage UC dans la page de vue d’ensemble de la machine virtuelle n’affichait pas les données de métriques. Les données sont désormais affichées.
Correction d’un problème où l’exécution de l’applet de commande Get-AzureStackLog échouait après l’exécution de Test-AzureStack dans la même session de point de terminaison privilégié. Vous pouvez désormais utiliser la session de point de terminaison privilégié dans laquelle vous avez exécuté Test-AzureStack.

Correction d’un problème lié aux sauvegardes automatiques, où le service du planificateur passait à l’état désactivé de façon inattendue.

Suppression du bouton Réinitialiser la passerelle du portail Azure Stack, qui générait une erreur lorsque l’on cliquait dessus. Ce bouton n’a pas d’utilité, puisqu’Azure Stack comprend une passerelle multilocataire et non des instances de machines virtuelles dédiées pour chaque passerelle VPN de locataire. Il a donc été supprimé pour éviter toute confusion.

Suppression du lien Règle de sécurité en vigueur dans le panneau Propriétés de réseau, car cette fonctionnalité n’est pas prise en charge dans Azure Stack. La présence de lien donnait l’impression que cette fonctionnalité était prise en charge, mais qu’elle ne fonctionnait pas. Pour éviter toute confusion, nous avons supprimé ce lien.

Correction d’un problème où, lorsqu’une mise à jour était appliquée à Azure Stack par un fabricant OEM, la notification Mise à jour disponible ne s’affichait pas dans le portail d’administration Azure Stack.

Modifications

Les améliorations en matière de sécurité introduites dans cette mise à jour entraînent une augmentation de la taille de sauvegarde du rôle service d’annuaire. Pour obtenir des conseils actualisés concernant le dimensionnement de l’emplacement de stockage externe, consultez la documentation sur la sauvegarde d’infrastructure (/azure-stack-backup-reference.md#storage-location-sizing). Cette modification a pour effet d’allonger la durée de la sauvegarde en raison de l’accroissement du volume des données transférées. Cette modification a une incidence sur les systèmes intégrés.
À compter de janvier 2019, vous pourrez déployer des clusters Kubernetes sur les tampons connectés à Azure Stack et inscrits auprès d’Active Directory Federated Services (AD FS) (l’accès à Internet est nécessaire). Pour télécharger le nouvel élément Place de marché de Kubernetes, suivez ces instructions. Pour déployer un cluster Kubernetes, suivez ces instructions. Notez les nouveaux paramètres indiquant si le système cible est inscrit auprès d’ADD ou d’AD FS. S’il est inscrit auprès d’AD FS, de nouveaux champs sont disponibles pour entrer les paramètres du coffre de clés où est stocké le certificat de déploiement.

Notez que même avec la prise en charge AD FS, le déploiement des clusters Kubernetes nécessite un accès à Internet.
Après l’installation de mises à jour ou de correctifs logiciels sur Azure Stack, de nouvelles fonctionnalités peuvent être ajoutées et nécessiter que de nouvelles autorisations soient accordées à une ou plusieurs applications d’identité. Pour accorder ces autorisations, vous avez besoin d’un accès administrateur au répertoire de base. Elles ne peuvent donc pas être accordées automatiquement. Par exemple :
```
$adminResourceManagerEndpoint = "https://adminmanagement.<region>.<domain>"
$homeDirectoryTenantName = "<homeDirectoryTenant>.onmicrosoft.com" # This is the primary tenant Azure Stack is registered to

Update-AzsHomeDirectoryTenant -AdminResourceManagerEndpoint $adminResourceManagerEndpoint `
   -DirectoryTenantName $homeDirectoryTenantName -Verbose
```
Un nouvel élément doit être pris en compte afin de planifier correctement la capacité Azure Stack. Avec la mise à jour 1901, le nombre total de machines virtuelles pouvant être créées est limité. Cette limite est destinée à être temporaire et a pour but de garantir la stabilité de la solution. Nous recherchons actuellement la cause du problème de stabilité en présence d’un plus grand nombre de machines virtuelles, mais aucun échéancier n’a encore été déterminé pour y remédier. Avec la mise à jour 1901, il y a désormais une limite de 60 machines virtuelles par serveur, la limite totale pour la solution étant de 700. Par exemple, la limite pour 8 serveurs Azure Stack serait 480 machines virtuelles (8 * 60). Pour une solution Azure Stack de 12 à 16 serveurs, la limite serait 700. Cette limite a été définie en gardant à l’esprit toutes les considérations relatives à la capacité de calcul, telles que la réserve de résilience et le rapport virtuel/physique de l’UC qu’un opérateur souhaite conserver. Pour plus d’informations, consultez la nouvelle version de l’outil de planification de la capacité.
Si la limite de mise à l’échelle de la machine virtuelle a été atteinte, les codes d’erreur suivants sont retournés en conséquence : VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceededed.
La version de l’API Compute est passée à 2017-12-01.
La sauvegarde de l’infrastructure nécessite désormais un certificat avec une clé publique uniquement (. CER) pour le chiffrement des données de sauvegarde. La prise en charge des clés de chiffrement symétrique est dépréciée à compter de la mise à jour 1901. Si la sauvegarde de l’infrastructure est configurée avant l’application de la mise à jour 1901, les clés de chiffrement resteront en place. Vous disposerez d’au moins deux mises à jour supplémentaires avec prise en charge de la compatibilité descendante pour mettre à jour les paramètres de sauvegarde. Pour plus d’informations, consultez Meilleures pratiques concernant le service de sauvegarde de l’infrastructure.

Vulnérabilités et menaces courantes

Cette mise à jour installe les mises à jour de sécurité suivantes :

Pour plus d’informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez l’article 4480977 de la Base de connaissances Microsoft.

Problèmes connus avec le processus de mise à jour

Lorsque vous tentez d’installer une mise à jour Azure Stack, l’état de la mise à jour peut échouer et définir l’état sur PreparationFailed. Cela est dû au fait que le fournisseur de ressources de mise à jour est dans l’impossibilité de transférer correctement les fichiers du conteneur de stockage vers un partage d’infrastructure interne à des fins de traitement. À compter de la version 1901 (1.1901.0.95), vous pouvez contourner ce problème en cliquant sur Mettre à jour maintenant à nouveau (et pas sur Reprendre). Le fournisseur de ressources de mise à jour nettoie les fichiers de la tentative précédente, puis redémarre le téléchargement.
Lors de l’exécution de la commande Test-AzureStack, si le test AzsInfraRoleSummary ou AzsPortalApiSummary échoue, vous êtes invité à exécuter la commande Test-AzureStack avec l’indicateur -Repair. Si vous exécutez cette commande, elle échoue et le message d’erreur suivant s’affiche : Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null.
Quand vous exécutez la commande Test-AzureStack, un message d’avertissement du contrôleur de gestion de la carte de base (BMC) s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.
Pendant l’installation de cette mise à jour, des alertes avec le titre « Erreur - Le modèle de FaultType UserAccounts.New est manquant » peuvent s’afficher. Vous pouvez les ignorer. Elles disparaîtront automatiquement une fois l’installation de cette mise à jour terminée.

Étapes après la mise à jour

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, voir Correctifs logiciels ainsi que notre Stratégie de maintenance.
Récupérez les clés de chiffrement de données au repos et stockez-les en toute sécurité hors de votre déploiement Azure Stack. Suivez les instructions sur la façon de récupérer les clés.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Compute

Lors de la création d'une machine virtuelle Windows, l’erreur suivante peut s’afficher :

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Cette erreur se produit si vous activez les diagnostics de démarrage sur une machine virtuelle alors que vous avez supprimé votre compte de stockage des diagnostics de démarrage. Pour contourner ce problème, recréez le compte de stockage avec le même nom que celui utilisé précédemment.

Quand vous créez un groupe de machines virtuelles identiques, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement, ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

Après avoir appliqué la mise à jour 1901, vous rencontrerez peut-être les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
- Si l’abonnement a été créé avant la mise à jour 1808, le déploiement d’une machine virtuelle avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Sélectionnez Fournisseurs de ressources, Microsoft.Compute, puis Réinscrire.
  2. Sous le même abonnement, accédez à Access Control (IAM) et vérifiez qu’AzureStack-DiskRP-Client est répertorié.
- Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre le problème, effectuez les étapes décrites dans cet article afin de reconfigurer chacun de vos annuaires invités.
Une machine virtuelle 18.04 Ubuntu créée avec une autorisation SSH activée ne vous permet pas d’utiliser les clés SSH pour vous connecter. Pour contourner ce problème, utilisez un accès à la machine virtuelle pour l’extension Linux afin d’implémenter des clés SSH après l’approvisionnement, ou utilisez une authentification par mot de passe.
Vous ne pouvez pas supprimer un groupe identique à partir du panneau Virtual Machine Scale Sets. Pour résoudre ce problème, sélectionnez le groupe identique que vous souhaitez supprimer, puis cliquez sur le bouton Supprimer dans le volet Vue d’ensemble.

Mise en réseau

Dans le portail Azure Stack, lorsque vous modifiez une adresse IP statique pour une configuration IP liée à une carte réseau connectée à une instance de machine virtuelle, le message d’avertissement suivant s’affiche :

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Vous pouvez ignorer ce message. L’adresse IP changera même si l’instance de machine virtuelle ne redémarre pas.

Dans le portail, si vous ajoutez une règle de sécurité de trafic entrant et sélectionnez Balise du service en tant que source, plusieurs options s’affichent dans la liste Balise source, qui ne sont pas disponibles pour Azure Stack. Les seules options valides dans Azure Stack sont les suivantes :
- Internet
- VirtualNetwork
- AzureLoadBalancer
  
  Les autres options ne sont pas pris en charge en tant que balises sources dans Azure Stack. De même, si vous ajoutez une règle de sécurité de trafic sortant et sélectionnez Balise du service en tant que destination, la même liste d’options s’affiche pour Balise source. Les seules options valides sont les mêmes que pour Balise source, comme décrit dans la liste précédente.
Les Groupes de sécurité réseau (NSG) ne fonctionnent pas de la même manière dans Azure Stack que dans le reste d'Azure. Dans Azure, vous pouvez définir plusieurs ports sur une règle NSG (en utilisant les modèles du portail, de PowerShell et de Resource Manager). Dans Azure Stack, cependant, vous ne pouvez définir qu’un seul port sur une règle NSG via la portail. Pour contourner ce problème, utilisez un modèle Resource Manager ou PowerShell qui vous permettra de définir ces autres règles.

Azure Stack ne permet pas d’attacher plus de quatre interfaces réseau à une instance de machine virtuelle, quelle que soit la taille de cette instance.

App Service

Avant de créer votre première fonction Azure dans l’abonnement, vous devez inscrire le fournisseur de ressources de stockage.

Syslog

La configuration syslog n’est pas conservée lors d’un cycle de mise à jour et, par conséquent, le client perd sa configuration et les messages syslog ne sont plus transférés. Ce problème s’applique à toutes les versions d’Azure Stack depuis la disponibilité générale du client syslog (1809). Pour contourner ce problème, reconfigurez le client syslog après avoir appliqué une mise à jour Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1901 d’Azure Stack à partir de cet emplacement.

Étapes suivantes

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.
Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Notes de publication archivées 1811

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1811. La mise à jour inclut des améliorations, des corrections de bogues et de nouvelles fonctionnalités pour cette version d’Azure Stack. Cet article décrit également les problèmes connus dans cette version, et contient un lien permettant de télécharger la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et problèmes propres à la build (après installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1811 d’Azure Stack est 1.1811.0.101.

Correctifs logiciels

Azure Stack publie des correctifs logiciels à intervalles réguliers. Avant d’installer la mise à jour 1811 d’Azure Stack, veillez à installer le dernier correctif logiciel d’Azure Stack pour la build 1809.

Correctifs logiciels d’Azure Stack

1809 : Kb 4481548 – Correctif logiciel Azure Stack 1.1809.12.114
1811 : Aucun correctif logiciel actuel n’est disponible.

Prérequis

Important

Pendant l’installation de la mise à jour 1811, vous devez vérifier que toutes les instances du portail administrateur sont fermées. Le portail utilisateur peut rester ouvert, mais le portail administrateur doit être fermé.

Préparez votre déploiement d’Azure Stack pour l’hôte d’extension d’Azure Stack. Préparez votre système en suivant les instructions suivantes : Préparez l’hôte d’extension pour Azure Stack.
Avant d’installer la mise à jour 1811, installez le dernier correctif logiciel d’Azure Stack pour la build 1809.
Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une intervention.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary, AzsHostingServiceCertificates
```
Si la configuration requise pour l’hôte d’extension n’est pas satisfaite, la sortie de la commande Test-AzureStack affiche le message suivant :

To proceed with installation of the 1811 update, you will need to import the SSL certificates required for Extension Host, which simplifies network integration and increases the security posture of Azure Stack. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare
Pour pouvoir installer la mise à jour 1811 d’Azure Stack, vous devez avoir au préalable correctement importé les certificats d’hôte d’extension obligatoires dans votre environnement Azure Stack. Pour installer la mise à jour 1811, vous devez importer les certificats SSL requis pour l’hôte d’extension. Pour savoir comment importer les certificats, voir cette section.

Si vous persistez à ignorer tous les avertissements préalables à l’installation de la mise à jour 1811, celle-ci échouera après environ une heure, et vous recevrez le message suivant :

The required SSL certificates for the Extension Host have not been found. The Azure Stack update will halt. Refer to this link to prepare for Extension Host: https://learn.microsoft.com/azure-stack/operator/azure-stack-extension-host-prepare, then resume the update. Exception: The Certificate path does not exist: [certificate path here]

Après avoir correctement importé les certificats d’hôte d’extension obligatoires, vous pouvez relancer la mise à jour 1811 à partir du portail administrateur. Même si Microsoft conseille aux opérateurs Azure Stack de planifier une fenêtre de maintenance pendant le processus de mise à jour, une défaillance due à l’absence de certificats d’hôte d’extension ne devrait pas avoir d’incidence sur les charges de travail ou les services existants.

Lors de l’installation de cette mise à jour, le portail utilisateur d’Azure Stack est indisponible pendant la configuration de l’hôte d’extension. La configuration de l’hôte d’extension peut prendre jusqu’à 5 heures. Pendant ce temps, vous pouvez vérifier l’état d’une mise à jour ou reprendre l’installation d’une mise à jour ayant échoué à l’aide d’Azure Stack Administrator PowerShell ou du point de terminaison privilégié.
Quand Azure Stack est géré par System Center Operations Manager, veillez à mettre à jour le Pack d’administration pour Microsoft Azure Stack vers la version 1.0.3.11 avant d’appliquer la mise à jour 1811.

Nouvelles fonctionnalités

Cette mise à jour inclut les nouvelles fonctionnalités et améliorations suivantes pour Azure Stack :

Avec cette publication, l’hôte d’extension est activé. L’hôte d’extension simplifie l’intégration du réseau et améliore la situation de sécurité d’Azure Stack.
Ajout de la prise en charge de l’authentification des appareils avec les services de fédération Active Directory (AD FS), en particulier lors de l’utilisation d’Azure CLI. Pour plus d’informations, voir Utiliser des profils de version des API avec Azure CLI dans Azure Stack.
Ajout de la prise en charge des principaux de service utilisant une clé secrète client avec les services de fédération Active Directory (AD FS). Pour plus d’informations, voir Créer un principal de service pour AD FS.
Cette version ajoute la prise en charge des versions d’API de service Stockage Azure suivantes : 2017-07-29, 2017-11-09. La prise en charge est également ajoutée pour les versions suivantes de l’API fournisseur de ressources Stockage Azure : 2016-05-01, 2016-12-01, 2017-06-01 et 2017-10-01. Pour plus d’informations, consultez stockage Azure Stack : Différences et considérations.
Ajout de nouvelles commandes de point de terminaison privilégié pour la mise à jour et la suppression de principaux de service pour ADFS. Pour plus d’informations, voir Créer un principal de service pour AD FS.
Ajout de nouvelles opérations de nœud d’unité d’échelle qui permettent à un opérateur Azure Stack de démarrer, d’arrêter et de fermer un nœud d’unité d’échelle. Pour plus d’informations, voir Mettre à l’échelle des actions de nœud d’unité dans Azure Stack.
Ajout d’un nouveau panneau de propriétés de région qui affiche les détails d’inscription de l’environnement. Vous pouvez afficher ces informations en cliquant sur la mosaïque de gestion des régions sur le tableau de bord par défaut dans le portail administrateur, puis en sélectionnant Propriétés.
Ajout d’une nouvelle commande de point de terminaison privilégié pour mettre à jour les informations d’identification BMC avec un nom d’utilisateur et mot de passe utilisés pour communiquer avec les machines physiques. Pour plus d’informations, consultez Mettre à jour les informations d’identification du contrôleur de gestion de la carte de base (BMC).
Ajout de la possibilité d’accéder à la feuille de route Azure via l’icône d’aide et de support (point d’interrogation) dans l’angle supérieur droit des portails administrateur et utilisateur, comme dans le portail Microsoft Azure.
Amélioration de l’expérience de gestion de la Place de marché pour les utilisateurs déconnectés. Le processus de chargement pour publier un élément sur la Place de marché dans un environnement déconnecté est réduit à une seule étape, au lieu de devoir charger séparément l’image et le package de la Place de marché. Le produit téléchargé est également visible dans le panneau de gestion de la Place de marché.
Cette publication réduit la fenêtre de maintenance requise pour la rotation des secrets en ajoutant la possibilité de ne faire tourner que les certificats externes durant la rotation des secrets d’Azure Stack.
Azure Stack PowerShell a été mis à jour vers la version 1.6.0. La mise à jour prend en charge les nouvelles fonctionnalités de stockage dans Azure Stack. Pour plus d’informations, voir les notes de publication du Module d’administration Azure Stack 1.6.0 dans PowerShell Gallery. Pour plus d’informations sur la mise à jour ou l’installation d’Azure Stack PowerShell, voir Installer PowerShell pour Azure Stack.
La fonctionnalité Disques managés est désormais activée par défaut lors de la création de machines virtuelles via le portail Azure Stack. Pour connaître les étapes supplémentaires requises pour les disques managés afin d’éviter des échecs de création de machine virtuelle, voir la section Problèmes connus.
Cette publication introduit des actions d’alerte de type Réparer pour l’opérateur Azure Stack. Certaines alertes dans 1811 incluent un bouton Réparer que vous pouvez actionner pour résoudre le problème. Pour plus d’informations, voir Surveiller l’intégrité et les alertes dans Azure Stack.
Nouvelle expérience de mise à jour dans Azure Stack. Voici quelques-unes des améliorations de la mise à jour :
- Onglets scindant les mises à jour de l'historique des mises à jour pour mieux suivre les mises à jour en cours et terminées.
- Visualisations améliorées des états dans la section des Essentials avec de nouvelles icônes et une nouvelle présentation pour les versions actuelles et OEM, ainsi que la date de la dernière mise à jour.
- Le lien Afficher de la colonne Notes de publication permet à l'utilisateur d'accéder directement à la documentation spécifique à la mise à jour, et non à la page de mise à jour générique.
- L'onglet Historique des mises à jour permet de déterminer le temps d'exécution de chaque mise à jour et propose des fonctionnalités de filtrage améliorées.
- Les unités d'échelle Azure Stack connectées reçoivent automatiquement la Mise à jour disponible.
- Les unités d’échelle Azure Stack non connectées peuvent importer les mises à jour comme précédemment.
- Le processus de téléchargement des journaux d’activité JSON à partir du portail reste inchangé. Les opérateurs Azure Stack pourront suivre la progression des différentes étapes.
  
  Pour plus d’informations, consultez Effectuer des mises à jour dans Azure Stack.

Problèmes résolus

Résolution du problème des données d’utilisation des adresses IP publiques qui affichaient la même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de l’enregistrement. Vous pouvez désormais utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Résolution d’un problème qui se produisait lors de la création d’une machine virtuelle à l’aide du portail Azure Stack. La sélection de la taille de machine virtuelle avait pour effet que la colonne USD/mois affichait le message Indisponible. Cette colonne ne s’affiche plus, car l’affichage de la colonne des prix des machines virtuelles n’est pas pris en charge dans Azure Stack.

Résolution d’un problème dans le portail administrateur où, quand vous accédiez aux détails d’un abonnement utilisateur, après que vous aviez fermé le panneau et cliqué sur Récent, le nom de l’abonnement utilisateur n’apparaissait pas. Désormais, le nom d’abonnement utilisateur apparaît.

Résolution d’un problème dans les portails administrateur et utilisateur où, quand vous cliquiez sur les paramètres du portail et sélectionniez l’option Supprimer tous les paramètres et tableaux de bord privés, cette action ne produisait pas le résultat escompté et entraînait l’affichage d’une notification d’erreur. Cette option fonctionne désormais correctement.

Résolution d’un problème dans les portails administrateur et utilisateur où, sous Tous les services, l’élément Plans de protection DDoS n’était pas correctement répertorié. Il n’est pas disponible dans Azure Stack. L’affichage de la liste a été supprimé.

Correction d’un problème qui avait pour effet que, quand vous installiez un nouvel environnement Azure Stack, l’alerte Activation requise ne s’affichait pas. Elle s’affiche désormais correctement.

Correction d’un problème qui empêchait l’application de stratégies de contrôle d’accès en fonction du rôle (RBAC) à un groupe d’utilisateurs lors de l’utilisation d’ADFS.

Correction d’un problème d’échec des sauvegardes d’infrastructure en raison d’un serveur de fichiers inaccessible à partir du réseau d’adresses IP virtuelles publiques. Ce correctif replace le service de sauvegarde d’infrastructure (Infrastructure Backup) dans le réseau d’infrastructure publique. Si vous avez appliqué le dernier correctif logiciel Azure Stack pour 1809 qui traite ce problème, la mise à jour 1811 n’apportera pas d’autre modification.

Correction d’un problème qui avait pour effet que le compte que vous utilisiez pour vous connecter au portail administrateur ou utilisateur d’Azure Stack s’affichait en tant qu’Utilisateur non identifié. Ce message s’affichait quand le prénom ou le nom du compte n’étaient pas spécifiés.

Correction d’un problème qui avait pour effet que, quand vous utilisiez le portail pour créer un groupe de machines virtuelles identiques (VMSS), la liste déroulante Taille d’instance ne se chargeait pas correctement dans Internet Explorer. Ce navigateur fonctionne désormais correctement.

Correction d’un problème qui générait des alertes bruyantes indiquant qu’une instance de rôle d’infrastructure était indisponible ou qu’un nœud d’unité d’échelle était hors connexion.

Correction d'un problème qui empêchait la page de présentation de machine virtuelle d'afficher correctement le graphique des métriques de machine virtuelle.

Modifications

La mise à jour 1811 introduit une nouvelle façon d’afficher et de modifier les quotas dans une offre. Pour plus d’informations, voir Afficher un quota existant.

Les améliorations en matière de sécurité introduites dans cette mise à jour entraînent une augmentation de la taille de sauvegarde du rôle service d’annuaire. Pour obtenir des conseils actualisés concernant le dimensionnement de l’emplacement de stockage externe, voir la documentation sur la sauvegarde d’infrastructure. Cette modification a pour effet d’allonger la durée de la sauvegarde en raison de l’accroissement du volume des données transférées. Cette modification a une incidence sur les systèmes intégrés.
L’applet de commande PEP existante pour récupérer les clés de récupération BitLocker est renommée de Get-AzsCsvsRecoveryKeys en Get-AzsRecoveryKeys dans la mise à jour 1811. Pour plus d’informations sur la façon d’obtenir les clés de récupération BitLocker, voir les instructions sur la façon d’obtenir les clés.

Vulnérabilités et menaces courantes

Cette mise à jour installe les mises à jour de sécurité suivantes :

Pour plus d'informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez l'article 4478877 de la Base de connaissances Microsoft.

Problèmes connus avec le processus de mise à jour

Si vous exécutez la cmdlet PowerShell Get-AzureStackLog après avoir exécuté Test-AzureStack dans la même session de point de terminaison privilégié, Get-AzureStackLog échoue. Pour contourner ce problème, fermez la session de point de terminaison privilégié dans laquelle vous avez exécuté Test-AzureStack, puis ouvrez une nouvelle session pour exécuter Get-AzureStackLog.
Durant l’installation de la mise à jour 1811, assurez-vous que toutes les instances du portail administrateur sont fermées. Le portail utilisateur peut rester ouvert, mais le portail administrateur doit être fermé.
Lors de l’exécution de la commande Test-AzureStack, si le test AzsInfraRoleSummary ou AzsPortalApiSummary échoue, vous êtes invité à exécuter la commande Test-AzureStack avec l’indicateur -Repair. Si vous exécutez cette commande, elle échoue et le message d’erreur suivant s’affiche : Unexpected exception getting Azure Stack health status. Cannot bind argument to parameter 'TestResult' because it is null. Ce problème sera résolu dans une publication ultérieure.
Lors de l’installation de la mise à jour 1811, le portail d’utilisation Azure Stack est indisponible durant la configuration de l’hôte d’extension. La configuration de l’hôte d’extension peut prendre jusqu’à 5 heures. Pendant ce temps, vous pouvez vérifier l’état d’une mise à jour ou reprendre l’installation d’une mise à jour ayant échoué à l’aide d’Azure Stack Administrator PowerShell ou du point de terminaison privilégié.
Pendant l’installation de la mise à jour 1811, il se peut que le tableau de bord du portail utilisateur soit indisponible et que des personnalisations soient perdues. Vous pouvez restaurer le tableau de bord par défaut une fois la mise à jour terminée en accédant aux paramètres du portail, puis en sélectionnant Restaurer les paramètres par défaut.
Quand vous exécutez la commande Test-AzureStack, un message d’avertissement du contrôleur de gestion de la carte de base (BMC) s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.
Pendant l’installation de cette mise à jour, vous pouvez voir des alertes avec le titre « Erreur - Le modèle de FaultType UserAccounts.New est manquant ». Vous pouvez les ignorer. Elles disparaîtront automatiquement une fois l’installation de cette mise à jour terminée.
Si vous avez appliqué à Azure Stack une mise à jour provenant de votre fabricant d’ordinateurs (OEM), il se peut que la notification **Mise à jour disponible** n’apparaisse pas sur le portail administrateur d’Azure Stack. Pour installer la mise à jour Microsoft, téléchargez et importez manuellement cette mise à jour en suivant les instructions indiquées ici [Apply updates in Azure Stack](../azure-stack-apply-updates.md).

Étapes après la mise à jour

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, voir Correctifs logiciels ainsi que notre Stratégie de maintenance.
Récupérez les clés de chiffrement de données au repos et stockez-les en toute sécurité hors de votre déploiement Azure Stack. Suivez les instructions sur la façon de récupérer les clés.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :
- Alerte 1 :
  - NOM : Rôle d’infrastructure défectueux
  - GRAVITÉ : Avertissement
  - COMPOSANT : Contrôleur d’intégrité
  - DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
- Alerte 2 :
  - NOM : Rôle d’infrastructure défectueux
  - GRAVITÉ : Avertissement
  - COMPOSANT : Contrôleur d’intégrité
  - DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
  Ces deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement dans le temps.

Compute

Lors de la création d’une machine virtuelle Windows, vous devez sélectionner un port d’entrée public dans le panneau Paramètres pour pouvoir continuer. Dans la mise à jour 1811, ce paramètre est obligatoire, mais n’a aucun effet. En effet, cette fonctionnalité dépend du Pare-feu Azure qui n’est pas implémenté dans Azure Stack. Vous pouvez sélectionner Aucun port d’entrée public ou toute autre option pour poursuivre la création de machine virtuelle. Le paramètre n’a aucun effet.
Lors de la création d'une machine virtuelle Windows, l’erreur suivante peut s’afficher :

'Failed to start virtual machine 'vm-name'. Error: Failed to update serial output settings for VM 'vm-name'

Cette erreur se produit si vous activez les diagnostics de démarrage sur une machine virtuelle alors que vous avez supprimé votre compte de stockage des diagnostics de démarrage. Pour contourner ce problème, recréez le compte de stockage avec le même nom que celui utilisé précédemment.
Lorsque vous créez une machine virtuelle de série Dv2, les machines virtuelles D11-14v2 vous autorisent à créer 4, 8, 16 et 32 disques de données respectivement. Toutefois, le volet Créer une machine virtuelle affiche 8, 16, 32 et 64 disques de données.
Les enregistrements d'utilisation sur Azure Stack peuvent contenir des majuscules inattendues ; par exemple :

{"Microsoft.Resources":{"resourceUri":"/subscriptions/<subid>/resourceGroups/ANDREWRG/providers/Microsoft.Compute/ virtualMachines/andrewVM0002","location":"twm","tags":"null","additionalInfo": "{\"ServiceType\":\"Standard_DS3_v2\",\"ImageType\":\"Windows_Server\"}"}}

Dans cet exemple, le nom du groupe de ressources doit être AndrewRG. Vous pouvez ignorer cette incohérence.

Pour déployer des machines virtuelles dont les tailles contiennent un suffixe v2 (par exemple, Standard_A2_v2), spécifiez le suffixe sous la forme Standard_A2_v2 (v minuscule). N’utilisez pas Standard_A2_V2 (V majuscule). Cette méthode fonctionne dans Azure global et constitue une incohérence sur Azure Stack.

Quand vous utilisez l’applet de commande Add-AzsPlatformImage, vous devez spécifier le paramètre -OsUri comme URI du compte de stockage où le disque est chargé. Si vous utilisez le chemin local du disque, l’applet de commande échoue avec l’erreur suivante :

Long running operation failed with status 'Failed'

Quand vous utilisez le portail pour créer des machines virtuelles de taille Premium (DS, Ds_v2, FS, FSv2), celles-ci sont créées dans un compte de stockage standard. La création dans un compte de stockage standard n’a pas d’impact sur les fonctionnalités, l’IOP ou la facturation. Vous pouvez sans risque ignorer l’avertissement qui indique :

You've chosen to use a standard disk on a size that supports premium disks. This could impact operating system performance and is not recommended. Consider using premium storage (SSD) instead.

Quand vous créez un groupe de machines virtuelles identiques, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement, ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

En utilisant les applets de commande PowerShell Start-AzsScaleUnitNode ou Stop-AzsScaleunitNode pour gérer les unités d’échelle, il est possible que la première tentative de démarrage ou d’arrêt de l’unité d’échelle échoue. Si la cmdlet échoue une première fois, exécutez-la une seconde fois. La deuxième exécution doit accomplir correctement l’opération.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, laissez expirer le délai d’attente de l’approvisionnement au lieu d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

La fonctionnalité Disques managés créent deux nouveaux types de quotas de calcul pour limiter la capacité maximale des disques managés qui peuvent être provisionnés. Par défaut, 2 048 Gio sont alloués pour chaque type de quota de disques managés. Toutefois, vous pouvez rencontrer les problèmes suivants :
- Pour les quotas créés avant la mise à jour 1808, le quota de la fonctionnalité Disques managés affichera des valeurs 0 dans le portail de l’administrateur, bien que 2 048 Gio soient alloués. Vous pouvez augmenter ou diminuer la valeur en fonction de vos besoins réels, et la nouvelle valeur de quota remplace la valeur par défaut de 2 048 Gio.
- Si vous mettez à jour la valeur de quota à 0, cela équivalut à la valeur par défaut de 2 048 Gio. En guise de solution de contournement, définissez la valeur de quota sur 1.

Après avoir appliqué la mise à jour 1811, il se peut que vous rencontriez les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
- Si l’abonnement a été créé avant la mise à jour 1808, le déploiement d’une machine virtuelle avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Sélectionnez Fournisseurs de ressources, Microsoft.Compute, puis Réinscrire.
  2. Sous le même abonnement, accédez à Contrôle d'accès (IAM) et vérifiez que le rôle AzureStack-DiskRP-Client est répertorié.
- Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre le problème, effectuez les étapes décrites dans cet article afin de reconfigurer chacun de vos annuaires invités.
Une machine virtuelle 18.04 Ubuntu créée avec une autorisation SSH activée ne vous permet pas d’utiliser les clés SSH pour vous connecter. Pour contourner ce problème, utilisez un accès à la machine virtuelle pour l’extension Linux afin d’implémenter des clés SSH après l’approvisionnement, ou utilisez une authentification par mot de passe.

Mise en réseau

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont rejetées.

Sur un réseau virtuel créé avec un paramètre de serveur DNS défini sur Automatique, la modification d’un serveur DNS personnalisé échoue. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

Durant la rotation des secrets Azure Stack, une période de deux à cinq minutes s’écoule pendant laquelle les adresses IP publiques sont inaccessibles.

Lorsque le locataire accède à des machines virtuelles à l’aide d’un tunnel VPN S2S, il peut être confronté à une situation où les tentatives de connexion échouent si le sous-réseau local a été ajouté à la passerelle de réseau local après la création de la passerelle.
Dans le portail Azure Stack, lorsque vous modifiez une adresse IP statique pour une configuration IP liée à une carte réseau connectée à une instance de machine virtuelle, le message d’avertissement suivant s’affiche :

The virtual machine associated with this network interface will be restarted to utilize the new private IP address....

Vous pouvez ignorer ce message. L’adresse IP changera même si l’instance de machine virtuelle ne redémarre pas.
Sur le portail, le panneau Propriétés de réseau contient un lien Obtenir les règles de sécurité effectives pour chaque carte réseau. Si vous sélectionnez ce lien, un nouveau panneau s’ouvre qui affiche le message d’erreur Not Found.. Cette erreur se produit parce qu’Azure Stack ne prend pas encore en charge la fonction Obtenir les règles de sécurité effectives.
Dans le portail, si vous ajoutez une règle de sécurité de trafic entrant et sélectionnez Balise du service en tant que source, plusieurs options s’affichent dans la liste Balise source, qui ne sont pas disponibles pour Azure Stack. Les seules options valides dans Azure Stack sont les suivantes :
- Internet
- VirtualNetwork
- AzureLoadBalancer
  
  Les autres options ne sont pas pris en charge en tant que balises sources dans Azure Stack. De même, si vous ajoutez une règle de sécurité de trafic sortant et sélectionnez Balise du service en tant que destination, la même liste d’options s’affiche pour Balise source. Les seules options valides sont les mêmes que pour Balise source, comme décrit dans la liste précédente.
L’applet de commande PowerShell New-AzureRmIpSecPolicy ne prend pas en charge la valeur DHGroup24 pour le paramètre DHGroup.
Les Groupes de sécurité réseau (NSG) ne fonctionnent pas de la même manière dans Azure Stack que dans le reste d'Azure. Dans Azure, vous pouvez définir plusieurs ports sur une règle NSG (en utilisant les modèles du portail, de PowerShell et de Resource Manager). Dans Azure Stack, via le portail, vous ne pouvez définir qu'un seul port sur une règle NSG. Pour contourner ce problème, utilisez un modèle Resource Manager qui vous permettra de définir ces autres règles.

Infrastructure Backup

Après activation des sauvegardes automatiques, le service du planificateur passe à l’état désactivé de façon inattendue. Le service du contrôleur de sauvegarde détecte que les sauvegardes automatiques sont désactivées et déclenche un avertissement dans le portail administrateur. Cet avertissement est attendu quand les sauvegardes automatiques sont désactivées.
- Cause : ce problème est dû à un bogue dans le service qui entraîne une perte de configuration du planificateur. Ce bogue ne modifie pas l’emplacement de stockage, le nom d’utilisateur, le mot de passe ou la clé de chiffrement.
- Correction : pour atténuer ce problème, ouvrez le panneau paramètres du contrôleur de sauvegarde dans le fournisseur de ressources Infrastructure Backup, puis sélectionnez Activer les sauvegardes automatiques. Veillez à définir la fréquence et la période de rétention souhaitées.
- Occurrence : Faible

App Service

Avant de créer votre première fonction Azure dans l’abonnement, vous devez inscrire le fournisseur de ressources de stockage.

Syslog

La configuration syslog n’est pas conservée lors d’un cycle de mise à jour et, par conséquent, le client perd sa configuration et les messages syslog ne sont plus transférés. Ce problème s’applique à toutes les versions d’Azure Stack depuis la disponibilité générale du client syslog (1809). Pour contourner ce problème, reconfigurez le client syslog après avoir appliqué une mise à jour Azure Stack.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1811 d’Azure Stack à partir de cet emplacement.

Étapes suivantes

Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1809

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1809. La mise à jour inclut des améliorations, des corrections et des problèmes connus de cette version d’Azure Stack. Cet article inclut également un lien de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1809 d’Azure Stack est 1.1809.0.90.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations suivantes pour Azure Stack :

Avec cette version, les systèmes intégrés Azure Stack prennent en charge des configurations de 4 à 16 nœuds. Vous pouvez utiliser Azure Stack Capacity Planner pour vous aider à planifier la capacité et la configuration d’Azure Stack.

Client Syslog Azure Stack (disponibilité générale) : ce client permet de transférer des journaux d’audit, d’alertes et de sécurité relatifs à l’infrastructure Azure Stack vers un serveur Syslog ou une solution SIEM (Security Information and Event Management, gestion des informations et événements de sécurité) externe à Azure Stack. Le client Syslog prend désormais en charge la spécification du port sur lequel écoute le serveur Syslog.

Avec cette publication, le client Syslog devient généralement disponible et peut être utilisé en environnement de production.

Pour plus d’informations, consultez Transfert de syslog dans Azure Stack.
Vous pouvez à présent déplacer la ressource d’inscription sur Azure entre des groupes de ressources sans avoir à vous réinscrire. Les fournisseurs de solutions cloud (CSP) peuvent également déplacer la ressource d’inscription entre des abonnements, tant que les anciens et nouveaux abonnements sont mappés vers le même ID de partenaire CSP. Cela n’affecte pas les mappages du locataire client existants.
Ajout de la prise en charge de l’attribution de plusieurs adresses IP par interface réseau. Pour plus d’informations, consultez Affecter plusieurs adresses IP à des machines virtuelles avec PowerShell.

Problèmes résolus

Dans le portail, le graphique indiquant la mémoire libre et la capacité utilisée est désormais plus précis. Vous pouvez maintenant prévoir de manière plus fiable le nombre de machines virtuelles que vous êtes en mesure de créer.

Le problème a été résolu, dans lequel le portail affichait un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de la série DS lorsque vous créez des machines virtuelles sur le portail utilisateur Azure Stack. Les machines virtuelles de série DS peuvent prendre en charge autant de disques de données que la configuration Azure.
Les problèmes de disque managé suivants ont été corrigés dans la mise à jour 1809 ainsi que dans la mise à jour 1808 Correctif Azure Stack 1.1808.9.117 :
- Le problème a été résolu, dans lequel l’attachement de disques de données SSD à des machines virtuelles avec des disques managés de taille Premium (DS, DSv2, Fs, Fs_V2) échouait avec une erreur : Échec de la mise à jour des disques pour la machine virtuelle ’vmname’ Erreur : l’opération demandée ne peut pas être effectuée, car le type de compte de stockage ’Premium_LRS’ n’est pas pris en charge pour la taille de machine virtuelle ’Standard_DS/Ds_V2/FS/Fs_v2)’.
- Création d’une machine virtuelle avec disque managé à l’aide de createOption : Attach échoue avec l’erreur suivante : Échec de l’opération de longue durée avec l’état « Failed ». Informations supplémentaires : Une erreur d'exécution interne s'est produite. ErrorCode: InternalExecutionError ErrorMessage : Une erreur d’exécution interne s’est produite.
  
  Ce problème est à présent résolu.
Problème résolu de la conservation des adresses IP publiques déployées à l’aide de la méthode d’allocation dynamique qui n’était pas garantie après l’émission d’une commande d’arrêt/libération. Elles sont désormais conservées.
Si une machine virtuelle était arrêtée/libérée avant la mise à jour 1808, il n’était pas possible de la réallouer après cette mise à jour. Ce problème a été résolu dans la mise à jour 1809. Grâce à ce correctif introduit dans la mise à jour 1809, les instances qui se trouvaient dans cet état empêchant leur démarrage peuvent désormais être démarrées. Le correctif empêche également que ce problème se reproduise.

Modifications

Le service de sauvegarde de l’infrastructure se passe du réseau d’infrastructure publique au réseau d’adresse IP virtuelle publique. Les clients doivent vérifier que le service a accès à l’emplacement de stockage de sauvegarde à partir du réseau d’adresse IP virtuelle publique.

Important

Si vous avez un pare-feu qui n’autorise pas les connexions du réseau d’adresse IP virtuelle publique au serveur de fichiers, ce changement entraîne l’échec des sauvegardes d’infrastructure avec l’« Erreur 53 Le chemin réseau n’a pas été trouvé ». Il s’agit d’un changement cassant pour lequel il n’existe aucune solution de contournement raisonnable. Sur la base des remarques des clients, Microsoft établira ce changement dans un correctif. Pour plus d’informations sur les correctifs logiciels disponibles pour 1809, passez en revue la section relative aux étapes post-mise à jour. Une fois le correctif logiciel disponible, veillez à l’appliquer après avoir effectué la mise à jour vers 1809 uniquement si vos stratégies réseau n’autorisent pas le réseau d’adresse IP virtuelle publique à accéder aux ressources d’infrastructure. Dans 1811, cette modification sera appliquée à tous les systèmes. Si vous avez appliqué le correctif logiciel dans 1809, aucune action supplémentaire n’est nécessaire.

Vulnérabilités et menaces courantes

Cette mise à jour installe les mises à jour de sécurité suivantes :

Pour plus d’informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez les articles de la Base de connaissances Microsoft 4457131 et 4462917.

Prérequis

Installez le dernier correctif Azure Stack pour 1808 avant d’appliquer 1809. Pour plus d’informations, consultez KB 4481066 - Correctif Azure Stack 1.1808.9.117. Bien que Microsoft recommande le dernier correctif logiciel disponible, la version minimale requise pour installer 1809 est 1.1808.5.110.
Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une intervention.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```
Quand Azure Stack est géré par System Center Operations Manager, veillez à mettre à jour le Pack d’administration pour Microsoft Azure Stack vers la version 1.0.3.11 avant d’appliquer la mise à jour 1809.

Problèmes connus avec le processus de mise à jour

Quand vous exécutez Test-AzureStack après la mise à jour 1809, un message d’avertissement du contrôleur BMC s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.

Pendant l’installation de cette mise à jour, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles se fermeront automatiquement une fois l’installation de la mise à jour terminée.
Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).
Si vous avez appliqué une mise à jour à Azure Stack à partir de votre matériel OEM, la notification Mise à jour disponible peut ne pas apparaître dans le portail d’administration Azure Stack. Pour installer la mise à jour Microsoft, téléchargez et importez manuellement cette mise à jour en suivant les instructions indiquées ici Effectuer des mises à jour dans Azure Stack.

Étapes après la mise à jour

Important

Préparer votre déploiement Azure Stack pour l’hôte d’extension qui est activé par le prochain package de mise à jour. Préparez votre système en utilisant les instructions suivantes, Préparer l’hôte d’extension pour Azure Stack.

Après l’installation de cette mise à jour, installez les correctifs logiciels applicables. Pour plus d’informations, consultez les articles suivants de la base de connaissances, ainsi que notre stratégie de maintenance.

KB 4481548 - Correctif Azure Stack 1.1809.12.114

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

La documentation technique Azure Stack s’applique à la dernière version. En raison des changements apportés au portail entre les versions, ce que vous voyez dans les portails Azure Stack peut différer du contenu de la documentation.

Dans le portail d’administration, quand vous affichez les détails d’un abonnement utilisateur, après avoir fermé le panneau et cliqué sur Récent, le nom de l’abonnement utilisateur n’apparaît pas.

Dans les portails d’administration et utilisateur, quand vous cliquez sur les paramètres du portail et sélectionnez Supprimer tous les paramètres et tableaux de bord privés, le résultat n’est pas le comportement prévu. Une notification d’erreur s’affiche.

Dans les portails d’administration et utilisateur, sous Tous les services, l’élément Plans de protection DDoS est incorrectement répertorié. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, une erreur s’affiche indiquant que le portail ne peut pas créer cet élément de la Place de marché.

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. Il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Le compte que vous utilisez pour vous connecter au portail d’administration ou utilisateur Azure Stack s’affiche comme Utilisateur non identifié. Ce message s’affiche quand le prénom ou le nom du compte n’a pas été spécifié. Pour contourner ce problème, modifiez le compte d’utilisateur afin d’ajouter le nom ou le prénom. Vous devez ensuite vous déconnecter et vous reconnecter au portail.

Quand vous utilisez le portail pour créer un groupe de machines virtuelles identiques, la liste déroulante Taille d’instance ne se charge pas correctement dans Internet Explorer. Pour contourner ce problème, utilisez un autre navigateur quand vous créez un groupe de machines virtuelles identiques à l’aide du portail.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Quand vous installez un nouvel environnement Azure Stack qui exécute cette version, l’alerte Activation requise peut ne pas s’afficher. L’activation est nécessaire avant que vous puissiez utiliser la syndication de Place de marché.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Intégrité et surveillance

Vous risquez de recevoir les alertes suivantes à plusieurs reprises avant qu’elles ne disparaissent sur votre système Azure Stack :
- Instance de rôle d’infrastructure non disponible
- Nœud d’unité d’échelle hors ligne
Exécutez l’applet de commande Test-AzureStack pour vérifier l’intégrité des instances de rôle d’infrastructure et des nœuds d’unité d’échelle. Si aucun problème n’est détecté par Test-AzureStack, vous pouvez ignorer ces alertes. Si un problème est détecté, vous pouvez tenter de démarrer l’instance de rôle d’infrastructure ou le nœud à l’aide du portail d’administration ou de PowerShell.

Ce problème est résolu dans la dernière version de correctif logiciel 1809, par conséquent, veillez à installer ce correctif logiciel si vous rencontrez le problème.

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Les deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement au bout d’un moment.

Vous pouvez voir une alerte pour le composant Stockage avec les informations suivantes :
- NOM : Erreur de communication interne du service de stockage
- GRAVITÉ : Critique
- COMPOSANT : Stockage
- DESCRIPTION : Une erreur de communication interne du service de stockage s’est produite lors de l’envoi des requêtes aux nœuds suivants.
  
  L’alerte peut être ignorée sans risque, mais vous devez la fermer manuellement.

En tant qu’opérateur d’Azure Stack, si vous recevez une alerte de mémoire insuffisante et que les machines virtuelles de locataire ne parviennent pas à se déployer à cause d’une erreur de création de machine virtuelle de structure, il est possible que l’horodatage d’Azure Stack soit à court de mémoire. Utilisez le Capacity Planner Azure Stack pour mieux comprendre la capacité disponible pour vos charges de travail.

Compute

Lorsque vous créez une machine virtuelle de série Dv2, les machines virtuelles D11-14v2 vous autorisent à créer 4, 8, 16 et 32 disques de données respectivement. Toutefois, le volet Créer une machine virtuelle affiche 8, 16, 32 et 64 disques de données.

Pour déployer des machines virtuelles avec des tailles contenant un suffixe v2 ; par exemple, Standard_A2_v2, spécifiez le suffixe sous la forme Standard_A2_v2 (v minuscule). N’utilisez pas Standard_A2_V2 (V majuscule). Cette méthode fonctionne dans Azure global et constitue une incohérence sur Azure Stack.

Quand vous créez une machine virtuelle à l’aide du portail Azure Stack et sélectionnez la taille de machine virtuelle, la colonne EUR/mois s’affiche avec le message Indisponible. Cette colonne ne devrait pas s’afficher, car l’affichage de la colonne des prix des machines virtuelles n’est pas pris en charge dans Azure Stack.

Quand vous utilisez l’applet de commande Add-AzsPlatformImage, vous devez spécifier le paramètre -OsUri comme URI du compte de stockage où le disque est chargé. Si vous utilisez le chemin local du disque, la cmdlet échoue avec l’erreur suivante : Échec de l’opération de longue durée avec l’état « Failed ».

Quand vous utilisez le portail pour créer des machines virtuelles de taille Premium (DS, Ds_v2, FS, FSv2), celles-ci sont créées dans un compte de stockage standard. La création dans un compte de stockage standard n’a pas d’impact sur les fonctionnalités, l’IOP ou la facturation.

Vous pouvez ignorer en toute sécurité l’avertissement indiquant : Vous avez choisi d’utiliser un disque standard sur une taille qui prend en charge les disques Premium. Cela peut avoir un impact sur les performances du système d’exploitation et n’est pas recommandé. Envisagez plutôt d’utiliser le stockage Premium (SSD).

Quand vous créez un groupe de machines virtuelles identiques, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

En utilisant les applets de commande PowerShell Start-AzsScaleUnitNode ou Stop-AzsScaleunitNode pour gérer les unités d’échelle, il est possible que la première tentative de démarrage ou d’arrêt de l’unité d’échelle échoue. Si la cmdlet échoue une première fois, exécutez-la une seconde fois. La deuxième exécution doit permettre de terminer l’opération.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Quand vous inscrivez le fournisseur de ressources Microsoft.Insight dans les paramètres d’abonnement, puis créez une machine virtuelle Windows en ayant activé les diagnostics du système d’exploitation invité, le graphique Pourcentage UC dans la page de vue d’ensemble de la machine virtuelle n’affiche pas les données de métriques.

Pour trouver les données de métriques, comme le graphique Pourcentage UC, accédez à la fenêtre Métriques, puis affichez toutes les métriques d’invité de machine virtuelle Windows prises en charge.

La fonctionnalité Disques managés créent deux nouveaux types de quotas de calcul pour limiter la capacité maximale des disques managés qui peuvent être provisionnés. Par défaut, 2 048 Gio sont alloués pour chaque type de quota de disques managés. Toutefois, vous pouvez rencontrer les problèmes suivants :
- Pour les quotas créés avant la mise à jour 1808, le quota de la fonctionnalité Disques managés affichera des valeurs 0 dans le portail de l’administrateur, bien que 2 048 Gio soient alloués. Vous pouvez augmenter ou diminuer la valeur en fonction de vos besoins réels, et la nouvelle valeur de quota remplace la valeur par défaut de 2 048 Gio.
- Si vous mettez à jour la valeur de quota à 0, cela équivalut à la valeur par défaut de 2 048 Gio. En guise de solution de contournement, définissez la valeur de quota sur 1.

Après avoir appliqué la mise à jour 1809, vous rencontrerez peut-être les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
- Si l’abonnement a été créé avant la mise à jour 1808, le déploiement d’une machine virtuelle avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Cliquez sur Fournisseurs de ressources, sur Microsoft.Compute, puis sur Réinscrire.
  2. Sous le même abonnement, accédez à Contrôle d'accès (IAM) et vérifiez que le rôle AzureStack-DiskRP-Client est répertorié.
- Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre le problème, effectuez les étapes décrites dans cet article afin de reconfigurer chacun de vos annuaires invités.
Une machine virtuelle 18.04 Ubuntu créée avec une autorisation SSH activée ne vous permet pas d’utiliser les clés SSH pour vous connecter. Pour contourner ce problème, utilisez un accès à la machine virtuelle pour l’extension Linux afin d’implémenter des clés SSH après l’approvisionnement, ou utilisez une authentification par mot de passe.

Mise en réseau

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.

Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

Durant la rotation des secrets Azure Stack, une période de deux à cinq minutes s’écoule pendant laquelle les adresses IP publiques sont inaccessibles.

Dans les cas où le locataire accède à ses machines virtuelles à l’aide d’un tunnel VPN S2S, il peut rencontrer un scénario où les tentatives de connexion échouent si le sous-réseau local a été ajouté à la passerelle de réseau local après la création de la passerelle.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.

Utilisation

Les données d’utilisation des adresses IP publiques affichent la même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1809 d’Azure Stack à partir de cet emplacement.

Étapes suivantes

Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1808

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1808. La mise à jour inclut des améliorations, des corrections et des problèmes connus de cette version d’Azure Stack. Cet article inclut également un lien de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1808 d’Azure Stack est 1.1808.0.97.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations suivantes pour Azure Stack.

Tous les environnements Azure Stack utilisent maintenant le format du fuseau horaire UTC (Temps Universel Coordonné). Toutes les données de journal et informations connexes sont donc affichées au format UTC. Si vous effectuez une mise à jour d’une version antérieure qui n’avait pas été installée avec le format UTC, votre environnement est mis à jour pour utiliser ce format.

Les disques managés sont pris en charge. Vous pouvez maintenant utiliser des disques managés dans les machines virtuelles et les groupes de machines virtuelles identiques Azure Stack. Pour plus d’informations, consultez Fonctionnalité Disques managés d’Azure Stack : différences et considérations.

Azure Monitor. Tout comme Azure Monitor sur Azure, Azure Monitor sur Azure Stack fournit des métriques et journaux d’activité de base à propos de l’infrastructure pour une majorité de services. Pour plus d’informations, consultez Azure Monitor sur Azure Stack.

Préparer l’hôte d’extension. Vous pouvez utiliser l’hôte d’extension pour sécuriser Azure Stack en réduisant le nombre de ports TCP/IP requis. Avec la mise à jour 1808, vous pouvez préparer l’hôte d’extension afin de l’utiliser dans votre système Azure Stack. Pour plus d’informations, consultez Préparer l’hôte d’extension pour Azure Stack.

Les éléments de la galerie pour les groupes de machines virtuelles identiques sont maintenant intégrés. L’élément de galerie Groupe de machines virtuelles identiques est désormais accessible dans les portails administrateur et utilisateur sans avoir à le télécharger. Si vous effectuez une mise à niveau vers la version 1808, cet élément est disponible à la fin de la mise à niveau.

Mise à l’échelle de groupe de machines virtuelles identiques. Vous pouvez utiliser le portail pour mettre à l’échelle un groupe de machines virtuelles identiques (VMSS).

Prise en charge des configurations de stratégie IPSec/IKE personnalisées pour les passerelles VPN dans Azure Stack.

Élément Kubernetes de la Place de marché. Vous pouvez désormais déployer des clusters Kubernetes avec l’élément Kubernetes de la Place de marché. Pour déployer un cluster Kubernetes sur Azure Stack, les utilisateurs n’ont qu’à sélectionner l’élément Kubernetes et renseigner quelques paramètres. L’objectif des modèles est de permettre aux utilisateurs de créer des déploiements Kubernetes de développement et de test en quelques étapes seulement.

Modèles Blockchain. Vous pouvez maintenant exécuter des déploiements de consortium Ethereum sur Azure Stack. Les modèles de démarrage rapide Azure Stack proposent trois nouveaux modèles. Avec ces nouveaux modèles, les utilisateurs peuvent déployer et configurer un réseau Ethereum pour former un consortium de membres, sans avoir besoin de connaissances avancées sur Azure et Ethereum. L’objectif des modèles est de permettre aux utilisateurs de créer des déploiements Blockchain de développement et de test facilement, en quelques étapes seulement.

Le profil de version d’API 2017-03-09-profile a été mis à jour vers 2018-03-01-hybrid. Les profils d’API précisent le fournisseur de ressources Azure ainsi que la version d’API des points de terminaison Azure REST. Pour plus d’informations sur les profils, consultez Gérer les profils de version des API dans Azure Stack.

Problèmes résolus

Nous avons résolu le problème de la création d’un groupe à haute disponibilité dans le portail qui aboutissait à un groupe avec un domaine d’erreur et un domaine de mise à jour 1.

Les paramètres de mise à l’échelle des groupe de machines virtuelles identiques sont maintenant disponibles dans le portail.

Le problème qui empêchait l’affichage de certaines tailles de machine virtuelle de série F quand vous sélectionniez une taille de machine virtuelle pour le déploiement est maintenant résolu.

Améliorations des performances lors de la création de machines virtuelles, et utilisation optimisée du stockage sous-jacent.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Modifications

Les tutoriels de démarrage rapide dans le tableau de bord du portail utilisateur renvoient désormais vers des articles pertinents de la documentation Azure Stack en ligne.

L’option Tous les services remplace l’option Autres services dans les portails d’administration et utilisateur Azure Stack. Vous pouvez maintenant utiliser Tous les services comme alternative pour naviguer dans les portails Azure Stack de la même façon que dans les portails Azure.

L’option + Créer une ressource remplace l’option + Nouveau dans les portails d’administration et utilisateur Azure Stack. Vous pouvez maintenant utiliser + Créer une ressource comme alternative pour naviguer dans les portails Azure Stack de la même façon que dans les portails Azure.

Les tailles de machine virtuelle De base A ne sont plus disponibles pour la création de groupes de machines virtuelles identiques (VMSS) dans le portail. Pour créer un groupe de machines virtuelles identiques avec cette taille, utilisez PowerShell ou un modèle.

Failles et menaces courantes

Cette mise à jour installe les mises à jour suivantes :

Pour plus d’informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez l’article de la Base de connaissances Microsoft 4343887.

Cette mise à jour contient également l’atténuation de la vulnérabilité du canal auxiliaire d’exécution spéculative appelée L1TF (L1 Terminal Fault) et décrite dans l’avis de sécurité Microsoft ADV180018.

Prérequis

Installez la mise à jour 1807 d'Azure Stack avant d'appliquer la mise à jour 1808.
Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une intervention.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```

Problèmes connus avec le processus de mise à jour

Quand vous exécutez Test-AzureStack après la mise à jour 1808, un message d’avertissement du contrôleur BMC s’affiche. Vous pouvez ignorer cet avertissement en toute sécurité.

Pendant l’installation de cette mise à jour, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles se fermeront automatiquement une fois l’installation de la mise à jour terminée.

Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).

Dans certaines circonstances quand une mise à jour nécessite une attention particulière, l’alerte correspondante peut ne pas être générée. L’état précis apparaît quand même dans le portail et n’est pas affecté.

Étapes après la mise à jour

KB 4465859 - Correctif Azure Stack 1.1808.2.104

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

La documentation technique Azure Stack s’applique à la dernière version. En raison des changements apportés au portail entre les versions, ce que vous voyez dans les portails Azure Stack peut différer du contenu de la documentation.

Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, cliquez sur Modifier le tableau de bord, puis cliquez avec le bouton droit sur Rétablir l’état par défaut.

Dans le portail d’administration, quand vous affichez les détails d’un abonnement utilisateur, après avoir fermé le panneau et cliqué sur Récent, le nom de l’abonnement utilisateur n’apparaît pas.

Dans les portails d’administration et utilisateur, quand vous cliquez sur les paramètres du portail et sélectionnez Supprimer tous les paramètres et tableaux de bord privés, le résultat n’est pas le comportement prévu. Une notification d’erreur s’affiche.

Dans les portails d’administration et utilisateur, sous Tous les services, l’élément Plans de protection DDoS est incorrectement répertorié. En effet, il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, une erreur s’affiche indiquant que le portail ne peut pas créer cet élément de la Place de marché.

Dans les portails d’administration et utilisateur, si vous recherchez « Docker », l’élément est incorrectement retourné dans les résultats. En effet, il n’est pas disponible dans Azure Stack. Si vous essayez de le créer, un panneau indiquant une erreur s’affiche.

Le compte que vous utilisez pour vous connecter au portail d’administration ou utilisateur Azure Stack s’affiche comme Utilisateur non identifié. Cela se produit quand le prénom ou le nom du compte n’a pas été spécifié. Pour contourner ce problème, modifiez le compte d’utilisateur afin d’ajouter le nom ou le prénom. Vous devez ensuite vous déconnecter et vous reconnecter au portail.

Quand vous utilisez le portail pour créer un groupe de machines virtuelles identiques, la liste déroulante Taille d’instance ne se charge pas correctement dans Internet Explorer. Pour contourner ce problème, utilisez un autre navigateur quand vous créez un groupe de machines virtuelles identiques à l’aide du portail.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Quand vous installez un nouvel environnement Azure Stack qui exécute cette version, l’alerte Activation requise peut ne pas s’afficher. L’activation est nécessaire avant que vous puissiez utiliser la syndication de Place de marché.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Les deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement au bout d’un moment.

Vous pouvez voir une alerte pour le composant Stockage avec les informations suivantes :
- NOM : Erreur de communication interne du service de stockage
- GRAVITÉ : Critique
- COMPOSANT : Stockage
- DESCRIPTION : Une erreur de communication interne du service de stockage s’est produite lors de l’envoi des requêtes aux nœuds suivants.
  
  L’alerte peut être ignorée sans risque, mais vous devez la fermer manuellement.

En tant qu’opérateur d’Azure Stack, si vous recevez une alerte de mémoire insuffisante et que les machines virtuelles de locataire ne parviennent pas à se déployer à cause d’une erreur de création de machine virtuelle de structure, il est possible que l’horodatage d’Azure Stack soit à court de mémoire. Utilisez le Capacity Planner Azure Stack pour mieux comprendre la capacité disponible pour vos charges de travail.

Compute

Quand vous créez une machine virtuelle à l’aide du portail Azure Stack et sélectionnez la taille de machine virtuelle, la colonne EUR/mois s’affiche avec le message Indisponible. Cette colonne ne devrait pas s’afficher, car l’affichage de la colonne des prix des machines virtuelles n’est pas pris en charge dans Azure Stack.

Après avoir appliqué la mise à jour 1808, il se peut que vous rencontriez les problèmes suivants lors du déploiement de machines virtuelles avec la fonctionnalité Disques managés :
1. Si l’abonnement a été créé avant la mise à jour 1808, le déploiement de machines virtuelles avec la fonctionnalité Disques managés peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit pour chaque abonnement :
  1. Dans le portail locataire, accédez à Abonnements et recherchez l’abonnement. Cliquez sur Fournisseurs de ressources, sur Microsoft.Compute, puis sur Réinscrire.
  2. Sous le même abonnement, accédez à Contrôle d’accès (IAM) et vérifiez que Disques managés d’Azure Stack figure dans la liste.
2. Si vous avez configuré un environnement multilocataire, le déploiement de machines virtuelles dans un abonnement associé à un annuaire invité peut échouer avec un message d’erreur interne. Pour résoudre l’erreur, procédez comme suit :
  1. Appliquez le correctif 1808 d’Azure Stack.
  2. Effectuez les étapes décrites dans cet article pour reconfigurer chacun de vos annuaires invités.

Quand vous utilisez l’applet de commande Add-AzsPlatformImage, vous devez spécifier le paramètre -OsUri comme URI du compte de stockage où le disque est chargé. Si vous utilisez le chemin local du disque, l’applet de commande échoue avec l’erreur suivante : Échec de l’opération de longue durée avec l’état Échec.

L’attachement de disques de données SSD à des machines virtuelles avec des disques managés de taille Premium (DS, DSv2, Fs, Fs_V2) échoue avec une erreur : Échec de la mise à jour des disques pour la machine virtuelle ’vmname’ Erreur : l’opération demandée ne peut pas être effectuée, car le type de compte de stockage ’Premium_LRS’ n’est pas pris en charge pour la taille de machine virtuelle ’Standard_DS/Ds_V2/FS/Fs_v2)’

Pour contourner ce problème, utilisez des disques de données Standard_LRS à la place de disques Premium_LRS. L’utilisation de disques de données Standard_LRS n’a pas d’impact sur l’IOP ou le coût de facturation.

Quand vous utilisez le portail pour créer des machines virtuelles de taille Premium (DS, Ds_v2, FS, FSv2), celles-ci sont créées dans un compte de stockage standard. La création dans un compte de stockage standard n’a pas d’impact sur les fonctionnalités, l’IOP ou la facturation.

Vous pouvez ignorer en toute sécurité l’avertissement indiquant : Vous avez choisi d’utiliser un disque standard sur une taille qui prend en charge les disques Premium. Cela peut avoir un impact sur les performances du système d’exploitation et n’est pas recommandé. Envisagez plutôt d’utiliser le stockage Premium (SSD).

Quand vous créez un groupe de machines virtuelles identiques, l’option CentOS 7.2 est proposée pour le déploiement. Étant donné que cette image n’est pas disponible sur Azure Stack, sélectionnez un autre système d’exploitation pour votre déploiement ou choisissez un modèle Azure Resource Manager spécifiant une autre image CentOS qui a été téléchargée par l’opérateur avant le déploiement à partir de la Place de marché.

En utilisant les applets de commande PowerShell Start-AzsScaleUnitNode ou Stop-AzsScaleunitNode pour gérer les unités d’échelle, il est possible que la première tentative de démarrage ou d’arrêt de l’unité d’échelle échoue. Si la cmdlet échoue une première fois, exécutez-la une seconde fois. La deuxième exécution doit permettre de terminer l’opération.

Lorsque vous créez des machines virtuelles sur le portail utilisateur Azure Stack, le portail affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de la série DS. Les machines virtuelles de série DS peuvent prendre en charge autant de disques de données que la configuration Azure.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Quand vous inscrivez le fournisseur de ressources Microsoft.Insight dans les paramètres d’abonnement et créez une machine virtuelle Windows avec les diagnostics du système d’exploitation invité activés, le graphique de pourcentage d’UC dans la page de vue d’ensemble de machine virtuelle ne peut pas afficher les données de métriques.

Pour trouver le graphique de pourcentage d’UC de la machine virtuelle, accédez au panneau Métriques et affichez toutes les métriques de machines virtuelles Windows invitées prises en charge.

Mise en réseau

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.

Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

La conservation des adresses IP publiques déployées à l’aide de la méthode d’allocation dynamique n’est pas garantie après l’émission d’une commande Arrêter/Libérer.

Durant la rotation des secrets Azure Stack, une période de deux à cinq minutes s’écoule pendant laquelle les adresses IP publiques sont inaccessibles.

Dans les cas où le locataire accède à ses machines virtuelles à l’aide d’un tunnel VPN S2S, il peut rencontrer un scénario où les tentatives de connexion échouent si le sous-réseau local a été ajouté à la passerelle de réseau local après la création de la passerelle.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.

Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

Utilisation

Les données d’utilisation des adresses IP publiques indiquent une même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Télécharger la mise à jour

Vous pouvez télécharger la mise à jour 1808 d’Azure Stack à partir de cet emplacement.

Étapes suivantes

Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1807

S’applique à : systèmes intégrés Azure Stack

Cet article décrit le contenu de la mise à jour 1807. Cette mise à jour inclut des améliorations, des corrections, des problèmes connus de cette version d’Azure Stack et l’emplacement de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de mise à jour d’Azure Stack 1807 est 1.1807.0.76.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations suivantes pour Azure Stack.

Démarrer les sauvegardes selon un calendrier prédéfini : En tant qu’appliance, Azure Stack peut maintenant lancer automatiquement des sauvegardes périodiques de l’infrastructure afin d’éviter toute intervention humaine. Azure Stack nettoie également automatiquement le partage externe des sauvegardes antérieures à la période de rétention définie. Pour en savoir plus, voir Activer la sauvegarde d’Azure Stack avec PowerShell.

Ajout du temps de transfert des données au temps total de sauvegarde. Pour en savoir plus, voir Activer la sauvegarde d’Azure Stack avec PowerShell.

La capacité externe de sauvegarde affiche maintenant la capacité correcte du partage externe. (Auparavant, il s’agissait d’un code dur à 10 Go.) Pour plus d’informations, consultez Activer la sauvegarde pour Azure Stack avec PowerShell.

Augmenter la capacité en ajoutant des nœuds d’unité d’échelle supplémentaires.

Les modèles Azure Resource Manager prennent désormais en charge l’élément de condition : Vous pouvez désormais déployer une ressource dans un modèle Azure Resource Manager à l’aide d’une condition. Vous pouvez concevoir votre modèle afin de déployer une ressource en fonction d’une condition, par exemple évaluer si une valeur de paramètre est présente. Pour plus d’informations sur l’utilisation d’un modèle en tant que condition, consultez Déployer une ressource de manière conditionnelle et Section Variables des modèles Azure Resource Manager dans la documentation Azure.

Vous pouvez également utiliser des modèles pour déployer des ressources Azure sur plusieurs groupes de ressources ou abonnements.

La prise en charge de la version de ressource d’API Microsoft.Network a été mise à jour pour inclure la prise en charge de la version d’API 2017-10-01 à partir de la version 2015-06-15 pour les ressources réseau Azure Stack. La prise en charge des versions de ressources entre 2017-10-01 et 2015-06-15 n’est pas incluse dans cette version. Pour connaître les différences de fonctionnalités, consultez Considérations relatives à la mise en réseau Azure Stack.

Azure Stack a ajouté la prise en charge des recherches DNS inversées pour les points de terminaison d’infrastructure Azure Stack externes (autrement dit pour portal, adminportal, management et adminmanagement). Cela permet de résoudre les noms des points de terminaison externes Azure Stack à partir d’une adresse IP.

Azure Stack prend désormais en charge l’ajout d’interfaces réseau supplémentaires à une machine virtuelle existante. Cette fonctionnalité est disponible à l’aide du portail, de PowerShell et de l’interface CLI. Pour plus d’informations, consultez Ajouter ou supprimer des interfaces réseau dans la documentation Azure.

Des améliorations en matière de précision et de résilience ont été apportées aux compteurs d’utilisation de mise en réseau. Les compteurs d’utilisation réseau sont désormais plus précis et tiennent compte des abonnements suspendus, des périodes d’interruption et des conditions de concurrence.

Notification de disponibilité de mise à jour. Les déploiements Azure Stack connectés contactent désormais périodiquement un point de terminaison sécurisé afin de déterminer si une mise à jour est disponible pour votre cloud. Cette notification s’affiche dans la vignette Mise à jour, comme elle le ferait après la vérification et l’importation manuelles d’une nouvelle mise à jour. Découvrez-en plus sur la gestion des mises à jour pour Azure Stack.

Améliorations apportées au client syslog Azure Stack (fonctionnalité en préversion). Ce client permet le transfert des journaux d’activité et de l’audit liés à l’infrastructure d’Azure Stack vers un serveur Syslog ou un logiciel SIEM externe à Azure Stack. Le client syslog prend désormais en charge le protocole TCP avec texte brut ou chiffrement TLS 1.2, cette dernière option étant la configuration par défaut. Vous pouvez configurer la connexion TLS avec authentification mutuelle ou serveur uniquement.

Pour configurer la façon dont le client syslog communique avec le serveur syslog (par exemple le protocole, le chiffrement et l’authentification), utilisez l’applet de commande Set-SyslogServer. Cette applet de commande est disponible à partir du point de terminaison privilégié (PEP).

Pour ajouter le certificat côté client pour l’authentification mutuelle TLS 1.2 du client syslog, utilisez l’applet de commande Set-SyslogClient dans le PEP.

Avec cette préversion, vous pouvez voir un plus grand nombre d’audits et d’alertes.

Cette fonctionnalité étant toujours en préversion, ne vous reposez pas sur elle dans les environnements de production.

Pour plus d’informations, consultez Transfert de syslog dans Azure Stack.

Azure Resource Manager inclut le nom de la région. Avec cette version, les objets récupérés à partir d’Azure Resource Manager incluront désormais l’attribut de nom de région. Si un script PowerShell existant passe directement l’objet à une autre applet de commande, le script peut générer une erreur et échouer. Ce comportement est conforme à Azure Resource Manager et oblige le client appelant à soustraire l’attribut de région. Pour plus d’informations sur Azure Resource Manager, consultez la documentation Azure Resource Manager.

Modifications apportées à la fonctionnalité Fournisseurs délégués. À compter de la version 1807, le modèle Fournisseurs délégués est simplifié afin de mieux s’aligner sur le modèle de revendeur Azure, et les fournisseurs délégués ne pourront pas créer d’autres fournisseurs délégués, ce qui revient à aplanir le modèle et à rendre la fonctionnalité de fournisseur délégué disponible sur un seul niveau. Pour permettre la transition vers le nouveau modèle et la gestion des abonnements, vous pouvez maintenant déplacer les abonnements utilisateur entre des abonnements Fournisseur délégué nouveaux ou existants qui appartiennent au même locataire d’annuaire. Les abonnements utilisateur appartenant à l’abonnement Fournisseur par défaut peuvent également être déplacés vers les abonnements Fournisseur délégué dans le même locataire d’annuaire. Pour plus d’informations, consultez Déléguer des offres dans Azure Stack.

Amélioration du temps de création de machine virtuelle pour les machines virtuelles créées avec des images que vous téléchargez à partir de la Place de marché Azure.

Améliorations de facilité d’utilisation d’Azure Stack Capacity Planner. Azure Stack Capacity Planner offre désormais une expérience simplifiée pour la saisie de cache S2D et de capacité S2D lors de la définition des références (SKU) de solution. La limite de 1000 machines virtuelles a été supprimée.

Problèmes résolus

Différentes améliorations ont été apportées au processus de mise à jour afin de le rendre plus fiable. Des correctifs ont également été apportés à l’infrastructure sous-jacente afin de réduire le risque d’interruption pour les charges de travail pendant la mise à jour.

Nous avons corrigé un problème qui empêchait l’application d’une limite de quota modifiée aux abonnements existants. Désormais, lorsque vous augmentez la limite de quota d’une ressource réseau faisant partie d’une offre et d’un plan associés à un abonnement d’utilisateur, la nouvelle limite s’applique aux abonnements préexistants, ainsi qu’aux nouveaux abonnements.

Il est désormais possible d’interroger correctement les journaux d’activité des systèmes déployés dans un fuseau horaire UTC+N.

La vérification préalable des paramètres de configuration de la sauvegarde (chemin, nom d’utilisateur, mot de passe, clé de chiffrement) ne définit plus de paramètres incorrects pour la configuration de la sauvegarde. (Les paramètres incorrects étaient définis auparavant dans la sauvegarde, et celle-ci échouait lors de son déclenchement.)

La liste de sauvegarde s’actualise désormais quand vous supprimez manuellement la sauvegarde du partage externe.

La mise à jour de cette version ne réinitialise plus le propriétaire par défaut de l’abonnement du fournisseur par défaut à l’utilisateur CloudAdmin intégré en cas de déploiement avec AD FS.

Quand vous configurez l’intégration du centre de données, vous n’accédez plus au fichier de métadonnées AD FS à partir d’un partage de fichiers Azure. Pour plus d’informations, consultez la rubrique Configuration de l’intégration AD FS en fournissant un fichier de métadonnées de fédération.

Nous avons corrigé un problème qui empêchait les utilisateurs d’attribuer une adresse IP publique existante ayant déjà été attribuée à une interface réseau ou à un équilibreur de charge à une nouvelle interface réseau ou à un nouvel équilibreur de charge.

Quand vous sélectionnez Vue d’ensemble pour un compte de stockage dans le portail d’administration ou utilisateur, le volet Éléments principaux affiche désormais correctement toutes les informations attendues.

Quand vous sélectionnez Balises pour un compte de stockage dans le portail d’administration ou utilisateur, les informations sont désormais affichées correctement.

Cette version d’Azure Stack corrige le problème qui empêchait l’application des mises à jour de pilote à partir de packages d’extension OEM.

Nous avons résolu un problème qui vous empêchait de supprimer des machines virtuelles du panneau de calcul quand la création de la machine virtuelle échouait.

L’alerte de faible capacité mémoire n’apparaît plus incorrectement.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Failles et menaces courantes

Azure Stack utilise des installations Server Core de Windows Server 2016 pour héberger l’infrastructure clé. Cette version installe les mises à jour suivantes de Windows Server 2016 sur les serveurs d’infrastructure pour Azure Stack :

Pour plus d’informations sur ces vulnérabilités, cliquez sur les liens précédents ou consultez les articles de la Base de connaissances Microsoft 4338814 et 4345418.

Avant de commencer

Prérequis

Installez la mise à jour 1805 d’Azure Stack avant d’appliquer la mise à jour 1807. Il n’existe pas de mise à jour 1806.
Installez la dernière mise à jour ou le dernier correctif logiciel disponibles pour la version 1805.
Avant de démarrer l’installation de cette mise à jour, exécutez Test-AzureStack avec les paramètres suivants pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés, y compris tous les avertissements et les échecs. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une intervention.
```
Test-AzureStack -Include AzsControlPlane, AzsDefenderSummary, AzsHostingInfraSummary, AzsHostingInfraUtilization, AzsInfraCapacity, AzsInfraRoleSummary, AzsPortalAPISummary, AzsSFRoleSummary, AzsStampBMCSummary
```

Problèmes connus avec le processus de mise à jour

Pendant l’installation de cette mise à jour, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles se fermeront automatiquement une fois l’installation de la mise à jour terminée.

Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).

Dans certaines circonstances quand une mise à jour nécessite une attention particulière, l’alerte correspondante peut ne pas être générée. L’état précis apparaît quand même dans le portail et n’est pas affecté.

Étapes après la mise à jour

KB 4464231 - Correctif Azure Stack 1.1807.1.78

Après l’installation de cette mise à jour, vous observerez une amélioration des informations d’état en cas d’échec d’une installation de mise à jour. Par exemple, les informations sur les échecs d’installations de mises à jour antérieures ont été modifiées pour refléter les deux nouvelles catégories d’état (STATE). Les nouvelles catégories STATE sont PreparationFailed et InstallationFailed.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

La documentation technique Azure Stack s’applique à la dernière version. En raison des changements apportés au portail entre les versions, ce que vous voyez dans les portails Azure Stack peut différer du contenu de la documentation.
L’option pour ouvrir une nouvelle demande de support à partir de la liste déroulante dans le portail d’administration n’est pas disponible. À la place, pour les systèmes intégrés Azure Stack, utilisez le lien suivant : https://aka.ms/newsupportrequest.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Quand vous installez un nouvel environnement Azure Stack qui exécute cette version, l’alerte Activation requise peut ne pas s’afficher. L’activation est nécessaire avant que vous puissiez utiliser la syndication de Place de marché.

Les deux types d’abonnements d’administration qui ont été introduits avec la version 1804 ne doivent pas être utilisés. Les types d’abonnements sont Metering (Compteur) et Consumption (Consommation). Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

Il se peut que vous ne puissiez pas utiliser la barre de défilement horizontale au bas du portail d’administration et du portail utilisateur. Si vous ne pouvez pas accéder à la barre de défilement horizontale, utilisez les barres de navigation pour accéder à un panneau précédent dans le portail, en sélectionnant le nom du panneau que vous souhaitez afficher dans la liste des barres de navigation en haut à gauche du portail.

Il se peut qu’il ne soit pas possible d’afficher les ressources de calcul ou de stockage sur le portail d’administration. Ce problème est dû au fait qu’une erreur s’est produite pendant l’installation de la mise à jour, et que celle-ci a été, à tort, signalée comme réussie. Si ce problème se produit, contactez les services de support technique Microsoft pour obtenir de l’aide.

Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, sélectionnez l’icône d’engrenage dans l’angle supérieur droit du portail, puis choisissez Restaurer les paramètres par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Les deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement au bout d’un moment.

Vous pouvez voir une alerte pour le composant Stockage avec les informations suivantes :
- NOM : Erreur de communication interne du service de stockage
- GRAVITÉ : Critique
- COMPOSANT : Stockage
- DESCRIPTION : Une erreur de communication interne du service de stockage s’est produite lors de l’envoi des requêtes aux nœuds suivants.
  
  L’alerte peut être ignorée sans risque, mais vous devez la fermer manuellement.

En tant qu’opérateur d’Azure Stack, si vous recevez une alerte de mémoire insuffisante et que les machines virtuelles de locataire ne parviennent pas à se déployer à cause d’une erreur de création de machine virtuelle de structure, il est possible que l’horodatage d’Azure Stack soit à court de mémoire. Utilisez le Capacity Planner Azure Stack pour mieux comprendre la capacité disponible pour vos charges de travail.

Compute

En utilisant les applets de commande PowerShell Start-AzsScaleUnitNode ou Stop-AzsScaleunitNode pour gérer les unités d’échelle, il est possible que la première tentative de démarrage ou d’arrêt de l’unité d’échelle échoue. Si la cmdlet échoue une première fois, exécutez-la une seconde fois. La deuxième exécution doit permettre de terminer l’opération.

Quand vous sélectionnez une taille de machine virtuelle pour un déploiement de machine virtuelle, certaines tailles de machine virtuelle de série F ne sont pas visibles dans le sélecteur de taille lorsque vous créez une machine virtuelle. Les tailles de machine virtuelle suivantes n’apparaissent pas dans le sélecteur : F8s_v2, F16s_v2, F32s_v2 et F64s_v2.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes pour déployer une machine virtuelle. Dans chaque méthode, vous devez spécifier la taille de machine virtuelle que vous voulez utiliser.
- Modèle Azure Resource Manager : lorsque vous utilisez un modèle, définissez la valeur vmSize dans le modèle pour qu’elle soit égale à la taille de machine virtuelle que vous voulez utiliser. Par exemple, l’entrée suivante permet de déployer une machine virtuelle qui utilise la taille F32s_v2 :
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI : Vous pouvez utiliser la commande az vm create et spécifiez la taille de machine virtuelle comme paramètre, identique à --size "Standard_F32s_v2".
- PowerShell : avec PowerShell, vous pouvez utiliser New-AzureRMVMConfig avec le paramètre qui spécifie la taille de machine virtuelle, identique à -VMSize "Standard_F32s_v2".

Les paramètres de mise à l’échelle des groupes de machines virtuelles identiques ne sont pas disponibles dans le portail. Pour résoudre ce problème, vous pouvez utiliser Azure PowerShell. En raison des différences de version de PowerShell, vous devez utiliser le paramètre -Name au lieu du paramètre -VMScaleSetName.

Lorsque vous créez un groupe à haute disponibilité dans le portail en accédant à Nouveau>Compute>Groupe à haute disponibilité, vous pouvez uniquement créer un groupe à haute disponibilité avec un domaine d’erreur et un domaine de mise à jour de 1. Pour contourner ce problème, lors de la création d’une nouvelle machine virtuelle, créez le groupe à haute disponibilité à l’aide de PowerShell, CLI, ou depuis le portail.

Lorsque vous créez des machines virtuelles sur le portail utilisateur Azure Stack, le portail affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de la série DS. Les machines virtuelles de série DS peuvent prendre en charge autant de disques de données que la configuration Azure.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Quand vous inscrivez le fournisseur de ressources Microsoft.Insight dans les paramètres d’abonnement, puis créez une machine virtuelle Windows en ayant activé les diagnostics du système d’exploitation invité, la page de vue d’ensemble de la machine virtuelle n’affiche pas les données de métriques.

Pour trouver les données de métriques, comme le graphique de pourcentage d’UC, accédez au panneau Métriques et affichez toutes les métriques d’invité de machine virtuelle Windows prises en charge.

Mise en réseau

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.

Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

La conservation des adresses IP publiques déployées à l’aide de la méthode d’allocation dynamique n’est pas garantie après l’émission d’une commande Arrêter/Libérer.

Durant la rotation des secrets Azure Stack, une période de deux à cinq minutes s’écoule pendant laquelle les adresses IP publiques sont inaccessibles.

Dans les cas où le locataire accède à ses machines virtuelles à l’aide d’un tunnel VPN S2S, il peut rencontrer un scénario où les tentatives de connexion échouent si le sous-réseau local a été ajouté à la passerelle de réseau local après la création de la passerelle.

SQL et MySQL

Les caractères spéciaux, notamment les espaces et les points, ne sont pas pris en charge dans les noms de Famille lors de la création d’une référence SKU pour les fournisseurs de ressources SQL et MySQL.

Seul le fournisseur de ressources est pris en charge pour créer des éléments sur des serveurs qui hébergent SQL ou MySQL. Les éléments créés sur un serveur hôte qui ne sont pas créés par le fournisseur de ressources peuvent entraîner un état qui ne correspond pas.

Remarque

Après la mise à jour vers cette version d’Azure Stack, vous pouvez continuer à utiliser les fournisseurs de ressources SQL et MySQL que vous avez déjà déployés. Nous vous recommandons de mettre à jour SQL et MySQL lorsqu’une nouvelle version est disponible. Comme Azure Stack, appliquez de façon séquentielle les mises à jour aux fournisseurs de ressources SQL et MySQL. Par exemple, si vous utilisez la version 1804, commencez par appliquer la version 1805 avant de passer à la version 1807.

L’installation de cette mise à jour n’affecte pas l’utilisation actuelle des fournisseurs de ressources SQL ou MySQL par vos utilisateurs. Quelle que soit la version des fournisseurs de ressources que vous utilisez, vos données utilisateur dans leurs bases de données restent intactes et accessibles.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.

Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

Le déploiement d’App Service n’est possible à l’heure actuelle que sur l’abonnement du fournisseur par défaut.

Utilisation

Les données d’utilisation des adresses IP publiques indiquent une même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour Azure Stack 1807 à partir de cet emplacement.

Étapes suivantes

Pour passer en revue la stratégie de maintenance pour les systèmes intégrés Azure Stack et pour connaître la marche à suivre afin de conserver votre système dans un état de prise en charge, consultez Stratégie de maintenance Azure Stack.
Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1805

S’applique à : systèmes intégrés Azure Stack

Cet article décrit les améliorations et correctifs contenus dans le package de mise à jour 1805, les problèmes connus pour cette version, ainsi que l’emplacement de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1805 d’Azure Stack est 1.1805.1.47.

Conseil

En fonction des commentaires des clients, il existe une mise à jour du schéma de la version en cours d’utilisation pour Microsoft Azure Stack. À compter de cette mise à jour, 1805, le nouveau schéma représente mieux la version cloud actuelle.

Le schéma de version est à présent Version.YearYearMonthMonth.MinorVersion.BuildNumber où le deuxième et le troisième ensemble indiquent la version et la publication. Par exemple, 1805.1 représente la version finalisée de 1805.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations suivantes pour Azure Stack.

Azure Stack inclut désormais un client Syslog en tant que fonctionnalité préliminaire. Ce client permet le transfert des journaux d’activité d’audit et de sécurité liés à l’infrastructure d’Azure Stack vers un serveur Syslog ou un logiciel SIEM externes à Azure Stack. Actuellement, le client Syslog ne prend en charge que les connexions UDP non authentifiées via le port par défaut 514. La charge utile de chaque message Syslog est formatée en CEF (Common Event Format).

Pour configurer le client Syslog, utilisez la cmdlet Set-SyslogServer exposée dans le point de terminaison privilégié.

Avec cette préversion, vous pouvez voir les trois alertes suivantes. Présentées par Azure Stack, ces alertes incluent des descriptions et des conseils de correction.
- TITRE : Intégrité du code désactivée
- TITRE : Intégrité du code en mode audit
- TITRE : Compte d’utilisateur créé
Tant que cette fonctionnalité est en préversion, vous ne devez pas l’utiliser dans votre environnement de production.

Problèmes résolus

Nous avons résolu le problème qui bloquait l’ouverture d’une nouvelle requête de support dans la liste déroulante depuis le portail d’administration. Cette option fonctionne désormais normalement.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Avant de commencer

Prérequis

Installez la mise à jour 1804 d’Azure Stack avant d’appliquer la mise à jour 1805 d’Azure Stack.
Installez la dernière mise à jour ou le dernier correctif logiciel disponibles pour la version 1804.
Avant de commencer l’installation de la mise à jour 1805, exécutez Test-AzureStack pour valider l’état de votre Azure Stack et résoudre les éventuels problèmes opérationnels détectés. Examinez aussi les alertes actives et résolvez toutes celles qui nécessitent une intervention.

Problèmes connus avec le processus de mise à jour

Pendant l’installation de la mise à jour 1805, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles se fermeront automatiquement une fois la mise à jour 1805 terminée.

Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).

Étapes après la mise à jour

Après l’installation de la version 1805, installez les correctifs logiciels applicables. Pour plus d’informations, consultez les articles suivants de la base de connaissances, ainsi que notre stratégie de maintenance.

KB 4344102 – Correctif logiciel Azure Stack 1.1805.7.57.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus qui apparaissent après l’installation de cette build.

Portail

La documentation technique Azure Stack s’applique à la dernière version. En raison des changements apportés au portail entre les versions, ce que vous voyez dans les portails Azure Stack peut différer du contenu de la documentation.

Les plans ajoutés à un abonnement utilisateur comme plan d’extension ne peuvent pas être supprimés, même quand vous supprimez le plan de l’abonnement utilisateur. Le plan est conservé jusqu’à ce que les abonnements qui référencent le plan d’extension soient aussi supprimés.

Vous ne pouvez pas appliquer les mises à jour de pilote à l’aide d’un package d’extension OEM avec cette version d’Azure Stack. Il n’existe aucune solution de contournement pour ce problème.

Lorsque vous sélectionnez Vue d’ensemble pour un compte de stockage sur le portail d’administration ou utilisateur, les informations du volet Éléments principaux ne s’affichent pas. Le volet Éléments principaux affiche des informations sur le compte comme son groupe de ressources, son emplacement et son ID d’abonnement. D’autres options de la vue d’ensemble sont accessibles, par exemple Services et Surveillance, ainsi que des options permettant d’Ouvrir dans Explorer ou de Supprimer le compte de stockage.

Pour afficher les informations non disponibles, utilisez la cmdlet PowerShell Get-azureRMstorageaccount.

Lorsque vous sélectionnez Balises pour un compte de stockage sur le portail d’administration ou utilisateur, les informations ne se chargent pas.

Pour afficher les informations non disponibles, utilisez la cmdlet PowerShell Get-AzureRmTag.

Lorsque vous utilisez AD FS pour votre système d’identité Azure Stack et effectuez la mise à jour vers cette version d’Azure Stack, le propriétaire par défaut de l’abonnement Fournisseur par défaut redevient l’utilisateur CloudAdmin intégré.
Solution de contournement : pour résoudre ce problème après avoir installé cette mise à jour, utilisez l’étape 3 de la procédure Déclencher l’automation pour configurer un fournisseur de revendications de confiance dans Azure Stack afin de réinitialiser le propriétaire de l’abonnement Fournisseur par défaut.

Certains types d’abonnement d’administration ne sont pas disponibles. Lorsque vous mettez à niveau Azure Stack vers cette version, les deux types d’abonnements qui ont été introduits avec la version 1804 ne sont pas visibles dans la console. Ceci est normal. Les types d’abonnement indisponibles sont Abonnement de contrôle, et Abonnement de consommation. Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

Il se peut que vous ne puissiez pas utiliser la barre de défilement horizontale au bas du portail d’administration et du portail utilisateur. Si vous ne pouvez pas accéder à la barre de défilement horizontale, utilisez les barres de navigation pour accéder à un panneau précédent dans le portail, en sélectionnant le nom du panneau que vous souhaitez afficher dans la liste des barres de navigation en haut à gauche du portail.

Il se peut qu’il ne soit pas possible d’afficher les ressources de calcul ou de stockage sur le portail d’administration. Ce problème est dû au fait qu’une erreur s’est produite pendant l’installation de la mise à jour, et que celle-ci a été, à tort, signalée comme réussie. Si ce problème se produit, contactez les services de support technique Microsoft pour obtenir de l’aide.

Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, sélectionnez l’icône d’engrenage dans l’angle supérieur droit du portail, puis choisissez Restaurer les paramètres par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Les deux alertes 1 et 2 peuvent être ignorées en toute sécurité. Elles se ferment automatiquement au bout d’un moment.

Vous pouvez également voir l’alerte suivante pour Capacité. Pour cette alerte, le pourcentage de mémoire disponible identifiée dans la description peut varier :

Alerte 3 :
- NOM : Capacité de mémoire faible
- GRAVITÉ : Critique
- COMPOSANT : Capacité
- DESCRIPTION : La région a consommé plus de 80 % de la mémoire disponible. La création de machines virtuelles avec de grandes quantités de mémoire peut échouer.
Dans cette version d’Azure Stack, cette alerte peut se déclencher de façon incorrecte. Si les machines virtuelles de locataire continuent le déploiement avec succès, vous pouvez ignorer cette alerte en toute sécurité.

L’alerte 3 n’est pas automatiquement fermée. Si vous fermez cette alerte, Azure Stack crée la même alerte dans les 15 minutes qui suivent.

En tant qu’opérateur d’Azure Stack, si vous recevez une alerte d’insuffisance de mémoire et que les machines virtuelles de locataire ne parviennent pas à se déployer à cause d’une erreur de création de machine virtuelle Fabric, il est possible que l’horodatage d’Azure Stack soit à court de mémoire disponible. Utilisez le Capacity Planner Azure Stack pour mieux comprendre la capacité disponible pour vos charges de travail.

Compute

Quand vous sélectionnez une taille de machine virtuelle pour un déploiement de machine virtuelle, certaines tailles de machine virtuelle de série F ne sont pas visibles dans le sélecteur de taille lorsque vous créez une machine virtuelle. Les tailles de machine virtuelle suivantes n’apparaissent pas dans le sélecteur : F8s_v2, F16s_v2, F32s_v2 et F64s_v2.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes pour déployer une machine virtuelle. Dans chaque méthode, vous devez spécifier la taille de machine virtuelle que vous voulez utiliser.
- Modèle Azure Resource Manager : lorsque vous utilisez un modèle, définissez la valeur vmSize dans le modèle pour qu’elle soit égale à la taille de machine virtuelle que vous voulez utiliser. Par exemple, l’entrée suivante permet de déployer une machine virtuelle qui utilise la taille F32s_v2 :
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI : Vous pouvez utiliser la commande az vm create et spécifiez la taille de machine virtuelle comme paramètre, identique à --size "Standard_F32s_v2".
- PowerShell : avec PowerShell, vous pouvez utiliser New-AzureRMVMConfig avec le paramètre qui spécifie la taille de machine virtuelle, identique à -VMSize "Standard_F32s_v2".

Les paramètres de mise à l’échelle des groupes de machines virtuelles identiques ne sont pas disponibles dans le portail. Pour résoudre ce problème, vous pouvez utiliser Azure PowerShell. En raison des différences de version de PowerShell, vous devez utiliser le paramètre -Name au lieu du paramètre -VMScaleSetName.

Lorsque vous créez un groupe à haute disponibilité dans le portail en accédant à Nouveau>Compute>Groupe à haute disponibilité, vous pouvez uniquement créer un groupe à haute disponibilité avec un domaine d’erreur et un domaine de mise à jour de 1. Pour contourner ce problème, lors de la création d’une nouvelle machine virtuelle, créez le groupe à haute disponibilité à l’aide de PowerShell, CLI, ou depuis le portail.

Lorsque vous créez des machines virtuelles sur le portail utilisateur Azure Stack, le portail affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de la série DS. Les machines virtuelles de série DS peuvent prendre en charge autant de disques de données que la configuration Azure.

Lorsqu’une image de machine virtuelle ne peut pas être créée, un élément ayant échoué que vous ne pouvez pas supprimer peut être ajouté au panneau Compute des images de machine virtuelle.

Pour contourner ce problème, créez une image de machine virtuelle avec un disque dur virtuel factice qui peut être créé via Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Ce processus doit résoudre le problème qui empêche la suppression de l’élément ayant échoué. Ensuite, 15 minutes après avoir créé l’image factice, vous pouvez correctement la supprimer.

Vous pouvez alors essayer de retélécharger l’image de machine virtuelle ayant précédemment échoué.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Mise en réseau

Vous ne pouvez pas créer d’itinéraires définis par l’utilisateur, que ce soit sur le portail d’administration ou le portail utilisateur. Pour résoudre ce problème, utilisez Azure PowerShell.

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Une fois une machine virtuelle créée et associée à une adresse IP publique, vous ne pouvez pas dissocier cette machine virtuelle de cette adresse IP. La dissociation semble fonctionner, mais l’adresse IP publique qui a été assignée précédemment reste associée à la machine virtuelle d’origine.

Actuellement, vous devez utiliser uniquement les nouvelles adresses IP publiques pour les nouvelles machines virtuelles que vous créez.

Ce comportement se produit même si vous réaffectez l’adresse IP à une nouvelle machine virtuelle (ce qui est communément appelé un échange d’adresses IP virtuelles). Toutes les futures tentatives de connexion au moyen de cette adresse IP aboutissent à une connexion à la machine virtuelle originelle et non à la nouvelle.

Si vous définissez une limite de quota pour une ressource réseau qui fait partie d’une offre et d’un plan associés à un abonnement de locataire, la nouvelle limite n’est pas appliquée à cet abonnement. Toutefois, la nouvelle limite s’applique aux nouveaux abonnements créés après l’augmentation du quota.

Pour contourner ce problème, utilisez un plan d’extension pour augmenter un quota réseau quand le plan est déjà associé à un abonnement. Pour plus d’informations, découvrez comment rendre un plan d’extension disponible.

Vous ne pouvez pas supprimer un abonnement auquel sont associées des ressources de la zone DNS ou de la table de routage. Pour supprimer l’abonnement, vous devez d’abord supprimer les ressources de la zone DNS ou de la table de routage de l’abonnement de locataire.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.

Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

Azure Stack ne prend pas en charge l’ajout d’interfaces réseau supplémentaires sur une instance de machine virtuelle une fois que la machine virtuelle est déployée. Si la machine virtuelle nécessite plusieurs interfaces réseau, elles doivent être définies au moment du déploiement.

Vous ne pouvez pas utiliser le portail d’administration pour mettre à jour les règles d’un groupe de sécurité réseau.

Solution de contournement pour App Service : si vous avez besoin d’établir la connexion d’un bureau à distance à des instances de contrôleur, vous modifiez les règles de sécurité dans les groupes de sécurité réseau avec PowerShell. Voici des exemples montrant comment autoriser la configuration, puis la restaurer sur refuser :

Autoriser :

Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Refuser :


Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL et MySQL

Seul le fournisseur de ressources est pris en charge pour créer des éléments sur des serveurs qui hébergent SQL ou MySQL. Les éléments créés sur un serveur hôte qui ne sont pas créés par le fournisseur de ressources peuvent entraîner un état qui ne correspond pas.

Les caractères spéciaux, y compris les espaces et les points, ne sont pas pris en charge dans les noms Famille et Niveau lors de la création d’une référence SKU pour les fournisseurs de ressources SQL et MySQL.

Remarque

Après la mise à jour vers Azure Stack 1805, vous pouvez continuer à utiliser les fournisseurs de ressources SQL et MySQL que vous avez déployés précédemment. Nous vous recommandons de mettre à jour SQL et MySQL lorsqu’une nouvelle version est disponible. Comme Azure Stack, appliquez de façon séquentielle les mises à jour aux fournisseurs de ressources SQL et MySQL. Par exemple, si vous utilisez la version 1803, commencez par appliquer la version 1804, avant de mettre à jour vers la 1805.

L’installation de la mise à jour 1805 n’affecte pas l’utilisation actuelle des fournisseurs de ressources SQL ou MySQL par vos utilisateurs. Quelle que soit la version des fournisseurs de ressources que vous utilisez, vos données utilisateur dans leurs bases de données restent intactes et accessibles.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.

Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

Le déploiement d’App Service n’est possible à l’heure actuelle que sur l’abonnement du fournisseur par défaut.

Utilisation

Les données d’utilisation des adresses IP publiques indiquent une même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour 1805 d’Azure Stack à partir de cet emplacement.

Voir aussi

Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1804

S’applique à : systèmes intégrés Azure Stack

Cet article décrit les améliorations et correctifs contenus dans le package de mise à jour 1804, les problèmes connus pour cette publication, ainsi que l’emplacement de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de la mise à jour 1804 d’Azure Stack est 20180513.1.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations suivantes pour Azure Stack.

Prise en charge par Visual Studio des déploiements Azure Stack déconnectés avec AD FS. Visual Studio permet maintenant d’ajouter des abonnements et de s’authentifier avec des identifiants d’utilisateur fédéré AD FS.

Utilisation de machines virtuelles des séries Av2 et F. Azure Stack peut maintenant utiliser des machines virtuelles de la taille des séries Av2 et F. Pour plus d’informations, voir Tailles de machines virtuelles prises en charge dans Azure Stack.

Nouveaux abonnements d’administration. Avec 1804, deux nouveaux types d’abonnement sont disponibles dans le portail. Ces nouveaux types d’abonnement viennent s’ajouter à l’abonnement Fournisseur par défaut et sont visibles dans les nouvelles installations d’Azure Stack depuis la version 1804. N’utilisez pas ces nouveaux types d’abonnement avec cette version d’Azure Stack. Nous annoncerons quand ces types d’abonnement pourront être utilisés dans une mise à jour ultérieure.

Si vous mettez à jour Azure Stack vers la version 1804, les deux nouveaux types d’abonnement ne sont pas visibles. Toutefois, les nouveaux déploiements de systèmes intégrés Azure Stack et les installations du Kit de développement Azure Stack versions 1804 ou ultérieures ont accès aux trois types d’abonnement.

Ces nouveaux types d’abonnement s’inscrivent dans un changement plus large destiné à sécuriser l’abonnement Fournisseur par défaut et à faciliter le déploiement de ressources partagées telles que les serveurs d’hébergement SQL. À mesure que nous étofferons ce changement au travers de mises à jour d’Azure Stack, les ressources déployées sous ces nouveaux types d’abonnement pourront être perdues.

Les trois types d’abonnement maintenant visibles sont les suivants :
- Abonnement Fournisseur par défaut : continuez à utiliser ce type d’abonnement.
- Abonnement À l’usage : n’utilisez pas ce type d’abonnement.
- Abonnement Consommation : n’utilisez pas ce type d’abonnement

Problèmes résolus

Dans le portail d’administration, vous n’avez plus besoin d’actualiser la vignette Update avant d’afficher des informations.

Vous pouvez désormais utiliser le portail d’administration pour modifier les métriques de stockage pour le service Blob, le service Table et le service File d’attente.

Sous Mise en réseau, lorsque vous cliquez sur Connexion pour configurer une connexion VPN, le site à site (IPsec) est désormais la seule option disponible.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Autres versions synchronisées avec cette mise à jour

Les versions suivantes sont maintenant disponibles, mais ne nécessitent pas la mise à jour 1804 d’Azure Stack.

Mise à jour avec le Pack d’analyse System Center Operations Manager de Microsoft Azure Stack. Une nouvelle version (1.0.3.0) du Pack d’analyse System Center Operations Manager de Microsoft Azure Stack est disponible au téléchargement. Avec cette version, vous pouvez utiliser des principaux de service quand vous ajoutez un déploiement Azure Stack connecté. Cette version propose également une expérience de gestion des mises à jour qui vous permet d’effectuer une action de correction directement à partir d’Operations Manager. Il existe aussi des nouveaux tableaux de bord qui affichent les fournisseurs de ressources, les unités d’échelle et les nœuds d’unités d’échelle.
Nouvelle version 1.3.0 d’Azure Stack PowerShell pour les administrateurs. Azure Stack PowerShell version 1.3.0 est désormais disponible pour l’installation. Cette version fournit des commandes pour tous les fournisseurs de ressources d’administrateur pour gérer Azure Stack. Avec cette version, une partie du contenu sera dépréciée dans le dépôt GitHub d’outils Azure Stack.

Pour obtenir les détails de l’installation, suivez les instructions ou le contenu d’aide du Module Azure Stack 1.3.0.
Informations de référence sur la version initiale de l’API REST Azure Stack. Les informations de référence sur l’API pour tous les fournisseurs de ressources d’administrateur Azure Stack sont maintenant publiées.

Avant de commencer

Prérequis

Installez la mise à jour 1803 d’Azure Stack avant d’appliquer la mise à jour 1804.
Installez la dernière mise à jour ou le dernier correctif logiciel disponibles pour la version 1803.

Problèmes connus avec le processus de mise à jour

Pendant l’installation de la mise à jour 1804, des alertes avec le titre Erreur - Le modèle de FaultType UserAccounts.New est manquant peuvent s’afficher. Vous pouvez en toute sécurité ignorer ces alertes. Elles se fermeront automatiquement une fois la mise à jour 1804 terminée.

Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).

Étapes après la mise à jour

Après l’installation de la version 1804, installez les correctifs logiciels applicables. Pour plus d’informations, consultez les articles suivants de la base de connaissances, ainsi que notre stratégie de maintenance.

KB 4344114 – Correctif logiciel Azure Stack 1.0.180527.15.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus après l’installation pour la build 20180513.1.

Portail

La documentation technique Azure Stack s’applique à la dernière version. En raison des changements apportés au portail entre les versions, ce que vous voyez dans les portails Azure Stack peut différer du contenu de la documentation.

Vous ne pouvez pas appliquer les mises à jour de pilote à l’aide d’un package d’extension OEM avec cette version d’Azure Stack. Il n’existe aucune solution de contournement pour ce problème.

Après avoir installé ou mis à jour cette version d’Azure Stack, il se peut que vous ne puissiez pas afficher les unités d’échelle Azure Stack dans le portail d’administration.
Solution de contournement : Utiliser PowerShell pour voir des informations sur les unités d’échelle. Pour plus d’informations, consultez le contenu d’aide du Module Azure Stack 1.3.0.

Lorsque vous utilisez AD FS pour votre système d’identité Azure Stack et effectuez la mise à jour vers cette version d’Azure Stack, le propriétaire par défaut de l’abonnement Fournisseur par défaut redevient l’utilisateur CloudAdmin intégré.
Solution de contournement : pour résoudre ce problème après avoir installé cette mise à jour, utilisez l’étape 3 de la procédure Déclencher l’automation pour configurer un fournisseur de revendications de confiance dans Azure Stack afin de réinitialiser le propriétaire de l’abonnement Fournisseur par défaut.

Certains types d’abonnement d’administration ne sont pas disponibles. Lorsque vous mettez à niveau Azure Stack vers cette version, les deux types d’abonnements qui ont été introduits avec la version 1804 ne sont pas visibles dans la console. Ceci est normal. Les types d’abonnement indisponibles sont Abonnement de contrôle, et Abonnement de consommation. Ces types d’abonnements sont visibles dans les nouveaux environnements Azure Stack depuis la version 1804, mais ils ne sont pas encore prêts à être utilisés. Vous devez continuer à utiliser le type d’abonnement Fournisseur par défaut.

La possibilité d’ouvrir une nouvelle demande de support dans la liste déroulante à partir du portail administrateur n’est pas disponible. Utilisez plutôt le lien suivant :
- Pour les systèmes Azure Stack intégrés, utilisez https://aka.ms/newsupportrequest.

Il se peut que vous ne puissiez pas utiliser la barre de défilement horizontale au bas du portail d’administration et du portail utilisateur. Si vous ne pouvez pas accéder à la barre de défilement horizontale, utilisez les barres de navigation pour accéder à un panneau précédent dans le portail, en sélectionnant le nom du panneau que vous souhaitez afficher dans la liste des barres de navigation en haut à gauche du portail.

Il se peut qu’il ne soit pas possible d’afficher les ressources de calcul ou de stockage sur le portail d’administration. Ce problème est dû au fait qu’une erreur s’est produite pendant l’installation de la mise à jour, et que celle-ci a été, à tort, signalée comme réussie. Si ce problème se produit, contactez les services de support technique Microsoft pour obtenir de l’aide.

Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, sélectionnez l’icône d’engrenage dans l’angle supérieur droit du portail, puis choisissez Restaurer les paramètres par défaut.

La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.

Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.

Dans le portail d’administration, vous pouvez voir une alerte critique pour le composant Microsoft.Update.Admin. Le nom de l’alerte, la description et la correction s’affichent tous comme suit :
- ERROR - Template for FaultType ResourceProviderTimeout is missing. (ERREUR - Absence du modèle de FaultType ResourceProviderTimeout.)
Cette alerte peut être ignorée en toute sécurité.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Ces deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement dans le temps.

Compute

Quand vous sélectionnez une taille de machine virtuelle pour un déploiement de machine virtuelle, certaines tailles de machine virtuelle de série F ne sont pas visibles dans le sélecteur de taille lorsque vous créez une machine virtuelle. Les tailles de machine virtuelle suivantes n’apparaissent pas dans le sélecteur : F8s_v2, F16s_v2, F32s_v2 et F64s_v2.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes pour déployer une machine virtuelle. Dans chaque méthode, vous devez spécifier la taille de machine virtuelle que vous voulez utiliser.
- Modèle Azure Resource Manager : quand vous utilisez un modèle, définissez la valeur vmSize dans le modèle pour qu’elle soit égale à la taille de machine virtuelle souhaitée. Par exemple, le code suivant permet de déployer une machine virtuelle qui utilise la taille F32s_v2 :
```
    "properties": {
    "hardwareProfile": {
            "vmSize": "Standard_F32s_v2"
    },
```
- Azure CLI : Vous pouvez utiliser la commande az vm create et spécifiez la taille de machine virtuelle comme paramètre, identique à --size "Standard_F32s_v2".
- PowerShell : avec PowerShell, vous pouvez utiliser New-AzureRMVMConfig avec le paramètre qui spécifie la taille de machine virtuelle, identique à -VMSize "Standard_F32s_v2".

Les paramètres de mise à l’échelle des groupes de machines virtuelles identiques ne sont pas disponibles dans le portail. Pour résoudre ce problème, vous pouvez utiliser Azure PowerShell. En raison des différences de version de PowerShell, vous devez utiliser le paramètre -Name au lieu du paramètre -VMScaleSetName.

Lorsque vous créez un groupe à haute disponibilité dans le portail en accédant à Nouveau>Compute>Groupe à haute disponibilité, vous pouvez uniquement créer un groupe à haute disponibilité avec un domaine d’erreur et un domaine de mise à jour de 1. Pour contourner ce problème, lors de la création d’une nouvelle machine virtuelle, créez le groupe à haute disponibilité à l’aide de PowerShell, CLI, ou depuis le portail.

Quand vous créez des machines virtuelles sur le portail utilisateur Azure Stack, ce dernier affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de série D. Toutes les machines virtuelles de série D prises en charge peuvent prendre en charge autant de disques de données que la configuration Azure.

Lorsqu’une image de machine virtuelle ne peut pas être créée, un élément ayant échoué que vous ne pouvez pas supprimer peut être ajouté au panneau Compute des images de machine virtuelle.

Pour contourner ce problème, créez une image de machine virtuelle avec un disque dur virtuel factice qui peut être créé via Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Ce processus doit résoudre le problème qui empêche la suppression de l’élément ayant échoué. Ensuite, 15 minutes après avoir créé l’image factice, vous pouvez correctement la supprimer.

Vous pouvez alors essayer de retélécharger l’image de machine virtuelle ayant précédemment échoué.

Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Mise en réseau

Sous Mise en réseau, si vous cliquez sur Créer une passerelle VPN pour configurer une connexion VPN, l’option Basé sur des stratégies s’affiche dans la liste des types de VPN. Ne sélectionnez pas cette option. Seule l’option Basé sur itinéraires est prise en charge dans Azure Stack.

Une fois une machine virtuelle créée et associée à une adresse IP publique, vous ne pouvez pas dissocier cette machine virtuelle de cette adresse IP. La dissociation semble fonctionner, mais l’adresse IP publique qui a été assignée précédemment reste associée à la machine virtuelle d’origine.

Actuellement, vous devez utiliser uniquement les nouvelles adresses IP publiques pour les nouvelles machines virtuelles que vous créez.

Ce comportement se produit même si vous réaffectez l’adresse IP à une nouvelle machine virtuelle (ce qui est communément appelé un échange d’adresses IP virtuelles). Toutes les futures tentatives de connexion au moyen de cette adresse IP aboutissent à une connexion à la machine virtuelle associée à l’origine et non à la nouvelle.

Si vous définissez une limite de quota pour une ressource réseau qui fait partie d’une offre et d’un plan associés à un abonnement de locataire, la nouvelle limite n’est pas appliquée à cet abonnement. Toutefois, la nouvelle limite s’applique aux nouveaux abonnements créés après l’augmentation du quota.

Pour contourner ce problème, utilisez un plan d’extension pour augmenter un quota réseau quand le plan est déjà associé à un abonnement. Pour plus d’informations, découvrez comment rendre un plan d’extension disponible.

Vous ne pouvez pas supprimer un abonnement auquel sont associées des ressources de la zone DNS ou de la table de routage. Pour supprimer l’abonnement, vous devez d’abord supprimer les ressources de la zone DNS ou de la table de routage de l’abonnement de locataire.

Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.

Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.

Azure Stack ne prend pas en charge l’ajout d’interfaces réseau supplémentaires sur une instance de machine virtuelle une fois que la machine virtuelle est déployée. Si la machine virtuelle nécessite plusieurs interfaces réseau, elles doivent être définies au moment du déploiement.

Vous ne pouvez pas utiliser le portail d’administration pour mettre à jour les règles d’un groupe de sécurité réseau.

Autoriser :

Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Refuser :


Connect-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL et MySQL

Seul le fournisseur de ressources est pris en charge pour créer des éléments sur des serveurs qui hébergent SQL ou MySQL. Les éléments créés sur un serveur hôte qui ne sont pas créés par le fournisseur de ressources peuvent entraîner un état qui ne correspond pas.

Les caractères spéciaux, y compris les espaces et les points, ne sont pas pris en charge dans les noms Famille et Niveau lors de la création d’une référence SKU pour les fournisseurs de ressources SQL et MySQL.

Remarque

Après avoir effectué la mise à jour vers Azure Stack 1804, vous pouvez continuer à utiliser les fournisseurs de ressources SQL et MySQL que vous avez déployés précédemment. Nous vous recommandons de mettre à jour SQL et MySQL lorsqu’une nouvelle version est disponible. Comme Azure Stack, appliquez de façon séquentielle les mises à jour aux fournisseurs de ressources SQL et MySQL. Par exemple, si vous utilisez la version 1802, commencez par appliquer la version 1803 avant de passer à la version 1804.

L’installation de la mise à jour 1804 n’affecte pas l’utilisation actuelle des fournisseurs de ressources SQL ou MySQL par vos utilisateurs. Quelle que soit la version des fournisseurs de ressources que vous utilisez, vos données utilisateur dans leurs bases de données restent intactes et accessibles.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.

Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

App Service peut uniquement être déployé sur l’abonnement Fournisseur par défaut pour l’instant. Dans une prochaine mise à jour, App Service se déploiera sur le nouvel abonnement À l’usage introduit dans Azure Stack 1804, et tous les déploiements existants seront également migrés vers ce nouvel abonnement.

Utilisation

Les données d’utilisation des adresses IP publiques indiquent une même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour 1804 d’Azure Stack à partir de cet emplacement.

Voir aussi

Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1803

S’applique à : systèmes intégrés Azure Stack

Cet article décrit les améliorations et correctifs contenus dans cette mise à jour 1803, les problèmes connus dans cette publication, et l’emplacement de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de mise à jour d’Azure Stack 1803 est 20180329.1.

Avant de commencer

Important

Ne tentez pas de créer des machines virtuelles pendant l’installation de cette mise à jour. Pour plus d’informations sur la gestion des mises à jour, consultez Manage updates in Azure Stack overview (Vue d’ensemble de la gestion des mises à jour dans Azure Stack).

Prérequis

Installez la mise à jour 1802 d’Azure Stack avant d’appliquer la mise à jour 1803.
Installez le correctif logiciel AzS 1.0.180312.1 - Build 20180222.2 avant d’appliquer la mise à jour 1803 d’Azure Stack. Ce correctif logiciel met à jour Windows Defender et est disponible lorsque vous téléchargez des mises à jour pour Azure Stack.

Pour installer le correctif logiciel, suivez les procédures normales pour l’installation des mises à jour d’Azure Stack. La mise à jour s’appelle Correctif logiciel AzS 1.0.180312.1 et comprend les fichiers suivants :
- PUPackageHotFix_20180222.2-1.exe
- PUPackageHotFix_20180222.2-1.bin
- Metadata.xml
Après avoir chargé ces fichiers dans un compte de stockage et un conteneur, exécutez la programmation d’installation à partir de la vignette Mise à jour du portail d’administration.

Contrairement aux mises à jour d’Azure Stack, l’installation de cette mise à jour ne modifie pas la version d’Azure Stack. Pour confirmer l’installation de cette mise à jour, affichez la liste des mises à jour installées.

Nouvelles fonctionnalités

Cette mise à jour inclut les améliorations et les correctifs suivants pour Azure Stack.

Mettre à jour les clés secrètes d’Azure Stack : comptes et certificats. Pour plus d’informations sur la gestion des clés secrètes, consultez Faire pivoter les clés secrètes dans Azure Stack.

Redirection automatique vers HTTPS si le protocole HTTP est utilisé pour accéder au portail d’administration ou au portail utilisateur. Cette amélioration a été effectuée à partir de commentaires UserVoice pour Azure Stack.

Accès à la Place de marché : il est maintenant possible d’ouvrir la Place de marché Azure Stack avec l’option + Nouveau à partir des portails administrateur et utilisateur, de la même façon que dans les portails Azure.

Azure Monitor : Azure Stack ajoute Azure Monitor au portail d’administration et au portail utilisateur. Il comprend de nouveaux explorateurs de mesures et de journaux d’activité. Le port 13012 doit être ouvert dans les configurations de pare-feu pour qu’Azure Monitor soit accessible à partir de réseaux externes. Pour plus d’informations sur les ports requis par Azure Stack, voir Intégration de centre de données Azure Stack – Publier des points de terminaison.

Également dans le cadre de cette modification, sous Plus de services, Journaux d’audits est désormais remplacé par Journaux d’activités. La fonctionnalité est désormais compatible avec le portail Azure.

Fichiers partiellement alloués : toute image ajoutée à Azure Stack ou par le biais de la syndication Marketplace est convertie en fichier partiellement alloué. Cette conversion n’est pas possible pour celles qui ont été ajoutées avant la version 1803 d’Azure Stack. Il faut alors utiliser la syndication Marketplace pour renvoyer ces images de façon à tirer parti de cette fonctionnalité.

Les fichiers partiellement alloués sont un format de fichier efficace utilisé pour réduire l’utilisation de l’espace de stockage et améliorer les E/S. Pour plus d’informations, consultez Fsutil sparse pour Windows Server.

Problèmes résolus

L’équilibrage de charge interne (ILB) gère désormais correctement les adresses MAC pour les machines virtuelles principales, ce qui entraîne la suppression des paquets sur le réseau principal lors de l’utilisation d’instances Linux sur le réseau principal. L’équilibrage de charge interne fonctionne bien avec des instances Windows sur le réseau principal.

Problème où les connexions VPN entre Azure Stack deviennent déconnectées en raison d’Azure Stack à l’aide de paramètres différents de la stratégie IKE qu’Azure. Les valeurs de SALifetime (heure) et de SALiftetime (octets) n’étaient pas compatibles avec Azure ; elles ont été modifiées dans la version 1803 pour correspondre aux paramètres Azure. La valeur de SALifetime (secondes) avant la version 1803 était de 14 400 ; elle devient 27 000 dans la version 1803. La valeur de SALifetime (octets) avant la version 1803 était de 819 200 ; elle devient 33 553 408 dans la version 1803.

Problème IP où les connexions VPN étaient précédemment visibles dans le portail ; toutefois, l’activation ou le basculement du transfert IP n’a aucun effet. La fonctionnalité est activée par défaut ; il n’est pas encore possible de modifier ce comportement. Ce contrôle a été supprimé du portail.

Azure Stack ne prend pas en charge les passerelle VPN basées sur des stratégies, même si l’option apparaît dans le portail. Cette option a été supprimée du portail.

Azure Stack empêche désormais le redimensionnement d’une machine virtuelle créée avec des disques dynamiques.

Les données d’utilisation des machines virtuelles sont désormais séparées à intervalles horaires. Ce comportement est cohérent avec Azure.

Le problème où, dans les portails d’administration et d’utilisateurs, le panneau Paramètres des sous-réseaux de réseaux virtuels ne parvient pas à se charger. Pour contourner le problème, utilisez PowerShell et l’applet de commande Get-AzureRmVirtualNetworkSubnetConfig afin de voir et de gérer ces informations.
Lorsque vous créez une machine virtuelle, le message Impossible d’afficher les tarifs ne s’affiche plus lors du choix d’une taille pour la machine virtuelle.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Modifications

La façon de changer l’état d’une offre nouvellement créée de privé à public ou à désactivé a été modifiée. Pour plus d’informations, consultez Créer une offre.

Problèmes connus avec le processus de mise à jour

Pendant l’installation de la mise à jour 1803, il peut y avoir un temps d’arrêt du service blob et des services internes qui utilisent le service blob. Certaines opérations de machine virtuelle sont concernées. Ce temps d’arrêt peut provoquer des échecs d’opérations de locataire ou des alertes de services qui ne parviennent pas à accéder aux données. Le problème se résout de lui-même une fois la mise à jour installée.

Étapes après la mise à jour

Après l’installation de la version 1803, installez les correctifs logiciels applicables. Pour plus d’informations, consultez les articles suivants de la base de connaissances, ainsi que notre stratégie de maintenance.
- KB 4344115 – Correctif logiciel Azure Stack 1.0.180427.15.
Après avoir installé cette mise à jour, vérifiez la configuration du pare-feu pour être sûr que les ports nécessaires sont ouverts. Par exemple, cette mise à jour comprend Azure Monitor, qui remplace les journaux d’audit par des journaux d’activité. Dans le cadre de cette modification, le port 13012 est désormais utilisé et doit également être ouvert.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus après l’installation pour la build 20180323.2.

Portail

Lorsque vous utilisez AD FS pour votre système d’identité Azure Stack et effectuez la mise à jour vers cette version d’Azure Stack, le propriétaire par défaut de l’abonnement Fournisseur par défaut redevient l’utilisateur CloudAdmin intégré.
Solution de contournement : pour résoudre ce problème après avoir installé cette mise à jour, utilisez l’étape 3 de la procédure Déclencher l’automation pour configurer un fournisseur de revendications de confiance dans Azure Stack afin de réinitialiser le propriétaire de l’abonnement Fournisseur par défaut.
La possibilité d’ouvrir une nouvelle demande de support dans la liste déroulante à partir du portail administrateur n’est pas disponible. À la place, utilisez le lien suivant :
- Pour les systèmes Azure Stack intégrés, utilisez https://aka.ms/newsupportrequest.

Dans le portail d’administration, il n’est pas possible de modifier les métriques de stockage pour le service Blob, le service Table ou le service File d’attente. Lorsque vous accédez au stockage et que vous sélectionnez la vignette du service Blob, de Table ou de File d’attente, un nouveau panneau qui affiche un graphique des métriques pour ce service s’ouvre. Si vous sélectionnez ensuite Modifier en haut de la vignette du graphique des métriques, le panneau Modifier le graphique s’ouvre, mais n’affiche pas les options pour modifier les métriques.
Il se peut qu’il ne soit pas possible d’afficher les ressources de calcul ou de stockage sur le portail d’administration. Ce problème est dû au fait qu’une erreur s’est produite pendant l’installation de la mise à jour, et que celle-ci a été, à tort, signalée comme réussie. Si ce problème se produit, contactez les services de support technique Microsoft pour obtenir de l’aide.
Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, sélectionnez l’icône d’engrenage dans l’angle supérieur droit du portail, puis choisissez Restaurer les paramètres par défaut.
La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.
Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.
Dans le tableau de bord du portail d’administration, la vignette Mise à jour ne parvient pas à afficher les informations sur les mises à jour. Pour résoudre ce problème, cliquez sur la vignette pour l’actualiser.
Dans le portail d’administration, vous pouvez voir une alerte critique pour le composant Microsoft.Update.Admin. Le nom de l’alerte, la description et la correction s’affichent tous comme suit :
- ERROR - Template for FaultType ResourceProviderTimeout is missing. (ERREUR - Absence du modèle de FaultType ResourceProviderTimeout.)
Cette alerte peut être ignorée en toute sécurité.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Ces deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement dans le temps.

Place de marché

Les utilisateurs ont la possibilité de parcourir entièrement le marketplace, et peuvent voir des éléments administratifs, tels que des plans et des offres, qui ne sont pas fonctionnels pour eux.

Compute

Les paramètres de mise à l’échelle des groupes de machines virtuelles identiques ne sont pas disponibles dans le portail. Pour résoudre ce problème, vous pouvez utiliser Azure PowerShell. En raison des différences de version de PowerShell, vous devez utiliser le paramètre -Name au lieu du paramètre -VMScaleSetName.
Lorsque vous créez un groupe à haute disponibilité dans le portail en accédant à Nouveau>Compute>Groupe à haute disponibilité, vous pouvez uniquement créer un groupe à haute disponibilité avec un domaine d’erreur et un domaine de mise à jour de 1. Pour contourner ce problème, lors de la création d’une nouvelle machine virtuelle, créez le groupe à haute disponibilité à l’aide de PowerShell, CLI, ou depuis le portail.
Quand vous créez des machines virtuelles sur le portail utilisateur Azure Stack, ce dernier affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de série D. Toutes les machines virtuelles de série D prises en charge peuvent prendre en charge autant de disques de données que la configuration Azure.
Lorsqu’une image de machine virtuelle ne peut pas être créée, un élément ayant échoué que vous ne pouvez pas supprimer peut être ajouté au panneau Compute des images de machine virtuelle.

Pour contourner ce problème, créez une image de machine virtuelle avec un disque dur virtuel factice qui peut être créé via Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Ce processus doit résoudre le problème qui empêche la suppression de l’élément ayant échoué. Ensuite, 15 minutes après avoir créé l’image factice, vous pouvez correctement la supprimer.

Vous pouvez alors essayer de retélécharger l’image de machine virtuelle ayant précédemment échoué.
Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Mise en réseau

Une fois une machine virtuelle créée et associée à une adresse IP publique, vous ne pouvez pas dissocier cette machine virtuelle de cette adresse IP. La dissociation semble fonctionner, mais l’adresse IP publique qui a été assignée précédemment reste associée à la machine virtuelle d’origine.

Actuellement, vous devez utiliser uniquement les nouvelles adresses IP publiques pour les nouvelles machines virtuelles que vous créez.

Ce comportement se produit même si vous réaffectez l’adresse IP à une nouvelle machine virtuelle (ce qui est communément appelé un échange d’adresses IP virtuelles). Toutes les futures tentatives de connexion au moyen de cette adresse IP aboutissent à une connexion à la machine virtuelle associée à l’origine et non à la nouvelle.
Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.
Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.
Azure Stack ne prend pas en charge l’ajout d’interfaces réseau supplémentaires sur une instance de machine virtuelle une fois que la machine virtuelle est déployée. Si la machine virtuelle nécessite plusieurs interfaces réseau, elles doivent être définies au moment du déploiement.

Vous ne pouvez pas utiliser le portail d’administration pour mettre à jour les règles d’un groupe de sécurité réseau.

Autoriser :

Add-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Refuser :


Add-AzureRmAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL et MySQL

Avant de continuer, consultez la remarque importante dans Avant de commencer vers le début de ces notes de publication.
Il faut parfois attendre une heure pour que les utilisateurs puissent créer des bases de données dans un nouveau déploiement SQL ou MySQL.
Seul le fournisseur de ressources est pris en charge pour créer des éléments sur des serveurs qui hébergent SQL ou MySQL. Les éléments créés sur un serveur hôte qui ne sont pas créés par le fournisseur de ressources peuvent entraîner un état qui ne correspond pas.

Les caractères spéciaux, notamment les espaces et les points, ne sont pas pris en charge dans les noms de Famille lors de la création d’une référence SKU pour les fournisseurs de ressources SQL et MySQL.

Remarque

Après la mise à jour vers Azure Stack 1803, vous pouvez continuer à utiliser les fournisseurs de ressources SQL et MySQL que vous avez déployés précédemment. Nous vous recommandons de mettre à jour SQL et MySQL lorsqu’une nouvelle version est disponible. Comme Azure Stack, appliquez de façon séquentielle les mises à jour aux fournisseurs de ressources SQL et MySQL. Par exemple, si vous utilisez la version 1711, commencez par appliquer la version 1712, puis la 1802, avant de mettre à jour vers la 1803.

L’installation de la mise à jour 1803 n’affecte pas l’utilisation actuelle des fournisseurs de ressources SQL ou MySQL par vos utilisateurs. Quelle que soit la version des fournisseurs de ressources que vous utilisez, vos données utilisateur dans leurs bases de données restent intactes et accessibles.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.
Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

Utilisation

Les données d’utilisation des adresses IP publiques indiquent une même valeur EventDateTime pour chaque enregistrement au lieu de l’horodatage TimeDate qui s’affiche lors de la création de chaque enregistrement. Pour le moment, vous ne pouvez pas utiliser ces données pour calculer de manière précise l’utilisation des adresses IP publiques.

Téléchargement des outils Azure Stack à partir de GitHub

Quand vous utilisez l’applet de commande PowerShell invoke-webrequest pour télécharger les outils Azure Stack à partir de GitHub, une erreur s’affiche :
- invoke-webrequest : La demande a été abandonnée : Impossible de créer un canal sécurisé SSL/TLS.
Cette erreur se produit en raison d’une désapprobation récente de la prise en charge GitHub des normes de chiffrement Tlsv1 et Tlsv1.1 (valeur par défaut pour PowerShell). Pour plus d’informations, consultez Avis de suppression des normes de chiffrement faible.

Pour résoudre ce problème, ajoutez [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 au début du script pour forcer la console PowerShell à utiliser TLSv1.2 lors du téléchargement à partir de dépôts GitHub.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour Azure Stack 1803 à partir de cet emplacement.

Voir aussi

Pour utiliser le Point de terminaison privilégié (PEP) afin de surveiller et de reprendre les mises à jour, consultez Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.
Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Notes de publication archivées 1802

S’applique à : systèmes intégrés Azure Stack

Cet article décrit les améliorations et correctifs contenus dans cette mise à jour 1802, les problèmes connus dans cette publication, et l’emplacement de téléchargement de la mise à jour. Les problèmes connus sont divisés en problèmes directement liés au processus de mise à jour et en problèmes propres à la build (après l’installation).

Important

Cette mise à jour est destinée uniquement aux systèmes intégrés d’Azure Stack. N’appliquez pas cette mise à jour au Kit de développement Azure Stack.

Référence de build

Le numéro de build de mise à jour d’Azure Stack 1802 est 20180302.1.

Avant de commencer

Important

Prérequis

Installez la mise à jour 1712 d’Azure Stack avant d’appliquer la mise à jour 1802.
Installez le correctif logiciel AzS 1.0.180312.1 - Build 20180222.2 avant d’appliquer la mise à jour 1802 d’Azure Stack. Ce correctif logiciel met à jour Windows Defender et est disponible lorsque vous téléchargez des mises à jour pour Azure Stack.

Pour installer le correctif logiciel, suivez les procédures normales pour l’installation des mises à jour d’Azure Stack. La mise à jour s’appelle Correctif logiciel AzS 1.0.180312.1 et comprend les fichiers suivants :
- PUPackageHotFix_20180222.2-1.exe
- PUPackageHotFix_20180222.2-1.bin
- Metadata.xml
Après avoir chargé ces fichiers dans un compte de stockage et un conteneur, exécutez la programmation d’installation à partir de la vignette Mise à jour du portail d’administration.

Contrairement aux mises à jour d’Azure Stack, l’installation de cette mise à jour ne modifie pas la version d’Azure Stack. Pour confirmer l’installation de cette mise à jour, affichez la liste des mises à jour installées.

Étapes après la mise à jour

Après l’installation de la version 1802, installez les correctifs logiciels applicables. Pour plus d’informations, consultez les articles suivants de la base de connaissances, ainsi que notre stratégie de maintenance.

Correctif Azure Stack 1.0.180302.4. KB 4131152 - Existing Virtual Machine Scale Sets may become unusable (Les groupes de machines virtuelles identiques existants peuvent devenir inutilisables)

Ce correctif résout également les problèmes détaillés dans KB 4103348 - Network Controller API service crashes when you try to install an Azure Stack update (Le service API du contrôleur réseau se bloque quand vous essayez d’installer une mise à jour Azure Stack).

Nouvelles fonctionnalités et correctifs

Cette mise à jour inclut les améliorations et les correctifs suivants pour Azure Stack.

La prise en charge est ajoutée pour les versions d’API de service de stockage Azure suivantes :
- 2017-04-17
- 2016-05-31
- 2015-12-11
- 2015-07-08
Pour plus d’informations, consultez Stockage Azure Stack : Différences et considérations.
Prise en charge des objets blob de blocs plus grands:
- La taille maximum de bloc autorisée passe de 4 Mo à 100 Mo.
- La taille maximum d’objet blob passe de 195 Go à 4,75 To.
Infrastructure backup s’affiche maintenant dans la vignette Fournisseurs de ressources, et des alertes de sauvegarde sont activées. Pour plus d’informations sur le service Infrastructure Backup, consultez Sauvegarde et récupération de données pour Azure Stack avec le service Infrastructure Backup.
Mettez à jour vers la cmdlet Test-AzureStack pour améliorer les diagnostics de stockage. Pour plus d’informations sur cette cmdlet, consultez Exécuter un test de validation pour Azure Stack.
Améliorations du contrôle d’accès en fonction du rôle : vous pouvez maintenant utiliser le contrôle d’accès en fonction du rôle pour déléguer des autorisations à des groupes d’utilisateurs universels lorsqu’Azure Stack est déployé avec AD FS. Pour en savoir plus sur le contrôle d’accès en fonction du rôle, consultez Gérer le contrôle d’accès en fonction du rôle.
La prise en charge est ajoutée pour plusieurs domaines d’erreur. Pour plus d’informations, consultez High availability for Azure Stack (Haute disponibilité pour Azure Stack).
Prise en charge des mises à niveau de la mémoire physique - Vous pouvez maintenant augmenter la capacité de mémoire du système Azure Stack intégré après le déploiement initial. Pour plus d’informations, consultez Gérer la capacité de mémoire physique pour Azure Stack.
Divers correctifs pour les performances, la stabilité, la sécurité et le système d’exploitation utilisé par Azure Stack.

Problèmes connus avec le processus de mise à jour

Il n’y a aucun problème connu pour l’installation de la mise à jour 1802.

Problèmes connus (après l’installation)

Les éléments suivants sont des problèmes connus après l’installation pour la build 20180302.1.

Portail

Lorsque vous utilisez AD FS pour votre système d’identité Azure Stack et effectuez la mise à jour vers cette version d’Azure Stack, le propriétaire par défaut de l’abonnement Fournisseur par défaut redevient l’utilisateur CloudAdmin intégré.
Solution de contournement : pour résoudre ce problème après avoir installé cette mise à jour, utilisez l’étape 3 de la procédure Déclencher l’automation pour configurer un fournisseur de revendications de confiance dans Azure Stack afin de réinitialiser le propriétaire de l’abonnement Fournisseur par défaut.
La possibilité d’ouvrir une nouvelle demande de support dans la liste déroulante à partir du portail administrateur n’est pas disponible. À la place, utilisez le lien suivant :
- Pour les systèmes Azure Stack intégrés, utilisez https://aka.ms/newsupportrequest.

Dans le portail d’administration, il n’est pas possible de modifier les métriques de stockage pour le service Blob, le service Table ou le service File d’attente. Lorsque vous accédez au stockage et que vous sélectionnez la vignette du service Blob, de Table ou de File d’attente, un nouveau panneau qui affiche un graphique des métriques pour ce service s’ouvre. Si vous sélectionnez ensuite Modifier en haut de la vignette du graphique des métriques, le panneau Modifier le graphique s’ouvre, mais n’affiche pas les options pour modifier les métriques.
Il se peut qu’il ne soit pas possible d’afficher les ressources de calcul ou de stockage sur le portail d’administration. Ce problème est dû au fait qu’une erreur s’est produite pendant l’installation de la mise à jour, et que celle-ci a été, à tort, signalée comme réussie. Si ce problème se produit, contactez les services de support technique Microsoft pour obtenir de l’aide.
Il se peut qu’un tableau de bord vide s’affiche sur le portail. Pour récupérer le tableau de bord, sélectionnez l’icône d’engrenage dans l’angle supérieur droit du portail, puis choisissez Restaurer les paramètres par défaut.
La suppression d’abonnements utilisateur aboutit à des ressources orphelines. Pour contourner ce problème, commencez pas supprimer des ressources d’utilisateurs ou la totalité du groupe de ressources, puis supprimez les abonnements utilisateur.
Vous ne pouvez pas afficher les autorisations définies pour votre abonnement à l’aide des portails Azure Stack. Pour contourner ce problème, utilisez PowerShell pour vérifier les autorisations.
Dans le tableau de bord du portail d’administration, la vignette Mise à jour ne parvient pas à afficher les informations sur les mises à jour. Pour résoudre ce problème, cliquez sur la vignette pour l’actualiser.
Dans le portail d’administration, vous pouvez voir une alerte critique pour le composant Microsoft.Update.Admin. Le nom de l’alerte, la description et la correction s’affichent tous comme suit :

ERROR - Template for FaultType ResourceProviderTimeout is missing. (ERREUR - Absence du modèle de FaultType ResourceProviderTimeout.)

Cette alerte peut être ignorée en toute sécurité.

Sur le portail d’administration et le portail utilisateur, le chargement du panneau Paramètres des sous-réseaux virtuels échoue. Pour contourner le problème, utilisez PowerShell et l’applet de commande Get-AzureRmVirtualNetworkSubnetConfig afin de voir et de gérer ces informations.
Dans le portail d’administration et le portail utilisateur, le panneau Vue d’ensemble ne parvient pas à charger lorsque vous sélectionnez le panneau Vue d’ensemble des comptes de stockage qui ont été créés avec une ancienne version de l’API (exemple : 2015-06-15). Cela inclut les comptes de stockage de système comme updateadminaccount utilisé pendant la mise à jour et le correctif.

Pour résoudre ce problème, utilisez PowerShell pour exécuter le script ResourceSynchronization.ps1 pour restaurer l’accès aux détails du compte de stockage. Le script est disponible à partir de GitHub et doit s’exécuter avec des informations d’identification d’administrateur de service sur le point de terminaison privilégié.
Le chargement du panneau Service Health a échoué. Si vous ouvrez le panneau Service Health dans le portail d’administration ou utilisateur, Azure Stack affiche une erreur et ne charge pas les informations. Ce comportement est normal. Même s’il est possible de sélectionner et d’ouvrir Service Health, cette fonctionnalité n’est pas encore disponible ; elle sera implémentée dans une prochaine version d’Azure Stack.

Intégrité et surveillance

Vous risquez de recevoir des alertes pour le composant Contrôleur d’intégrité contenant les informations suivantes :

Alerte 1 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur de pulsations du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Alerte 2 :
- NOM : Rôle d’infrastructure défectueux
- GRAVITÉ : Avertissement
- COMPOSANT : Contrôleur d’intégrité
- DESCRIPTION : L’analyseur d’erreur du contrôleur d’intégrité n’est pas disponible. Cela peut affecter les rapports et les métriques d’intégrité.
Ces deux alertes peuvent être ignorées en toute sécurité. Elles se ferment automatiquement dans le temps.

Place de marché

Les utilisateurs ont la possibilité de parcourir entièrement le marketplace, et peuvent voir des éléments administratifs, tels que des plans et des offres, qui ne sont pas fonctionnels pour eux.

Compute

Les paramètres de mise à l’échelle des groupes de machines virtuelles identiques ne sont pas disponibles dans le portail. Pour résoudre ce problème, vous pouvez utiliser Azure PowerShell. En raison des différences de version de PowerShell, vous devez utiliser le paramètre -Name au lieu du paramètre -VMScaleSetName.

Vous ne pouvez pas effectuer de scale-up pour un groupe de machines virtuelles identiques (VMSS) si celui-ci a été créé avec une version d’Azure Stack antérieure à 1802. Ceci est dû à la modification de la prise en charge de l’utilisation des groupes à haute disponibilité avec les groupes de machines virtuelles identiques. Cette prise en charge a été ajoutée avec la version 1802. Si vous tentez d’ajouter des instances en vue de mettre à l’échelle un groupe VMSS qui a été créé avant l’ajout de cette prise en charge, l’ajout échoue avec le message suivant : Échec du provisionnement.

Ce problème est résolu dans la version 1803. Pour résoudre ce problème avec la version 1802, installez le correctif logiciel Azure Stack 1.0.180302.4. Pour plus d’informations, consultez KB 4131152: Existing Virtual Machine Scale Sets may become unusable (Les groupes de machines virtuelles identiques existants peuvent devenir inutilisables).
Azure Stack prend en charge l’utilisation de disques durs virtuels de type fixe uniquement. Certaines images proposées par le biais de la Place de Marché sur Azure Stack utilisent des disques durs virtuels dynamiques, mais elles ont été supprimées. Le redimensionnement d’une machine virtuelle à laquelle un disque dynamique est attaché laisse la machine virtuelle dans un état d’échec.

Pour résoudre ce problème, supprimez la machine virtuelle sans supprimer son disque (un objet blob VHD dans un compte de stockage). Convertissez ensuite le disque dur virtuel de disque dynamique en disque fixe, puis recréez la machine virtuelle.
Lorsque vous créez un groupe à haute disponibilité dans le portail en accédant à Nouveau>Compute>Groupe à haute disponibilité, vous pouvez uniquement créer un groupe à haute disponibilité avec un domaine d’erreur et un domaine de mise à jour de 1. Pour contourner ce problème, lors de la création d’une nouvelle machine virtuelle, créez le groupe à haute disponibilité à l’aide de PowerShell, CLI, ou depuis le portail.
Quand vous créez des machines virtuelles sur le portail utilisateur Azure Stack, ce dernier affiche un nombre incorrect de disques de données que vous pouvez attacher à une machine virtuelle de série D. Toutes les machines virtuelles de série D prises en charge peuvent prendre en charge autant de disques de données que la configuration Azure.
Lorsqu’une image de machine virtuelle ne peut pas être créée, un élément ayant échoué que vous ne pouvez pas supprimer peut être ajouté au panneau Compute des images de machine virtuelle.

Pour contourner ce problème, créez une image de machine virtuelle avec un disque dur virtuel factice qui peut être créé via Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed -SizeBytes 1 GB). Ce processus doit résoudre le problème qui empêche la suppression de l’élément ayant échoué. Ensuite, 15 minutes après avoir créé l’image factice, vous pouvez correctement la supprimer.

Vous pouvez alors essayer de retélécharger l’image de machine virtuelle ayant précédemment échoué.
Si l’approvisionnement d’une extension sur un déploiement de machine virtuelle prend trop de temps, les utilisateurs doivent laisser expirer le délai d’attente plutôt que d’essayer d’arrêter le processus pour désallouer ou supprimer la machine virtuelle.

Les diagnostics de machine virtuelle Linux ne sont pas pris en charge dans Azure Stack. Lorsque vous déployez une machine virtuelle Linux en activant les diagnostics de machine virtuelle, le déploiement échoue. Le déploiement échoue également si vous activez les mesures de base de la machine virtuelle Linux dans les paramètres de diagnostic.

Mise en réseau

Une fois une machine virtuelle créée et associée à une adresse IP publique, vous ne pouvez pas dissocier cette machine virtuelle de cette adresse IP. La dissociation semble fonctionner, mais l’adresse IP publique qui a été assignée précédemment reste associée à la machine virtuelle d’origine.

Actuellement, vous devez utiliser uniquement les nouvelles adresses IP publiques pour les nouvelles machines virtuelles que vous créez.

Ce comportement se produit même si vous réaffectez l’adresse IP à une nouvelle machine virtuelle (ce qui est communément appelé un échange d’adresses IP virtuelles). Toutes les futures tentatives de connexion au moyen de cette adresse IP aboutissent à une connexion à la machine virtuelle associée à l’origine et non à la nouvelle.
L’équilibrage de charge interne gère incorrectement les adresses MAC des machines virtuelles principales, ce qui le bloque lorsqu’il utilise des instances Linux sur le réseau principal. L’équilibrage de charge interne fonctionne correctement avec des instances Windows sur le réseau principal.
La fonctionnalité de transfert IP est visible dans le portail ; toutefois son activation n’a aucun effet. Cette fonctionnalité n’est pas encore prise en charge.
Azure Stack prend en charge une seule passerelle de réseau local par adresse IP. Cela est vrai pour tous les abonnements de locataire. Après la création de la première connexion de passerelle de réseau local, les tentatives suivantes de création d’une ressource de passerelle de réseau local avec la même adresse IP sont bloquées.
Sur un réseau virtuel a été créé avec un paramètre de serveur DNS défini sur Automatique, vous ne pouvez pas choisir un serveur DNS personnalisé. Les paramètres mis à jour ne sont pas envoyés (par push) aux machines virtuelles dans ce réseau virtuel.
Azure Stack ne prend pas en charge l’ajout d’interfaces réseau supplémentaires sur une instance de machine virtuelle une fois que la machine virtuelle est déployée. Si la machine virtuelle nécessite plusieurs interfaces réseau, elles doivent être définies au moment du déploiement.

Vous ne pouvez pas utiliser le portail d’administration pour mettre à jour les règles d’un groupe de sécurité réseau.

Autoriser :

Login-AzureRMAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Allow `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

Refuser :


Login-AzureRMAccount -EnvironmentName AzureStackAdmin

$nsg = Get-AzureRmNetworkSecurityGroup -Name "ControllersNsg" -ResourceGroupName "AppService.local"

$RuleConfig_Inbound_Rdp_3389 =  $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389"

##This doesn't work. Need to set properties again even in case of edit

#Set-AzureRmNetworkSecurityRuleConfig -Name "Inbound_Rdp_3389" -NetworkSecurityGroup $nsg -Access Allow  

Set-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
  -Name $RuleConfig_Inbound_Rdp_3389.Name `
  -Description "Inbound_Rdp_3389" `
  -Access Deny `
  -Protocol $RuleConfig_Inbound_Rdp_3389.Protocol `
  -Direction $RuleConfig_Inbound_Rdp_3389.Direction `
  -Priority $RuleConfig_Inbound_Rdp_3389.Priority `
  -SourceAddressPrefix $RuleConfig_Inbound_Rdp_3389.SourceAddressPrefix `
  -SourcePortRange $RuleConfig_Inbound_Rdp_3389.SourcePortRange `
  -DestinationAddressPrefix $RuleConfig_Inbound_Rdp_3389.DestinationAddressPrefix `
  -DestinationPortRange $RuleConfig_Inbound_Rdp_3389.DestinationPortRange

# Commit the changes back to NSG
Set-AzureRmNetworkSecurityGroup -NetworkSecurityGroup $nsg

SQL et MySQL

Avant de continuer, consultez la remarque importante dans Avant de commencer vers le début de ces notes de publication.
Il faut parfois attendre une heure pour que les utilisateurs puissent créer des bases de données dans un nouveau déploiement SQL ou MySQL.
Seul le fournisseur de ressources est pris en charge pour créer des éléments sur des serveurs qui hébergent SQL ou MySQL. Les éléments créés sur un serveur hôte qui ne sont pas créés par le fournisseur de ressources peuvent entraîner un état qui ne correspond pas.

Les caractères spéciaux, notamment les espaces et les points, ne sont pas pris en charge dans les noms de Famille lors de la création d’une référence SKU pour les fournisseurs de ressources SQL et MySQL.

Remarque

Après la mise à jour vers Azure Stack 1802, vous pouvez continuer à utiliser les fournisseurs de ressources SQL et MySQL que vous avez déployés précédemment. Nous vous recommandons de mettre à jour SQL et MySQL lorsqu’une nouvelle version est disponible. Comme Azure Stack, appliquez de façon séquentielle les mises à jour aux fournisseurs de ressources SQL et MySQL. Par exemple, si vous utilisez la version 1710, commencez par appliquer la version 1711, puis la 1712 et ensuite mettez à jour vers la 1802.

L’installation de la mise à jour 1802 n’affecte pas l’utilisation actuelle des fournisseurs de ressources SQL ou MySQL par vos utilisateurs. Quelle que soit la version des fournisseurs de ressources que vous utilisez, vos données utilisateur dans leurs bases de données restent intactes et accessibles.

App Service

Les utilisateurs doivent inscrire le fournisseur de ressources de stockage avant de créer leur première fonction Azure dans l’abonnement.
Pour effectuer un scale-out de l’infrastructure (Workers, gestion, rôles frontaux), vous devez utiliser PowerShell comme décrit dans les notes de publication pour Compute.

Téléchargement des outils Azure Stack à partir de GitHub

Quand vous utilisez l’applet de commande PowerShell invoke-webrequest pour télécharger les outils Azure Stack à partir de GitHub, une erreur s’affiche :
- invoke-webrequest : La demande a été abandonnée : Impossible de créer un canal sécurisé SSL/TLS.
Cette erreur se produit en raison d’une désapprobation récente de la prise en charge GitHub des normes de chiffrement Tlsv1 et Tlsv1.1 (valeur par défaut pour PowerShell). Pour plus d’informations, consultez Avis de suppression des normes de chiffrement faible.

Pour résoudre ce problème, ajoutez [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 au début du script pour forcer la console PowerShell à utiliser TLSv1.2 lors du téléchargement à partir de dépôts GitHub.

Télécharger la mise à jour

Vous pouvez télécharger le package de mise à jour Azure Stack 1802 à partir de cet emplacement.

Plus d’informations

Microsoft fournit un moyen de surveiller et de reprendre les mises à jour à l’aide du point de terminaison privilégié (PEP) installé avec la mise à jour 1710.

Consultez la documentation Surveiller les mises à jour dans Azure Stack à l’aide du point de terminaison privilégié.

Voir aussi

Pour obtenir une vue d’ensemble de la gestion des mises à jour dans Azure Stack, consultez Gérer les mises à jour dans Azure Stack - Vue d’ensemble.
Pour plus d’informations sur la façon d’appliquer des mises à jour avec Azure Stack, consultez Effectuer des mises à jour dans Azure Stack.

Partage via

Notes de publication archivées pour Azure Stack Hub

Informations de référence sur la build 2306

Type de mise à jour

Nouveautés

Modifications

Mises à jour de sécurité

Correctifs logiciels

Prérequis du correctif logiciel : avant d’appliquer la mise à jour 2306

Après avoir appliqué la mise à jour 2306

Informations de référence sur la build 2301

Type de mise à jour

Nouveautés

Modifications

Mises à jour de sécurité

Correctifs logiciels

Prérequis du correctif logiciel : avant d’appliquer la mise à jour 2301

Après avoir appliqué la mise à jour 2301

Informations de référence sur la build 2206

Type de mise à jour

Nouveautés

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Prérequis pour les correctifs logiciels : avant d’appliquer la mise à jour 2206

Après l’application réussie de la mise à jour 2206

Référence de la build 2102

Type de mise à jour

Nouveautés

Améliorations

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Prérequis des correctifs logiciels : avant d’appliquer la mise à jour 2102

Après application correcte de la mise à jour 2102

Notes de publication pour les versions prises en charge

Référence de la build 2108

Type de mise à jour

Nouveautés

Améliorations

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Prérequis des correctifs logiciels : avant d’appliquer la mise à jour 2108

Après application correcte de la mise à jour 2108

Référence de la build 2008

Type de mise à jour

Nouveautés

Améliorations

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Après l’application réussie de la mise à jour 2008

Notes de publication archivées 2005

Type de mise à jour

Nouveautés

Améliorations

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Conditions préalables : avant d’appliquer la mise à jour 2005

Après l’application réussie de la mise à jour 2005

Notes de publication archivées 2002

Planification des mises à jour

Télécharger la mise à jour

Référence de la build 2002

Type de mise à jour

Nouveautés

Améliorations

Modifications

Correctifs

Mises à jour de sécurité

Correctifs logiciels

Conditions préalables : avant d’appliquer la mise à jour 2002

Après l’application de la mise à jour 2002