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

Article
04/04/2023

S’applique à : Exchange Server 2013

L'indicateur d'intégrité de messagerie unifiée surveille l'intégrité globale du service de messagerie unifiée de votre organisation.

Si vous recevez une alerte indiquant que la messagerie unifiée présente un manque d'intégrité, cela signifie qu'un problème empêche probablement les utilisateurs d'utiliser le service de messagerie unifiée de votre organisation. L'indicateur d'intégrité de la messagerie unifiée est étroitement lié aux indicateurs d'intégrité suivants :

Dépannage de l’indicateur d’intégrité UM.CallRouter

Dépannage de l’indicateur d’intégrité UM.Protocol

Explication

Le service de messagerie unifiée est contrôlé à l'aide des sondes et moniteurs suivants.

Sonde	Indicateur d'intégrité	Dépendances	Moniteurs associés
UMSelfTestProbe	Messagerie unifiée. Protocole	Services de domaine Active Directory (AD DS) ;	UMSelfTestMonitor
UMCallRouterTestProbe	Messagerie unifiée. CallRouter	Services de domaine Active Directory (AD DS) ;	UMCallRouterTestMonitor

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

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

Repérez les noms de l'indicateur d'intégrité et du serveur dans l'alerte.
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 émis l’alerte :
```
Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}
```
  Par exemple, pour récupérer les détails de l'indicateur d'intégrité UM.Protocol à propos de server1.contoso.com, exécutez la commande suivante :
```
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "UM.Protocol"}
```
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 sera Unhealthy.
3. Réexécutez la sonde associée pour le moniteur dont l'état 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, supposons que le moniteur défectueux soit UMSelfTestMonitor. La sonde associée à ce moniteur est UMSelfTestProbe. Pour exécuter cette sonde sur server1.contoso.com, exécutez la commande suivante :
```
Invoke-MonitoringProbe UM.Protocol\UMSelfTestMonitor -Server server1.contoso.com | Format-List
```
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.

Étapes de dépannage

Quand vous recevez une alerte de l'indicateur d'intégrité, le message électronique contient les informations suivantes :

nom du serveur ayant envoyé l'alerte ;
heure et date de l'alerte ;
mécanisme d'authentification utilisé et informations d'identification ;
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é.

Les options SIP vers le service de messagerie unifiée ont échoué

Déterminez si le service de messagerie unifiée est désactivé. Si le service de messagerie unifiée n'est pas démarré ou est désactivé, redémarrez le service de messagerie unifiée.

Plus de {0}% des appels entrants ont été rejetés par le service de messagerie unifiée au cours de la dernière heure

Consultez les journaux d'événement sur le serveur d'accès au client afin de déterminer si les objets de messagerie unifiée, tels que umipgateway et umhuntgroup, sont configurés correctement.

Si les journaux d'événement ne contiennent pas assez d'informations, vous devez peut-être activer les journaux d'événements de messagerie unifiée au niveau Expert, puis consulter les fichiers journaux des traces de messagerie unifiée.

Plus de {0}% des appels entrants ont été rejetés par le processus de travail de messagerie unifiée au cours de la dernière heure

Moins de {0}% des messages ont été traités avec succès au cours de la dernière heure

Le service de messagerie unifiée Microsoft Exchange a rejeté un appel car le pipeline de la messagerie unifiée est plein.

Le service Edge A/V n'est pas configuré correctement ou n'est pas en cours d'exécution

Consultez les journaux d'événement sur le serveur de boîtes aux lettres pour tenter de déterminer pourquoi les appels du serveur Lync échouent. Ensuite, procédez comme suit :
- Vérifiez que le pool Lync sélectionné par le service de messagerie unifiée est opérationnel.
- Pour utiliser un serveur Lync particulier, exécutez la commande suivante :
```
Set-UMServer ExchangeUMServer -SIPAccessService <ServerName>
```

Le serveur de messagerie unifiée n'a pas pu obtenir les informations d'identification auprès du service Edge A/V Communications Server.

Consultez les journaux d'événement pour identifier le pool Lync sélectionné et vérifier qu'il est opérationnel.

Le serveur Edge Audio/Vidéo Communications Server n'a pas pu ouvrir un port ou allouer des ressources lors de la tentative d'établissement d'une session.