Wir haben hier eine zugegebenermaßen alte Warenwirtschaft pro (2013 13.03.01.0159), aber vielleicht hat ja jemand das im folgenden beschriebene Problem schon einmal gesehen und kann zumindest andeuten, ob ein Upgrade hier überhaupt hilfreich sein kann oder ob dies ganz anders anzugehen ist.
Wir führen gerade eine Gruppenrichtlinie zur Softwareeinschränkung (SRP) ein, um das Ausführen von Programmen aus anderen als ausdrücklich genehmigten Pfaden zu verhindern, Server ist ein 2012R2, die Clients Windows 7 64 Bit. Das funktioniert auch im wesentlichen gut, nur Lexware schiesst noch etwas quer.
Die Warenwirtschaft ist lokal auf dem Client installiert mit Datenverzeichnissen auf einer Freigabe des Servers. Bei aktivierter Richtlinie lässt sich die warenwirtschaft zwar noch starten und der Benutzer kann sich anmelden, will man danach jedoch irgendetwas tun (z.B. Aufträge Verkauf aufrufen), kommt es zu einem Event 1002 „Application Hang“ mit folgendem Text: „Programm Framework.exe, Version 13.2.0.142 kann nicht mehr unter Windows ausgeführt werrden und wurde beendet“. Windows wird in diesem Moment insgesamt zäh bis zur Unbedienbarkeit, normales Arbeiten ist erst nach Abschießen von Lexware im Taskmanager wieder möglich. Weitere Fehlermeldungen sind nicht zu beobachten, im Nutzerprofil sind keine ausführbaren Dateien zu finden, die eventuell durch die Richtlinie geblockt werden könnten.
Was tut Lexware da? Wir haben die üblichen Pfade für ausführbare Dateien freigegeben (Systemverzeichnis und die Programmverzeichnisse für 64 und 32 Bit), das sollte eigentlich reichen.
Die ist tatsächlich schon etwas betagt. Ob ein Update bei dem oben geschilderten Sachverhalt etwas ändert müsste man ausprobieren, ich denke aber eher, die Problematik liegt woanders.
Ist die Richtlinie nicht aktiv, klappt alles soweit wieder problemlos?
dann muss ich an dieser Stelle leider passen, mit der Richtlinienthematik bin ich zu wenig vertraut.
Sollte niemand anderes aus der Community eine Idee oder einen Lösungsansatz hierzu haben, empfehle ich die Kontaktaufnahme mit der Lexware Hotline, welche bei Bedarf auch via Fernwartung mit auf den PC schauen kann.
Diese Geschichte hat sich irgendwann dann noch aufgeklärt, wenn auch nicht wirklich „schön“, wie ich finde. Hier eine kurze Zusammenfassung, falls andere mal darüber stolpern:
Das Entpacken nach %TMP%, in unserem Fall %APPDATA%\local\Temp funktioniert, aber von dort aus darf halt unter SRP nichts ausgeführt und auch keine DLL geladen werden. Schliesslich kann so ziemlich alles nach %TMP% schreiben, also auch jede unüberlegt heruntergeladene Malware. Daher möchten wir eigentlich von dort nichts ausführen oder laden.
Lexware versucht also, eine DB-Verbindung aufzumachen, entpackt dbdata12.dll nach %TMP%{16AA8FB8-4A98-4757-B7A5-0FF22C0A6E33}_1201_1 und versucht, die DLL zu laden. Sobald das nicht geht, gibt Lexware nicht etwa auf, sondern packt die DLL erneut aus, diesmal nach %TMP%{16AA8FB8-4A98-4757-B7A5-0FF22C0A6E33}_1201_2. Das geht so lange in sehr hohem Tempo weiter, bis man Lexware über den Taskmanager killt. Ich habe dort mehrere Tausend dieser Unterverzeichnisse vorgefunden…
Der einzige (unschöne) Workaround besteht derzeit in der Tat darin, in der SRP eine Ausnahmeregel für %TMP%{16AA8FB8-4A98-4757-B7A5-0FF22C0A6E33}_1201_1 zu definieren. Keine Ahnung, wieso Lexware die DLL nicht gleich im Installationsverzeichnis ablegt.
danke für die Rückmeldung und die ausführliche Erläuterung.
Warum das programmseitig so gehandhabt wird, kann wohl leider nur die Produktentwicklung beantworten. Ich hoffe aber, dass der Workaround für Euch gut funktioniert.
Das ist (leider) das Standardverhalten des Datenbanktreibers von Sybase. Lexware kann da nichts dran ändern. Unsere Tools handhaben das auch genauso, da es wie gesagt direkt vom Sybase .Net Treiber kommt.
