Anmeldung aller Benutzer schlägt fehl

planB

planB

Sehr aktives Mitglied
Teammitglied
Moin wie haben gerade ein extrem kurioses Problem bei einem Kunden.
Obwohl im Administrator alles zu funktionieren scheint, kann sich niemand mehr an der Applikation anmelden. Für jeden Benutzer wird ein Fehler im TraceLog geworfen der so ausieht.

Code: 
Es ist eine Ausnahme beim Datenzugriff aufgetreten: Sagede.OfficeLine.Data.DataAccessException: Fehler beim Aufbau der Datenverbindung. ---> System.Data.SqlClient.SqlException: Fehler bei der Anmeldung für den Benutzer "_OLSys_SAGE".
   bei System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   bei System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   bei System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   bei System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   bei System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   bei System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry)
   bei System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
   bei System.Data.SqlClient.SqlConnection.Open()
   bei Sagede.OfficeLine.Data.AdoNetConnection.InternalOpen()
   bei Sagede.OfficeLine.Data.AdoNetConnection.<>c__DisplayClass31_0.<OpenWithRetry>b__1()
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.<>c__DisplayClass1.<ExecuteAction>b__0()
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func)
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction(Action action)
   bei Sagede.OfficeLine.Data.AdoNetConnection.<>c__DisplayClass31_0.<OpenWithRetry>b__0()
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.<>c__DisplayClass1.<ExecuteAction>b__0()
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func)
   bei Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction(Action action)
   bei Sagede.OfficeLine.Data.AdoNetConnection.OpenWithRetry(RetryPolicySettings retryPolicy, Boolean suppressAccessTokenAssign)
   bei Sagede.OfficeLine.Data.AdoNetConnection.Open(NamePasswordCredential namePasswordCredential)
   --- Ende der internen Ausnahmestapelüberwachung ---
Nach Neuregistrierung der Datenbank passiert dasselbe auch für den DEFAULT Benutzer der Datenbank.
Das ist eine 9.0.11.1 mit einem SQL2019 und es wurde nix geändert, es hat einfach aufgehört zu funktionieren.
Neuanlage Benutzer, Reparatur AppServer, Server Neustart, alles ohne Ergebnis. Im SSMS sieht alles normal aus und in den Fehlerprotokollen des Server sieht man auch nur die fehlgeschlagenen Anmeldungen der OLSYS Benutzer.

Das ist doch wirklich seltsam, aber vielleicht hat das ja schon mal jemand anderes erlebt...
 
Tritt der Fehler nach dem Update auf die 9.0.11 auf?
Nach dem Update muss für jede Datenbank der Systembenutzer plus Kennwort im Sage 100 Administrator einmal neu eingetragen werden.
 
Hat der Kunde mehrere Datenbanken und betrifft das ggf. alle oder nur eine? Falls er nur eine hat: wäre die Anlage der Sage Demo-DB möglich für einen kurzen Test? Dauert i.d.R. nicht lange. Habt ihr die Zuordnung der OLSYS-Benutzer zu der / den Datenbank/en und deren Standardschema geprüft?
 
diakh schrieb:
Tritt der Fehler nach dem Update auf die 9.0.11 auf?
Nach dem Update muss für jede Datenbank der Systembenutzer plus Kennwort im Sage 100 Administrator einmal neu eingetragen werden.
Zum Vergrößern anklicken....
Nein, der Fehler trat erst etwa eine Woche nach Umstellung auf die 9.0.11 auf. Ich hatte ja auch geschrieben, dass die ich die Datenbank neu registriert habe.
 
diakh schrieb:
Auch die globale Datenbank?
Zum Vergrößern anklicken....
Ich muss mich korrigieren. Der Kunde hatte vorher die 9.0.10, wir haben auf 9.0.11 geupdated und danach wurde erst mal nicht gearbeitet. (Augenroll) mit der 9.0.11 hat es nie geklappt. Leider ist das noch noch ein SQL Server 2019 auf einem Server 2016. Ich befürchte das das endgültig nicht mehr passt. Demodatenbank zeigt dasselbe Verhalten. OLGlobal hiess anders, habe ich aus der Sicherung geholt und als OLGlobal wieder eingehängt. SQL Server noch mal aktualisiert. Hilft alles nicht. Es kann sich nicht mal mit seinem DEFAULT Benutzer intern anmelden. Sage muss da irgendwas geändert haben. Seufz. Wir werden wohl jetzt ausserplanmäßig einen neuen Server bauen müssen.
 
wir haben das Problem aktuell bei 3 Kundensystemen und die Tickets bei Sage Eskaliert, löschen aller _olsys_User und neuregistrierung der DB's führt nicht dazu, dass Sage die User neu anlegt und weiterhin den Fehler bringt. Neuanlage einer DEMO Datenbank funktioniert jedoch.
 
Ich konnte das Problem nachstellen, in dem ich in das sa-Passwort (habe dafür einen neuen Benutzer mit SA-Rechten angelegt) Umlaute und/oder ein "ß" eingefügt habe. Da war es so, dass es beim Klick auf "Weiter" bei der Benutzereingabe nichts gemacht hat und die Fehlermeldung von euch im Tracelog hatte. Sobald ich die Umlaute und das "ß" rausgenommen habe und das aktuelle Passwort in den Eigenschaften im Sage Administrator hinterlegt habe, hat die Anmeldung wieder funktioniert.

In einer 9.0.10er Umgebung gibt es das Problem scheinbar tatsächlich nicht. Da hat es bei mir auch mit Umlaut/"ß" funktioniert.

Evtl. hilft es euch ja weiter...
 
Danke für den Hinweis, aber ich verwende weder Umlaute noch ß in Passwörtern. Der Server 2016 ist ja nun sowieso fällig. Und der MS SQL 2025 Express kann ja nun auch 50GB. Also macht es Sinn, die Umstellung vorzuziehen. Ich hätte es nur gerne ohne den Extra Stress in Ruhe gemacht. Aber es ist wie es ist. Danke für Deine Mühe.
 
Zuletzt bearbeitet:
Tobias Langer schrieb:
wir haben das Problem aktuell bei 3 Kundensystemen und die Tickets bei Sage Eskaliert, löschen aller _olsys_User und neuregistrierung der DB's führt nicht dazu, dass Sage die User neu anlegt und weiterhin den Fehler bringt. Neuanlage einer DEMO Datenbank funktioniert jedoch.
Zum Vergrößern anklicken....
Das mit der DemoDatenbank habe ich auch probiert und die ging bei mir AUCH nicht. Aber ich bin ein bisschen froh das ich nicht alleine oder zu doof bin. :cool:
 
Das Problem hatten wir direkt nach dem Liveupdate auf 9.0.11.1 in unserer Entwicklungsumgebung auch und haben massiv Zeit für die Fehlersuche inkl. Sage-Support investiert.
Nach der Installation von 9.0.11.2 war das Problem aber weg.
Bitte um kurze Rückmeldung, ob das Liveupdate 9.0.11.2 geholfen hat!
 
Leider hat das Liveupdate auf die 9.0.11.2, was uns auch die Hotline als einzigen Lösungsvorschlag angeboten hatte, in diesem Falle nicht geholfen.
Ich würde halt nur gerne verstehen, was sage da geändert hat um vielleicht doch noch eine schnelle Lösung zu finden.
 
Neu ab der 9.0.11 ist, dass die Zugangsdaten des System-Benutzers über den "Application Gateway"-Dienst verwaltet werden. Daher müssen die Zugangsdaten auch einmalig neu im Administrator eingegeben werden und der Dienst "Sage Applicationgateway Service" ist für den Betrieb der Sage 100 erforderlich. Vielleicht ist hier das Problem zu suchen (Berechtigungen des Dienst-Kontos, ...)?!

An dem SQL Server 2019 wird es nicht liegen (läuft bei mir mit der 9.0.11).
An dem Server 2016 wahrscheinlich auch nicht - kann ich aber nicht beurteilen.
 
Das ist ziemlich aufschlussreich. Sage verwendet hier im Standard den Netzwerkdienst als Konto. Das authorisiert sich im Netz für den Zugriff auf Netzressourcen als das Computerkonto der Maschine auf der der Dienst läuft. Wenns aber ein verstecktes AD Problem ist, würde das erklären warum alle bisherigen Maßnahmen nichts gebracht haben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben