Résoudre les problèmes liés aux demandes ayant échoué à l’aide du suivi dans IIS 7

S’applique à : Internet Information Services 7.0

Remarque

Cet article s’applique à IIS 7.0. Pour les versions plus récentes, consultez Résoudre les échecs de requêtes à l’aide du suivi dans IIS 8.5.

Le suivi basé sur les demandes est disponible à la fois dans les serveurs IIS autonomes et sur les applications web Azure, et permet de déterminer ce qui se passe exactement avec vos demandes et pourquoi, si vous pouvez reproduire le problème que vous rencontrez. Des problèmes tels que des performances médiocres sur certaines demandes, ou des échecs liés à l’authentification sur d’autres demandes, ou l’erreur server 500 d’ASP ou de ASP.NET peuvent souvent être difficiles à résoudre, sauf si vous avez capturé la trace du problème lorsqu’il se produit. Cet article décrit le suivi des demandes ayant échoué sur le serveur IIS. Pour plus d’informations sur cette opération avec les applications web Azure, consultez Résoudre les problèmes d’une application dans Azure App Service à l’aide de Visual Studio.

Le suivi des demandes ayant échoué est conçu pour mettre en mémoire tampon les événements de trace d’une requête et les vider uniquement sur le disque en cas d’échec de la requête, où vous fournissez la définition de « échec ». Si vous souhaitez savoir pourquoi vous recevez des messages d’erreur 404.2 ou si vous commencez à suspendre la demande, utilisez Suivi des demandes ayant échoué.

Les tâches illustrées dans cet article sont les suivantes :

• Activation du module Suivi des demandes ayant échoué.
• Configuration de la sémantique du fichier journal du suivi des demandes ayant échoué.
• Définition de l’URL pour laquelle conserver les traces des demandes ayant échoué, y compris les définitions d’échec et les zones à suivre.
• Génération de la condition d’échec et affichage de la trace résultante.

Conditions préalables

Installer IIS

Vous devez installer IIS 7 ou version ultérieure avant de pouvoir effectuer les tâches décrites dans cet article. Accédez à http://localhost/ pour voir si IIS est installé. Si IIS n’est pas installé, consultez Installation d’IIS sur Windows Server 2008 pour obtenir des instructions d’installation. Lors de l’installation d’IIS, veillez à installer également les fonctionnalités suivantes :

• ASP.NET (sous Fonctionnalités de développement - d’applicationsdes services - World Wide Web ASP.NET)
• Traçage (sous World Wide Web Services - Health and Diagnostics - Tracing)

Se connecter en tant qu’administrateur

Vérifiez que le compte que vous utilisez pour vous connecter est le compte administrateur ou qu’il se trouve dans le groupe Administrateurs.

Remarque

Le fait d’être dans le groupe Administrateurs ne vous accorde pas de droits d’utilisateur d’administrateur complets par défaut. Vous devez exécuter des applications en tant qu’administrateur, ce que vous pouvez faire en cliquant avec le bouton droit sur l’icône de l’application et en sélectionnant Exécuter en tant qu’administrateur.

Effectuer une sauvegarde

Vous devez effectuer une sauvegarde de la configuration avant d’effectuer les tâches décrites dans les sections suivantes.

Pour effectuer une sauvegarde de la configuration, procédez comme suit :

1. Sélectionnez Démarrer>tous les accessoires de programmes>.

2. Cliquez avec le bouton droit sur Invite de commandes, puis sélectionnez Exécuter en tant qu’administrateur.

   

3. Dans une invite de commandes, exécutez la commande suivante :

   %windir%\system32\inetsrv\appcmd add backup cleanInstall
   

Créer un exemple de contenu

1. Accédez à la page %systemdrive%\inetpub\wwwroot.

2. Déplacez le contenu vers un emplacement sécurisé (si vous souhaitez restaurer le contenu existant) ou supprimez-le.

3. Créez un fichier vide et nommez-le test.asp.

4. Dans l’invite de commandes, accédez au fichier test.asp dans \inetpub\wwwroot.

5. Dans le fichier test.asp , collez le contenu suivant :

   <h2>Failed Request Tracing Lab</h2><br>
   <br>Today's date is <% response.write(Date()) %>
   

Désactiver ASP

ASP doit être désactivé pour cette tâche. ASP est désactivé uniquement à titre d’exemple et pour les besoins des tâches décrites dans cet article.

Pour désactiver ASP

1. Ouvrez le Gestionnaire des services Internet (IIS).

2. Double-cliquez sur Restrictions ISAPI et CGI.

   

3. Sélectionnez Pages du serveur actif. Dans le volet Actions , sélectionnez Refuser pour désactiver ASP.

   

Activer le suivi des demandes ayant échoué

Après avoir activé le suivi des demandes ayant échoué, vous devez configurer l’emplacement des fichiers journaux. Dans cette tâche, vous allez activer le suivi des demandes ayant échoué pour le site web par défaut et spécifier où placer les fichiers journaux. Vous allez ensuite configurer l’échec pour lequel générer les journaux d’échec.

Étape 1 : Activer le suivi des demandes ayant échoué pour le site et configurer le répertoire du fichier journal

1. Ouvrez une invite de commandes avec des droits d’utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.

2. Exécutez inetmgr pour ouvrir le Gestionnaire des services Internet.

3. Dans le volet Connections, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.

4. Dans le volet Actions , sous Configurer, sélectionnez Suivi des demandes ayant échoué.

   

5. Dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué sur le site web , configurez les éléments suivants :

   • Cochez la case Activer .
   • Conservez les valeurs par défaut pour les autres paramètres.

   

6. Sélectionnez OK.

Échec de la journalisation du suivi des demandes est désormais activée pour le site web par défaut. Vérifiez le fichier .config %windir%\system32\inetsrv\config\applicationHost pour vérifier que la configuration se présente comme suit :

<system.applicationHost>
   <sites> 
      <!-- site & app defaults --> 
      <site name="Default Web Site" id="1"> 
         <!-- other site configuration --> 
         <traceFailedRequestsLogging  enabled="true" /> 
      </site> 
   </sites> 
</system.applicationHost>

Étape 2 : Configurer vos définitions d’échec

Dans cette étape, vous allez configurer les définitions d’échec pour votre URL, y compris les zones à suivre. Vous allez résoudre les problèmes d’une version 404.2 retournée par IIS pour toutes les demandes adressées aux extensions qui n’ont pas encore été activées. Cela vous permet de déterminer les extensions particulières que vous devez activer.

1. Ouvrez une invite de commandes avec des droits d’utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.

2. Exécutez inetmgr pour ouvrir le Gestionnaire des services Internet.

3. Dans le volet Connections, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.

4. Double-cliquez sur Règles de suivi des demandes ayant échoué.

   

5. Sélectionnez Terminer.

6. Dans le volet Actions , sélectionnez Ajouter.

7. Dans l’Assistant Ajout d’une règle de suivi des demandes ayant échoué , dans la page Spécifier le contenu à la trace , sélectionnez Tout le contenu (*) . Sélectionnez Suivant.

   

8. Dans la page Définir les conditions de trace, cochez la case Code(s) d’état et entrez 404.2 comme code status à suivre.

   

9. Sélectionnez Suivant.

10. Dans la page Sélectionner les fournisseurs de traces , sous Fournisseurs, cochez la case Serveur WWW . Sous Zones, cochez la case Sécurité et désactivez toutes les autres cases à cocher.

    Le problème que vous générez entraîne la levée d’un événement de trace d’erreur de sécurité. En général, les problèmes d’authentification et d’autorisation (y compris les problèmes de liste de restriction ISAPI) peuvent être diagnostiqués à l’aide de la configuration serveur WWW - Zone de sécurité pour le suivi. Toutefois, étant donné que la feuille de style FREB.xsl permet de mettre en évidence les erreurs et les avertissements, vous pouvez toujours utiliser la configuration par défaut pour journaliser tous les événements dans tous les domaines et tous les fournisseurs. Sous Détail, sélectionnez Verbose.

    

11. Sélectionnez Terminer. Vous devez voir la définition suivante pour le site web par défaut :

    

Le Gestionnaire des services Internet écrit la configuration dans le fichier à l’aide %windir%\system32\inetsrv\config\applicationHost.config d’une <location> balise. La configuration doit se présenter comme suit :

<location path="Default Web Site"> 
    <system.webServer> 
        <tracing> 
            <traceFailedRequests> 
                <add path="*"> 
                    <traceAreas> 
                        <add provider="WWW Server" areas="Security" verbosity="Verbose" /> 
                    </traceAreas> 
                    <failureDefinitions statusCodes="404.2" /> 
                </add> 
            </traceFailedRequests> 
        </tracing> 
    </system.webServer> 
</location>

Tester et afficher le fichier journal des demandes d’échec

Dans cette tâche, vous allez générer une demande ayant échoué et afficher le journal de trace résultant. Vous avez déjà configuré IIS pour capturer les journaux de trace pour http://localhost/*.asp les requêtes qui échouent avec un code de réponse HTTP de 404.2. Vérifiez maintenant qu’il fonctionne.

Étape 1 : Générer une erreur et le fichier journal de la demande d’échec

1. Ouvrez une nouvelle fenêtre internet Explorer.

2. Entrez l’adresse suivante : http://localhost/test.asp.

3. Vous obtenez une erreur « Erreur HTTP 404.2 - Introuvable ».

   

Étape 2 : Afficher le fichier journal des demandes d’échec

1. Maintenant que vous avez généré une demande ayant échoué, ouvrez une invite de commandes avec des droits d’administrateur et accédez à %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1.

2. Exécutez démarrer pour démarrer une fenêtre Internet Explorer à partir du répertoire .

   

3. Notez quelques points ici : quand IIS écrit le fichier journal des demandes ayant échoué, il écrit un fichier par demande ayant échoué. Une feuille de style freb.xsl est également écrite, une par répertoire. Cela est utile lorsque vous affichez les fichiers journaux des demandes d’échec (comme fr000001.xml dans cet exemple).

4. Cliquez avec le bouton droit sur le fichier journal pour l’erreur 404.2, puis sélectionnez Ouvrir avec>Internet Explorer. Si c’est la première fois que vous ouvrez un fichier de suivi des demandes ayant échoué, vous devez ajouter about :internet à la liste des sites approuvés, car la configuration de sécurité renforcée d’Internet Explorer est activée par défaut. Si c’est le cas, vous voyez les éléments suivants :

   

5. Dans la boîte de dialogue Internet Explorer, sélectionnez Ajouter... pour ajouter about :internet à la liste des sites de confiance. Cela permet au XSL de fonctionner. Vous verrez ce qui suit après avoir ajouté about :internet à la liste des sites approuvés :

   

   Un résumé de la demande ayant échoué est enregistré en haut, avec la table Erreurs & Avertissements identifiant tous les événements qui sont AVERTISSEMENT, ERREUR ou ERREUR CRITIQUE dans Gravité. Dans cet exemple, le niveau de gravité WARNING est dû à LA RESTRICTION ISAPI. L’image que vous avez essayé de charger était %windir%\system32\inetsrv\asp.dll.

6. Ouvrez le fichier XML brut directement à l’aide d’un éditeur de texte et examinez le contenu de chaque événement.

Résumé

Vous avez effectué deux tâches : la configuration du suivi des demandes ayant échoué pour capturer les traces pour toute requête retournée par IIS avec un code status 404.2 et la vérification que IIS a capturé la trace pour votre demande. Vous avez également vérifié que le fichier journal freb.xml ne contenait pas d’autres demandes pour les demandes que vous avez effectuées, car les requêtes n’avaient pas de code de retour 404.2. Lorsque vous consultez le fichier journal des échecs, vous avez déterminé que la cause de l’échec était que l’extension a été désactivée pour cette demande. Vous pouvez essayer d’autres pages non HTML (comme les fichiers .gif ou .jpg) et notez que le fichier journal n’ajoute PAS ces traces. Vous pouvez également facilement modifier cette valeur sur 404, ou capturer l’échec si la demande prend plus de 30 secondes en définissant le champ timeTaken dans vos failureDefinitions.

Restaurer votre sauvegarde

Maintenant que vous avez terminé les tâches décrites dans cet article, vous pouvez restaurer la sauvegarde de la configuration. Exécutez la commande suivante avec les droits d’utilisateur d’administrateur :

%windir%\system32\inetsrv\appcmd restore backup cleanInstall