Problèmes de configuration et de gestion pour Azure Cloud Services (classique) : Forum Aux Questions (FAQ)

Nous recommandons aux clients d’installer la chaîne de certificats complète (certificat feuille, certificats intermédiaires et certificat racine) au lieu du seul certificat feuille. Quand vous installez uniquement le certificat feuille, vous faites confiance à Windows pour générer la chaîne de certificats en parcourant la liste CTL. Si Azure ou Windows Update rencontre des problèmes réseau ou DNS intermittents pendant que Windows tente de valider le certificat, celui-ci peut être considéré comme non valide. En installant la chaîne de certificats complète, ce problème peut être évité. L’article du blog intitulé How to install a chained SSL certificate (Comment installer un certificat SSL chaîné) explique comment effectuer cette opération.

Ces certificats sont créés automatiquement chaque fois qu’une extension est ajoutée au service cloud. Il s’agit le plus souvent de l’extension WAD ou RDP, mais il peut s’agit d’autres extensions, notamment Antimalware ou Log Collector. Ces certificats sont utilisés uniquement pour chiffrer et déchiffrer la configuration privée de l’extension. Dans la mesure où la date d’expiration n’est jamais vérifiée, l’expiration du certificat ne pose pas de problème. 

Vous pouvez ignorer ces certificats. Si vous voulez nettoyer les certificats, vous pouvez essayer de tous les supprimer. Azure génère une erreur si vous essayez de supprimer un certificat en cours d’utilisation.

Consultez le document d’instructions suivant :

Obtention d’un certificat pour une utilisation avec Windows Azure Web Sites (WAWS)

La demande de signature de certificat est un simple fichier texte. Il n’est pas nécessaire de la créer depuis la machine sur laquelle le certificat sera utilisé au final. Même si ce document est écrit pour un service d’application (App Service), la création d’une demande de signature de certificat est générique et s’applique aussi aux services cloud.

Vous pouvez utiliser les commandes PowerShell suivantes pour renouveler vos certificats de gestion :

Add-AzureAccount
Select-AzureSubscription -Current -SubscriptionName <your subscription name>
Get-AzurePublishSettingsFile

Get-AzurePublishSettingsFile crée un certificat de gestion dans Abonnement>Certificats de gestion dans le portail Azure. Le nom du nouveau certificat ressemble à « [nom_de_votre_abonnement]-[date_actuelle]-credentials ».

Vous pouvez automatiser cette tâche à l’aide d’un script de démarrage (batch/cmd/PowerShell) et enregistrer ce script de démarrage dans le fichier de définition de service. Ajoutez le script de démarrage et le certificat (fichier .p7b) dans le dossier de projet du même répertoire du script de démarrage.

Ce certificat est utilisé pour chiffrer les clés de machine sur les rôles web Azure. Pour plus d’informations, consultez ces conseils.

Pour plus d’informations, consultez les articles suivants :

• Comment configurer et exécuter des tâches de démarrage pour un service cloud
• Tâches courantes de démarrage dans le service cloud

La possibilité de générer un nouveau certificat de protocole RDP (Remote Desktop Protocol) est prévue prochainement. Vous pouvez également exécuter ce script :

$cert = New-SelfSignedCertificate -DnsName yourdomain.cloudapp.net -CertStoreLocation "cert:\LocalMachine\My" -KeyLength 20 48 -KeySpec "KeyExchange"
$password = ConvertTo-SecureString -String "your-password" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath ".\my-cert-file.pfx" -Password $password

La possibilité de choisir l’option « blob » ou « local » pour votre emplacement de chargement csdef et cscfg est prévue prochainement. À l’aide de New-AzureDeployment, vous pouvez définir chaque valeur d’emplacement.

La possibilité de surveiller les métriques au niveau de l’instance. Des fonctionnalités de supervision supplémentaires sont disponibles dans Guide pratique pour superviser des services cloud.

Vous avez épuisé le quota de stockage local pour l’écriture dans le répertoire des journaux. Pour corriger ce problème, vous avez trois solutions :

• Activez les diagnostics pour IIS et déplacez régulièrement les diagnostics sur le Stockage Blob.
• Supprimez manuellement les fichiers journaux du répertoire de journalisation.
• Augmentez la limite de quota pour les ressources locales.

Pour plus d’informations, consultez les documents suivants :

• Stocker et afficher des données de diagnostic dans le stockage Azure
• Le service Journaux d’activité IIS cesse d’écrire dans le service cloud

Vous pouvez activer la journalisation Diagnostics Azure pour Windows (WAD) par le biais des options suivantes :

1. Activer à partir de Visual Studio
2. Activer par le biais du code .NET
3. Activer par le biais de PowerShell

Pour obtenir les paramètres actuels des diagnostics Microsoft Azure de votre service cloud, vous pouvez utiliser la commande PowerShell Get-AzureServiceDiagnosticsExtensions ou les voir dans le portail en accédant au panneau « Services cloud --> Extensions ».

Vous pouvez spécifier le délai d’expiration dans votre fichier de définition de service (csdef) comme ceci :

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="mgVS2015Worker" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" />
    </ConfigurationSettings>
    <Imports>
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="10100"   idleTimeoutInMinutes="30" />
    </Endpoints>
  </WorkerRole>

Pour plus d’informations, consultez Nouveau : délai d’inactivité configurable pour Azure Load Balancer.

Pour configurer une adresse IP statique, vous devez créer une adresse IP réservée. Cette adresse IP réservée peut être associée à un nouveau service cloud ou à un déploiement existant. Pour plus d’informations, consultez les documents suivants :

• Comment créer une adresse IP réservée
• Réserver l’adresse IP d’un service cloud existant
• Associer une adresse IP réservée à un nouveau service cloud
• Associer une adresse IP réservée à un déploiement en cours d’exécution
• Associer une adresse IP réservée à un service cloud à l’aide d’un fichier de configuration de service

Azure propose des fonctionnalités IPS/IDS sur les serveurs physiques des centres de données pour assurer une protection contre les menaces. Par ailleurs, les clients peuvent déployer des solutions de sécurité tierces, telles que des pare-feu d’applications web, des pare-feu réseau, des logiciels anti-programmes malveillants, des systèmes de détection et de prévention des intrusions (IDS/IPS), etc. Pour plus d’informations, consultez Protégez vos données et vos biens en respectant les normes internationales de sécurité.

Microsoft surveille en continu les serveurs, les réseaux et les applications pour détecter les menaces. L’approche concertée de la gestion des menaces d’Azure utilise également la détection d’intrusion, la prévention des attaques par déni de service distribué (DDoS), le test de pénétration, l’analytique des comportements, la détection d’anomalies et le Machine Learning pour renforcer constamment ses défenses et réduire les risques. Microsoft Antimalware pour Azure protège les services cloud et les machines virtuelles Azure. Vous avez la possibilité de déployer des solutions de sécurité tierces supplémentaires, telles que des pare-feu d’applications web, des pare-feu réseau, des logiciels anti-programmes malveillants, des systèmes de détection et de prévention des intrusions (IDS/IPS), etc.

Windows 10 et Windows Server 2016 prennent en charge HTTP/2 à la fois côté client et côté serveur. Si votre (navigateur) client se connecte au serveur IIS sur TLS qui négocie HTTP/2 via les extensions TLS, vous n’avez pas besoin d’effectuer de modifications côté serveur. En effet, sur TLS, l’en-tête h2-14 spécifiant l’utilisation de HTTP/2 est envoyé par défaut. En revanche, si votre client envoie un en-tête de mise à niveau pour mettre à niveau vers HTTP/2, vous devez effectuer la modification ci-dessous côté serveur pour garantir la correcte mise à niveau et l’établissement d’une connexion HTTP/2.

1. Exécutez regedit.exe.
2. Accédez à la clé de registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
3. Créez une valeur DWORD nommée DuoEnabled.
4. Définissez-la sur 1.
5. Redémarrez votre serveur.
6. Accédez à votre site web par défaut et sous Liaisons, créez une liaison TLS avec le certificat auto-signé qui vient d’être créé.

Pour plus d'informations, consultez les pages suivantes :

• HTTP/2 sur IIS
• Vidéo : HTTP/2 dans Windows 10 : Navigateur, applications et serveur Web

Ces étapes peuvent être automatisées via une tâche de démarrage de manière à pouvoir effectuer les modifications ci-dessus dans le Registre système chaque fois qu’une instance PaaS est créée. Pour plus d’informations, consultez Comment configurer et exécuter des tâches de démarrage pour un service cloud.

Une fois terminé, vous pouvez vérifier si la connexion HTTP/2 a été activée ou non en utilisant l’une des méthodes suivantes :

• Activez la version de protocole dans les journaux d’activité IIS et consultez ces derniers. Vous y trouverez les informations sur HTTP/2.
• Activez l’outil de développement F12 dans Internet Explorer ou Microsoft Edge et basculez vers l’onglet Réseau pour vérifier le protocole.

Pour plus d’informations, consultez HTTP/2 sur IIS.

Azure Cloud Services ne prend pas en charge le modèle de contrôle d’accès en fonction du rôle Azure (Azure RBAC), car il ne s’agit pas d’un service Azure Resource Manager.

Voir Comprendre les différents rôles dans Azure.

Microsoft suit un processus strict qui ne permet pas à ses ingénieurs internes de se connecter en utilisant le Bureau à distance à votre service cloud sans une autorisation écrite (par e-mail ou toute autre communication écrite) de la part du propriétaire ou de son représentant.

Cette erreur peut se produire si vous utilisez le fichier RDP à partir d’une machine jointe à Microsoft Entra ID. Pour résoudre ce problème, effectuez les étapes suivantes :

1. Cliquez avec le bouton droit sur le fichier RDP que vous avez téléchargé, puis sélectionnez Modifier.
2. Ajoutez « \ » comme préfixe avant le nom d’utilisateur. Par exemple, utilisez .\nom_utilisateur au lieu de nom_utilisateur.

Le nombre de cœurs que vous pouvez utiliser est limité dans votre abonnement Azure. La mise à l’échelle ne fonctionnera pas si vous avez utilisé tous les cœurs disponibles. Par exemple, si vous avez une limite de 100 cœurs, cela signifie que vous pouvez avoir 100 instances de machine virtuelle A1 pour votre service cloud ou 50 instances de machine virtuelle A2.

La mise à l’échelle automatique en fonction des métriques de la mémoire pour un service cloud n’est pas prise en charge.

Pour contourner ce problème, vous pouvez utiliser Application Insights. La mise à l’échelle automatique prend en charge Application Insights en tant que source de métriques et peut mettre à l’échelle le nombre d’instances de rôle en fonction d’une métrique invitée telle que « Mémoire ». Vous devez configurer Application Insights dans votre fichier de package de projet de service cloud (*.cspkg) et activer l’extension Diagnostics Azure sur le service pour implémenter cette fonction.

Pour plus d’informations sur l’utilisation d’une métrique personnalisée par le biais d’Application Insights afin de configurer la mise à l’échelle automatique sur les services cloud, consultez Prise en main de la mise à l’échelle automatique par métrique personnalisée dans Azure.

Pour plus d’informations sur la façon d’intégrer Diagnostics Azure à Application Insights pour les services cloud, consultez Envoyer des données de diagnostic de service cloud, de machine virtuelle ou de Service Fabric à Application Insights.

Pour plus d’informations sur la façon d’activer Application Insights pour les services cloud, consultez Application Insights pour Services cloud Azure.

Pour plus d’informations sur la façon d’activer la journalisation Diagnostics Azure pour les services cloud, consultez Configurer les diagnostics pour les services cloud et les machines virtuelles Azure.

Pour empêcher les clients de détecter les types MIME, ajoutez un paramètre au fichier web.config.

<configuration>
   <system.webServer>
      <httpProtocol>
         <customHeaders>
            <add name="X-Content-Type-Options" value="nosniff" />
         </customHeaders>
      </httpProtocol>
   </system.webServer>
</configuration>

Vous pouvez également ajouter ce paramètre dans IIS. Utilisez la commande suivante avec l’article tâches courantes de démarrage.

%windir%\system32\inetsrv\appcmd set config /section:httpProtocol /+customHeaders.[name='X-Content-Type-Options',value='nosniff']

Utilisez le script de démarrage IIS à partir de l’article tâches courantes de démarrage.

Consultez Limites spécifiques des services.

Il s’agit d’un comportement normal qui ne devrait pas causer de problèmes à votre application. La journalisation est activée pour le lecteur %approot% des machines virtuelles Azure PaaS, ce qui dans l’absolu a pour effet de consommer normalement le double d’espace que les fichiers. Cependant, cela ne pose pas de problème, et ce pour plusieurs raisons.

La taille du lecteur %approot% est calculée selon la formule <taille du fichier .cspkg + taille maximale du journal + marge d’espace libre> ou est égale à 1,5 Go, la valeur la plus grande étant retenue. La taille de votre machine virtuelle n’a pas d’incidence sur ce calcul. (La taille de machine virtuelle affecte uniquement la taille du lecteur C: temporaire.)

L’écriture sur le lecteur %approot% n’est pas prise en charge. Si vous écrivez sur la machine virtuelle Azure, vous devez le faire dans une ressource LocalStorage temporaire (ou vous pouvez choisir une autre option, comme Stockage Blob, Azure Files, etc.). Autrement dit, la quantité d’espace libre dans le dossier %approot % n’est pas significative. Pour savoir avec certitude si votre application écrit ou non sur le lecteur %approot%, vous pouvez toujours laisser votre service s’exécuter pendant quelques jours, puis comparer sa taille « avant » et « après ». 

Azure n’écrit rien sur le lecteur %approot%. Une fois le disque dur virtuel créé à partir de votre fichier .cspkg et monté dans la machine virtuelle Azure, votre application est la seule à pouvoir écrire sur ce lecteur. 

Les paramètres de journal n’étant pas configurables, vous ne pouvez pas les désactiver.

Vous pouvez activer une extension Antimalware à l’aide du script PowerShell dans la tâche de démarrage. Suivez les étapes décrites dans les articles suivants pour l’implémenter :

• Créer une tâche de démarrage PowerShell
• Set-AzureServiceAntimalwareExtension

Pour plus d’informations sur les scénarios de déploiement Antimalware et la façon de l’activer à partir du portail, consultez Scénarios de déploiement Antimalware.

Vous pouvez activer SNI dans les services cloud en utilisant l’une des méthodes suivantes :

Méthode 1 : Utiliser PowerShell

La liaison SNI peut être configurée à l’aide de l’applet de commande PowerShell New-WebBinding dans une tâche de démarrage pour une instance de rôle de service cloud comme indiqué ci-dessous :

New-WebBinding -Name $WebsiteName -Protocol "https" -Port 443 -IPAddress $IPAddress -HostHeader $HostHeader -SslFlags $sslFlags

Comme décrit ici, $sslFlags peut adopter l’une des valeurs suivantes :

Méthode 2 : Utiliser le code

La liaison SNI peut également être configurée via code au cours du démarrage de rôle comme décrit dans ce billet de blog :

//<code snip> 
                var serverManager = new ServerManager(); 
                var site = serverManager.Sites[0]; 
                var binding = site.Bindings.Add(":443:www.test1.com", newCert.GetCertHash(), "My"); 
                binding.SetAttributeValue("sslFlags", 1); //enables the SNI 
                serverManager.CommitChanges(); 
    //</code snip>

Si vous utilisez l’une des approches ci-dessus, les certificats respectifs (*.pfx) pour les noms d’hôte spécifiques doivent être installés au préalable sur les instances de rôle à l’aide d’une tâche de démarrage ou via code pour activer la liaison SNI.

Le service cloud est une ressource classique. Seules les ressources créées via Azure Resource Manager prennent en charge les balises. Vous ne pouvez pas appliquer des étiquettes à des ressources classiques, comme un service cloud.

Nous travaillons à l’ajout de cette fonctionnalité au portail Azure. D’ici là, vous pouvez utiliser les commandes PowerShell suivantes pour obtenir la version du SDK :

Get-AzureService -ServiceName "<Cloud Service name>" | Get-AzureDeployment | Where-Object -Property SdkVersion -NE -Value "" | select ServiceName,SdkVersion,OSVersion,Slot

Un service cloud déjà déployé est facturé pour les ressources de calcul et de stockage qu’il utilise. Ainsi, même si vous arrêtez la machine virtuelle Azure, vous êtes néanmoins encore facturé pour le stockage.

Voici ce que vous pouvez faire pour réduire votre facturation sans perdre l’adresse IP de votre service :

1. Réservez l’adresse IP avant de supprimer les déploiements. Vous êtes uniquement facturé pour cette adresse IP. Pour plus d’informations sur la facturation d’une adresse IP, consultez Tarification des adresses IP.
2. Supprimez les déploiements. Ne supprimez pas xxx.cloudapp.net, afin que vous puissiez l’utiliser à l’avenir.
3. Si vous souhaitez redéployer le service cloud à l’aide de l’adresse IP de réserve que vous avez réservée dans votre abonnement, consultez Adresses IP réservées pour les services cloud et les machines virtuelles.