Druckvorschau und somit Belegdruck funktioniert nicht

NTComputing Mattern

NTComputing Mattern

Frank Mattern
Teammitglied
Hallo Zusammen,
ich habe bei einem Kunden ein sehr "interessantes" Phänomen im Bereich des Belegdrucks.

Bei Sage 100 Start auf dem PC funktioniert die Druckvorschau und der Druck
Bei Sage 100 Start auf dem TS funktioniert die Druckvorschau und der Druck nicht
(es erscheint nur die "Eieruhr" nach der Meldung das die Verbindung zum App-Server geklappt hat. Das Fenster kann geschlossen werden und dieBelegbearbeitung kann fortgesetzt werde).

Rechte in der Sage 100 sind OK.
Rechte im AD sind OK

Betroffen sind User, die sich ab Mitte Februar erstmalig am TS angemeldet haben.
User mit älteren Anmeldung am TS haben das Problem nicht.

Liveupdatestand der Sage 100: 9.0.3.7
TS: Windows Standard Server 2016, mit Februar Updates von Microsoft

Kennt jemand diese Phänomen?

Sonnigen Gruß aus Marburg
Frank
 
Hallo,

wir haben das Verhalten auch bei einem Kunden mit neuem Windows 10 Client, allerdings ist dort noch die Version 7.1 installiert.

Da das Tracelog hier nichts hilfreiches anzeigt und alle Reparaturversuche nichts gebracht haben, warten wir seit etwa 2 Wochen auf Lösungsvorschläge von Sage.
 
Moin Markus,
wir vermuten eventuell einen Beleganpassung. Da aber leider nicht bekannt ist seit wann das Phänomen auftritt, kann diese Aussage nicht verifiziert werden. Wir werden diese Woche weitere Test mit Demodaten und Standardbelegen der Sage 100 durchführen und dann weiter schauen.

Danke für die Info, dass wir nicht alleine sind :)
 
Moin Frank,

Anpassungen können wir bei unserem Kunden ausschließen, da der Belegdruck komplett im Standard genutzt wird.

Irgendwas muss Microsoft aber ja bei der Windows-Benutzeranlage (auf dem lokalen System) mittlerweile anders machen, wenn es auf dem TS nur neuere Windows-Benutzer betrifft. Die Theorie kann ich auf dem System unseres Kunden aber nicht bestätigen, da es dort keine "alten" Windows-Benutzer gibt.
 
Moin Markus,
ja, das mit den Windowsusern und dem anlagen vermuten wir auch fast.
Auf den jeweiligen PCs, auf denen es mit den Usern funktioniert, sind die User auch schon lange vorhanden.
Nur wenn sich dieselben User erstmalig ab Mitte 02 am Ts angemeldet und damit ein entsprechendes Profil erhalten haben, geht es nicht.
von sage kam jetzt der Hinweis in Richtung Metadaten importieren und Reparatur und Neukonfiguration für den Application-Server.

Das werden wir nachher um 17:00 Uhr durchführen und noch einen Test mit neu angelegten Demodaten durchführen.
 
Guten Morgen,
benutzt der TS die Access Runtime oder die Vollversion? Ich hatte letztens ein ähnliches VErhalten bei der Vollversion von Office 365 , da kam keien Vorschau und das Bild blieb leer obwohl unter "Fenster" dies geöffnet war. Ich musste die Access Runtime nachinstallieren 2016/2019 für Ofifce 365 , dann ging wieder alles... Gruss
 
Moin Herr Schmidt,
Kunde hat Access RT 2016. Das Problem tritt ja auch nur bei einigen Usern auf, nicht bei allen.

Metadaten und Reparatur Appserver hat übrigens nichts gebracht.
Im Tracelog habe wir jetzt aber immerhin Einträge:
Dem Computer muss für Delegierungszwecke vertraut werden und das aktuelle Benutzerkonto muss für die Zulassung von Delegationszwecken konfiguriert werden."

Von sage kam der Hinweis mit Kerberos bzw. den AppServer mit Domänenadmin starten.
Das testen wir jetzt

Sonnigen Gruss
 
@NTComputing Mattern Funktioniert der Druck vom PC eigentlich mit demselben Windows-Benutzer, mit dem es auf dem TS nicht funktioniert?

Grundsätzlich stellt sich ja auch die Frage, was Microsoft an den Windows-Benutzern überhaupt geändert hat. Dann könnte man einfach die Benutzer reparieren.

Über eine Rückmeldung, ob der Test als Domänenadmin beim AppServer (und Blobstorage Server?) erfolgreich war, würde ich mich freuen.
 
Moin Herr Becker,
sorry für die späte Antwort, ich komme leider erst jetzt dazu.

Ja: der User ist identisch, sowohl lokal als auch auf dem TS. Aber lokal arbeitet er bereits längeren Zeit auf dem PC, somit ist das Userprofil alt. Aus dem TS fand eine neue Anmeldung im April statt. Dort geht die Druckvorschau nicht.

Zu der Dienstanmeldung als Domänen-Admin kann ich leider keine Antwort geben. Der Kunde möchte dies noch nicht mal vernünftig und temporär testen. Hauptargument: "Wieso soll der Dienst die Rechte eines Domänenadmins haben. Das kann nicht sein. Wer weiß was der noch so alle tut".

Von daher noch keine Änderung.

Was aber interessant ist: Es handelt sich um eine Samba-Domäne mit AD. Eventuell ist hier auch eine Schwierigkeit? Diese Info la´kam leider erst jetzt.

Sonniger Gruß
Frank
 
Sichere mal bei den TS-usern, wo das Problem besteht über <Systemgrundlagen - Vorlagen-Export> die user Einstellungen und gehe dann über <Systemgrundlagen - System Reiter Diverses - Profil zurücksetzen> -> alles zurücksetzen. Wawi beenden, ein wenig warten und dann erneut testen. Wenn es klappt, dann die gesicherten Einstellungen wieder importieren und testen... erneuter Fehler? -> Übeltäter gefunden :eek:)
Man kann auch von einem user die funktionierende Vorlage über Vorlagen-Import (vorher natürlich vom user exportieren ;o) einspielen...
 
Ähnliches Problem sporadisch auch hier, nur bei Remotedesktopsitzungen gegen eine VM statt Terminalserver. Der Taskmanager zeigt dann eine hohe Last auf dem SAGE Prozess, SAGE hängt komplett und kann nur noch per Taskmanager abgeschossen werden. Betrifft auch genau einen (von 40) User, der im März neu im AD angelegt wurde. Allerdings sind noch zwei andere User später angelegt worden, und haben kein Problem.
 
Ich würde hier auch mal die Windows- Rechte auf das Dateisystem vom Terminalsever untersuchen.

In der Sage WDB gibt es dazu einen Eintrag 206366

und

nach den Einstellungen des Standard- Druckers in der Remotedesktopumgebung schauen.
 
Danke für den Tipp!
Ich habe, nur um mal ne Rückmeldung zu geben, jetzt sowohl die Druckereinstellungen kontrolliert und geändert, als auch die Officeline.config gelöscht, alle LiveUpdates gelöscht, um sie komplett neu holen zu lassen, den User als SAGE Admin laufen lassen etc.
Hat alles nichts gebracht, das Problem besteht tatsächlich aber nur bei diesem User und nur auf dieser VM, alle anderen Kombinationen (andere VM, anderer User an dieser VM) laufen ohne Problem. Ich würde tatsächlich vermuten, dass bei der Installation der Sage in diesem Benutzerkontext irgendwas schief gelaufen ist. Als Workaround bekommt er eine neue VM zugeteilt, und damit ist das Problem dann hoffentlich aus der Welt. Das ist bei einem Terminalserver natürlich was anderes.
 
Guten Morgen,
bei unserem Endkunden ist das Problem scheinbar gelöst. Letzte Tests stehen aber noch aus.
Ursache ist wohl eine Verschlüsselung die beim Anlage der Domäne in 2013 OK war.
diese Verschlüsselung ist aber geändert worden (Microsoft?) und in der Domäne wurde dieser Wechsel nicht mit durchgeführt.
Für User, bei denen die Druckvorschau noch funktionierte, wurde eine 2. Verschlüsselung verwendet, die aber wohl nicht bei ´jedem User vom AD verwendet wurde.
Der Schlüssel wurde jetzt neu erzeugt, und damit funktioniert die Druckvorschau auch bei den betroffenen User.
Sage verwendet diese Verschlüsselung bei der Erstellung des Drucks. Und ohne Verschlüsselung ging es nicht.
Ich werde noch nachtragen, so bald ich die Info habe, um welchen Schlüssel, bzw. Verschlüsselung es sich handelt.

Einen schönen Tag.
Frank
 
Falls es jemandem helfen sollte: bei uns hat sich das Problem dann dadurch erledigen lassen, dass wir dem Benutzer (Domänenbenutzer) gleichzeitig lokale Adminrechte auf der VM gegeben haben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben