Skip to main content link. Accesskey S
  • HCL Logo
  • HCL Notes and Domino wiki
  • THIS WIKI IS READ-ONLY. Individual names altered for privacy purposes.
  • HCL Forums and Blogs
  • Home
  • Product Documentation
  • Community Articles
  • Learning Center
  • API Documentation
Search
Community Articles > Lotus Domino > Domino messaging > Reading the MTSTORE Database
  • Share Show Menu▼
  • Subscribe Show Menu▼

Recent articles by this author

Reading the MTSTORE Database

The MTSORE database contains a wealth of information concerning the email that moves through your Domino Domain. This article is intended to show you how to read that database using a simple LotusScript program.
Community articleReading the MTSTORE Database
Added by ~Autumn Quetresazennivu | Edited by ~Autumn Quetresazennivu on November 2, 2010 | Version 4
  • Actions Show Menu▼
expanded Abstract
collapsed Abstract
The MTSORE database contains a wealth of information concerning the email that moves through your Domino Domain. This article is intended to show you how to read that database using a simple LotusScript program.
Tags: LotusScript, mtsore, mtstore.nsf, messaging

Within Lotus Domino there is a facility called Message Tracking.  Message Tracking is a very useful tool that allows you to monitor every email that travels across every server in your Domino Domain. First, to give a complete explanation of exactly what Message Tracking is, let's take a look at what the Domino Administrator help says about the topic:

 

After you enable message tracking on the server, the Mail Tracking Collector (MT Collector or MTC task) automatically creates the IBM® Lotus® Domino® MailTracker Store database (MTSTORE.NSF) in the MTDATA subdirectory of the Domino data directory. The MTC task periodically collects messaging information from raw data accumulated in special mail tracker log files (MTC files) produced by the Router. After collecting this message summary information -- information about the originators, recipients, arrival times, and delivery status of the messages processed by the server -- it adds it to the Domino MailTracker Store database. Mail users and administrators use the information stored in the Domino MailTracker Store to complete mail tracking requests and to generate mail usage reports.

 

It is this MailTracker Store database, MTSTORE.NSF, that we wish to investigate in this article.  Much information is stored in this database allowing the Domino administrator to be able to track individual messages through the system, to report on messages sent from or delivered to a particular individual, or to generate summary reports on all or a portion of the data contained therein. There are several "canned" reports that can be generated. The motivation to write this article comes from the fact that most of these pre-built reports, while being, interesting, are very limited in their content and thus not especially valuable in reporting on the message traffic in the Domino domain. However, this does not diminish the fact that the database can contain a wealth of information that, if properly analyzed, can provide useful reports which will describe the mail traffic in a logical and concise manner.

Enabling and Configuring the Message Tracking Facility

Before you can utilize the Message Tracking facility you must fill in some configuration information in your Domino Server Configuration document. The diagram below shows the section of the server document that you must configure:

 
  alt text
 

You will notice that, by default, the Message Tracking facility is not enabled.  To enable the facility, edit the configuration document and change the value in the Message tracking field to Enabled. The next thing to do is to decide if you are going to track message subjects. On the surface it would seem that you would always want to track subjects to have the information available for research and for reporting. However, some organizations have security policies that restrict what information can be retained so it is best to investigate your company's security policies before implementing this feature.

 

As you can see you can exclude some individual users from the message tracking facility and you can also exclude some users from having their message subjects logged.  This will give you more flexibility when making your case with management concerning why you want to enable Message Tracking. Some companies will want certain individuals excluded.

 

You will need to consider the Message Tracking Collection Interval and determine the proper value. This value controls how often information is written to the MTSTORE database. It does not control how often the information is collected. Once Message Tracking is enabled, information on all non-excluded messages is continually collected. The interval value controls how often this information is written to the database. On extremely busy mail servers you may need to shorten the collection interval. This will help in memory management and possibly relieve any performance burden that might be caused by using the memory to collect so much information. However, 15 minutes should work for most systems. My experience has been with servers having up to 2000 users and I have seen no impact from implementing this facility. However if you are working on larger systems you may want to occasionally monitor the memory usage and test to see if a shortened collection interval is warranted.

 

Be sure to fill in who can track messages. I would recommend that you add the LocalDomainServers group since you may want to track messages across all servers. You will also want to include the names of the people who will be allowed to use the tracking facility and to generate reports. Most likely this will be your administrators and/or managers so a group containing those names would be the best approach.

 

Generating Reports

 

Once the Message Tracking facility is enabled data will be collected and you can begin generating reports.  From the Domino Administrator Help:

 

After you set up the IBM® Lotus® Domino® MailTracker Store database, you can use the Reports database (REPORTS.NSF) to generate and store mail usage reports. Although the Reports database is created automatically when you set up the server, before you can generate mail usage reports, you must set up security for the database.

To create the Reports database

  1.    From the Domino Administrator, IBM® Lotus® Notes® client, or IBM® Lotus® Domino® Designer client, choose File - Application - New.

  2.    At the bottom of the New Application dialog box, click Show advanced templates.

  3.    Complete these fields and click OK:

Field

Enter

Server

The name of the server that stores the Mail Tracking Store database (MTSTORE.NSF)

Title

Reports

File name

Reports.nsf

Template server

The name of the server entered in the Server field

Template

Reports.ntf

To set up security for the Reports database

Note  Step 4 of this procedure requires use of the Domino Designer client.

  1.    Open the Reports database and choose File - Application - Access control to open the database ACL.

  2.    Verify that the server and the server administrator have Manager access, then click OK.

  3.    With the Reports database active in your client, choose View - Agents.

  4.    Verify that the scheduled agents (Daily, Monthly, and Weekly Report Agents, and the Housecleaning agents) are enabled. Enable agents as necessary by selecting the agent and clicking Enable; then close the Domino Designer.

  5.    From the Domino Administrator, click the Configuration tab, open the Server document for the server where you created the Reports database and click the Security tab.

  6.    In the Programmability Restrictions - Run unrestricted methods and operations field, enter the names of administrators who need access to the Reports database, and then click Save & Close.

 

Open the Reports.Nsf database:

 
  alt text
 

If you click on "New Report" you will get a dialog box from which you can select the type of report you want to generate:

 
  alt text
 

As you can see there are eleven reports from which you can choose.  I would suggest that once you have Message Tracking enabled, generate a sample of each of these reports and see if they meet your needs. If so, you may want to mark the new report as one that should run on schedule.  You can run the report once, or you can schedule it to run daily, weekly, or monthly:

 
  alt text
 

The reports that are generated are stored in the Reports.Nsf database or they can be mailed to the desired recipients.

 

The purpose of this article is not so much to teach you how to use these reports but more to show you how to generate other reports that might be more useful. For example, the "Top 25 Users by Count" is nice but what about the other hundreds or thousands of users that you may have? How can you tell how many emails the 26th highest user by count may have had? There is no way, with the built in reports, to report on this kind of information. 

 

You may run into other issues when running these reports.  If you have hundreds, or even thousands of users, and if you keep the Message Tracking information in the MTSTORE database for long periods of time you will accumulate very large amounts of tracking data. In these situations, it can take a very long time to generate some of these reports, especially if you want the report to include all of the data for something like a Message Volume Summary. In that case, you very likely will not be able to generate the report you have selected or at a minimum it will take a very long time to run the report.

 

What we want to discuss here is the layout of the records in the MTSTORE.NSF and how to write a LotusScript program that can read those records and store the data in such a way that views can be created that give meaningful reports.  Of course, other programs could be written to generate the reports in a more visually pleasing format or, if you wish, you could easily export the information and generate the reports in something like a Lotus Symphony or other spreadsheet program.

 

The MTSTORE.NSF Database

 

The MTSTORE.NSF Database probably contains far fewer actual records than you might expect. However, each record can contain a tremendous amount of data. The database does not store a single record for each email that passes through the system. Instead, each record is a table which contains information on many emails. The information is arranged so that it can be read by using an index method that links the various pieces of information for each email. Exactly what information is recorded for a particular email?  It depends on what you are recording. You get the name of the sender, the name of the recipient, the date and time the document was delivered, the size of the document, the names of each server the email passed through before being delivered,  and, if you have selected to record the information, you will have the subject line of the email. Other information, including but not limited to such things as as the Universal Document ID, the Message Type, and the document Originator are also collected.

All of this information is kept in the MTSTORE.NSF database and can be used to generate whatever reports you may need.

In this article I will show samples of the headers in the records contained in the MTSTORE.NSF database but I will not show the actual data since that information might be sensitive on my production servers. I suggest you open your own MTSTORE.NSF file and look around. CAUTION:  Do not attempt to edit the MTSTORE.NSF records directly. Unpredictable and Undesirable results WILL occur.

The records in the MTSTORE.NSF files are made up of tables. Those tables have cells defined which contain the information about each of the email documents.  Once the tables in a record have recorded information for up to 200 email documents, a new record will be generated. It is possible that a record will contain less than 200 entries in situations where the message tracking server has been restarted. On a server shutdown, the information that has been collected since the last interval expiration will be automatically written to the database and the record will be closed to further updates. Here is a list of the information contained in each table and cell:

Table 1:

DISPSTAT - 1=unknown 2=inqueue 4=delivered 8=delivery_failed 16=transferred 32=transfer_failed 64=group_expanded  1073741824=deleted

DISPTM - Time this message was dispatched

MSGTM - Time this message entered the tracking system.

MSGSZ - Message Size

MSGTYPE  - 1 =unknown 2=memo 4=deliveryreport 8=nondeliveryreport 16=returnreceipt 32=phonemessage 64=tracereport 128=notice

 

Table 2:

MTA  - Current mail server.

PREMTA - Mail server from which this message was transferred.

NEXTMTA - Mail server to which this message will be transferred.

 

Table 3:

UNQMSGID - Universal message id that does not change for this document.

INMSGID -

OUTMSGID

 

Table 4:

INORG  - Document originator.

OUTORG - Usually the same as INORG.

INRCP - Document recipient.

OUTRCP - Usually the same as INRCP

 

Table 5:

 

SUBJ  - Subject line of the message.

NODELREA -

 

When looking at these tables it is useful to know the legend that accompanies this database:

 

Legend:

Magenta = meta data           Gray = message data          Blue = recipient data

DISPSTAT: 1=unknown 2=inqueue 4=delivered 8=delivery_failed 16=transferred 32=transfer_failed 64=group_expanded  1073741824=deleted

MSGTYPE: 1=unknown 2=memo 4=deliveryreport 8=nondeliveryreport 16=returnreceipt 32=phonemessage 64=tracereport 128=notice

 

So we have five tables that contain information about our email. We see that information in each table is linked to the previous table and the next table by the location into which the information is stored. For example, the first entry in each cell represents the collection of information for the first email. For demonstration purposes I have created five tables here with the same header names in each cell that  you will find in the MTSTORE.NSF database. I have generated "test" data to illustrate the content of each cell:

 

 

DISPSTAT

DISPTM

MSGTM

MSGSZ

MSGTYPE

 

 

 

 

 

16

10/31/2010 05:05:00 AM

10/31/2010 05:05:00 AM

34260

2

 

MTA

PREMTA

NEXTMTA

 

 

 

MYMAILServer/MyDomain

YOURMAILServer/MyDomain

OutBoundSMTPServer/MyDomain

 

 

UNQMSGID

INMSGID

OUTMSGID

 

 

 

OFFFA44C71:F41BB47F ON442577CD:00368A20

OFFFA44C71.F41BB47F-ON442577CD.00368A20-442577CD.00367063

OFFFA44C71.F41BB47F-ON442577CD.00368A20-442577CD.00367063

 

 

INORG

OUTORG

INRCP

OUTRCP

 

 

 

 

Test User/MyDomain

Test User/MyDomain

internetuser@inter.net

internetuser@inter.net

 

 

SUBJ

NODELREA

 

 

First Test Message

`z

 

Here is some sample code to read the MTSTORE.NSF database:

 {Code;}<

Sub Initialize

      REM This routine is designed to read the MTSTORE database and then use

      REM that information to create an individual record for each email that

      REM is recorded. The records I create will contain the sender, the

      REM recipient, the delivery timestamp, and the message size. Keep in

      REM mind that when you are figuring out how many emails you are

      REM processing, you will find that it will be the number of NSF

      REM documents in the MTSTORE database multiplied by 200. So be prepared

      REM for a lot of records. In my testing, I have included this agent in

      REM a database with several other agents. I wanted to know how many

      REM documents each of my users has sent and received so I wrote an

      REM agent that reads the view where this agent stores all the documents

      REM and that second agent counts to see how many each user has sent and

      REM received and then a summary record containing that count is built

      REM for each user. Remember that when you read the sender and recipient

      REM names, you may be seeing the normal Notes Hierarchical name or you

      REM might see the name in an internet format such as,

      REM jdoe@mydomain.com. If the name is of the internet format, I chose

      REM to write code in another agent that converts the internet format

      REM into the associated Notes Hieracrhical name. I can then generate a

      REM report that has totals for all email showing up under the correct

      REM name.

     

      Dim s As New NotesSession

     

      Dim db As New NotesDatabase( "", "" )

      Dim data As NotesDatabase 'This will be where we store the docs

      Dim newdoc As NotesDocument

      Dim dc As NotesDocumentCollection

      Dim doc As NotesDocument

      Dim view As NotesView

      Set data = s.CurrentDatabase 'Notice that our agents run from here

     

      'I have copy of the mtstore.nsf on my local machine

      Call db.Open( "", "messagetracking\\mtstore1031.nsf" )

      reccount =1

     

      Set dc=db.AllDocuments  'Go get all the documents at the beginning

      Set view=db.GetView("MailTracking Data")

     

      If  Not(view Is Nothing) Then 

            Set doc=view.GetFirstDocument

           

            While Not(doc Is Nothing)

                 

                  For i=0 To Ubound(doc.inorg)

                  Print "Working on document number "+reccount+" and index= "+Cstr(i)

                        Set newdoc =New Notesdocument(data)

                       

                        'If Instr returns True the inorg field does

                        'not contain a name, but contains a number which can

                        'be extracted and used to find the name of the

                        'sender. What this says is that the correct sender        

                        'name is the value at the index indicated by that

                        'number. This technique cuts down on the amount of

                        ‘data that actually has to be stored in the database.

                        ‘Usually, the index will point to the last entry.

 

                        If Instr(doc.inorg(i),"`") Then

                             

                              first=Strleft(Strright(doc.inorg(i),"`"),"`")

                             

                              counter=Cint(first)

                              Newdoc.sender=doc.inorg(counter)

                             

                        Else

                             

                              Newdoc.sender=doc.inorg(i)

                             

                        End If

                       

                        If Instr(doc.inrcp(i),"`") Then

                             

                              first=Strleft(Strright(doc.inrcp(i),"`"),"`")

                             

                              counter=Cint(first)

                              Newdoc.Recipient=doc.inrcp(counter)

                             

                        Else

                              Newdoc.Recipient=doc.inrcp(i)

                        End If

                        Newdoc.TimeStamp=doc.msgtm(i)

                        Newdoc.MessageSize=doc.msgsz(i)

                        Call newdoc.Save(True, False)

                       

                  Next

                        Set doc = view.GetNextDocument(doc)

                        reccount=reccount+1

            Wend

      End If

     

End Sub

 >{code}

Be aware that to run this agent you must take several steps first:

 

  1. Create a new database with a blank template.
  2. Create a form for you records. This form must contain the fields indicated in this program that are being written in the Newdoc document.
  3. Create views to be able to see the documents.
  4. You may want to create other forms for summary data.
  5. You may want to create a wide assortment of views to be able to view the data from different perspectives.
  6. Include this agent and you may, of course, wish to write other agents that can perform actions such as creating summary data, or creating other records that suit your individual needs.

.

After the agent has run, the database will contain a single record for each email that has been either sent or received. In my test I had over 400 documents in the MTSTORE.NSF database which, multiplied by 200, means I had over 80,000 records.  After creating those records I then needed to summarize those records into one record for each user. That one record, maybe for John Doe, would contain the number of email documents sent and the number received for Mr. Doe. I could then create views in my database to allow a visual report of how much email each person is sending and receiving for a given time period. It is important to note that email sent or received by a particular individual may show up with the hierarchical name or a variety of internet address formats. As a simple example consider the following:

 

John Doe/MyDomain

jdoe@mydomain.com

 

Both of these addresses refer to the same person. If you want your reports to be accurate you may find that you need to write some programs to collect the data together and to figure out just how many different formats a person's name may take.

 

The information contained in this document is not guaranteed to be totally accurate and if you run the code given herein, you do so at your own risk. Please review each line to make sure it applies correctly to your environment.




 

  • Actions Show Menu▼


expanded Attachments (4)
collapsed Attachments (4)
Edit the article to add or modify attachments.
File TypeSizeFile NameCreated OnDelete file
image/jpeg 62 KB configmsgtrack.JPG 11/2/10, 2:22 AM
image/jpeg 37 KB reportsdb.JPG 11/2/10, 2:26 AM
image/jpeg 37 KB newrpt.JPG 11/2/10, 2:28 AM
image/jpeg 29 KB rptsched.JPG 11/2/10, 2:30 AM
expanded Versions (1)
collapsed Versions (1)
Version Comparison     
VersionDateChanged by              Summary of changes
This version (4)Nov 2, 2010, 2:39:28 AM~Autumn Quetresazennivu  
expanded Comments (0)
collapsed Comments (0)
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedAbout
  • HCL Software
  • HCL Digital Solutions community
  • HCL Software support
  • BlogsDigital Solutions blog
  • Community LinkHCL Software forums and blogs
  • About HCL Software
  • Privacy
  • Accessibility