Sage OL 6.2 | Zugriffsproblem WaWi

Constantin

Neues Mitglied
Hallo zusammen,

um mein Problem zu beschreiben muss ich etwas weiter ausholen:
Ich bin der Administrator in unserem Speditions-Unternehmen (vor knapp einem Jahr eingestellt worden - vorher keine IT Abteilung) und wir sind gerade im Umbruch, IT-technisch.

Es wurde hier jahrelang Sage Office Line 2014 verwendet (Rechnungswesen und Warenwirtschaft), aber vor einiger Zeit wurde von der Führungsriege entschieden in Sachen ERP System auf eine Software umzusteigen, die gänzlich auf das Speditionsgeschäft zugeschnitten ist. Diese Umstellung erfolgt allerdings erst im März, so lange muss ich noch Sage OL bzw. die Warenwirtschaft laufen lassen (Wartungsvertrag ausgelaufen). Zu beachten hierbei ist, dass wir aber das Update zu Sage100 gekauft haben und auch weiterhin Sage100 Rechnungswesen als FiBu Software nutzen werden.

Den Wartungsvertrag von Sage100 haben wir vom bisherigen Partner auf Sage direkt transferieren lassen (so wie wir das auch mit Sage HR Plus gemacht haben), daher kann ich zu meinem Problem keine Hilfe erwarten, da eben kein offizieller Wartungsvertrag für das alte OL mehr besteht.

In meiner Verzweiflung kam ich nun hier her und bitte um Hilfestellung.

- Windows 2012R2 Domain
- Aufgrund einiger Umstellungen werden bestimmte Mitarbeiter nun auf einem Terminalserver (Server 2016 - Domänenmitglied) arbeiten
- Sage Office Line 2014 Evolution 6.2 (Liveupdate vom... Freitag? Ist eingespielt)

Problem:
Wenn der Nutzer in der WaWi über - Auskünfte > Verkauf > Vorgangsauskunft eine Auftragsbestätigung öffnen will kommt lediglich die Meldung "Zugriff verweigert. Fehlercode 70".

Ich habe mich bereits nach dem Fehlercode wund gesucht aber nichts gefunden - auch nicht in der Wissensdatenbank in der Sage Servicewelt.

Das Kuriose kommt aber nun.

Die Meldung erscheint nicht bzw. ich kann die AB öffnen, wenn ich mich mit einem bestimmten anderen Windows-Domänenkonto auf den Terminalserver aufschalte (es macht nie einen Unterschied ob Windows-NT oder Login/Passwort zur Anmeldung in der WaWi verwendet wurde). Das weist ja irgendwo auf eine fehlende Berechtigung hin. Leider ist mir nicht bewusst wo. Im Sage Administrator unter Benutzern sind diese Konten für die Warenwirtschaft frei - ich denke anders könnten sie das Programm auch gar nicht erst öffnen. Auch unter "Berechtigungen" im Sage Administrator sind entsprechende Konten voll berechtigt.

Ich hatte das Tracelog nebenher laufen, aber so wirklich mit dem Fehlercode bzw. der Meldung assoziierte Vorgänge konnte ich nicht erkennen.

Hat vielleicht jemand eine Idee?

Im Voraus besten Dank und frohe Weihnachten!

Beste Grüße
 
Hallo,

das bedeutet also, mit einem bestimmten Windows-Nutzer geht es immer egal welcher Login für Sage verwendet wird?
Wenn dem so ist, deutet das auf eine Windows-Berechtigung hin.
Sind denn die einzelnen Domänen-User mit der gleichen Berechtigung versehen?
Wurde einmal probiert den nicht funktionierenden User mit lokalen Admin-Rechten auszustatten?
Kann man die Verkaufsbelegmaske unter "Auftragsbearbeitung" - "Verkaufsbelege bearbeiten" öffnen?
Sind ggf. Anpassungen in der Warenwirtschaft vorhanden?

Evtl. liegt es auch an einem Office Security Update. Vielleicht mal das hier probieren:
https://support.microsoft.com/af-za...rmission-denied-generate-guid-with-office-vba
 
Hallo Olli,

genau so sieht es aus.

Beispiel:

Nutzer "domain\schmidt" kann sich wie gewohnt an seiner Workstation anmelden und nimmt die NT-Anmeldung für Sage. Alles super, funktioniert. Melde ich mich mit "domain\schmidt" am Terminalserver an und verwende entweder NT-Anmeldung oder auch Login/PW, erhalte ich Zugriff verweigert.

Ein anderer Nutzer, sagen wir "domain\mueller", kann sich ganz einfach auf den Terminalserver aufschalten und dann, NT oder Login/PW, eine AB aus Vorgangsauskunft ohne Fehler öffnen.

Beide Nutzer sind identisch in Berechtigungen.

Das sieht ja irgendwo danach aus, dass an dem Server was faul ist?
Alles sehr kurios.

Die Verkaufsbelege bearbeiten Maske kann ich öffnen, aber sobald ich dann über Beleg "Vorherige Belege" eines auswähle ist erneut Ende.

Das entsprechende Security Update wollte er nicht installieren, da angeblich keine passenden Produkte auf dem System wären. Ich hatte dann die entsprechende Registry-Anpassung, welche am Ende erwähnt wird, durchgeführt. Kein Effekt.

Ansonsten vielleicht noch eine Idee?
 
Komisches Verhalten.
Ich würde jetzt mal auf ein Problem mit dem Benutzerprofil des Users tippen. Sind Servergespeicherte Profile im Einsatz?
Kann man das Benutzerprofil des betroffenen Users am Terminalserver einmal löschen?

Was passiert wenn man einen Testuser einmal komplett neu anlegt im AD und in Sage?
Hat der betroffene Benutzer evtl. Drucker in der TS-Sitzung verbunden welche nicht verfügbar oder deren Treiber defekt sind?
Hier auch beachten, dass der PDF-XChange Drucker nicht der Standard-Drucker sein darf.
 
Hallo, der Fehlercode 70 verweist auf ein Datei-Zugriffs-Problem. Ich gehe davon aus, dass der Anwender auf dem OL-Verzeichnis nicht alle Rechte hat. Bitte mal kontrollieren. Viele Grüße
 
Hallo zusammen,

sorry für die späte Rückmeldung - ich war für die Firma unterwegs.

Servergespeicherte Profile kommen nicht zum Einsatz. Die betroffenen Profile hatten ich bereits gelöscht und wieder neu angemeldet (auch hier: "domain\mueller" und der domain\administrator haben keinerlei Probleme - mein Domänen-Admin Account wiederrum auch).

Einen neuen Testuser (Login/PW als auch Domäne) hatte ich bereits erstellt - gleiches Spiel.

Da ich mittlerweile wirklich verzweifelt war, hatte ich zusätzlich einen herkömmlichen Server 2016 als auch Windows 7 und 10 virtuelle Maschinen erstellt. Volle Updates gefahren und alles frisch installiert.

Da erhalte ich zwar keinen Fehlercode 70 beim Öffnen eines Belegs über die Vorgangsauskunft, stattdessen aber ein saftiges:

"Die Methode "Run" für das Objekt '_Application' ist fehlgeschlafen
Fehlercode -2147024770"


Es häufen sich die Fehler, so dass mir schon Angst und Bange wird, ob das System es überhaupt bis März übersteht.
Ach was wäre das schön, hätte man einen aktiven Wartungsvertrag...
 
Zurück
Oben