An ELOxc instance always has a unique name during a service installation, is bound to a server type and always requires a compatible configuration version. At the same time, the configuration fragment of the instance ("InstanceDef") is the root of all other configuration fragments belonging to the instance.

The following illustrates a sample configuration in the ELOxc Console:

The following areas can be defined in the instance fragment:

• Execution mode of the instance
• Catalog
• Log settings
• Global parameters
• Parameters for processing addresses
• ELOix connection settings

The main form shows only the most important settings. If you want to configure more specific parameters, click Advanced to open the advanced configuration settings.

Alternatively, you can click the Edit XML button to modify the XML format of the configuration. In this case, you see a configuration fragment as it is shown in the additional text of the associated SORD.

Execution mode

When the service starts, all registered instances are executed. The first execution step is to load the corresponding configuration. If this process is successful, the instances are activated and are in execution mode. The default execution mode of an instance is an interval control ("interval" value) that specifies the interval between jobs. The range is from 5 minutes to 999 days, 23 hours, 59 minutes and 59 seconds, and the input format is 000:00:00:00.

The second time-triggered method can be configured with the value "daily" and allows you to set fixed daily execution times, which allows you to accommodate special requirements in the configuration of ELOxc, for example. In this case, the configured time specifications are applied and the day portion of the value is ignored, i.e. only hours, days, and minutes are valid. ELOxc will select the next possible execution time from the list starting from the current time. The instance goes into wait mode for the required duration.

"Once" mode means that the instance only runs once when the service starts. This is particularly suitable for direct calls from the command line or for test runs. The setting "Idle" enables you to load an instance without activating it. Unlike the "Interval", "Daily" or "Once" modes, processing does not take place until the start command has been explicitly issued via the ELOxc Console or the command window.

The mode "On Request" puts an instance in a state that allows you to trigger partial processing of the overall configuration. The data source, the action tree and even the container can be transferred as parameters within the data source. This method has restrictions in that the selected data source was also included in the configuration of the selected action tree in the ELOxc configuration. It is possible to restrict it to a specific container.

The last execution mode is "Creator". When this state is enabled, no data is transferred to the ELO repository. Instead, elements can be transferred to the Exchange Server. The classes allowed are messages ("IPM.Note"), calendar entries ("IPM.Appointment") and contact data ("IPM.Contact"). This mode is used when ELOxc interacts with ELO Business Solutions, for example.

Catalog

The catalog of an instance determines the maximum amount of available data sources. Action trees can only use data sources that are in the catalog. Besides the aspects of reproducibility and separating processing instructions, this complies with the authentication principle based on impersonation. In addition to the use of selection filters, a catalog defines above all the catalog registration of the ELOxc service user, who must not only be authorized to compile the catalog, but must also be able to carry out subsequent impersonations during processing.

The default catalog type is "ldap", which connects to the local Active Directory in the conventional way and determines the available mailbox owners using the filter

(&(objectCategory=person)(objectClass=user)(cn=*)).

If you modify the filter to restrict the selection to an organizational unit, for example, you must ensure that the resulting data records are suitable and contain the necessary attributes that ELOxc requires for processing. We therefore recommend that you keep the restrictions for the classes and categories, since the attributes "mail", "UserPrincipalName", "samAccountName", "distinguishedName", "displayName", "legacyExchangeDN", "mail", and "objectGUID" are required for cataloging the LDAP data set. The integrated Active Directory connection requires that you specify a domain and corresponding read permissions for the service account.

If you want to build the catalog for processing an Exchange Server in the cloud, you need to check whether it is possible to use the Remote Powershell first. In significantly reduced environments, you can only use the EWS interface, but it is not possible to list the available mailboxes as you cannot access them via Remote PowerShell, as is the case with Microsoft Office 365. This means you are forced to use less convenient catalog types such as "ews" or even "statlogin". The required attributes to be determined using the Remote Powershell include at least "UserPrincipalName", "samAccountName", "PrimarySmtpAddress", "distinguishedName", "legacyExchangeDN", "displayName", "RecipientTypeDetails" and "Guid". As the filters for the Remote Powershell allow conventional wildcards, the default is "*". If you want to narrow down the set of results, you can use manual tests and "get-mailbox" to ensure that the results of the customized filter determine the desired selection.

The catalog, which can be used to query the EWS interface directly, is configured with "ews". However, it is only recommended if either a sufficient number of filters is configured or the expected set of results is small anyway. Since querying mailboxes via the EWS interface was designed for the address fields in e-mail programs, the result is limited to a maximum of 100 mailboxes. If you need to process a greater number of mailboxes, this will require an appropriate set of filters in order to prevent gaps in processing.

However, if you are unable to configure list queries, then you will need to use a static catalog ("statlogin") and configure all catalog entries manually. If you use impersonation for this catalog type, you do not need to enter the full logon data. However, if this is not possible, you will need to enter the logon data (account and password) for each of these manual entries.

Please note: Each configured filter is evaluated. Although the data is anonymized based the respective identity criterion, unnecessary catalog queries reduce the runtime performance of ELOxc, since catalogs (with the exception of "statlogin") are determined every time before a job is executed.

ELOix parameters

The instance-specific parameters for connecting to the ELOix are designed to solve typical processing problems. The parameters "Timeout" and "SessionsTimeout" specify the maximum waiting time for the returning function calls of ELOix or the maximum amount of time until the session ends.

"TruncateStrings" sets all relevant strings (SORD name and index fields) to be truncated if the size of the database fields are exceeded.

"MaxColumnIndex", on the other hand, limits the number of column indices allowed for copying the list of addressees when using the "EloRecipients" field, and the "CryptKey" elements configure any encryption keys required for backing up the archived documents.

The element "AccountMapping" is used to define the details of the user import from the Active Directory. This is especially useful for creating ELO user accounts in a new repository that does not have any ELO users yet. The advantage is that access to the documents is set up exclusively and automatically for a user from the first archived message. If this option is to be applied in existing repositories, it is only recommended if the accounts have already been transferred from the Active Directory. However, this requires careful consideration in certain cases, since the "AccountMapping" function did not add some LDAP attributes to the user schema in ELOam until ELO 10. When ELOxc transfers accounts to historically grown user databases, as in the case of the ELO LDAP import, this can lead to divergent data sets, since ELOxc transfers the attribute "objectGUID" as a user GUID to ELO, while older repository versions generated the user GUID randomly. If you want to link historically grown repositories to "AccountMapping", you must modify the settings manually to ensure compatibility (see "Practice" chapter).

Please note: If you have enabled automatic user import from the Active Directory, you will not be able to create ELO users whose mailboxes are to be archived with any other method. As soon as you encounter conflicts, you will be to disable automatic import to ELOxc.