Comment fonctionne l’Archivage des Messages Instantanés (IMs) dans la version OCS 2007 R2?
Cette fois-ci on s’intéressera plus précisément au rôle du serveur d’archivage, ses liens avec les autres composants et son fonctionnement interne.
Ce billet passera en revue aussi les points suivants:
Description et considérations générales
Architecture de l’archivage et fonctionnement interne
Configurations et topologies supportées
Exemple (en utilisant les outils tel que: Windbg,SQL Profiler…)
Description et considérations générales
La notion d’Archivage consiste à enregistrer les messages instantanés ( IMs ) échangés entre les usagers de communicateur Microsoft 2007 ou 2007 R2(MOC).
Qu’est-ce qui a changé par rapport à la version OCS 2007?
_ Archivage des messages Instantanés (IMs) et Enregistrement des détails (CDR) sont maintenant séparés
_ Amélioration de l’extensibilité comparée à la version OCS 2007
Qu’est-ce qui n’a pas changé par rapport à la version OCS 2007?
_ Possibilité d’archiver des messages de tous ou de certains utilisateurs
_ Pas d’archivage de type Audio ou Vidéo
_ Fonctionnement en mode critique pour respecter la légalité
Quand est-ce qu’il faut archiver?
Généralement la fonctionnalité d’archivage des messages est requise dans les cas suivants:
_ Respect de la légalité en vigueur (facteur dépendant des législations des pays)
_ Archivage des messages des partenaires fonctionnant en mode “fédération”
Pré-requis pour l’Archivage
Les pré-requis concernent notamment les composants logiciels dont la fonctionnalité d’archivage a besoin et les différents paramétrages à mettre en place. Entre autres, MSMQ est obligatoire pour cette fonctionnalité.
Aussi, être sûr que l’instance SQL qui héberge la base de données contenant le contenu des IMs (en clair ) et le serveur d’archivage (rôle) appartiennent au même site AD.
Message Queuing (MSMQ)
_ MSMQ doit être installé sur chaque front end
_ MSMQ doit être installé sur chaque serveur d’archivage
_ Ajouter l’ordinateur au groupe “Windows Authorization Access”
_ MSQM doit être installé avec l’intégration du composant Active Directory (AD)
Valeurs possibles pour la queue privée
_ Corps du message
_ En option (paramétrage par défaut d’OCS)
Même site AD pour l’instance SQL et le serveur d’archivage
Architecture de l’Archivage et fonctionnement interne
Pour bien comprendre l’archivage des messages instantanés, il faut connaitre le protocole d’échange de messages au niveau du protocole SIP (Session Initiation Protocol)
Des usagers qui s’échangent des messages peut être schématisé ainsi:
En fait le schéma ci-dessous montre à l’évidence que tout échange de messages instantanés transite par le serveur Front End (rôle dans OCS).
Le protocole qui sous-tend cette communication est le suivant:
Une architecture possible mettant en œuvre cette fonctionnalité d’archivage peut-être représenté comme suit:
Cette architecture ci-dessus se compose de 3 serveurs différents (pavés violets) :
_ Serveur Front End
_ Serveur d’Archivage
_ Serveur SQL
Les messages à archiver sont envoyés en mode transactionnel à la queue privée distante (lcslog) se trouvant sur le serveur d’Archivage par l’intermédiaire du processus RTCSRV.exe (Front End).
En fait, pour être encore plus précis, c’est le composant que l’on appelle communément (Agent d’Archivage) qui invoque la fonction MQSendMessage (du composant MSMQ) pour transmettre le contenu des messages instantanés (IMs)
Ce composant (Agent d’Archivage) n’est rien d’autres qu’un ensemble de threads implémentés dans le processus RTCSRV.exe. On verra cela en détails dans l’exemple avec l’outil Windbg.
Le service d’archivage (RTCArch.exe) de façon continue se met à l’écoute de la queue privée (lcslog). Ce processus lis tout message écrit dans cette queue. Evidemment, là encore ce processus (RTCArch.exe) invoque la fonction MQReceiveMessage de MSMQ et ensuite envoie le message au serveur SQL en invoquant par exemple la fonction CSprocDbLogMessage.
Une fois, le message est au niveau due serveur SQL, celui-ci invoque la procédure stockée “LogMessage” pour que le message soit persisté dans la base de données “lcslog” réservée à cet effet.
Ce n’est qu’une fois le message est écrit dans la bases de données “lcslog” et que le service d’archivage ait reçu un acquittement positif du serveur SQL que le message est effacé de la queue privée (lcslog).
Configurations et topologies supportées
Topologies supportées:
Un serveur d’archivage peut archiver des messages pour un ou plusieurs pools. Un pool représente un ou plusieurs serveurs Front End.
Un exemple de topologie peut-être représenté par les figures suivantes.
Configurations supportées:
Guide de planification
Un serveur d’archivage peut supporter jusqu’à 300000 utilisateurs.
Configuration
Activer le contenu de l’archivage
_ Configurer l’archivage au niveau global pour les communications intra-entreprise et les communications en mode fédération
_ Activer le contenu de IMs à archiver
_ Valider l’archivage en mode critique( option )
_ Associer un serveur d’archivage avec un serveur Front End
_ Notifier aux utilisateurs fédérés que les conversations IMs sont archivés
Exemple
Prenant un exemple où un utilisateur A envoi un message à autre utilisateur B.
Dans notre cas, Yannis envoie le message “Test Archiving Messages” à l’utilisateur “Administrator” comme la figure suivante le montre:
Avant d’envoyer le message, attacher d’abord le debugger “Windbg” au processus RTCSRV.exe et s’assurer que vos symboles sont corrects.
Pour se faire, vous pouvez utiliser la commande .symfix pour avoir les symboles publiques.
Et poser un point d’arrêt au niveau de la fonction MQSendMessage (bp mqrt!MQSendMessage;g) :
Une fois le message envoyé, le processus RTCSRV.exe s’arrête quand la fonction MQSendMessage est invoquée et le contenu de la pile du thread contient:
et c’est le thread numéro 30 qui fait appel à cette fonction (dans ce cas précis):
Vous pouvez poser des points d’arrêt au niveau du processus RTCArch.exe ( Service d’archivage) pour suivre l’éxecution de ce méchanisme d’archivage, à savoir:
bp MQRT!MQReceiveMessage ==> pour recevoirle message de la queue
MSMQ (lcslog)
bp RTCArch!CSprocDbLogMessage::CSprocDbLogMessage ==> pour envoyer le message à archiver dans la base de données (LcsLog).
Pour voir comment et par quel moyen le serveur SQL persiste ce message, il suffit de prendre une trace SQL profiler et filtrer sur le contenu du message envoyé par exemple (Test Archiving Messages)
On constate que le serveur SQL fait appel à la procédure stockée (LogMessage) pour écrire le contenu du message (IM) dans la table “Messages” de la base de données LcsLog