予定されていた保守を実行中のため、サポートサイトでのフォームの送信が一時的に利用できません。 すぐにサポートが必要な場合は、テクニカルサポートまでお問い合わせください。 ご不便をおかけして申し訳ありません。
オンラインヘルプの参照
登録の完了
サインイン
価格設定をリクエスト
営業担当に連絡
製品バンドルが選択されました。 リクエストにより良く対応できるように、個別の製品を選択していただけますか? *
現在、テクニカル・サポート・エンジニアはお客様のチャットに対応できません。 迅速にサービスを受けられるよう、サービス・リクエスト・フォームを使用して
お客様の説明に基づいて、以下の記事が問題解決に役立つ可能性があります。
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.
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.
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.
You must determine the requirements for gathering the Exchange tracking logs and for gathering the Exchange attributes.
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.
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.
Quest *product*のオンラインサポートヘルプは、関連会社のサポートサイトで参照できます。「Continue（続行）」をクリックすると、*product*の適切なサポートコンテンツとアシスタンスへ移動します。
The document was helpful.
評価を選択
I easily found the information I needed.
Quest Softwareポータルでは、IE8、9、10のサポートを終了しました。ブラウザを最新バージョンのInternet ExplorerまたはChromeにアップグレードすることをお勧めします。
IE 11へのアップグレード: ここをクリック
Chromeへのアップグレード: ここをクリック
の優れたセルフサービス機能を最大限に活用していただけるよう、IE8、9、10以外のブラウザをぜひご利用ください。
