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

Archive Shuttle 11.4 - Administration Guide

Introduction Configuring Archive Shuttle Using HOTS Using the Archive Shuttle user interface Dashboards Manage Configuration Advanced configuration Monitoring Logging Reporting Journal Transformation migration Troubleshooting

Providing accepted domains for a migration

Accepted domains are used in a Journal Transformation configuration to limit which domains are enabled for migration.

Consider a large journal archive where there might be hundreds of SMTP domains contained within messages. If you know you are only interested in:

domain1.com

domain2.com

and no others.

You can set the Accepted Domains in the System Configuration to:

domain1.com

domain2.dom

and only those will be eligible for enabling for migration.

Why legal hold needs to be applied for data retention after migration

As part of any Archive Shuttle migration, all active user mailboxes must be put on litigation hold prior to any migration activity. This is not done by the product. It should be applied before migration begins and remain in place until the end of the migration project. By default Archive Shuttle does not allow migration to active user accounts during Journal Transformation if litigation hold is not applied.

·Preserve mailbox items deleted by users or automatic deletion processes such as MRM

·Preserve items indefinitely or for a specific duration

·Enable In-Place eDiscovery searches of items placed on hold

Once litigation hold is enabled the storage quota for the Recoverable Items folder is automatically increased from 30 GB to 100 GB for the primary mailbox and unlimited for the EOA (Auto expanding feature is required)

Automatically identifty known distribution lists and mark them as such

Under Journal Transformation, in the user interface, there is an option called ‘Auto-creation Rules Management’. This option allows an operator to create rules around email addresses to identify certain email addresses as distribution lists.

Operators can add a rule to automatically mark ‘mailboxes’ matching the expression as distribution lists. Recipients are evaluated frequently and compared against a list of known distribution lists for their organization. When a match is made that recipient is marked as ‘set as distribution list’ in the solution automatically.

JTDL

Enable logging

In this article we’ll discover information about log files and logging that can be performed by Archive Shuttle.

Logging Overview

All log files are centralised on the core server under the logging directory specified during installation.

It is rare to need to access module servers in order to review log files.

Logs are:

·Generated per module

·Roll over automatically (10 rollover files are kept)

·Default to ‘info’ level reporting

 

Important Log Files

Several important log files include:

WEBUI.TXT

This is the log file for all user interface interactions

ArchiveShuttle.WebServicesLog.txt

This is the web services log file. It contains server side information about module to core communication. It can show which tasks or commands were queued and executed.

ArchiveShuttle.Service.Log.txt

This contains information about execution of database updates, and scheduled tasks.

JCLogging

Module core logs

These have a *.ModuleName.Core.txt suffix. They contain communication between the core and applicable module.

Module client logs

These have a *.ModuleName.Client.txt suffix.

info

NOTE: All log files from a specific machine include the machine name in the filename, for easy identification.

Logging Levels

Module logging levels are controlled from the user interface. Go to Configuration > Modules > Select the desired module and choose the ‘Set Log Level’ button.  Changes take place almost instantly, there is no need for modules to be restarted.

Core logging level is set via System Configuration > General

Trace level logging is the most detailed.

Overview of a log file

JCLogFile

Key of terms

1.Date/time in UTC

2.Process ID

3.Hostname

4.Thread ID

5.Logging level

6.Function

7.Log entry

>> Implies the start of a request

<< Implies the completion of a request

Summary log file entries

Some log entries provide a summary of the modules current activity. This is often the visible report of a system’s health.

Entries can contain a lot of information to aid in troubleshooting:

·Current performance

·Resource conumption

·Current processing statistics

·Summary of actions taken

·Duration of actions taken

Here is an example:

JCLogfileentries

Errors, warning, exceptions

Log levels are used to clearly identify exceptions. All warnings are logged at WARN logging level. All exceptions are ERROR or FATAL log levels.

How to identify what log to look in

Many issues are highly reproducible. Try to identify the conditions resulting in an issue. Being able to reproduce an issue on demand helps issue resolution and investigation.

Determining which log file to look into often comes with experience.

·webui – user interface errors/issues

·services – database upgrades and scheduled task execution

·*client* – problems with an actual module

·*core* – problems with retrieving and processing of commands

How to adjust logging levels

Go to Configuration > Modules, then select the desired module and choose the ‘Set Log Level’ button.  Changes take place almost instantly and there is no need for modules to be restarted.

Core logging level is set via System Configuration > General.

Identifying the point of failure

At the highest level, Archive Shuttle recommends to:

·Enable trace level logging on the Core (if appropriate) and modules which may be involved in the issue

·Try to repeat the activity of action which resulted in an error (for example retrying failed items, or retrying a Stage 2 workflow command)

·Search the log files for ERROR

·Check the thread ID of that error message and search in the logs for everything that the thread has done around about the time of the failure.

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択