Dépannage de l’indicateur d’intégrité OWA

  • Article

S’applique à : Exchange Server 2013

Le jeu d’intégrité Outlook Web App (OWA) surveille l’intégrité globale du service Outlook Web App.

Si vous recevez une alerte indiquant qu’Outlook Web App n’est pas sain, cela indique un problème qui peut empêcher les utilisateurs d’accéder à leurs boîtes aux lettres à l’aide d’Outlook Web App.

Explication

Le service Outlook Web App est surveillé à l’aide des sondes et moniteurs suivants.

Sonde Indicateur d'intégrité Dépendances Moniteurs associés
OwaCtpProbe Outlook Web App Active Directory

Banque d'informations		 OwaCtpMonitor

Pour plus d’informations sur les sondes et les moniteurs, consultez Intégrité et performances du serveur.

Problèmes courants

Cette sonde peut échouer pour diverses raisons. Les plus courantes sont les suivantes :

  • Le pool d’applications Outlook Web App hébergé sur le serveur d’accès au client (CAS) analysé ne répond pas, ou le pool d’applications hébergé sur le serveur de boîtes aux lettres ne répond pas.
  • Le CAS rencontre des problèmes de réseau, et ne peut pas se connecter au ou serveur de boîtes aux lettres ou au contrôleur de domaine.
  • Les informations d'identification du compte assurant le contrôle sont incorrectes.
  • La base de données de l'utilisateur n'est pas montée, ou la banque d'Informations est inaccessible pour cette boîte aux lettres.
  • La banque d'informations ne répond pas.
  • Les contrôleurs de domaine ne répondent pas.

Action de l'utilisateur

Il se peut que le service ait récupéré après avoir émis l'alerte. Par conséquent, quand vous recevez une alerte signalant que l'indicateur d'intégrité n'est pas intègre, vérifiez tout d'abord que le problème existe toujours. Si tel est le cas, exécutez les actions de récupération appropriées décrites dans les sections suivantes.

Vérification de l'existence du problème

  1. Repérez les noms de l'indicateur d'intégrité et du serveur dans l'alerte.

  2. Les détails du message fournissent des informations sur la cause exacte de l'alerte. Le plus souvent, le message fournit des informations de dépannage suffisantes pour identifier la cause première. Si les détails du message ne sont pas clairs, procédez comme suit :

    1. Ouvrez Exchange Management Shell, puis exécutez la commande suivante pour récupérer les détails du jeu d’intégrité qui a généré l’alerte :

      Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

      Détails du jeu d’intégrité Outlook Web App sur server1.contoso.com, exécutez la commande suivante :

      Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "OWA"}

    2. Consultez la sortie de la commande pour déterminer quel moniteur a signalé l'erreur. La valeur AlertValue pour le moniteur qui a émis l’alerte est Unhealthy.

    3. Réexécutez la sonde associée au moniteur qui n'est pas intègre. Pour rechercher la sonde associée, reportez-vous au tableau figurant dans la section Explanation. Pour ce faire, exécutez la commande suivante :

      Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> | Format-List

      Par exemple, pour créer une sonde de surveillance Exchange ActiveSync sur server1.contoso.com, exécutez la commande suivante :

      Invoke-MonitoringProbe -Identity ActiveSync.Protocol\ActiveSyncSelfTestProbe -Server server1.contoso.com

    4. Dans la sortie de la commande, consultez la valeur Result de la sonde. Si elle indique Succeeded, le problème était une erreur passagère, qui n'existe plus. Autrement, reportez-vous aux étapes de récupération décrites dans les sections suivantes.

Actions de récupération OwaCtpMonitor

Une alerte par courrier électronique en provenance de l'indicateur d'intégrité contient les données suivantes :

  • nom du serveur ayant envoyé l'alerte ;

  • trace d'exception complète de la dernière erreur, notamment données de diagnostic et informations d'en-tête HTTP spécifiques.

    Remarque : vous pouvez utiliser les informations de la trace d’exception complète pour résoudre le problème. L'exception générée par la sonde contient un motif de l'échec qui décrit pourquoi la sonde a échoué. Par exemple, l’exception contient les informations suivantes :

    • MissingKeyword : un mot clé attendu est introuvable dans la réponse du serveur. Dans ce cas, l'exception contient les mots clés attendus.

    • NameResolution : la résolution DNS ne parvient pas à résoudre un nom de serveur donné.

    • NetworkConnection : la sonde reçoit un échec de connexion réseau lorsqu’elle tente de se connecter au pool d’applications OWA sur CAFE.

    • UnexpectedHttpResponseCode : la réponse comportait un code HTTP inattendu. Par exemple, le serveur a renvoyé un code HTTP 503.

    • RequestTimeout : le serveur a pris trop de temps pour répondre à une demande du client.

    • ScenarioTimeout : la sonde s’est terminée correctement, mais cela a pris plus d’une minute. Cela indique généralement une surcharge du système.

    • OwaErrorPage : Outlook Web App a retourné une page d’erreur. Le nom de l'erreur à l'origine de l'échec figure généralement dans le message d'exception.

    • OwaMailboxErrorPage : Outlook Web App a retourné une page d’erreur qui contient une erreur liée au magasin de boîtes aux lettres. Cela indique généralement que la banque de boîtes aux lettres est hors service ou que des boîtes aux lettres sont en cours de démontage.

    La trace de l'exception contient un champ important nommé FailingComponent. La sonde tente de déterminer la défaillance, comme dans l'exemple suivant :

    • Boîte aux lettres : la sonde peut atteindre Outlook Web App, mais elle ne peut pas se connecter au magasin de boîtes aux lettres. Dans ce cas, la sonde est défaillante ou la latence d'accès à la boîte aux lettres a entraîné l'échec de la sonde et généré une erreur ScenarioTimeout. Lorsque des échecs de ce type se produisent, vous devez contrôler l'intégrité des serveurs de boîtes aux lettres.

    • Active Directory : la sonde peut atteindre Outlook Web App, mais elle ne peut pas se connecter à Active Directory. Dans ce cas, la sonde a échoué ou les latences d’appel Active Directory peuvent avoir provoqué l’expiration du délai de la sonde. Lorsque ces types d’échecs se produisent, vous devez vérifier l’intégrité des contrôleurs de domaine, ainsi que les connexions réseau entre les serveurs d’autorité de certification et de boîte aux lettres, et les contrôleurs de domaine.

    • Owa : cela signifie généralement qu’une erreur s’est produite à l’intérieur de la couche Outlook Web App. Lorsque ces types d’échecs se produisent, vous devez vérifier l’intégrité du processus Outlook Web App sur les serveurs d’autorité de certification et de boîte aux lettres, et également vérifier les connexions réseau.

      L'exception contient également la dernière requête HTTP et les informations de réponse reçues avant la défaillance de la sonde. Le corps de l'escalade contient le chemin d'accès aux journaux de la sonde. Ces informations vous permettent de déterminer l'ensemble des requêtes HTTP web et des réponses envoyées lors de l'échec de la sonde. Ce fichier contient des données concernant uniquement les sondes défaillantes, car seules les tentatives qui ont échoué sont journalisées. Vous pouvez utiliser ces informations pour mieux comprendre la cause de l'échec du test.

  • Importance de la chute de la métrique de disponibilité (x%).

  • Chemin d'accès complet au dossier contenant les traces de requête HTTP complètes associées à la sonde. Par défaut, ces informations se trouvent dans le dossier %ExchangeInstallPath%Logging\Monitoring\OWA\ClientAccessProbe .

  • Heure et date de l'alerte.

Pour résoudre ce problème, procédez comme suit :

  1. Créez un compte d'utilisateur test, puis connectez-vous au CAS en utilisant ce compte. Par exemple, ouvrez une session à l’aide de https://<servername>/owa.

    En cas d'échec, testez en utilisant un autre CAS pour vérifier si le problème se produit sur un CAS spécifique et non sur le serveur de boîtes aux lettres.

  2. Vérifiez la connectivité entre le CAS et les serveurs de boîtes aux lettres. Utilisez ping.exe pour vérifier que tous les serveurs répondent.

  3. Recherchez dans l'indicateur d'intégrité OWA.Protocol des alertes indiquant qu'un problème affecte un serveur de boîtes aux lettres spécifique. Pour plus d'informations, consultez la rubrique Troubleshooting OWA.Protocol Health Set.

  4. Démarrez le Gestionnaire des services Internet, puis connectez-vous au serveur signalant le problème afin de déterminer si le pool d'applications MSExchangeOwaAppPool est en cours d'exécution sur le CAS.

  5. Dans le Gestionnaire des services Internet, vérifiez si le site web par défaut est opérationnel.

  6. Identifiez la base de données de boîtes aux lettres à l'origine de l'échec de la sonde, puis vérifiez que la base de données de boîtes aux lettres est active sur le serveur de boîtes aux lettres, et que la banque de boîtes aux lettres est intègre. Pour identifier les informations de GUID de la base de données défaillante, consultez les informations de la trace de l'exception. Chaque échec doit être associé à une entrée ressemblant à ceci :

    Starting Owa probe with Target: https://localhost/owa/, Username: _HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com*

  7. Copiez le GUID HealthMailbox, puis exécutez la commande suivante dans l'environnement de ligne de commande :

    Get-Mailbox -Monitoring -Identity <username>

    Par exemple, exécutez la commande suivante :

    Get-Mailbox -Monitoring -Identity HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com

    L'objet renvoyé vous permet de déterminer le nom de base de données de l'utilisateur ainsi que l'emplacement où réside la base de données active.

  8. Si vous avez configuré une redirection entre sites, il se peut que vous voyiez des sondes en échec et générant une erreur MissingKeyword. Cela se produit parce que, par défaut, les sondes CAS s'exécutent sur les comptes pour tout emplacement, et parce que la probe ne tente pas de tester un CAS sur un autre site quand elle utilise une redirection. Pour résoudre ce problème, vérifiez que les serveurs sur chaque se trouvent dans MonitoringGroups. Les CAS d'un groupe d'analyse donné effectuent le test uniquement avec des serveurs de boîtes aux lettres figurant dans le même groupe.

    Pour déterminer les groupes d'analyse pour vos serveurs, exécutez la commande suivante :

    Get-ExchangeServer | ft MonitoringGroup

    Pour modifier le groupe d'analyse sur un serveur, utilisez la cmdlet Set-ExchangeServer avec le paramètre MonitoringGroup. Par exemple, utilisez la commande suivante :

    Set-ExchangeServer -Identity "ServerName" -MonitoringGroup "Primary"

  9. Dans le Gestionnaire des services Internet, cliquez sur Pools d’applications, puis recyclez le pool d’applications MSExchangeOWAAppPool en exécutant la commande suivante :

    %SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeOWAAppPool

  10. Réexécutez la sonde associée, comme indiqué à l’étape 2c de la section Vérification de l’existence du problème.

  11. Si le problème persiste, recyclez le service IIS à l'aide de l'utilitaire IISReset ou en exécutant la commande suivante :

    Iisreset /noforce

  12. Réexécutez la sonde associée, comme indiqué à l’étape 2c de la section Vérification de l’existence du problème.

  13. Si le problème persiste, redémarrez le serveur.

  14. Une fois le serveur redémarré, réexécutez la sonde associée de la manière décrite dans l'étape 2c de la section Verifying the issue still exists.

  15. Si l'échec de la sonde persiste, vous avez peut-être besoin d'assistance pour résoudre le problème. Contactez un professionnel du Support Technique de Microsoft pour résoudre ce problème. Pour contacter un professionnel Support Microsoft, accédez au Support pour les entreprises, puis sélectionnez Serveurs>Exchange Server. Étant donné que votre organisation peut avoir une procédure spécifique pour contacter directement les Services de Support Technique Microsoft, assurez-vous de connaître d'abord les instructions propres à votre organisation.

Informations supplémentaires

Nouveautés d’Exchange 2013

Exchange PowerShell