/
3.1.1a Dienst startet nicht:

3.1.1a Dienst startet nicht:

Owned by Former user (Deleted)
Last updated: Jun 10, 2025 by CSE (OSB-Support)

enaio Version bis 3.x: 

In dieser Version müssen aslic.cfg und aslic.dat direkt in das OS-Server-Verzeichnis kopiert werden. In der ASLIC.CFG müssen Server, die Client-Stationen und Lizenzen korrekt zugewiesen sein. Ist die Lizenz abgelaufen oder ein Eintrag nicht korrekt, startet der Dienst nicht mehr. Eine Startup.txt gibt es noch nicht. Gern bei diesen KB-Einträge weiterlesen, wenn es kein Lizenzproblem sein sollte:

  • Bis 3x.: -047/01 (KB fehlt tatsächlich vor der Nummer)

  • Ab 4.x: KB-003/07

 

für alle anderen enaio Versionen: 

Bei allen Versionen größer 3.x gibt es im SERVER\OSTEMP-Verzeichnis eine STARTUP.TXT. Darin sind die einzelnen Schritte des Dienststartes protokolliert. Man kann damit sehr genau sehen, an welcher Stelle es Probleme gibt.

Sofern diese nicht erstellt wird, handelt es sich um vorgelagertes, meist ein Windows-Problem oder Windows-Rechte-Problem.

 

nachfolgend:

 

Falls keine Startup.txt geschrieben wird: 

  • Welche Meldung kommt beim Dienststart?

  • Dienstbenutzer prüfen:

    • Hat der Dienstbenutzer noch genügend Windows-Rechte oder ist er gar gesperrt?

    • Ist der Dienstbenutzer noch lokaler Admin?

    • Ist das Passwort des Dienstbenutzers abgelaufen?

    • Wurden dem Dienstbenutzer Rechte oder GPOs entzogen?

    • Kommt der Dienststart weiter, wenn man von "Dienstbenutzer" auf "lokales System" umstellt? 

  • Was wurde geändert oder zuletzt ausgeführt (z. Bsp. Windows-Updates, Virenscannerupdates)?

  • Sind die Ports noch freigeschaltet oder hat das letzte Windows-Patch oder Virenscanner-Patch alle Ports gesperrt? 

  • Startet der Dienst, wenn der Virenscanner abgeschaltet wird?

  • Kann der enaio Dienst per START.BAT (im OS-Server-Verzeichnis) gestartet werden?

  • Sind Leerzeichen im Pfad zum OS-Dienst?
    Falls ja: Bitte zum Test den Pfad in Hochkomma setzen, siehe auch KB-072/14.
    Bsp.:  "D:\Programme und Funktionen\ENAIO\SERVER\axsvckrn.exe" -n MeinECM

  • Stimmen die Parameter für den Dienststart noch?
    entweder über Dienst-Eigenschaften ermitteln oder besser per Registry HKLM\System\CurrentControlset\Services\<dienstname> bei ImagePath

    • Wurde evtl. "-n Dienstname" geändert?

    • Steht "-rt" (+ Timestamp) oder "-rl" (= Lizenzinformation) an der richtigen Stelle, siehe auch 3.1.1e rund um Startup.txt / Shutdown.txt (= Protokoll bei enaio Dienst-starten/stoppen) ?
      Ein häufiges Problem ist, dass der Parameter für die Erweiterung der STARTUP.TXT an der falschen Stelle gesetzt wird. Bsp.:
      Korrekt:              D:\ENAIO\SERVER\axsvckrn.exe -rt -rl -n enaios01p
      Fehlerhaft:         D:\ENAIO\SERVER\axsvckrn.exe -n -rt enaios01p

  • Hat eventuell ein Virenscanner Dateien entfernt?

  • Falls dies alles keine Hinweise liefert, alle periodischen Jobs abschalten. Startet der Dienst dann?

  • Einzelne Executoren abschalten:
    Wenn man WFM-Engine deaktiviert, startet der Dienst?
    Wenn man VTX abschaltet, startet der Dienst? 

  • Gibt es schon enaio Err-Logs 8enaio Server-Verzeichnis prüfen?

  • Ansonsten das Server-Flow-Protokoll auf Level 6 (mind. 5) stellen und versuchen den Dienst zu starten. Das Log danach wieder abschalten. 

 

Wenn eine Startup.txt geschrieben wird: 

Sofern eine STARTUP.TXT geschrieben wird, diese Datei bitte mit einem Texteditor öffnen und ans Ende gehen/scrollen. Hier steht normalerweise, wie weit der enaio-Dienst gekommen ist.
Siehe auch OS_Systemhandbuch-DMS_de.pdf, z. Bsp. im Handbuch der Version 8.50 ab S. 205 ff.

  • Wir benötigen die STARTUP.TXT aus dem SERVER\OSTEMP-Verzeichnis.

  • Wenn möglich ein Server-Flow-Log Level 6, siehe Punkt "2.6b enaio Protokolle". Bitte danach das Flow-Protokoll wieder anhalten bzw. ausschalten.

  • Sollte es ein Problem mit der Datenbank geben, hilft das Aktivieren des SQL-Logs. Im Log sieht man die Statements. Diese der Reihe nach ausführen. Das Log bitte nach dem Test wieder deaktivieren. 

Eine Übersicht der bekannten Probleme findet man auch in KB-003/07.

 

Häufige Ursachen:

  • 700er Fehler sind meist Fehler im Zusammenhang mit der Lizenz. 
    Die Lizenz ist abgelaufen oder es wurde eine falsche oder fehlerhafte Lizenz importiert, weiteres siehe Punkt 3.5.9 Lizenzen: .

  • Die Datenbank ist nicht verfügbar oder der Datenbankbenutzer wurde geändert (Rechte, Schema, Rollen und Passwort), weiteres siehe Punkt 3.5.2 Datenbanken: .

  • Oracle: 

    • Es ist eine Oracle-Datenbank 64bit: AlternativeODBC muss 1 sein! 
      Standardmäßig fehlt der Eintrag. Er muss angelegt werden unter 
      HKLM\Software\Optimal Systems\<dienstname>\Schemata 4.0\Database 
      "AlternativeODBC=1"
      Wichtig: Bei Verwendung MSSQL und Oracle mit enaio 32bit Server, muss der Wert 0 sein oder darf fehlen. 

    • Bei Oracle: Die Datenbank ist umgezogen und es wurde vergessen, die tnsnames.ora anzupassen, siehe auch Was tun, wenn per ODBC die enaio Datenbank nicht zur Auswahl steht? . 

    • Bei Oracle: Jemand hat die ODBC-Datenquelle geändert von "commit only if all statements succeed" (= Standard) auf "commit all successful statements". Bitte wieder auf Standard stellen. 

  • kein Zugriff auf das WORK-Verzeichnis mehr 

  • kein Plattenplatz mehr (Datenbank, enaio Server, WORK-Verzeichnis ...)

  • Zugriff auf die Archivmedien (und/oder BACKUP) nicht mehr fehlerfrei möglich.
    Wenn die Medien nicht erreichbar sind, gibt es bei uns kein Problem beim Dienststart, da ein Timeout kommt oder Zugriff verweigert.
    Wenn die Archivmedien allerdings die Anfrage unseres Dienstes annehmen, aber die Antwort nicht ankommt, dann gibt es ein Problem. In diesem Fall bitte den Support benachrichtigen. 
    Workaround bis zur Behebung des Problems auf/beim Archivsystem: In der Tabelle PATH die problematischen Pfade ändern auf z. Bsp. von "\\Langzeitarchiv\" auf "\\LangzeitarchivXX\"
    Vorher die Datenbank und mindestens die Tabelle sichern. Anpassung bitte mit OS Berlin Support, ansonsten auf eigene Gefahr. 

  • Dienst war abgestürzt bei Anpassung des Rechtesystems oder Profilverteilung. In der Datenbank stehen damit u.U. fehlerhafte Daten, und das Rechtesystem (DMS-Executor) kann nicht mehr geladen werden. 
    Workaround in Mehrserversystemen: Bei einem laufenden Dienst das Speichern im Rechtesystem wiederholen. Ansonsten auf den Support zukommen. 

  • Die maximale Trefferzahl ist zu klein eingestellt? (steht im enaio Enterprisemanager unter "Servereigenschaften" Kategorie "Daten" - Standardwert 50.000)

  • bei "Klauselfehler" in der Startup.txt:
    Der Datenbankbenutzer hat mehr Rechte bekommen als DBOwner oder das Schema wurde angepasst oder die Datenbank wurde umgezogen und das Schema oder bei Oracle stimmt der Tablespace nicht mehr.
    Die Daten können damit nicht mehr ausgelesen werden, weil der Datenbankbenutzer seine Tabellen nicht mehr findet (altes Schema z. Bsp. sysadm, neues Schema dbo). 
    Infos zum Schema: 
    Wie kann man herausfinden, welches Schema der Datenbankbenutzer hat?

  • Es kann auch ein Klauselfehler im Rechtesystem sein. Dann bleibt aber eher der STD-Executor hängen beim ersten Check-Permission.

  • Es sind zu viele Workflows in der Worker-Queue oder es gibt Workflows, die das System blockieren. 
    Empfehlung: alle WFM-Batche in der Registry auf “enable=0” stellen
    Dann den Dienst starten und den WF-Administrator. Bei System prüfen, ob es Sperren gibt und welche Workflows es betrifft. Diese entsperren und dann anhalten. Läuft das System weiter, wenn die Batche im enaio Enterprisemanager wieder aktiviert werden?
    Falls nein: Betrifft es ein Workflowmodell und einen bestimmten Arbeitsschritt? Wird evtl. etwas extern aufgerufen?

  • Es gibt Deadlocks auf der Datenbank, z. Bsp. OSOBJHIST, weil Indexe fehlen oder entfernt wurden. Indexe siehe: Was ist in Bezug auf die Indexe zu beachten (empfohlene Indexe)?

  • Der Virenscanner hat Dateien entfernt. Hierbei hilft nur eine Reparatur der enaio Installation. 
    Versionen kleiner enaio 10.00 und 32bit: Setup aufrufen und "Aktualisieren / Reparieren" auswählen
    Versionen kleiner enaio 10.00 und 64bit und ab enaio 10.00: Server-Patch.exe aufrufen und das Setup noch einmal ausführen. 

  • Es tritt ein Timeout ein, z. Bsp. beim Zugriff auf die Datenbank. Das ist Schritt 763. Hier werden Informationen aus der Datenbank geladen und die Threads erstellt. 
    Mögliche Ursache: die Verbindung zur Datenbank wurde unterbrochen oder ist nicht möglich oder die Abfrage für das Laden des Threads dauert länger als 10 Sekunden. 
    Abhilfe schafft, JobStartTimeout unter HKEY_LOCAL_MACHINE\SOFTWARE\OPTIMAL SYSTEMS\<dienstname>\Schemata\4.0\Threads zu erhöhen, z. Bsp. 30.000ms. Standardwert = 10.000ms. 

  • speziell Fehler 727: 
    Es ist ein Datenbankfehler aufgetreten. ODBC Diagnostic: , systemeigener Fehler: 8705
    "Es ist ein Datenbankfehler aufgetreten. ODBC Diagnostic: , systemeigener Fehler: 8705, Status: 42000, Text: [Microsoft][ODBC SQL Server Driver][SQL Server]Eine DML-Anweisung hat einen fehlenden Eintrag in Index-ID 0 der Tabellen-ID 1541580530 in Datenbank "enaio" erkannt, verursacht durch eine Interaktion mit einer anderen Transaktion. Falls dieser Fehler weiterhin angezeigt wird, erwägen Sie die Verwendung eines wiederholbaren Lesevorgangs oder einer höheren Isolationsstufe.
    DELETE FROM oslockedres WHERE sessionguid NOT IN (SELECT ss.sessionguid FROM ossession ss)"
    Diese Meldung bedeutet, dass darauf hin, dass Indexe defekt sind. Die gleiche Fehlermeldung kommt auch direkt beim Ausführen auf der Datenbank. Lösung in diesem Fall war alle vorhandene Indexe der betroffenen Tabellen OSLOCKEDRES und OSSESSION löschen.
    Nach dem Dienststart unbedingt, über den enaio Editor die Indexe als SQL ausgeben und für die beiden Tabellen wieder anlegen. 

  • speziell Fehler 723:
    Das deutet auf ein Problem mit der Datenbank und dem Schema hin. Wenn in der startup.txt steht "Fehler beim Ausführen der ODBC-Funktion SQLColumn; Fetch(benutzer.benutzer). Rückgabecode: 0", bitte das Schema in der Datenbank prüfen und die Registry, siehe auch
    Wie kann man herausfinden, welches Schema der Datenbankbenutzer hat? :
    HKEY_LOCAL_MACHINE\SOFTWARE\OPTIMAL SYSTEMS\<dienstname>\Schemata\4.0\Database\Schema
    und HKEY_LOCAL_MACHINE\SOFTWARE\OPTIMAL SYSTEMS\<dienstname>\Schemata\4.0\Database\DBSchema
    Ist das Schema = Benutzer, darf hier nichts stehen. Steht an dieser Stelle z. Bsp. DBO, aber das Schema ist sysadm, kommt es zum Fehler. 

  • nach Update/Installation/Server-Umzug/Mehrserver auf 1 Server bringen:
    Meldung in der startup.txt Schritt 771 "The user name (SERVER_ROOT_3) is known, has a correct account type, but there was no server found which has this account. " 


    Die Benutzertabelle prüfen und die Server-Tabelle. Jeder enaio Dienst hat einen Server-Root-Benutzer mit der Server-ID, also: SERVER_ROOT_< Server-ID > 
    SELECT * FROM SERVER; 
    SELECT * FROM BENUTZER WHERE BENUTZER LIKE 'SERVER_ROOT%';
    Beispiel für fehlerhafte Daten: 
    In der Server-Tabelle gibt es nur 1 Eintrag, aber in der Benutzer-Tabelle gibt es 2x Server_Root_3. Der mit der ID 1071275 darf nicht existieren. Nur der Eintrag mit der ID 3 darf erhalten bleiben.


    Wichtig: Diese Anpassung ist nur mit dem Support Berlin auszuführen! Es könnte noch weitere Tabellen geben, die aufgeräumt werden müssten. 

  • weitere Infos (einzelne Schritte und benannte Fehler/Ursachen) sind in KB-003/07 beschrieben. 

 

Selten aufgetreten und Ursache nicht erklärbar:

  • Meldung im Log "Language for user server_root_3 could not be determined".
    Ursache: In der Tabelle OSLANGUAGES gab es keine aktive Sprache mehr. Alle Sprachen standen auf 0. Als Workaround den Eintrag für "de_DE" auf "active=2" gesetzt. Im Screenshot ID 7:

 

Verwandte Artikel