The Instance configuration area contains the basic configuration of an ELOxc instance. This is where you specify the global processing parameters.

You access the instance configuration via the ELOxc Workspace home screen (house icon). Select the instance you require and click the button with the repository tree and the pen icon.

Configuration version

In the field Configuration version, you can see which version you are using. The configuration version is identical to the program version.

Information: If your configuration version turns out to be outdated, the configuration will not update automatically when you start the service. In this case, contact ELO product support.

Instance type

The value in the Instance type field specifies the type of e-mail server. XC stands for Microsoft Exchange.

The following subareas can be defined in the instance fragment:

• Process control settings
• Mailbox catalog
• ELO settings
• Settings for recipients
• Global settings
• Load settings
• Log settings

Information: Refer to the

Information on account mapping

In the Account mapping area, you configure how catalog users are mapped to ELO. It is only possible to map accounts using the catalog types "ldap", "ps", and "azure". Account mapping is used to define the details of the user import from Azure 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 Active Directory. However, this requires careful consideration in certain cases, since the account mapping function did not add specific LDAP properties 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 property "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.

Please note: If you have enabled automatic user import from 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 need to disable automatic import to ELOxc. Furthermore, do not use account mapping together with an LDAP import.

If account mapping is not enabled in ELOxc, ELOxc does not manage existing users or the access rights (ACLs) to repository paths. In this case, ELOxc uses implicit ACL inheritance and the settings made by the administrator.

If account mapping is enabled, which you should do as soon as you have created the repositories and the user database, external users who cannot be identified in the set of ELO users are mapped as ELO users. When creating ELO users, you can optionally create random passwords and have ELOxc send them to the users via e-mail. However, you can also assign a default password for all user accounts.

If external users can be identified as ELO users, ELOxc is also able to generate an ACL to secure the user folder for the "mapped mailbox owner". This occurs without prior authentication by the ELO user.

The precise repository path of the user folder depends on how the repository paths (see "ArcPathDef") were configured in ELOxc. Repository paths can be created in relation to the repository object (repository root), which corresponds to an absolute path specification, or in relation to the ELO user of the mailbox owner (ELO user path). ELOxc can support both path types in a single configuration, but ELO user paths can only be used with account mapping.

The identification of external users as ELO users plays a pivotal role in ensuring that account mapping works over the long term. If identification does not work, it may lead to users being created multiple times or mailbox owners being mapped to the wrong ELO users. Finding and eliminating the cause is very time-consuming because the archived data with the user IDs is stored in the ACLs. An ACL always contains a user ID. If external users are transferred twice, a new, second ID would be used, which would also change the ACL used.

The account mapping defined by ELOxc requires use of the ELOam table "ldapuserprops". This table functions as an extension of the ELO user database for connecting external data sets to ELO data sets. The fields of the external data set are stored in this table so that it is possible to identify ELO users based on their external data once they have been created. The GUID, which exists in the data set of supported catalogs, plays an important role. This GUID is also used when creating the ELO user in "userdata". As a rule, it is possible to make a direct association between the external user and the ELO user. You can also specify the format of the ELO user name in the ELOxc configuration.

Identification can fail if ELOxc is mapping accounts from an ELO user database that has grown over the years. Complex heuristic methods can be used to determine an ELO user based on current external data (GUID, SMTP, SAMAccountName, UserPrincipalName, DisplayName), but these can also fail. ELO user databases usually have no values for "ldapuserprops", but at best application-specific "user props" properties, so that identification depends on the quality of the data in "user name", "Windows logon", and/or "email".