These general parameters can be used to configure any type of import operation. They cover such areas as the administrator account used to log in to the CMS, how individual events are associated with CA DataMinder user accounts (including the handling of imported events that do not match any existing CA DataMinder user), logging options and event queue handling.
(For Import Policy jobs only) Defaults to No. This parameter specifies how to implement the Import Policy feature. The syntax is:
Engine.UsePolicyEngineConnector=Yes, No or Hub
Import Policy provides a mechanism to connect Event Import to policy engines in order to apply policy triggers to events as they are imported. You can set this parameter to any of the following:
Event Import passes events directly to the local policy engine. The policy engine analyzes these events, applying policy triggers as necessary, and then replicates the events up to the CMS. If this parameter is set to Yes, you also need to configure the Policy Engine settings in the machine policy.
Event Import stores events in the local database without applying policy.
Event Import passes imported events to multiple (local or remote) policy engines via a policy engine hub (the policy engine connector). When a control trigger activates, a control event is generated and saved on the CMS (for example, a warning or blocking). If using this setting, you also need to configure the policy engine parameters in the import.ini template file on the machine hosting the policy engine hub.
Note: If Import Policy is in hub mode, you must edit the corresponding registry values to determine which user policy to apply to imported emails.
Using the iConsole, or Data Management console, these events on the CMS can then be searched for and reviewed in the normal way. But crucially, because the email has already been sent, the control action can never be invoked, so warning dialogs are not actually shown, emails are not actually blocked, and so on.
This specifies the name of an existing CA DataMinder user that is used to create new CA DataMinder users as necessary. The syntax is:
Engine.BulkImportUsername=<CA DataMinder user name>
This user must have the 'Events: Allow event import' and 'Events: Allow bulk session management' administrative privileges.
If Engine.BulkImportUsername is not specified in the command line or configuration file, Event Import prompts you for a user.
The account credentials specified by this parameter are the same as those set using the -setcredentials command line parameter.
Note: This parameter cannot be used with Import Policy.
This specifies the password for the CA DataMinder user specified by the Engine.BulkImportUsername parameter. The syntax is:
Engine.BulkImportUserpasswd=<CA DataMinder user password>
If Engine.BulkImportUserpasswd is not specified in the command line or configuration file, Event Import prompts you for a password.
Note: This parameter cannot be used with Import Policy.
Defaults to 10. This specifies the number of concurrent 'worker' threads used by Event Import to import events. The syntax is:
Engine.WorkerThreads=<number>
For Import Policy jobs, it is possible to use fewer worker threads. You only need to increase the number of worker threads if the policy engine hub is not receiving enough events to process.
Defaults to No. This specifies whether non-critical errors cause Event Import to stop importing events the first time an error occurs, or whether it logs the error and continues importing. The syntax is:
Engine.StopOnError=Yes or No
Note: Formerly known as Engine.EventNumberInQueueHigh.
Defaults to 250. This parameter specifies the maximum number of events that can be open in the importer at any one time. The syntax is:
Engine.EventNumberInImporterHigh=<number of open events>
If importing is slow due to excessive memory swapping, you can reduce the number of events held in the queue. When the number of events in the queue rises to the number specified by this parameter, further event imports are suspended until the number of events in the importer has fallen below the threshold defined by Engine.EventNumberInImporterLow (see below). This allows more time to process and store the pending events.
Importing from Exchange 2003
Important! If importing emails from Exchange 2003, Engine.EventNumberInImporterHigh must not be set above 200! This is because of a known issue with MAPI clients opening more than the default number of server objects. For details, see MS Knowledge Base article Q830829.
Note: Formerly known as Engine.EventNumberInQueueHigh.
Defaults to 200. This parameter specifies when import operations resume. The syntax is:
Engine.EventNumberInImporterLow=<numberof open events>
If event imports are suspended because Engine.EventNumberInImporterHigh has been reached, they only resume when the queue size falls below the Engine.EventNumberInImporterLow threshold.
This specifies the minimum retention period for imported events. The syntax is:
Engine.EventRetentionPeriod=<number of days>
That is, it defines how many days imported events are retained before they become earmarked for purging from the local database (typically the CMS). To specify that imported events never become eligible for purging, set this parameter to zero.
If this parameter is not set, the retention period for these imported events is determined by the Minimum Retention (Days) setting in the CMS policy.
Out of date emails are ignored
If the EMail.EventDateFromEMail parameter is set to Yes, then the capture date assigned to an imported email is derived from its delivery date or the date it was sent, not the date it was imported. However, the retention period is always calculated from an event’s capture date. This means that for some emails, the retention may have already expired before they can be imported. These ‘out of date’ emails are ignored by Event Import and excluded from the import job.
For example, an import job runs on 1 June, with an event retention period of 90 days. However, the import job includes an email sent on 1 January. Because 90 days has already elapsed since 1 January, the email is ignored by Event Import.
Note: This parameter cannot be used with Import Policy.
Defaults to 2. This determines the level of logging for the import process. The syntax is:
Engine.LogLevel=<number>
For example, you can configure Event Import to only log errors or important system messages. The supported logging levels are:
1 Errors only
2 Errors and warnings
3 Errors and warnings, plus informational and status messages.
Log entries are written to the evtimport_<instance name>_<date>.log file, where <instance> is the name set by the Event Import service wgnimpsv.exe and <date> is the date and time when the log file was created; find this file in the system\data\logs folder.
Note: Setting EngineLogLevel=3 will cause the log file to grow extremely rapidly. This level of logging is provided for testing purposes only.
Defaults to Unlimited. This specifies the maximum size for each log file. The syntax is:
Engine.LogMaxSizeBytes=<number of bytes>
When the current log file reaches its maximum size, the import process creates a new log file. Log entries are written to the evtimport_<instance name>_<date>.log file—for details see Engine.LogLevel.
Defaults to Unlimited. This specifies the maximum number of log files. The syntax is:
Engine.LogMaxNumFiles=<number of log files>
When the maximum number of log files exists and the maximum size of the latest is reached (see above), the oldest log file is deleted to enable a new one to be created.
Defaults to No. When importing emails from a third party archive, this parameter specifies whether to create temporary blob (Binary Large Object) files for each imported email. Event Import ignores this parameter when importing data from other sources, such as Exchange mailboxes or PST files. The syntax is:
Engine.SuppressBlobCaching=Yes or No
Set this parameter to Yes to prevent Event Import creating blob files. You may want to do this when importing emails from a third party archive in order to significantly boost import performance. Note that these temporary blob files are eventually deleted by event purges on the CMS.
By default, when email are imported, CA DataMinder stores the event locally, with each event comprising metadata, written to the CA DataMinder database and including general event details such an email’s delivery date, and a blob file containing the email content, saved on physical media and subsequently replicated to the CMS. When importing emails from an archive, the metadata for each event automatically includes a reference to the corresponding archive entry, so there is no need to save the email content in a blob file.
|
Copyright © 2014 CA.
All rights reserved.
|
|