This section describes the requirements for service accounts in ELOxc, both at the Windows domain level and in ELO.

Please note: The requirements for service accounts are different between various versions of Exchange and Exchange Online/Office 365 environments. These differences are noted where relevant.

The differences between Microsoft Office and Office 365 is a frequent cause of support requests. This is primarily caused by the fact that Microsoft Office supports both traditional Exchange servers and Exchange Online, and Office 365 is often referred to synonymously with Exchange Online. Only the difference between "on-site" and Exchange Online is relevant to ELOxc EWS configurations.

For the sake of simplicity, the two server modes are referred to in the following as On-premise and Office 365, although strictly speaking, for the reasons above, the latter term is not completely correct.

ELOxc for Microsoft EWS requires a service account to work. This consists of both a Windows domain account and an ELO user. The Windows account is described first.

Exchange roles

The service account requires the following Microsoft Exchange Server roles: ApplicationImpersonation and ArchiveApplication. These rights are set in the Microsoft Exchange Management Console.

For Exchange 2016 and Exchange Online/Office 365, the user also needs to have the MailboxSearchApplication, OfficeExtensionApplication, and UserApplication roles.

Information: It is also recommended (but not necessary) to give the service account the Send As, Receive As, Full Access, and Read Access rights. The Send As right will allow the Exchange Server to send error messages by e-mail in certain cases. The other rights can help avoid certain unusual error scenarios.

Directory rights

The service account requires file system access (read and write) to the following directories:

• Windows registry
• ELOxc installation folder
• The instance log directory

Mailbox

The service account requires a configured mailbox on the Exchange server.

Login

The service account name in the ELOxc instance definition (login in the InstanceDef) is different between On-premise and Office 365 accounts.

On-premise: The service account name is the account's SAMAccountName. An example of this type of account name is ELOXC_Service.

Office 365: The service account name is the account's User Principal Name. An example of this type of account name is eloxc@mydomain.com.

LDAP

The service account must have read access to the LDAP catalog in all configured domains.

With an On-premise service account, you can test this access with an LDAP browser. However, you can also see if this access works in the ELOxc Console, which implicitly performs an LDAP access test.

With an Office 365 service account, the account must also have remote PowerShell access rights. To enable this, you must run the following PowerShell commands from within the ELOxc service account's security context:

Local (log on to Windows and run the following in PowerShell):

• Enable-PSRemoting
• Set-ExecutionPolicy RemoteSigned

Remote (on Office 365) (log on to Office 365 via PowerShell and run the following):

• Set-User -Identity <service account> -RemotePowerShellEnabled $True

Replace <service account> with the service account's User Principal Name when you run this command.

You should also run the following test after enabling these LDAP and PowerShell rights:

ELO user

A service user is required in ELO in order to connect to the Indexserver and the repository. This user requires the View all entries, ignore permissions right. It is also recommended to give the user the Main administrator right.

You can use the ELO Service user for this purpose, but it is recommended to create a different service user for ELOxc. By separating the ELOxc service actions from other actions, it is easier to search the ELO logs for relevant data.