Preparations

ELO users and their access rights in the repository are central to e-mail storage because correspondence, business or otherwise, should not generally be compromised. It is possible to prepare the repository manually before archiving any e-mails, or it can be done automatically by ELOxc. Central to e-mail archiving is the external mailbox owner whose messages are to be processed and later made available in the repository. ELOxc groups all external mailbox owners in mailbox catalogs, which are created when external directories are queried.

Automatic import of user accounts from the catalog is not a default setting in ELOxc, because it can lead to conflicts with the LDAP import function in the ELO Administration Console or existing legacy data. However, if you have already used the ELO Indexserver LDAP connection, there is nothing to prevent you from allowing ELOxc to import users, but you should consider whether this is actually necessary or whether the LDAP connection is not the better function. ELOxc is limited to mailbox properties. Nevertheless, both import methods are compatible as they both identify the external users based on the GUID in the directories. This allows ELOxc to import user data before the ELO Indexserver LDAP connection is used without preventing it being used later on.

You should therefore do some careful planning before you import user accounts. Once you have done so, ELOxc can automatically import the relevant catalog data of the users and also configure permissions settings for archived items. This decision is likely made when messages need to be stored before mailbox owners have a chance to log into the repository for the first time.

In addition, the different mailbox types processed by ELOxc as well as the filing path influence the resulting permission settings after an e-mail has been stored. Therefore, this usage example consists of several parts, which build on one another and also illustrate central control mechanisms of ELO access permissions.

We recommend that you test the configuration examples and verify the usage example with your own tests depending on your individual level of experience.

You need:

• ELO 20
• ELO Administration Console
• ELO client
• Microsoft Outlook
• 3x user mailboxes – 1x sender, 2x recipients
• 1x shared mailbox (with these user mailboxes as delegates)
• ELOxc
• Microsoft Active Directory
• Microsoft 365
• Remote PowerShell (Default authentication mode)
• App registration for Microsoft Graph API (OAuth2)

Standard method

The standard method in ELOxc is based on the assumption that the user structure has been configured in the repository before the first mailboxes are archived. Mailboxes are only associated with ELO data via the filing path using the automated functions of form permissions, which also play an essential role in the following examples with automatic user import. The standard method is used specifically if you want to separate external users and ELO users. However, it must be used if a static mailbox catalog has been configured.

In this example, a user gets a separate folder in the main folder E-mails (prepared), in which messages will be stored according to the folder structure in Outlook. This folder should be named after its SMTP address:

Both folders are created using the default folder form so that all users have access to them. However, since we want to configure a user-specific e-mail repository, the stored e-mails must be protected against unauthorized access by other users using appropriate permission settings.

The first step is to create the user. This is done in the ELO Administration Console:

After you save the new user, it shows up in the list:

In the client, you now set the permissions for both folders. Navigate to the main folder E-mails (prepared).

All users have read access to the main folder:

The user folder that will contain the stored mailbox is assigned permission settings that grant xc191 the rights to read the e-mails, move them, and change their metadata as needed:

Once the folders have been configured accordingly, messages for xc191 can be stored. The expected Outlook folder structure is automatically secured based on the permission settings of the metadata forms used. The default Folder and E-mail forms already have the required Parent rights permissions settings, which ensures that permissions for the transferred mailbox folders and messages are passed on correctly during processing.

ELOxc is now used to configure simple e-mail storage. It is based on the metadata templates KW_DEFAULT_DOCUMENT and KW_DEFAULT_FOLDER. KW_DEFAULT_DOCUMENT is assigned to the stored documents or messages and KW_DEFAULT_FOLDER is assigned to the created folders:

Both metadata templates are part of the default settings of ELOxc, which is why they are verified every time ELOxc is started. If they are missing, ELOxc automatically creates them. In addition, they already contain the default mappings of message properties to metadata fields, which is why they shouldn't be changed. If other templates are required, you can create customized copies of the two standard templates.

This simple storage process uses an active Archive Simple action tree.

The active action tree calls a subtree (or template tree) in which Export, Archiving, Tag, and Save are configured.

To ensure that the correct filing target is used in the repository, the Filing path action must be configured in advance.

During filing, the path is created by using existing path segments and creating missing ones. This ensures that the settings of the folders E-mails (prepared) and xc191@xc.local remain unchanged. This also means that the path segments in the repository are not changed by ELOxc once they have been created because the only identifier used is the folder name.

The segment for the main folder is configured as follows:

Since the name E-mails (prepared) is assigned by default and cannot be changed, the segment type must be set to constant. The metadata template of this path segment remains empty because the KW_DEFAULT_FOLDER template is already set at the top level of the entire action. If you want to use different templates for individual segments of the filing path, using different metadata forms, for example, you can configure this in this field of the segment. However, the segments are not linked to the metadata in this example.

The automatically generated name of the next segment in this example is the mailbox SMTP address. The variable BoxAddr is responsible in this case.

The third path segment uses the BoxPath variable, which is used to transfer the structure from Outlook during filing.

Now, when messages are processed, you can see in the repository that the desired permission settings are automatically applied correctly:

Automatic import of user accounts

This example with automatic user import for e-mail storage also assumes that there is a main folder, which will now be called E-mails (unprepared). This is where the mailbox folders with Outlook structures will be stored after filing. This does not require any preparations in the repository. Also, no ELO users are created. In your tests, make sure that you delete the created users over and over so that you can see changes to the user import process in new examples.

Make sure that you have enabled user import in the instanced configuration.

Parameters:

• Assume ownership: Enabling this option means that the user automatically created in the repository is also entered as the owner of the newly created documents.
• User notification: Enabling this option means that a message containing the user's credentials is automatically sent.
• Identity format: This selection field determines which catalog property to use as the ELO user name. The possible properties are UserPrincipalName, sAMAccountName, and displayName.
• Password: In this field, you can configure a default password for all imported users. If you leave the field blank, ELOxc generates a random password. In this case, you need to enable user notification because the password is not known otherwise. A new ELO user is able to set their own password when they log on for the first time.
• Default ACL: This where you specify the ACL for the user folder. This permission setting is applied to all transferred items based on the inheritance mechanisms of the metadata form (RW was selected here to distinguish it from RWDELP).
• Group membership and Group prefix: Each transferred user is automatically created as a member of a group whose name is set in these two fields. Separate group name and group prefix fields are required to allow recognition of the groups generated by ELOxc. If a user mailbox is processed, the group name ELOxc_USERS is used. However, in other cases, the USERS part of the name may be overwritten by names of shared mailboxes.

If you store an e-mail with these settings, you will get the following result:

The message Automatically without taking ownership is archived and is assigned the configured permissions settings RW. In addition, the user xc191 is notified that the ELO user account was created:

The user is now able to to log on to the repository where they will be prompted to set their own password:

If you enable the Assume ownership option in the instance configuration, each stored e-mail and each filing path folder created in this way will be assigned to the mailbox owner as if they had stored it manually:

If you do not enable this option, the stored message will be automatically assigned to the service account.

The assignment of rights in automatic user import only works properly if the filing path uses a variable that is associated with the mailbox owner:

The variables are assigned as follows: