Chat now with support
Chat with Support

MessageStats 7.8.1 - Deployment Guide

MessageStats Architecture Overview Planning for Deployment Deployment Recommendations and Solutions

Recommendations for Large Installations

MessageStats is designed to work efficiently immediately after it is installed. The Default Gathering is the quickest gathering, stores the least amount of information, and is designed for performance.

When MessageStats is run in a large-scale environment with more than 50 Exchange servers, large Exchange tracking logs can cause the database to grow significantly in a short amount of time, despite MessageStats optimizations to store a minimum amount of data.

Database growth can lead to gathering problems if there is insufficient memory available on the database server, or if the Microsoft SQL Server version is not set to support more than 2 GB of RAM. To process large amounts of data, SQL Server must have the appropriate resources available.

Database performance can be affected by platform software that is not enterprise quality.

Recommended Hardware and Software

For large installations, it is recommended that you run 64-bit Microsoft SQL Server 2012 or later (Enterprise Edition). The 64-bit version ensures that sufficient RAM is allocated.

MessageStats calculates statistics for each mailbox and against each Exchange server, and the calculations require locks on several tables at once. MessageStats performs the calculations at gathering time rather than at report time to ensure report rendering performance.

Even on a server with 4 GB of RAM, the full 4 GB is not available to programs. Regardless of the amount of physical memory, Windows uses a virtual address space of 4 GB, with 2 GB allocated to user-mode processes (such as applications) and 2 GB allocated to kernel-mode processes (such as the operating system and kernel-mode drivers). Since there are usually other user applications on the server, only about 1.3 GB of RAM is likely dedicated to SQL, rather than the 2 GB maximum that Standard Edition uses.

It is recommended that you use a computer with a minimum of 16 GB of RAM, and the 64-bit version of Microsoft SQL Server 2012 or later, Enterprise Edition, when running in large scale environments.

For a detailed list of the hardware and software prerequisites, see the MessageStats Quick Start Guide.

Deploying a Distributed Installation Using Windows Authentication

Typically, if you install the MessageStats database and the MessageStats reports server on separate computers, you would use SQL authentication.

However, if you want to use Windows authentication, you must set up Kerberos delegation from the MessageStats Reports server to the MessageStats Database server.

The following steps explain how to set up Kerberos delegation for installations in which the MessageStats database and reports are installed on separate servers. Procedures are provided for each step.

1. Register the MSSQLSvc SPN with the run-as domain account.

2. Enable delegation from the Reports Server to the Database Server.

3. Specify Windows authentication in the QMSReports.udl file.

4. Enable IIS Settings and Restart IIS.

1. Register the MSSQLSvc SPN with the run-as domain account.

To set up delegation to MessageStats database server, the MSSQLSvc Service Principal Name (SPN) for the SQL Server instance that hosts the MessageStats database must be registered with the run-as domain account.  The SPN must be in the following format:

MSSQLSvc/fully-qualified server DNS name:TCPport

For example, if the server’s fully qualified DNS name is QMS-DB.QMS-RP.QC.CA.QST and the port number is 1433, the SPN would be:

MSSQLSvc/QMS-DB.QMS-RP.QC.CA.QST:1433

When the SQL Server service runs as a machine account (such as LocalSystem, NetworkService, or LocalService), the SQL Server service automatically registers the appropriate MSSQLSvc SPN with the domain machine account.  In this case, you do not need to register the SPN manually.

However, when the SQL Server service runs as a domain user account, you must register the MSSQLSvc SPN manually with the AD user object.  To determine the required SPN, you need the following information:

•
the fully-qualified DNS name of the server
•
the TCP port of the SQL Server instance hosting the MessageStats database. 

To find the TCP port of the SQL Server instance, you can view the IP Addresses property page for the TCP/IP protocol in the SQL Server Configuration Manager.

To determine the TCP Port Number
1
On the SQL server that hosts the MessageStats database, open the SQL Server Configuration Manager.
2
Select Protocols for the instance that hosts the MessageStats database and select TCP/IP in the list.
3
Click the IP Address tab and view the TCP Port number.

Once you know the TCP port and fully-qualified server name, use the SetSPN utility to register the SPN with the run-as account. 

For example, suppose the SQL Server instance is on TCP port 1433 of server QMS-DB.QMS-RP.QC.CA.QST and is running as the domain account QMS-E10\db-svc. You would register the MSSQLSvc SPN with the domain account by entering the SetSPN command as follows:

setspn -A MSSQLSvc/QMS-DB.QMS-RP.QC.CA.QST:1433 QMS-E10\db-svc

Register the SPN with only one Active Directory object. Delegation will not work properly if the SPN is registered with more than one AD object.  To verify this, you can use the SetSPN utility included with Windows.

The SetSPN utility has a -X switch that shows any SPNs that are registered to more than one AD object. 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating