9.0.5 bei Terminal Server

B

Bisut

Aktives Mitglied
Hallo,

ich habe nun den dritten Endkunden, wo das Live Update von 9.0.4.11 auf 9.0.5.3 nicht durchläuft. Tickets bei Sage wurden schon gestellt. Bisher ist Sage dort nichts bekannt, aber von einem Zufall kann ich nicht mehr sprechen. Bei allen drei Kunden haben wir virtuelle Server, wo die Sage Basis auf einen Server läuft, sowie die Anwendung auf den Terminal Server. Das Sage Live Update starte ich wie gewohnt auf den Sage Basis Server und da läuft es dann einfach nicht durch und es Blockieren sich immer DLL Dateien. Nicht einer oder zwei, sondern sehr viele. Laut Sage kann man vor dem Live Update die Sage Dienste beenden, dann nur Verteilungsdienst und Mehrbenutzer Dienst starten und dann das Live Update durchführen, aber das brachte keine Lösung. Ferner sollten alle USER sich nicht nur von der Anwendung Sage abmelden (Das ist doch sowieso immer so); sondern sich vom Terminal Server komplett abmelden, aber auch das bringt keine Lösung.

Ich kann mir einfach nicht mehr vorstellen, das ich nun der einzige bin, der solche Probleme hat. Denn vor der 9.0.5 lief immer alles gut. Ferner kann ich bei allen drei Kunden wieder auf die vorherige Version 9.0.4.11 zurück - ohne Probleme, ohne DLL Blockierungsprobleme. Und alle drei Kunden haben kein weiteres Produkt von SAGE, z.B. Handwerk, HR oder so.

Jemand das bekannt.

Hier nur ein Auszug von den vielen DLL Dateien, die Blockiert werden:
Sage_LiveUpate_905_DLL_Blockiert.PNG
 
In der Meldung steht 5 Minuten warten, und dann wieder probieren, haben wir schon hinter uns. Bringt auch nichts!
 
Das sieht stark nach einem Berechtigungsproblem aus.

Kann man mit dem angemeldten User die genannten Dateien denn testhalber umbenennen ohne Meldung?
 
Ein Berechtigung ist es nicht. Alle Live Updates werden immer bei mir mit dem Domänen Admin durchgeführt. Ferner gab es vor dem Live Upate 9.0.5 ja nie solche Probleme. Sage hatte mir ja auch den Vorschlag gemacht, die einzelnen DLL Dateien zu "umbenennen"; aber diesen Vorschlag habe ich gleich Abgelehnt. Das es so viele waren. Bei weniger als 5 DLL hätte ich mir das auch noch angetan. Aber so nicht.
 
Bei uns waren es die Dienste der OLSI-Schnittstelle, die beendet werden mussten. Vielleicht läuft bei Euch ja auch so ein ähnlicher Dienst.
 
Auf meiner Test- Umgebung war das auch so.
Der Hinweis von Sage (alle Sage-Dienste mittels Sage- Server- Manager beenden) hat bei mir funktioniert.
 
Hilft es nicht, wenn du über den Windows Ressourcenmonitor die Prozesse ausfindig machst, die die genannten Dateien sperren? Und dann beendest du diese einfach.
 
Zum einen könnte es einfach der Preload sein. Teilweise findet man im Taskmanager noch Prozesse die beendet werden müssen und ich hatte auch schon den Fall, dass ,warum auch immer, noch Isolation-Prozesse auf dem Server aktiv waren.
Am besten alles nach Sage durchsuchen und beenden, was nicht mit dem Deployment zusammen hängt.
 
Danke, ich werde nächste Woche noch mal einen weiteren Versuch wagen, der auch Terminal Server hat, vielleicht werde ich bewusst, auf die Uhr schauen und mal wirklich mehr als 5 Minuten warten und im Ressourcenmonitor wirklich schauen. Zumindest hatte ich vorher solch ein Problem nicht. Scheint Sage doch irgendetwas wieder anders zu machen. Egal, Lösungsansätze habe ich ja nun. Danke für guten Beiträge. Ich werde nächste Woche berichten.
 
http://live.sysinternals.com/procexp64.exe

Hilft mir da immer sehr, als Administrator ausgeführt kann man über "Find"-"Find Handle or DLL" schnell den offenen Prozess finden und beenden oder abschießen.

Ich hatte das Problem in letzter Zeit aber auch, da war zwar der Applikation Server Dienst beendet, aber die Isolation Prozesse waren alle noch da. obwohl das ja eigentlich SubProzesse sind. Kopfkratz.
 
Morje,

jo selbst wenn die SAGE Dienste aus sind, manchmal hängen da noch Isolation Prozesse / Preload Prozesse oder Dienste anderer Anbieter dran.. ein Bulk von Prüfungen die man durchführen muss :) Bald ist selbst ein Live Update ausführen ein Projekt und nichts was man so nebenbei machen sollte / kann :)
 
@d.schmitt = Danke, sehe ich mittlerweile genauso, so das ich maximal ein Live Update einplanen kann und keine weiteren Termine. Ich habe heute Nachmittag wieder einen weiteren Kunden mit Terminal Server, ich bin gespannt. Ich lasse hier Trace Log mitlaufen und habe zwei Tickets bei Sage offen. Nun habe ich aber viele Ansätze durch das Forum bekommen, so das ich beim Live Update heute durchaus anders vorgehen werde. Bin sehr gespannt.
 
Ich hatte durch Try & Error herausgefunden, dass der "Windows-Ereignisprotokoll"-Dienst auf den Sage MultiUserServiceServer.exe zugreift und die Datei dadurch weiterhin in Benutzung ist. Diesen dann an der Stelle einmal beenden und erneut prüfen ob Dateien gesperrt sind, dann lief das LU weiter.
 
Vielen Dank für die Unterstützungen. Erledigt!

Ich konnte mit der "Langen Warten der Sage Prozesse" es erreichen, das die DLL nicht blockiert sind. In dem ich auf dem Server Manger alle Sage Prozesse eine halbe Stunde vorher beendet hatte. Und alle Terminal USER auch wirklich vom Terminal Server abgemeldet sind. Bisher hatte es gereicht, das die aus Sage nur raus gingen. Jetzt bin ich auf Nummer sicher gegangen. Und das lief nun Reibungslos durch. Ohne Probleme, das sich die DLL jetzt blockierten. Die ISO Prozesse von Sage haben in der Tat länger als 10 Minuten gebraucht, bis diese frei wurden. Dank der von @planB (EXE) zum Suchen der Prozesse, konnte ich das gut erkennen. Damit ist das Thema erledigt. Ich werde bei den nächsten Terminal Server Updates nun genauso vorgehen. Damit ist ein Sage Live Update (mal eben in der Mittagspause der USER) nicht mehr möglich. Gehe nun sensibler an das Thema heran. Update ist also auf 9.0.5.4 durchgelaufen und funktioniert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben