Eine Instanz von ELOxc hat im Rahmen einer Dienstinstallation immer einen eindeutigen Namen, ist an einen Servertyp gebunden und erfordert immer eine kompatible Konfigurationsversion. Gleichzeitig ist das Konfigurationsfragment der Instanz („InstanceDef“) die Wurzel aller zur Instanz gehörenden weiteren Konfigurationsfragmente.

Im Folgenden ein Beispiel aus der ELOxc Console:

Im Instanzenfragment können folgende Bereiche festgelegt werden:

• Ausführungsmodus der Instanz
• Katalog
• Protokolleinstellungen
• Globale Parameter
• Parameter zur Verarbeitung von Adressen
• Einstellungen für die Verbindung mit dem ELOix

Das Hauptformular zeigt dabei nur die wichtigsten Einstellungen. Möchten Sie speziellere Parameter konfigurieren, öffnen Sie die erweiterten Einstellungen für den kompletten Konfigurationsumfang. Klicken Sie hierfür auf die Schaltfläche Erweitert.

Alternativ können Sie über die Schaltfläche XML bearbeiten das XML-Format der Konfiguration direkt bearbeiten. In diesem Fall sehen Sie ein Konfigurationsfragment so, wie es im Zusatztext des zugehörigen SORDs vorliegt.

Ausführungsmodus

Bei Dienststart werden alle registrierten Instanzen ausgeführt. Der erste Schritt der Ausführung besteht dabei darin, die zugehörige Konfiguration zu laden. Ist dieser Vorgang erfolgreich, werden die Instanzen aktiviert und befinden sich in der Ausführung. Der Standardausführungsmodus einer Instanz ist eine Intervallsteuerung (Wert „interval“), wobei die als erstes konfigurierte Zeitangabe die Wartezeit vor Ausführung dem nächsten Job festlegt. Der Wertebereich der Zeitangabe liegt zwischen 5 Minuten und 999 Tagen, 23 Stunden, 59 Minuten und 59 Sekunden, und das Eingabeformat ist 000:00:00:00.

Der zweite Modus der Zeitsteuerung kann mit dem Wert „täglich“ konfiguriert werden und erlaubt es, täglich feste Ausführungszeitpunkte zu verwenden, womit beispielsweise Besonderheiten in der Konfiguration von ELOxc berücksichtigt werden können. Hierbei werden dann alle konfigurierten Zeitangaben angewendet, wobei der Wertanteil für Tage ignoriert wird. Es gelten also nur Stunden, Minuten und Sekunden. ELOxc wählt in diesem Fall vom aktuellen Zeitpunkt ausgehend immer den nächstmöglichen Ausführungszeitpunkt aus der Liste aus und versetzt die Instanz für die notwendige Dauer in den Wartezustand.

Der Modus „Einmalig“ bewirkt, dass eine Instanz bei Dienstart nur einmal ausgeführt wird. Das eignet sich vor allem für Direktaufrufe über die Befehlszeile oder für Testläufe. Mit der Einstellung „Leerlauf“ können Sie einstellen, dass eine Instanz zwar geladen, aber nicht aktiviert wird. Anders als bei „Intervall“, „Täglich“ oder „Einmalig“ findet keine Verarbeitung statt, bis per ELOxc Console oder über das Befehlsfenster ausdrücklich der Startbefehl abgesetzt wurde.

Die Verwendung von „Auf Nachfrage“ versetzt eine Instanz in einen Zustand, der es erlaubt, eine Teilverarbeitung der Gesamtkonfiguration anzustoßen. Hierbei können die Datenquelle, der Aktionsbaum und sogar der Container innerhalb der Datenquelle als Parameter übergeben werden. Die Beschränkung dieser Ausführungsmethode besteht darin, dass in der Konfiguration von ELOxc die gewählte Datenquelle auch in der Konfiguration des gewählten Aktionsbaums berücksichtigt wurde. Die Einschränkung auf einen bestimmten Container ist optional.

Der letzte und speziellste Ausführungsmodus ist „creator“. In diesem Zustand werden keine Daten in das ELO Archiv übertragen. Stattdessen können Elemente an den Exchange Server übertragen werden. Die zulässigen Klassen sind dabei Nachrichten („IPM.Note“), Kalendereinträge („IPM.Appointment“) und Kontaktdaten („IPM.Contact“). Verwendung findet dieser Modus beispielsweise im Zusammenspiel von ELOxc mit den Produkten der ELO Business Solutions.

Katalog

Der Katalog einer Instanz legt den maximalen Umfang verfügbarer Datenquellen fest. Aktionsbäume können nur Datenquellen verwenden, die im Katalog enthalten sind. Das kommt neben den Aspekten der Reproduzierbarkeit und Abgrenzung konfigurierter Verarbeitungsvorschriften vor allem dem Authentifizierungsprinzip durch „Inbesitznahme“ („Impersonation“) entgegen. Ein Katalog definiert neben der Benutzung von Auswahlfiltern vor allem die Kataloganmeldung des ELOxc Service Users, der nicht nur für die Katalogzusammenstellung autorisiert sein muss, sondern auch die späteren Inbesitznahmen während der Verarbeitung durchführen können muss.

Der Standardkatalogtyp ist „ldap“, für den eine klassische LDAP-Verbindung zum lokalen Active Directory aufgebaut wird und die verfügbaren Postfachbesitzer unter Verwendung des Filters

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

ermittelt werden. Passen Sie den Filter an, um die Selektion beispielsweise mit einer Organisationseinheit einzuschränken, müssen Sie dafür sorgen, dass die resultierenden Datensätze geeignet sind und die notwendigen Attribute enthalten, die ELOxc für eine Verarbeitung benötigt. Wir empfehlen daher, die Klassen- und Kategorieneinschränkung beizubehalten, denn die Attribute „mail“, „UserPrincipalName“, „samAccountName“, „distinguishedName“, „displayName“, „legacyExchangeDN“, „mail“ und „objectGUID“ sind zwingend erforderlich, damit der LDAP-Datensatz katalogisiert wird. Und der integrierte Verbindungsaufbau zum Active Directory erfordert die Angabe einer Domäne und entsprechende Leseberechtigungen des Dienstkontos.

Möchten Sie den Katalog für die Verarbeitung eines Exchange Servers in der Cloud aufbauen, müssen Sie vorab prüfen, ob die Verwendung der Remote PowerShell möglich ist. Stark reduzierte Umgebungen erlauben lediglich die Nutzung der EWS-Schnittstelle und verbieten dagegen aber eine Aufzählung der verfügbaren Postfächer, indem Zugriffe per Remote PowerShell nicht freigeschaltet werden, wie es unter Microsoft Office 365 der Fall ist. Damit sind Sie gezwungen, weniger komfortable Katalogtypen wie „ews“ oder sogar „statlogin“ zu verwenden. Die erforderlichen Attribute, die unter Verwendung der Remote PowerShell zu ermitteln sind, umfassen mindestens „UserPrincipalName“, „samAccountName“, „PrimarySmtpAddress“, „distinguishedName“, „legacyExchangeDN“, „displayName“, „RecipientTypeDetails“ und „Guid“. Da die Filter für die Remote PowerShell klassische Wildcards erlauben, ist der Standardfall „*“. Möchten Sie die Resultatmenge einschränken, können Sie mit manuellen Tests und der Verwendung von „get-mailbox“ vorab sicherstellen, dass die Ergebnisse des angepassten Filters die gewünschte Auswahl ermitteln.

Der Katalog, der für die direkte Abfrage der EWS-Schnittstelle verwendet werden kann, wird mit „ews“ konfiguriert. Er ist jedoch nur dann empfehlenswert, wenn entweder eine ausreichende Anzahl an Filtern konfiguriert wird, oder die erwartete Resultatmenge ohnehin klein ist. Da die Abfrage von Postfächern über die EWS-Schnittstelle für die Adressfelder in E-Mail-Programmen konzipiert wurde, wird das Resultat auf ein Maximum von 100 Postfächern beschränkt. Bei einer größeren Anzahl zu verarbeitender Postfächer wird eine geeignete Filtersammlung zwingend notwendig sein, um Verarbeitungslücken zu vermeiden.

Haben Sie dagegen keinerlei Möglichkeit, Listenabfragen zu konfigurieren, bleibt lediglich die Verwendung eines statischen Katalogs („statlogin“) übrig. Hierbei werden alle Katalogeinträge manuell konfiguriert. Verwenden Sie für diesen Katalogtyp eine Inbesitznahme, ist die Erfassung vollständiger Anmeldedaten nicht notwendig. Ist aber selbst das nicht möglich, erfordert jeder dieser manuellen Einträge auch die Anmeldedaten (Konto und Kennwort).

Beachten Sie: Jeder konfigurierte Filter wird ausgewertet. Die Daten werden zwar anhand des jeweiligen Identitätskriteriums disambiguiert, doch überflüssige Katalogabfragen verringern die Laufzeitleistung von ELOxc, da Kataloge (mit Ausnahme von „statlogin“) vor jeder Ausführung eines Jobs neu ermittelt werden.

ELOix Parameter

Die instanzenspezifischen Parameter für die ELOix-Verbindung unterstützen die Lösung typischer Verarbeitungsprobleme. Die Parameter „Timeout“ und „SessionsTimeout“ definieren die maximale Wartezeit für die zurückkehrenden Funktionsaufrufe des ELOix bzw. die maximale Zeit bis zum Sitzungsablauf.

„TruncateStrings“ stellt ein, dass alle relevanten Zeichenketten (Name und Indexzeilen von SORDs) unter Umständen gekürzt werden, wenn die Datenbankfeldgrößen überschritten werden.

„MaxColumnIndex“ beschränkt dagegen die Anzahl der erlaubten Spaltenindizes für die Übernahme der Adressatenliste bei Verwendung des Feldes „EloRecipients“, und die Elemente „CryptKey“ konfigurieren eventuell erforderliche Verschlüsselungskreise zur Sicherung der archivierten Dokumente.

Mit dem Element „AccountMapping“ definieren Sie die Details der Benutzerübernahme aus dem Active Directory. Dies eignet sich vor allem dazu, die ELO Benutzerkonten in einem neuen Archiv zu erstellen, das noch keine ELO Benutzer hat. Der Vorteil besteht darin, dass bereits ab der ersten archivierten Nachricht eines Benutzers der Zugriff auf die Dokumente für ihn exklusiv und automatisch eingerichtet wird. Soll diese Option in bereits bestehenden Archiven angewandt werden, so ist es nur dann empfehlenswert, wenn es bis dato bereits eine Übernahme von Konten aus dem Active Directory gegeben hat. Das muss allerdings im Einzelfall sorgfältig erwogen werden, da mit „AccountMapping“ das Benutzerschema im ELOam erst mit ELO 10 um einige LDAP-Attribute erweitert wurde. Das hat zur Folge, dass die von ELOxc durchgeführte Kontenübernahme in historisch gewachsene Benutzerdatenbanken wie im Falle des ELO LDAP-Imports zu divergenten Datenbeständen führen kann, da ELOxc das Attribut „objectGUID“ direkt als Benutzer-GUID in ELO überträgt, während ältere Archivversionen die Benutzer-GUID zufällig erzeugt haben. Möchten Sie historisch gewachsene Archive an das „AccountMapping“ anschließen, müssen Sie die Kompatibilität mit manuellen Eingriffen vorbereiten (siehe Kapitel Praxis).

Beachten Sie: Ist die automatische Benutzerübernahme aus dem Active Directory aktiviert ist, können ELO Benutzer, deren Postfächer archiviert werden, nicht auf eine andere Weise angelegt werden. Sobald Konflikte entstehen, muss auf die automatische Übertragung durch ELOxc verzichtet werden.