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 comptez sur Windows pour générer la chaîne de certificats en parcourant la liste CTL (liste de certificats de confiance). Si Azure ou Windows Update rencontre des problèmes réseau ou DNS (Domain Name System) intermittents quand 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é. Le blog Comment installer un certificat SSL de chaîne montre comment installer la chaîne de certificats complète.

Ces certificats sont créés automatiquement chaque fois qu’une extension est ajoutée au service cloud. Le plus souvent, il s’agit de l’extension WAD ou RDP, mais il peut s’agir d’autres extensions, par exemple l’extension Logiciel anti-programme malveillant ou l’extension Collecteur de journaux. 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 lève une erreur si vous tentez de supprimer un certificat en cours d’utilisation.

Consultez le document d’instructions suivant :

Obtention d’un certificat à utiliser avec WAWS (Microsoft Azure Web Sites)

La demande de signature de certificat est un simple fichier texte. Vous n’avez pas besoin de le créer à partir de la machine destinée à utiliser le certificat. 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 au sein du 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 pouvez effectuer l’une des trois actions suivantes :

• 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 WAD (Diagnostics Microsoft Azure) via les 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. De plus, les clients peuvent déployer des solutions de sécurité non Microsoft, par exemple des pare-feux d’applications web, des pare-feux réseau, des logiciels anti-programmes malveillants, des systèmes de détection d’intrusion, des systèmes IDS/IPS (systèmes de détection et de prévention des intrusions), 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 pouvez également déployer des solutions de sécurité non Microsoft, par exemple des pare-feux d’applications web, des pare-feux réseau, des logiciels anti-programmes malveillants, des systèmes IDS/IPS (systèmes de détection et de prévention des intrusions), etc.

Windows 10 et Windows Server 2016 prennent en charge HTTP/2 à la fois côté client et côté serveur. Si votre client (navigateur) se connecte au serveur IIS via le protocole TLS, qui négocie HTTP/2 via les extensions TLS, vous n’avez pas besoin d’effectuer de changements côté serveur. Vous n’avez pas besoin d’effectuer de changements, car l’en-tête h2-14 spécifiant l’utilisation de HTTP/2 est envoyé par défaut via le protocole TLS. Si, en revanche, votre client envoie un en-tête de mise à niveau pour effectuer une mise à niveau vers HTTP/2, vous devez effectuer le changement suivant côté serveur pour garantir le bon fonctionnement de la 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. Sous Liaisons, dans votre site web par défaut, créez une liaison TLS avec le certificat auto-signé que vous avez créé.

Pour plus d’informations, consultez l’article suivant :

• 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. Ainsi, à chaque création d’une instance PaaS, elle peut effectuer les changements ci-dessus dans le Registre système. Pour plus d’informations, consultez Comment configurer et exécuter des tâches de démarrage pour un service cloud.

Une fois que vous avez fini, vous pouvez vérifier si HTTP/2 est activé ou non à l’aide de l’une des méthodes suivantes :

• Activez la version de protocole dans les journaux d’activité IIS et consultez ces derniers. HTTP/2 est affiché dans les journaux.
• Activez les Outils de développement F12 dans Internet Explorer ou Microsoft Edge, puis passez à l’onglet Réseau. Ici, vous pouvez vérifier le protocole.

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

Cloud Services ne prend pas en charge le modèle de contrôle d’accès en fonction du rôle (RBAC) Azure, 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 interdit à ses ingénieurs internes d’utiliser le Bureau à distance pour se connecter à votre instance de Cloud Services sans une autorisation écrite (par e-mail ou toute autre forme de communication écrite) 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 fonctionne 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 basée sur les métriques de mémoire pour une instance de Cloud Services n’est pas prise en charge pour le moment.

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 d’invité 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 via Application Insights afin de configurer la mise à l’échelle automatique sur Cloud Services, 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.

Ce comportement est attendu, et ne devrait pas poser de problème à 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. Toutefois, il existe plusieurs éléments à prendre en compte pour que cet événement ne pose pas de problème.

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.). La quantité d’espace libre dans le dossier %approot% n’est donc 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 VHD (disque dur virtuel) créé à partir de votre .cspkg et monté sur la machine virtuelle Azure, la seule chose qui peut écrire sur ce lecteur est votre application. 

Les paramètres de journal ne sont pas configurables. Vous ne pouvez donc pas désactiver la journalisation.

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

• 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 la cmdlet PowerShell New-WebBinding suivante dans une tâche de démarrage d’une instance de rôle Cloud Services :

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

Comme indiqué ici, $sslFlags peut prendre 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 précédentes, les certificats respectifs (*.pfx) des noms d’hôtes spécifiques doivent d’abord être installés sur les instances de rôle à l’aide d’une tâche de démarrage ou via du code pour que la liaison SNI soit effective.

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 toujours 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. Azure vous facture uniquement 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.