Before installing the policy engine and starting the service, you need to configure some policy engine performance parameters and settings to determine how the policy engine applies policy to emails from unrecognized senders and to files when no other means are available to determine the policy participant. To do this, you edit the machine policy for the host machine. You need to modify these settings in the Policy Engine folder of the local machine policy:
Defaults to zero. A zero value means an unlimited number of policies can be retained in memory.
This setting defines the maximum number of user policies that the policy engine can hold in its memory at one time. Because each policy requires a significant amount of memory, this setting can prevent excessive memory usage.
Note that if the policy engine is already holding its maximum number of policies when it needs to load a new policy (in order to process an email from a sender whose policy is not already cached), it discards the least recently used policy before loading the new policy.
However, such policy swaps can significantly slow the processing for an individual email. For this reason, we strongly recommend that your policy engine host machine has sufficient memory so that you do not need to limit number of loaded policies. In fact, we recommend that the host machine can hold all the effective policies for your organization simultaneously.
Defaults to 5. This setting defines the maximum number of emails that can be processed simultaneously by a policy engine. It enables the policy engine to make the most efficient use of system resources. You do not normally need to change the default value. However, you may want to increase the maximum limit if the policy engine is running on a multiprocessor computer.
If this maximum limit is reached, the policy engine delays accepting any further emails from the policy engine hub until the number of emails being processed falls below this maximum limit. This means that when an email completes processing, another is accepted, so maintaining the number of emails at the maximum limit. For example, if five emails finish processing simultaneously, the policy engine immediately accepts five new emails.
This setting is provided for diagnostic purposes only. It specifies whether the policy engine can retrieve email address details and distribution list members from an LDAP directory. We strongly recommend that you do not change this setting!
Policy engines need to distinguish between ‘genuine’ emails and ‘embedded content’ emails (that is, EML emails containing embedded IM conversations, Bloomberg messages or other communications such as eFaxes). This is accomplished through the Embedded Message Identification policy setting.
This setting enables policy engines to detect embedded content emails and set the event type as ‘embedded IM’, ‘Bloomberg’, or ‘eFax’. For IM conversations, this setting can also be used to extract or set the IM network.
The default values for this setting enable policy engines to automatically detect:
However, if you want policy engines to detect other forms of embedded content (such as eFaxes or IM conversations embedded in EML files that were generated by third party applications), you need to add additional values to this policy setting.
Defaults to one hour. This setting is designed to maintain processing capacity. It specifies how long a thread must be inactive while processing an event before the policy engine considers the thread to have stalled.
To guard against any problems that might cause a policy engine to take an excessively long time to analyze an event, the policy engine monitors all processing threads. If it detects a deadlock, it creates a new thread for each stalled thread.
Defaults to 7 (days). This setting defines the frequency of policy time-outs. That is, the amount of time a policy engine retains a policy that has not been used. After this period of time, the policy is unloaded.
This setting specifies the name of a CA DataMinder user. It defaults to UnknownInternalSender; this user account is created automatically when you install a new CMS.
Policy engines use this setting to apply policy to emails sent from someone within your organization. The policy engine applies the Unknown Internal Sender’s policy if the sender’s address matches an address pattern listed in the Internal Email Address Pattern setting) but no corresponding user exists. For example, this can happen if a new recruit has an account in Active Directory but no CA DataMinder account has been created for them yet.
Important! You can specify a different account if necessary, but this setting must identify a user account, not a group account. Restart the policy engine for the changes to take effect.
This setting specifies the name of a CA DataMinder user. It defaults to ExternalSender; this user account is created automatically when you install a new CMS.
Policy engines use this setting to apply policy to external emails. That is, emails sent from someone outside your organization. The policy engine applies the External Sender’s policy if the sender’s address does not match an address pattern listed in the Internal Email Address Pattern setting (see below).
Important! You can specify a different account if necessary, but this setting must identify a user account, not a group account. Restart the policy engine for the changes to take effect.
This setting specifies a semicolon separated list of full or partial email addresses.
When the policy engine processes an email, it first checks the sender’s email address against these address patterns. If the sender’s address does match an internal address pattern, the policy engine attempts to map the sender onto an existing CA DataMinder user account.
The policy engine only expands the sender’s email address against the LDAP directory if it matches an address pattern in this list. Typically, you use this setting to detect emails sent by users within your organization.
The recipient details of an email are only expanded against the LDAP directory if the recipient’s address matches an item in this list. Therefore, if you want to expand recipients’ full details (for example, for policy testing), you must ensure that the list is comprehensive enough to match against all addresses you expect to encounter, for example, Exchange and SMTP addresses.
Address Book (MAPI) lookup operations are only performed for recipient email addresses matching an item in this list.
Note: This setting was formerly the policy engine hub registry value UserSpecificAddrPattern.
If an address does not match listed patterns (that is, the sender does not match any of the listed address patterns), the policy engine infers the sender is not a CA DataMinder user and:
If the sender address does match a listed address pattern but no corresponding CA DataMinder user exists:
Important! You must restart the policy engine for changes to this setting to take effect.
Address patterns can contain special characters, such as wildcards, spaces, quotes and semicolons:
/" or /;
This setting specifies the name of a CA DataMinder user. A policy engine will apply this user's policy to scanned, captured or imported files if no other means are available to determine the policy participant.
For example, if an Import Policy job for FSA scanning job omit to specify the policy participant, or if the specified user account does not exist, the policy engine applies the Default Policy for Files to the imported or scanned files.
|
Copyright © 2014 CA.
All rights reserved.
|
|