rfbdoc hat geschrieben:Auch wenn das von CGM/TM nich kommuniziert wird, denke ich, dass die Netsetup Automatik "ausgebaut" wurde.
...
Hallo,
kann ich nicht erkennen, bei uns funktioniert(e) das Befüllen von Netsetup und das automatische Update der Clients beim ersten Start nach Update des Servers seit Umstellung von TM-DOS auf TM-WIN 2008 bis einschließlich 18.1.1 immer zuverlässig.
Man sollte lediglich das Update an den Clients erst starten, wenn das Update am Server weitgehend durch ist, da zumindest bisher beim Serverupdate erst der Inhalt der "1.CD" (obwohl ja schon lange von 2CD's auf 1 DVD umgestellt wurde, lief es ja immer noch als 2CD-Version) in Netsetup kopiert wurde, dann ein Teil des Updates durchlief, dann der Inhalt der "2.CD") in Netsetup kopiert wurde, und dann schließlich der Rest des Serverupdates erfolgte.
Bei Start an den Clients kurz nach Beginn am Server ist es mir anfänglich einmal passiert, daß die Updateroutine an den Clients schneller als am Server ablief (hier entfällt ja der Kopiervorgang von DVD in Netsetup) und daher nach etwa der Hälfte wegen noch nicht vorhandener Dateien fehlerhaft abbrach.
Vor diesem Update hatte ich noch 17.1.2.
Da ich mir nicht sicher war, ob es jetzt beim Überspringen von Updates nicht doch ernstliche Probleme gibt, da ja als Voraussetzung für 18.1.1 mindestens 17.4.1 angegeben war, habe ich zuerst die letzte offizielle "Installationsversion" 17.3.2, dann 17.4.1 und schließlich 18.1.1 am Server installiert und jeweils dazwischen den Server neugestartet.
Es wurde jedesmal Netsetup korrekt befüllt, bei 17.3.2 und 17.4.1 auch Fastobjectsserver64 korrekt als Dienst gestartet.
Lediglich nach Update 18.1.1 wurde kurioserweise eine Verknüpfung "TurboMed Datenbank Server (x64)" zu Fastobjectsserver64 ins Autostartverzeichnis gelegt und auch gleich gestartet. Der Dienst war noch vorhanden, bei Klick auf Starten kam die Meldung "wurde gestartet und wieder angehalten" oder so ähnlich, möglicherweise, weil ja der Fastobjectsserver schon als Programm gestartet worden war.
Habe dann die Verknüpfung aus dem Autostartordner gelöscht, nach Neustart gings dann wieder als Dienst.
Dabei ist mir allerdings aufgefallen, daß man den Pfad der ptserver.cfg geändert hat:
vorher:
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\Turbomed\Programm
\FastObjects64\ptserver.cfg"
jetzt (auch bei der 64Bit-Version):
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\Turbomed\Programm\ptserver.cfg"
Das war wohl auch überfällig, da beim Update \turbomed\Programm\ptserver.cfg schon immer "gewartet" wurde, hatte nach jedem Update zumindestens ein aktuelles Datum, \Turbomed\Programm\FastObjects64\ptserver.cfg hatte bei mir dagegen ein Datum vom März 2015
Die Clients habe ich dann erst nachdem am Server alles fertig war gestartet, es kam wie üblich die Meldung, daß eine neue TM-Version in Netsetup liegt, das Update lief hier dann direkt von 17.1.2 auf 18.1.1.
Natürlich wurde bemängelt, daß die Voraussetzung 17.4.1 nicht erfüllt ist und dabei neben "Abbrechen" ein "Vollupdate" angeboten.
Letzteres lief problemlos durch, einen Unterschied zwischen "Vollupdate" und den bisherigen Updates habe ich nicht bemerkt.
Aufgefallen sind mir ansonsten noch 2 Dinge:
1. Wie nach jedem Update sind in den CGM-Assist Einstellungen wieder einige Häkchen gesetzt. Eins davon: "Hinweis VERA ® TopVersorgt" unter HZV-Assistent kommt nach dem deaktivieren hartnäckig immer wieder.
2. Sicherheitshalber lasse ich nach dem Update immer im Ifap unter Wartung eine Registrierungs- und Dateiprüfung laufen:
Bei der Dateiprüfung wird diesmal an allen Stationen eine fehlende Datei bemängelt: ifapDB\Praxiscenter3\ipcneu.exe: hab sicherheitshalber das ifap-Setup nochmal laufen lassen, diese Datei scheints definitiv nicht zu geben, ist wohl ein Fehler im Wartungsprogramm (hab mal versuchsweise ipc.exe in ipcneu.exe umbenannt, danach läßt sich Ifap zwar nur noch händisch via ipcneu.exe starten, TM läuft ohne ifap, aber die Datei- und Registrierungsprüfung laufen fehlerfrei durch
).
Gruß
FranzKonrad