Automatic Email Processor - Frequently Asked Questions (FAQ)

This page answers frequently asked questions about Automatic Email Processor. For detailed step-by-step instructions on the program features, please see the online help.

Affected messages in the error log:

• "The encrypted message cannot be decrypted. The matching certificate with the private key was not found."
• "No matching private key was found in the personal Windows certificate store of the signed-in user."

Cause: To decrypt S/MIME-encrypted emails, Automatic Email Processor requires your personal certificate including its private key. It must be located in the Windows certificate store "Personal" of the user account under which processing runs. The most common cause of the message: the certificate was transferred without its private key (e.g. exported as a .cer file), or it was imported under a different Windows user account.

How to set up the certificate correctly:

1. Export the certificate on the computer where it already works (e.g. where you can read encrypted emails in your email program): press Windows key + R, enter certmgr.msc, right-click the certificate under "Personal > Certificates", then select "All Tasks > Export...".
2. In the export wizard, choose the option "Yes, export the private key" and save the file in PFX format, protected with a password. If the option is grayed out, the certificate was originally installed without an exportable private key; in that case, request the PFX file from the certificate issuer or your IT department.
3. Import the PFX file on the computer running Automatic Email Processor by double-clicking it: store location "Current User", enter the password, certificate store "Personal" (or let Windows select it automatically).
4. If processing runs as a Windows service: perform the import under the Windows user account the service runs as - the certificate store is per user account.
5. Afterwards, process the affected emails again, e.g. via "Catch-up processing...".

Note: A .cer file only contains the public part of the certificate and is not sufficient for decryption - it must be a PFX file including the private key.

Typical signs: The sign-in and the account test succeed, but no emails are ever processed. The folder selection only shows the standard folders (Inbox, Sent Items, etc.) - subfolders you created yourself, which are visible in Outlook, are missing.

Cause: In this case, the email of your domain is not hosted at Microsoft but at a different provider (for example, the web hoster of your company domain). In addition, a second, practically empty mailbox with the same address exists in the Microsoft account - for example, because a Microsoft 365 account was created for the Office applications. The program connects to this empty mailbox when the account is set up as a Microsoft 365 account, while your actual emails and folders are located on the server of your email provider. Automatic Email Processor shows a warning in this constellation, among other places when the account is created and during the account test.

How to connect the correct mailbox:

1. Remove the Microsoft 365 account under "Menu > Options > Email accounts". You can confirm the note that the account is still in use.
2. Create the account again, this time with the account type IMAP. You get the server details (incoming mail server, usually port 993 with SSL) and the credentials from your email provider; they are the same ones other email programs use for this mailbox.
3. After saving, the program offers to transfer the existing profile references to the new account - please confirm this.
4. Then check under "Options > Notifications" and "Options > Report" whether the correct sender account is still selected there.
5. Run "Test account" and check in the folder selection of a profile whether the subfolders now appear.

Note: If the email of your domain is actually hosted at Microsoft (Microsoft 365 or Exchange Online is your email provider), the Microsoft 365 account type is the right choice - in that case, no warning appears either.

Special case email security gateway: In larger organizations, an email security gateway (e.g. Retarus, Mimecast, Proofpoint, or Hornetsecurity) is often placed in front of the Microsoft 365 mailbox. The DNS record of the domain then points to this gateway, which checks incoming email and forwards it to Microsoft 365. In this constellation, the warning may appear even though the mailbox is actually hosted at Microsoft. As long as expected messages arrive in the account, you can ignore the note; the Microsoft 365 account type is then the right choice.

Typical signs: The test under "Options > Email accounts > Test connection" reports success. Nevertheless, the error log shows entries such as "Connection to account ... was lost during the check", "Timeout exceeded", or "Cannot send command to the server", and processing pauses from time to time.

Cause: The connection test only establishes a short, fresh connection to the mail server. The actual check, however, may work for several minutes at a time, querying all monitored folders one after the other. Such longer connections are sensitive to an unstable internet connection, an overloaded or slowly responding mail server, and security software that intercepts email connections for scanning. If the connection is lost during the check, the program skips the remaining folders or messages of the account and checks again in the next run. Important: nothing is lost - skipped emails are processed normally during the next run.

How to narrow down the cause:

1. Check the error log for patterns: Do the drops only affect accounts of a certain provider, or do they occur more frequently at certain times? If so, it is worth asking the email provider (keyword: connection drops and timeouts on IMAP/POP3 connections).
2. Temporarily disable the email or SSL scanning of your antivirus or firewall software. Such programs hook into encrypted connections and are a common cause of drops during longer transfers.
3. Check the computer's internet connection (Wi-Fi reception, router, DNS resolution). If the error log also shows messages such as "Unable to resolve hostname", this indicates a network or DNS problem on your side.
4. If a large number of folders is monitored, do not set the check interval too tightly - this leaves room between runs, and a single drop matters less.
5. If the problem persists, send us an error report ("Menu > More > Create error report...") - it usually lets us read the drop pattern precisely.

Background: In the profile settings under "Notifications", a custom notification text can be stored that contains the storage folder of the filed documents as a link via the placeholder <StoragePathLink>. However, whether this link is clickable for the recipient is decided by their email program - links into the file system are blocked by many programs for security reasons.

The most important rules:

• Network paths (e.g. \\server\share\invoices) can be clicked directly in Outlook (classic) - in both plain text and HTML emails. This is the recommended approach.
• Local paths (e.g. C:\Archive\...) are always blocked by Outlook; unblocking them would only be possible via policies on the recipient side and is not recommended.
• The new Outlook, Outlook on the web and most webmail services (e.g. Gmail) generally display file system paths as text only - the recipient can then select and copy the path and paste it into the address bar of Windows Explorer.

Recommendation:

1. Use a network path (\\server\share\...) as the storage target of the profile if recipients should be able to jump to the storage folder with one click.
2. Additionally add the placeholder <StoragePath> to the notification text - this way, the path is always included in the email as copyable text.
3. Test the notification with the email program your recipients actually use.

Note: The link is only generated as a clickable HTML link if the notification text contains HTML. In plain text emails, the path is inserted as text - Outlook (classic) also recognizes network paths there and makes them clickable itself.

Background: Your organization is configured in Microsoft 365 in such a way that users are not allowed to grant applications access to their own mailbox themselves. An administrator has to grant consent to the application "Automatic Email Processor" once. A separate app registration in Microsoft Entra ID is not required - the application already comes with its own registration.

How to grant consent:

1. In the account editor, click "Sign in with Microsoft..." again and sign in at the Microsoft sign-in page with an administrator account of your organization.
2. In the consent dialog, select the checkbox "Consent on behalf of your organization" and confirm.
3. Afterwards, click "Remove credentials" in the account editor and repeat the sign-in with the actual account - it now completes without an approval prompt.

Note for administrators:

The application requests delegated permissions only, i.e. access solely in the context of the signed-in user and no tenant-wide application access: Mail.ReadWrite, Mail.ReadWrite.Shared, Mail.Send, Mail.Send.Shared, User.Read, and MailboxSettings.Read. After consent has been granted, the application appears in the Entra admin center under "Enterprise applications", where it can be reviewed or revoked at any time.

Background: The Microsoft 365 account type connects through the Graph interface of the Microsoft cloud and therefore only works with Microsoft 365 / Exchange Online mailboxes. An Exchange server hosted on your own premises is connected as an IMAP account instead - Exchange fully supports IMAP, including folders, moving messages, and real-time detection of new email.

One thing to keep in mind: in a default Exchange installation, the IMAP services are disabled. Your administrator needs to enable them once and assign a certificate to the IMAP service; after that, the account is set up in the program like any other IMAP account (port 993, SSL/TLS).

All steps - including the commands for the Exchange server and solutions to common issues - are described in the guide How to connect an on-premises Exchange server.

Background: Error 1069 ("The service did not start due to a logon failure") means that Windows could not log on the service account. The error occurs before the program itself starts - that is why the service's diagnostics log contains nothing. It typically shows up at the first service start after an update or a server restart, because a service that is already running does not re-check the logon.

Common causes:

• The password of the service account has been changed in the meantime.
• The account is temporarily locked, e.g. after failed logon attempts elsewhere.
• The account lacks the "Log on as a service" right, for example because a group policy removed it.
• The domain controller was briefly unreachable at start time (for domain accounts).

The solution is the same in all cases: Open the program options, section "Windows Service", click "Set up service..." and enter the current password of the service account - this also grants the logon right again. There is no need to remove the service or restart the server. For further details, see the how-to "Set up as a Windows service".

Immediate action in case of mass printing: Stop the processing service or the program and then clear the Windows print queue (Settings > Bluetooth & devices > Printers & scanners > your printer > Open print queue). Print jobs already handed over to Windows will otherwise continue to be printed even after the program has long been stopped.

The program remembers processed e-mails in a processing database per Windows user account. Renewed processing of older e-mails therefore almost always has one of these three causes:

• A second installation under a different Windows user: If the program (or the service) additionally runs under another user account, each instance keeps its own processing memory - both process the same e-mails. Run the processing under a single user account only.
• The "Catch up on processing" function without the option to ignore previously successfully processed items: Without this option, catching up processes all e-mails of the selected period again - including those already processed.
• Application data on a network share (folder redirection, roaming profile): The Windows service often cannot open the processing database there and then no longer recognizes what has already been processed. As of version 4.6.9, the program halts processing in this case instead of processing again; in addition, the service setup shows a warning. Use local application data for service operation or run the program in its window.

If all counters remain at 0 during catch-up processing, one of these three causes is almost always responsible:

• The emails have already been processed: In the catch-up window, the option "Ignore messages: that were previously successfully processed" is enabled by default - already processed emails are then skipped deliberately and are not counted anywhere. Uncheck the option if emails should be processed again. As of version 4.6.11, the result window shows the number of emails skipped for this reason.
• The emails are no longer on the mail server: Catch-up processing can only process emails that are currently still on the server. Especially with POP3 accounts, many email programs (e.g. Outlook) delete messages from the server shortly after retrieval - older emails then only exist locally in the email program and cannot be reached by the catch-up processing.
• The selected period does not match: Check the dates under "Limit received date of messages to time range". After an empty run, the result window shows the total number of messages in the monitored folders and, if available, the dates of the oldest and newest message.

Note for POP3 accounts: Reading the message list can take several minutes for large mailboxes; the counters remain at 0 during this phase. Please let the process run to completion. If the program unexpectedly processes old emails again, see the entry above.

As of version 4.7.0, there are two ways to do this, which can also be combined:

• Automatic dispatch by email: In the options under "Error Report via Email", you define a schedule, recipients, and the sending account. With the option "Only send if new error log entries have been added since the last send", only those installations report in on which something was actually logged - an empty mailbox then means: nothing unusual.
• Command line for scripted operation: The call AEPProcessor.exe --errorreport "\\Server\Share\AEP-Reports" (e.g. via the Windows Task Scheduler) places the complete error report in a central folder; the file name automatically includes the computer name, so any number of installations can share the same folder. With the additions --send and --onlynew, the call sends the report by email instead, or only if there are new entries.

Both approaches are described in detail in the program help in the chapter "Error Report via Email".