Notes de publication d’App Service sur Azure Stack Hub 2302

Article
10/30/2024

Ces notes de publication décrivent les améliorations et les correctifs dans Azure App Service sur Azure Stack Hub 2302, ainsi que les problèmes connus. Les problèmes connus ont été répartis selon qu’ils concernent le déploiement, le processus de mise à jour ou la build (après l’installation).

Important

Mettez à jour Azure Stack Hub vers une version prise en charge (ou déployez le dernier Kit de développement Azure Stack), si nécessaire, avant de déployer ou de mettre à jour le fournisseur de ressources App Service (RP). Veillez à lire les notes de publication basées sur les revendications afin de découvrir les nouvelles fonctionnalités, les correctifs et les problèmes connus susceptibles d’affecter votre déploiement.

Version minimale d’Azure Stack Hub prise en charge Version basée sur les revendications de App Service

2301 et versions ultérieures Programme d’installation 2302 (notes de publication)

Version minimale d’Azure Stack Hub prise en charge	Version basée sur les revendications de App Service
2301 et versions ultérieures	Programme d’installation 2302 (notes de publication)

Référence de build

Le numéro de build App Service sur Azure Stack Hub 2302 est 98.0.1.703

Nouveautés

Azure App Service sur Azure Stack Hub 2302 remplace la version 2022 H1 et inclut des correctifs pour les problèmes suivants :

CVE-2023-21703 Azure App Service sur une vulnérabilité d’élévation de privilèges Azure Stack Hub.
Impossible d’ouvrir l’expérience utilisateur des groupes de machines virtuelles identiques à partir de l’expérience utilisateur administrateur des rôles App Service dans le portail d’administration Azure Stack Hub.
Toutes les autres mises à jour sont documentées dans les notes de publication d’Azure App Service sur Azure Stack Hub 2022 H1.
À compter de la mise à jour d’Azure App Service sur Azure Stack Hub 2022 H1, la lettre K est désormais une lettre de référence SKU réservée. Si vous avez défini une référence SKU personnalisée qui utilise la lettre K, contactez le support technique pour résoudre cette situation avant la mise à niveau.

Prérequis

Avant de passer au déploiement, consultez la documentation Avant de commencer.

Avant de commencer la mise à niveau d’Azure App Service sur Azure Stack Hub vers 2302 :

Vérifiez que votre Azure Stack Hub est mis à jour vers la version 1.2108.2.127 ou 1.2206.2.52.
Vérifiez que tous les rôles sont prêts dans l’administration Azure App Service dans le portail d’administration Azure Stack Hub.
Sauvegardez les secrets App Service à l’aide de l’administration App Service dans le portail d’administration Azure Stack Hub.
Sauvegardez les bases de données maîtres App Service et SQL Server :
- AppService_Hosting
- AppService_Metering
- Élément maître
Sauvegardez le partage de fichiers de contenu d’application du locataire.

Important

Les opérateurs cloud sont responsables de la maintenance et du fonctionnement du serveur de fichiers et de SQL Server. Le fournisseur de ressources ne gère pas ces ressources. L'opérateur cloud est responsable de la sauvegarde des bases de données App Service et du partage des fichiers de contenu des locataires.
Syndicatez l’extension de script personnalisé version 1.9.3 à partir de la Place de marché.

Étapes de pré-mise à jour

Remarque

Si vous avez déjà déployé Azure App Service sur Azure Stack Hub 2022 H1 sur votre tampon Azure Stack Hub, cette version est une mise à niveau mineure vers 2022 H1 qui résout deux problèmes.

Azure App Service sur Azure Stack Hub 2302 est une mise à jour significative qui prendra plusieurs heures. L’ensemble du déploiement sera mis à jour et tous les rôles recréés avec le système d’exploitation Windows Server 2022 Datacenter. Par conséquent, nous vous recommandons d’informer les clients finaux d’une mise à jour planifiée avant d’appliquer la mise à jour.

À compter de la mise à jour d’Azure App Service sur Azure Stack Hub 2022 H1, la lettre K est désormais une lettre de référence SKU réservée. Si vous avez défini une référence SKU personnalisée qui utilise la lettre K, contactez le support technique pour résoudre cette situation avant la mise à niveau.

Passez en revue les problèmes connus pour la mise à jour et effectuez toutes les actions prescrites.

Étapes de post-déploiement

Important

Si vous avez fourni au fournisseur de ressources App Service une instance SQL Always On, vous devez ajouter les bases de données appservice_hosting et appservice_metering à un groupe de disponibilité et synchroniser les bases de données pour éviter toute perte de service en cas de basculement de base de données.

Problèmes connus (mise à jour)

Dans les cas où vous avez converti les bases de données appservice_hosting et appservice_metering en bases de données autonomes, la mise à niveau peut échouer si les connexions n’ont pas été correctement migrées vers des utilisateurs autonomes.

Si vous avez converti les bases de données appservice_hosting et appservice_metering en bases de données autonomes après le déploiement et que vous n’avez pas correctement migré les connexions de base de données vers des utilisateurs autonomes, vous risquez d’rencontrer des échecs de mise à niveau.

Vous devez exécuter le script suivant sur l’hébergement SQL Server appservice_hosting et appservice_metering avant de mettre à niveau votre installation d’Azure App Service sur Azure Stack Hub vers 2020 Q3. Ce script est non destructeur et n’entraîne pas de temps d’arrêt.

Ce script doit être exécuté dans les conditions suivantes :

Par un utilisateur disposant du privilège d’administrateur système, par exemple le compte SA SQL.
Si vous utilisez SQL Always On, vérifiez que le script est exécuté à partir de l’instance SQL qui contient toutes les connexions App Service dans le formulaire :
- appservice_hosting_FileServer
- appservice_hosting_HostingAdmin
- appservice_hosting_LoadBalancer
- appservice_hosting_Operations
- appservice_hosting_Publisher
- appservice_hosting_SecurePublisher
- appservice_hosting_WebWorkerManager
- appservice_metering_Common
- appservice_metering_Operations
- Toutes les connexions WebWorker, qui se présentent sous la forme WebWorker_<adresse IP de l’instance>

      USE appservice_hosting
      IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1)
      BEGIN
      DECLARE @username sysname ;  
      DECLARE user_cursor CURSOR  
      FOR
          SELECT dp.name
          FROM sys.database_principals AS dp  
          JOIN sys.server_principals AS sp
              ON dp.sid = sp.sid  
              WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA');
          OPEN user_cursor  
          FETCH NEXT FROM user_cursor INTO @username  
              WHILE @@FETCH_STATUS = 0  
              BEGIN  
                  EXECUTE sp_migrate_user_to_contained
                  @username = @username,  
                  @rename = N'copy_login_name',  
                  @disablelogin = N'do_not_disable_login';  
              FETCH NEXT FROM user_cursor INTO @username  
          END  
          CLOSE user_cursor ;  
          DEALLOCATE user_cursor ;
          END
      GO

      USE appservice_metering
      IF EXISTS(SELECT * FROM sys.databases WHERE Name=DB_NAME() AND containment = 1)
      BEGIN
      DECLARE @username sysname ;  
      DECLARE user_cursor CURSOR  
      FOR
          SELECT dp.name
          FROM sys.database_principals AS dp  
          JOIN sys.server_principals AS sp
              ON dp.sid = sp.sid  
              WHERE dp.authentication_type = 1 AND dp.name NOT IN ('dbo','sys','guest','INFORMATION_SCHEMA');
          OPEN user_cursor  
          FETCH NEXT FROM user_cursor INTO @username  
              WHILE @@FETCH_STATUS = 0  
              BEGIN  
                  EXECUTE sp_migrate_user_to_contained
                  @username = @username,  
                  @rename = N'copy_login_name',  
                  @disablelogin = N'do_not_disable_login';  
              FETCH NEXT FROM user_cursor INTO @username  
          END  
          CLOSE user_cursor ;  
          DEALLOCATE user_cursor ;
          END
      GO

Les applications clientes ne peuvent pas lier de certificats aux applications après la mise à niveau.

La cause de ce problème est due à une fonctionnalité manquante sur les serveurs frontaux après la mise à niveau vers Windows Server 2022. Les opérateurs doivent suivre cette procédure pour résoudre le problème.
1. Dans le portail d’administration Azure Stack Hub, accédez aux groupes de sécurité réseau et affichez le groupe de sécurité réseau ControllersNSG .
2. Par défaut, le Bureau à distance est désactivé pour tous les rôles d’infrastructure App Service. Modifiez l’action de règle Inbound_Rdp_3389 pour autoriser l’accès.
3. Accédez au groupe de ressources contenant le déploiement du fournisseur de ressources App Service, par défaut, le nom est AppService.<région> et connexion à CN0-VM.
4. Revenez à la session bureau à distance CN0-VM .
5. Dans une session PowerShell d’administrateur, exécutez :
  
  Important
  
  Pendant l’exécution de ce script, il y aura une pause pour chaque instance dans le scaleset frontal. S’il existe un message indiquant que la fonctionnalité est en cours d’installation, cette instance sera redémarré. Utilisez la pause dans le script pour maintenir la disponibilité frontale. Les opérateurs doivent s’assurer qu’au moins une instance frontale est « Prêt » à tout moment pour garantir que les applications clientes peuvent recevoir du trafic et ne pas rencontrer de temps d’arrêt.
```
$c = Get-AppServiceConfig -Type Credential -CredentialName FrontEndCredential
$spwd = ConvertTo-SecureString -String $c.Password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PsCredential ($c.UserName, $spwd)

Get-AppServiceServer -ServerType LoadBalancer | ForEach-Object {
    $lb = $_
    $session = New-PSSession -ComputerName $lb.Name -Credential $cred

    Invoke-Command -Session $session {
      $f = Get-WindowsFeature -Name Web-CertProvider
      if (-not $f.Installed) {
          Write-Host Install feature on $env:COMPUTERNAME
          Install-WindowsFeature -Name Web-CertProvider

          Shutdown /t 5 /r /f 
      }
   }
}

Remove-PSSession -Session $session

Read-Host -Prompt "If installing the feature, the machine will reboot. Wait until there's enough frontend availability, then press ENTER to continue"
```
6. Dans le portail d’administration Azure Stack, revenez au groupe de sécurité réseau ControllersNSG .
7. Modifiez la règle Inbound_Rdp_3389 pour refuser l’accès.

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

Les workers ne peuvent pas atteindre le serveur de fichiers lorsque App Service est déployé dans un réseau virtuel existant et que le serveur de fichiers est disponible uniquement sur le réseau privé, comme indiqué dans la documentation de déploiement d’Azure App Service sur Azure Stack.

Si vous avez choisi de procéder au déploiement dans un réseau virtuel existant et une adresse IP interne pour vous connecter à votre serveur de fichiers, vous devez ajouter une règle de sécurité sortante, qui autorise le trafic SMB entre le sous-réseau Worker et le serveur de fichiers. Accédez au WorkersNsg dans le portail d’administration, puis ajoutez une règle de sécurité sortante comportant les propriétés suivantes :
- Source : Quelconque
- Plage de ports source : : *
- Destination : adresses IP
- Plage d’adresses IP de destination : plage d’adresses IP de votre serveur de fichiers
- Plage de ports de destination : 445
- Protocole : TCP
- Action : Allow
- Priorité : 700
- Nom : Outbound_Allow_SMB445
Pour supprimer la latence lorsque les workers communiquent avec le serveur de fichiers, nous vous conseillons également d’ajouter la règle suivante au groupe de sécurité réseau worker pour autoriser le trafic LDAP sortant et Kerberos vers vos contrôleurs Active Directory si vous sécurisez le serveur de fichiers à l’aide d’Active Directory ; par exemple, si vous avez utilisé le modèle de démarrage rapide pour déployer un serveur de fichiers haute disponibilité et SQL Server.

Accédez au WorkersNsg dans le portail d’administration, puis ajoutez une règle de sécurité sortante comportant les propriétés suivantes :
- Source : Quelconque
- Plage de ports source : : *
- Destination : adresses IP
- Plage d’adresses IP de destination : plage des IP de vos serveurs AD, par exemple, avec le modèle de démarrage rapide 10.0.0.100, 10.0.0.101
- Plage des ports de destination : 389,88
- Protocole : N’importe laquelle
- Action : Autoriser
- Priorité : 710
- Nom : Outbound_Allow_LDAP_and_Kerberos_to_Domain_Controllers
Les applications clientes ne peuvent pas lier de certificats aux applications après la mise à niveau.

La cause de ce problème est due à une fonctionnalité manquante sur les serveurs frontaux après la mise à niveau vers Windows Server 2022. Les opérateurs doivent suivre cette procédure pour résoudre le problème :
1. Dans le portail d’administration Azure Stack Hub, accédez aux groupes de sécurité réseau et affichez le groupe de sécurité réseau ControllersNSG .
2. Par défaut, le Bureau à distance est désactivé pour tous les rôles d’infrastructure App Service. Modifiez l’action de règle Inbound_Rdp_3389 pour autoriser l’accès.
3. Accédez au groupe de ressources contenant le déploiement du fournisseur de ressources App Service, par défaut, le nom est AppService.<région> et connexion à CN0-VM.
4. Revenez à la session bureau à distance CN0-VM .
5. Dans une session PowerShell d’administrateur, exécutez :
  
  Important
  
  Pendant l’exécution de ce script, il y aura une pause pour chaque instance dans le scaleset frontal. S’il existe un message indiquant que la fonctionnalité est en cours d’installation, cette instance sera redémarré. Utilisez la pause dans le script pour maintenir la disponibilité frontale. Les opérateurs doivent s’assurer qu’au moins une instance frontale est « Prêt » à tout moment pour garantir que les applications clientes peuvent recevoir du trafic et ne pas rencontrer de temps d’arrêt.
```
$c = Get-AppServiceConfig -Type Credential -CredentialName FrontEndCredential
$spwd = ConvertTo-SecureString -String $c.Password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PsCredential ($c.UserName, $spwd)

Get-AppServiceServer -ServerType LoadBalancer | ForEach-Object {
    $lb = $_
    $session = New-PSSession -ComputerName $lb.Name -Credential $cred

    Invoke-Command -Session $session {
      $f = Get-WindowsFeature -Name Web-CertProvider
      if (-not $f.Installed) {
          Write-Host Install feature on $env:COMPUTERNAME
          Install-WindowsFeature -Name Web-CertProvider

          Read-Host -Prompt "If installing the feature, the machine will reboot. Wait until there's enough frontend availability, then press ENTER to continue"
          Shutdown /t 5 /r /f 
      }
   }
}

Remove-PSSession -Session $session      
```
6. Dans le portail d’administration Azure Stack, revenez au groupe de sécurité réseau ControllersNSG .
7. Modifiez la règle Inbound_Rdp_3389 pour refuser l’accès.

Problèmes connus des administrateurs cloud utilisant Azure App Service sur Azure Stack

Les domaines personnalisés ne sont pas pris en charge dans les environnements déconnectés.

App Service effectue la vérification de propriété de domaine sur les points de terminaison DNS publics. Par conséquent, les domaines personnalisés ne sont pas pris en charge dans les scénarios déconnectés.
Réseau virtuel’intégration pour les applications web et de fonction n’est pas prise en charge.

La possibilité d’ajouter l’intégration de réseau virtuel aux applications web et de fonction s’affiche dans le portail Azure Stack Hub et si un locataire tente de configurer, il reçoit une erreur de serveur interne. Cette fonctionnalité n’est pas prise en charge dans Azure App Service sur Azure Stack Hub.

Étapes suivantes

Pour une présentation d’Azure App Service, consultez Vue d’ensemble d’App Service sur Azure Stack.
Pour plus d’informations sur la préparation au déploiement d’App Service on Azure Stack, consultez Avant de commencer avec App Service sur Azure Stack.

Partager via