サポートと今すぐチャット
サポートとのチャット

MessageStats 7.8.1 - Deployment Guide

MessageStats Architecture Overview Planning for Deployment Deployment Recommendations and Solutions

Locate the MessageStats Reports Server

Ideally, the MessageStats Reports IIS server should reside on the same computer as the SQL server that hosts the MessageStats database.

Co-location avoids moving information multiple times between servers and clients. Multiple hops can cause Windows security problems, as acknowledged by Microsoft. Clients tend to lose their credentials when accessing the reports site, and may reach the SQL Server as anonymous users and be unable to access the report information.

If co-locating the IIS report server and SQL database server is not possible, you must configure the SQL server to use SQL authentication. You must also configure the file used to create the data link for the reports to use a special SQL account so that the reports can access the MessageStats database as valid consumers.

Determine the Tracking Log Compression Requirements

Network administrators have specific tolerances for network traffic. Larger organizations can be more or less tolerant of the type of traffic that flows over the network.

Exchange tracking logs can grow very large, in the range of 10 to 30 gigabytes and may require compression before the log files are transported to the Task Execution Server for processing. Make the decision to compress tracking logs in consultation with your Exchange administrator. Compressing log files has a very small footprint on the Exchange server.

The MessageStats compression utility (QMSDeployment.exe, QMSCompress.exe) can reduce the size of the tracking log file by up to 80%, which is significant when transporting logs that are gigabytes in size. The compressed logs are not decompressed on the Task Execution Server. They are processed in stream, which means that they do not require extra disk space on the servers for processing.

For information about configuring the MessageStats compression utility on an Exchange server, see the chapter titled "Compressing Tracking Log Files" in the MessageStats Administrator Guide.

Plan the Data Collection Schedule

MessageStats depends on the Exchange tracking logs to deliver the activity and volume-based reports. The Default Gathering task, which includes the tracking log gathering, must not be scheduled until the tracking logs are closed. Typically, tracking logs are closed at midnight UTC, so Exchange objects can be collected at any time during the day. However, those objects will be dated on the UTC date they are retrieved.

A worldwide deployment must be tuned in consideration of business activities. To minimize the impact of data collection, tasks must be scheduled to run during off-business hours for the geographic area from which data is collected.

Collection must be planned to complete within a 24 hour UTC cycle. If tracking logs become backlogged and do not complete within 24 hours, collection and subsequent reports will not be accurate.

Consider the time periods when the reports web site will be accessed the most and avoid that time period when scheduling data collection.

Determine the Requirements for Gathering

Determine the Requirements for Gathering

You must determine the requirements for gathering the Exchange tracking logs and for gathering the Exchange attributes.

Optimal Gathering of Exchange Tracking Logs

Tracking logs are copied to Task Execution Servers to be analyzed and summarized into useful information for the activity-related reports. The analysis can create a large amount of information to be stored in the database, which should be located near the server doing the processing.

A best practice is to remotely compress the tracking logs and to copy the compressed log files to a central location for processing and storage.

The following diagram provides an optimal design for collecting tracking log files, which can include compression, allowing the log file processing to be executed near the database server.

Figure 1. Optimal design for tracking log collection.
Optimal Gathering for Exchange Attributes

Exchange attributes are collected and stored with little processing. This information is best collected near the Exchange servers themselves.

The following diagram shows how, by positioning the Task Execution Servers geographically near and by connecting to the Exchange servers that contain the information, you can optimize the amount of time required to perform a data collection.

Figure 2. Optimal design for collecting Exchange attributes.
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択