eAU-Reparatur-Batch Nummer 2

Fragen, Anregungen oder Tipps und Tricks? Hier ist der erste Anlaufpunkt.
Nicht sicher, wo ein Thema hingehört? Hier hinein - wir kümmern uns! :)

Moderator: Forum Moderatoren

Forumsregeln
TM-Startforum - "offen für alle Themen".
Beiträge, die in einen anderen Bereich passen, werden bei Bedarf verschoben.
Benutzeravatar
FortiSecond
Beiträge: 562
Registriert: Dienstag 2. August 2022, 21:30
1
Hat sich bedankt: 207 times
Bedankt: 141 times

eAU-Reparatur-Batch Nummer 2

Beitrag von FortiSecond »

Hier nun Version 2 ohne Puffer-Ordner.

Aufgabe
Damit eAU wieder läuft: Plugins-Pfad automatisiert bereinigen.
Version 2 kommt ohne Auslagern dern .jar-Dateien daher und ist damit quasi updatefest (neue Ordner müssen manuell nachgetragen werden - sicher ist sicher).

Was macht die Batch-Datei?
1) Die Batchdatei killt die Java-Prozesse des CGM Communicator
2) Die Batchdatei entleert alle Ordner unterhalb \turbomed\programm\communicator\plugins
Das war´s auch schon.
An manchen Clients reicht´s einmalig. An anderen muss es alle paar Stunden passieren. Nun ja...

Anwendung:
TM beenden
Batchdatei "Als Administrator ausführen"
TM starten


Wichtig:
- Anpassung an eigene Laufwerke/Ordner erforderlich.
- Auf Terminalserver beachten, dass das Killen der Java-Prozesse dann alle angemeldeten Stationen einschließt, so dass dort jeweils TM zwar weiterläuft, aber für alles, was der Communicator so macht, unter Umständen die stationsbezogenen Communicator-Instanzen wieder zu starten sein werden (TM beenden, starten, fertig)

Haftung:
Schließe ich aus. Alles auf eigene Verantwortung.
Mir sind keine negativen Aspekte bekannt.


Hinweis zur eigenen Sicherheit: Die Batch ist "so" nicht direkt wirksam, um Schaden durch versehentliches Ausführen zu vermeiden.
Die beiden mit REM startenden Zeilen UNBEDINGT an den Arbeitsplatz bzw. RDP-Server anpassen und danach das REM entfernen.
Die pause-Anweisung am Ende kann auch entfernt werden. Sie dient nur der Funktionskontrolle...

Code: Alles auswählen

@echo off
echo Jetzt sollte TurboMed beendet werden oder bereits geschlossen sein! Wenn nicht: Abbruch mit STRG+C und TM beenden.
pause
REM wmic process where ExecutablePath='d:\\TurboMed\\Programm\\communicator\\jre\\bin\\javaw.exe' delete
REM set plugpath=d:\turbomed\programm\communicator\plugins\
del /s /q %plugpath%AeND
del /s /q %plugpath%ArminPlugin
del /s /q %plugpath%CgmAssist
del /s /q %plugpath%Clickdoc
del /s /q %plugpath%Connectdiagnostic
del /s /q %plugpath%ubePlugin
del /s /q %plugpath%DaleUV
del /s /q %plugpath%DaleUVCommunication
del /s /q %plugpath%DigaStore
del /s /q %plugpath%eInvoice
del /s /q %plugpath%EPrescription
del /s /q %plugpath%EVaccinationCertificateService
del /s /q %plugpath%IdentityProvider
del /s /q %plugpath%JesajaNetPlugin
del /s /q %plugpath%KomLePlugin
del /s /q %plugpath%KvCommunicationsPlugin
del /s /q %plugpath%MedDataPlugin
del /s /q %plugpath%Privadis
del /s /q %plugpath%ReadinessCheck
del /s /q %plugpath%SaniQPlugin
del /s /q %plugpath%SecureFileTransfer
del /s /q %plugpath%SecureMailClient
del /s /q %plugpath%SimpleFileTransfer
del /s /q %plugpath%SmartUpdate
del /s /q %plugpath%TelematikPlugin
del /s /q %plugpath%vitaphone
del /s /q %plugpath%WebService
pause
PS: Hier befindet sich bewusst kein Dateianhang. Zum Einen blockieren moderne Browser und Virenscanner Download/Ausführung von BAT-Dateien aus gutem Grund. Zum Anderen ist ein gewisses Maß an Grundwissen obligatorisch. Und die Anpassung kann so nicht vergessen werden :)
--
TurboMechaniker seit 1992, kann auch etwas T2, Medoff, ALBIS, inSuite
W. Steuber
Beiträge: 143
Registriert: Samstag 3. Januar 2009, 16:55
15
Wohnort: Rinteln
Bedankt: 7 times

Jetzt mal ehrlich

Beitrag von W. Steuber »

Wie schlimm ist das denn?
Also nicht die Batch, die sicherlich Rettungsanker für Viele sein kann.
Sondern der Anlass: Ein hochbezahltes Unternehmen schafft es nicht, seine Produkte den Alltagserfordernissen entsprechend anzupassen??
Wenn dies ein Betriebsprogramm für Kernkraftwerke wäre, ließe sich ausmalen, wie die Zukunft aussähe ....

Respekt für die, die immer noch weiter machen mit diesem System ....

Und vor allem Respekt für Retter in der Not, Aufklärer und Wasauchimmer wie die zweitevierzig ;)
Benutzeravatar
FortiSecond
Beiträge: 562
Registriert: Dienstag 2. August 2022, 21:30
1
Hat sich bedankt: 207 times
Bedankt: 141 times

Re: Jetzt mal ehrlich

Beitrag von FortiSecond »

W. Steuber hat geschrieben:Wie schlimm ist das denn?
Also nicht die Batch, die sicherlich Rettungsanker für Viele sein kann.
Sondern der Anlass: Ein hochbezahltes Unternehmen schafft es nicht, seine Produkte den Alltagserfordernissen entsprechend anzupassen??
Wenn dies ein Betriebsprogramm für Kernkraftwerke wäre, ließe sich ausmalen, wie die Zukunft aussähe ....

Respekt für die, die immer noch weiter machen mit diesem System ....

Und vor allem Respekt für Retter in der Not, Aufklärer und Wasauchimmer wie die zweitevierzig ;)
Danke für die Blumen. :P
Der Aufwand ist überschaubar, und mit vielleicht 1 Stunde gezielter Programmierung wäre das ganze mit Abfrage der Registry für die Pfade, mit für RDP auch sitzungsbezogene Taskbeendigung (Java) und als signierter Installer mit Mini-GUI abzuliefern.
Wie lange hatte CGM nun dafür Zeit?!
Ach nee, die baden lieber in ihrem Geldspeicher mit dem Zufluss aus aus SWP für RKI-Zertifikate, Fremdkonnektor-Anbindungen und einem ePA-Zuschlag beim Zugangsdienst.

Zurück zur Batch: Leistet seit Wochen gute Dienste. Heute die letzte Praxis versorgt, ab morgen dann die neue Fassung für alle. Besonders in den Stoßzeiten sind die Unterbrechungen damit gut im Griff.



Zwar weicht es etwas vom Thema ab, aber so ein paar Erlebnisse der letzten Wochen lassen mich nun hart durchgreifen und Ernst machen. Zwischenstand:
- Zwei laufende Wechsel zu T2med, einer zu MedOff (Praxis mit zugeflogenen MFA, die es in- und auswendig kennen).
- Weitere sind sprungbereit.
- "Meine" Praxen, die ab 30.09.2023 noch mit einem CGM-PVS arbeiten (mit Ausnahme ALBIS und natürlich einigen Kolleginnen und Kollegen, die dem Ruhestand entgegensehen), dürfen sich einen neuen Servicedienstleister suchen. Und das wird schwer in unserer Region... zumindest wenn man zweistellige Stundensätze, freie Hardware-Wahl ohne "Doktoren-Aufschlag" sowie kreative/moderne Ansätze schätzen gelernt hat und unterbrechende Aktionen gern über Nacht erledigt sieht. Das sieht nur geschrieben so forsch aus - in diesen stressigen Zeiten sind (bisher) alle dankbar für diesen "Ruck". Und nach 30 Minuten Demo-Client ist das sowieso ein Selbstläufer.

Ziel: Stressbegrenzung/Fürsorge für mein Team, mich selbst, die vielen frustrierten MFA samt deren Brötchengebenden (scnr) und am Ende Wirtschaftlichkeit für alle. Kurz: Partnerschaftlich nach vorn schauen. Da habe ich es mit den 4 Viechern aus Bremen: "Etwas Besseres als den xyz finden wir überall." Für xyz kann eine beliebige Kombi aus drei Buchstaben eingesetzt werden, z.B. Tod oder WTF oder irgendwas mit C.

Neuester Tiefschlag: VPN-Zugangsdienst 12 Monate weiterzahlen, obwohl Konnektor unbrauchbar. Für ein anderes CGM-Programm kostet das Modul für Fremdkonnektoren gut 300 Euro netto und dann monatlich was bei 10 Euro. Also sponsore ich zum Dank die Datenkonvertierung zu T2med (bin frei, bekomme keine Sonderkonditionen) und behalte die Praxis in guter Betreuung. Letztlich gebe ich damit den Umsatz aus dem Mehraufwand für die CGM eAU zurück. Das sind mir meine geschätzten Praxen wert. Und noch mehr - aber das gehört hier nicht ins Forum :)

Auf einen kurzen Mittwoch - 42nd :)
--
TurboMechaniker seit 1992, kann auch etwas T2, Medoff, ALBIS, inSuite
McLeod
Beiträge: 412
Registriert: Samstag 25. Februar 2012, 15:04
12
Bedankt: 13 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von McLeod »

Ich gebe hier ja nur ungern den "Party-Pooper", aber wenn ich mir o.g. Ordner ansehe, finden sich dort eigentlich nur Dateien, die seit dem letzten Update nicht mehr verändert wurden. Somit sehe ich nicht wirklich, daß hier primär das Problem sitzen soll. Der ganze skizzierte Vorgang wird schon zum gewünschten Ergebnis führen, aber wohl eher als eine Art "Sekundäreffekt".
Viel interssanter ist in diesem Zusammenhang eigentlich <TM-Pfad>\Daten\Var\aWinS\local\<Host- bzw. Clientname>, dessen Leerung (nach PC-Neustart bzw. Ab- und wieder Anmelden der Terminalsitzung -> "automatische" Bereinigung evtl. hängender Java-Prozesse) bis jetzt jedesmal zuverlässig die nach Absturz des eMuster-Centers auftauchende CGM-Connect-Nervmeldung wieder beseitigt hat.
Legt man nun besagten Ordner als Verknüpfung auf den Desktop oder dort eine Einzeiler-Batchdatei zur "EIn-Klick-Bereinigung" ab, kann der eigentliche "Reparaturvorgang" problemlos von jedem Benutzer selbst durchgeführt werden.
Benutzeravatar
Lazarus
Beiträge: 1151
Registriert: Freitag 22. Dezember 2006, 17:04
17
Hat sich bedankt: 13 times
Bedankt: 24 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Lazarus »

Den Inhalt von
<TM-Pfad>\Daten\Var\aWinS\local\<Host- bzw. Clientname>,
löschen klingt gut.
Müssen die Javaprozesse überhaupt vorher beendet werden?
Benutzeravatar
FortiSecond
Beiträge: 562
Registriert: Dienstag 2. August 2022, 21:30
1
Hat sich bedankt: 207 times
Bedankt: 141 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von FortiSecond »

Die betreffenden Java-Prozesse müssen beendet werden, weil sie auf die Dateien zugreifen.
Beim aWinS kommt wohl noch mindestens ein Prozess von CGM Assist hinzu. Denn beim Absturz kann TM diese Prozesse nicht beenden. Und selbst beim normalen Beenden bleibt CGM Assist manchmal offen.

@McLeod: Danke für diesen spannenden Tipp. Eine Ebene "höher" suchen, denn -> Interessant, wenn der andere Weg auch zum Ziel führt.

Am Ende sind Wirkung und Ergebnis beider Varianten meiner ersten Sichtung nach gleich ->

1) Die Batchdatei löscht unter plugins die stationsbezogenen (beim TS die globalen) Einstellungen des communicators, die beim Start von CGM Connect (vermutlich) aus der Datenbank heraus regeneriert werden.
Konkret werden ausschließlich die Dateien in den aufgeführten Unterordnern gelöscht. Die sind nicht seit dem Update unverändert, sondern werden im Betrieb sowohl gelesen als auch geschrieben (kleine SQlite und sowas, sind auslesbar). Die Ordnerstruktur und die .jar fasst die Version 2 nicht mehr an.

2) Das Löschen der Stationseinstellungen im CGM Assist (aWinS) führt zu... Neuaufbau der Einstellungen in aWinS und danach zum... Neuaufbau der Dateien in den Ordnern, die in der Batch aufgeführt sind.

Was sich daraus schließen lässt:
Die Ursache liegt in der Ebene /%$/&@ CGM ASSIST bzw. dessen Konfiguration, die während der Laufzeit zu Fehlern oder Hängern in den Dateien unterhalb plugins führt. Oder noch weiter oben.

Vermuten kann ich hier verbuggten Code oder "zu viele Kochende", denn was so ein Debug-Trace hergibt, ist schon eine Menge. Beim KIM-Clientmodul ist es ja ähnlich, aber das ist ein anderes Thema.
Auch vermute ich, dass CGM ASSIST für alles herhalten muss, weil alles nur noch dort entwickelt und per Schnittstelle an TM, ALBIS und Co. angebunden wird.

Seitenhieb auf ASSIST und CGM CONNECT: Lt. Beschreibung TURBOMED ist CGM CONNECT zu keinem Zeitpunkt zwingend erforderlich, sondern rein freiwillig. Ich würde sagen, dass es erforderlich IST. Allenfalls ist ein Konto (Praxiskonto, Arztkonto) nicht zwingend nötig.
--
TurboMechaniker seit 1992, kann auch etwas T2, Medoff, ALBIS, inSuite
Benutzeravatar
Lazarus
Beiträge: 1151
Registriert: Freitag 22. Dezember 2006, 17:04
17
Hat sich bedankt: 13 times
Bedankt: 24 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Lazarus »

ok, mit dieser Batch-Datei (wir habeen Nr1 angepasst) können wir das Problem beim Einlesen der Karten bei Neupatienten und neuen Karten einigermaßen lösen. Nach Absturz kann der Patient sofort wieder eingelesen werden.
(Es scheint ein Problem mit dem Länderkennzeichen zu geben, so wie es aussieht, es wird nach dem Absturz erneut abgefragt als Adressänderung.)
Die eAUs lassen sich dann auch wieder erstellen, wenn nach dem Versand der PC hängt. oder die DMPs u.s.w
P.S.: Mittlerweile können wir alle eAU auf eimal abschicken, nicht mehr portionsweise


Dennoch ist das, was hier von der Firma geboten wird, eine Zumutung
Schorsch
Beiträge: 87
Registriert: Sonntag 5. Januar 2020, 21:50
4

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Schorsch »

kurze Frage: Kann es sein, dass der Fehler "201" auch durch das gleiche Problem erzeugt wird.
Bei uns in der Praxis funktionierte die eAU für 1,5 Tage, seitdem kommt die Fehlermeldung, dass das Passwort nicht korrekt sei..

in der Datei: "KIMMailprotokoll" steht folgendes geschrieben:
03.01.2023 11:41:17|<PRAXISNAME>@tm.kim.telematik|erfolgreich|erfolgreich
03.01.2023 17:48:21|<PRAXISNAME>@tm.kim.telematik|fail|Exception when getting mails. Invalid password. The mail poller stopped.

Im "Communicator"Protokoll tauchen in dem Zeitraum folgende Infos auf:
2023-01-03 15:06:52,059 [DEBUG] [GMR] cgm.connect.connector.plugindb.RetryingDataSource - Retrying to establish a database connection, attempt no 7.
2023-01-03 15:06:54,061 [DEBUG] [VSJ] cgm.connect.connector.plugindb.RetryingDataSource - Database connection failed
java.sql.SQLException: Cannot create PoolableConnectionFactory (Verbindung ist unterbrochen: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831"
Connection is broken: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831" [90067-199])
at org.apache.commons.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:653) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.apache.commons.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:531) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:731) ~[commons-dbcp2-2.9.0.jar:2.9.0]
at com.cgm.connect.connector.plugindb.AbstractDataSource.getConnection(AbstractDataSource.java:35) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.H2BasicDataSource.getConnection(H2BasicDataSource.java:29) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.RetryingDataSource.connectWithRetry(RetryingDataSource.java:76) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugindb.RetryingDataSource.getConnection(RetryingDataSource.java:64) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugins.smartupdate.dao.LiquibaseUtil.updateDatabase(LiquibaseUtil.java:26) ~[SmartUpdate-core-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugins.smartupdate.SmartUpdatePlugin.init(SmartUpdatePlugin.java:147) ~[SmartUpdate-core-2.3.1.jar:2.3.1]
at com.cgm.connect.communicator.plugins.smartupdate.CommunicatorSmartUpdatePlugin.initialize(CommunicatorSmartUpdatePlugin.java:133) ~[Communicator-SmartUpdate-Plugin-2.3.1.jar:2.3.1]
at com.cgm.connect.communicator.plugin.ServicePluginManager.initialize(ServicePluginManager.java:304) ~[Communicator.jar:2.3.1]
at com.cgm.connect.connector.plugin.AbstractServicePluginManager.initializePlugin(AbstractServicePluginManager.java:402) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.connector.plugin.AbstractServicePluginManager.lambda$new$0(AbstractServicePluginManager.java:103) ~[Connector-impl-2.3.1.jar:2.3.1]
at com.cgm.connect.common.util.plugin.PluginManager.lambda$installPlugin$13(PluginManager.java:669) ~[util-2.3.0.jar:2.3.0]
at java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source) [?:?]
at java.util.concurrent.CompletableFuture$Completion.run(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
Caused by: org.h2.jdbc.JdbcSQLNonTransientConnectionException: Verbindung ist unterbrochen: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831"
Connection is broken: "java.net.SocketTimeoutException: connect timed out: SERVERNAME:47831" [90067-199]
...und so weiter..

kann damit jemand was anfangen?
Schorsch
Beiträge: 87
Registriert: Sonntag 5. Januar 2020, 21:50
4

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Schorsch »

Reicht das aus, wenn das an dem Rechner durchläuft wo die Signierung ausgeführt wird?
Kann es irgendwelche Probleme geben, wenn man das in einem Client-Server-System auf dem Server und allen Arbeitsplätzen ausführt?
(Hab es bisher nur auf einem Client getestet und das scheint nicht auszureichen?
FortiSecond hat geschrieben:Hier nun Version 2 ohne Puffer-Ordner.

n manchen Clients reicht´s einmalig. An anderen muss es alle paar Stunden passieren. Nun ja...

Anwendung:
TM beenden
Batchdatei "Als Administrator ausführen"
TM starten


Wichtig:
- Anpassung an eigene Laufwerke/Ordner erforderlich.
- Auf Terminalserver beachten, dass das Killen der Java-Prozesse dann alle angemeldeten Stationen einschließt, so dass dort jeweils TM zwar weiterläuft, aber für alles, was der Communicator so macht, unter Umständen die stationsbezogenen Communicator-Instanzen wieder zu starten sein werden (TM beenden, starten, fertig)
Benutzeravatar
FortiSecond
Beiträge: 562
Registriert: Dienstag 2. August 2022, 21:30
1
Hat sich bedankt: 207 times
Bedankt: 141 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von FortiSecond »

Kurz: Es kann nicht schaden, das an allen Stationen auszuführen.
Eigentlich sollte es reichen, an den signierenden Stationen die Batch laufen zu lassen. Aber möglicherweise muss der Server es auch haben. Kann ich gerade nicht prüfen (Zeit).
--
TurboMechaniker seit 1992, kann auch etwas T2, Medoff, ALBIS, inSuite
rfbdoc
PowerUser
Beiträge: 2918
Registriert: Sonntag 30. April 2006, 19:31
17
Hat sich bedankt: 28 times
Bedankt: 49 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von rfbdoc »

Inzwischen arbeite ich auch mit dieser Batch, Vielen Dank an Fortisecond

Mehr durch Zufall bin ich allerdings auf einen kleinen Schreibfehler in einer Zeile gestoßen
Die Zeile
del /s /q %plugpath%ubePlugin
soll vermutlich
del /s /q %plugpath%CubePlugin
lauten

Ich arbeite jetzt mit folgender Syntax, die zugleich auch den TM Installationspfad abfragt
**************************************************************************************************************
@echo off
::Auslesen der Windowsversion
reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set OS=32BIT || set OS=64BIT
if %OS%==32BIT goto :Win32
if %OS%==64BIT goto :Win64

::Auslesen des TurboMed Installationspfades aus der Registry
:Win32
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win32
echo TurboMed Installation: %x%
set TmPfad=%x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo%TmPfad% als Variable TmPfad gesetzt
echo Die Variable wurden aus der Registry ausgelesen
goto :Weiter

:Win64
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win64
echo TurboMed Installation: %x%
set TmPfad=%x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo Die Variable wurden aus der Registry ausgelesen
echo TmPfad=%TmPfad% gesetzt
goto :Weiter

:Weiter
set plugpath=%TmPfad%\turbomed\programm\communicator\plugins\
echo PlugPath=%plugpath% gesetzt
Pause
wmic process where ExecutablePath='%TmPfad%\\TurboMed\\Programm\\communicator\\jre\\bin\\javaw.exe' delete
pause
del /s /q %plugpath%AeND
del /s /q %plugpath%ArminPlugin
del /s /q %plugpath%CgmAssist
del /s /q %plugpath%Clickdoc
del /s /q %plugpath%Connectdiagnostic
del /s /q %plugpath%CubePlugin
del /s /q %plugpath%DaleUV
del /s /q %plugpath%DaleUVCommunication
del /s /q %plugpath%DigaStore
del /s /q %plugpath%eInvoice
del /s /q %plugpath%EPrescription
del /s /q %plugpath%EVaccinationCertificateService
del /s /q %plugpath%IdentityProvider
del /s /q %plugpath%JesajaNetPlugin
del /s /q %plugpath%KomLePlugin
del /s /q %plugpath%KvCommunicationsPlugin
del /s /q %plugpath%MedDataPlugin
del /s /q %plugpath%Privadis
del /s /q %plugpath%ReadinessCheck
del /s /q %plugpath%SaniQPlugin
del /s /q %plugpath%SecureFileTransfer
del /s /q %plugpath%SecureMailClient
del /s /q %plugpath%SimpleFileTransfer
del /s /q %plugpath%SmartUpdate
del /s /q %plugpath%TelematikPlugin
del /s /q %plugpath%vitaphone
del /s /q %plugpath%WebService
pause
********************************************************************************************************
R.F.B.
Johnny
Beiträge: 1092
Registriert: Freitag 2. Februar 2007, 00:47
17
Wohnort: Kiel
Hat sich bedankt: 108 times
Bedankt: 10 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Johnny »

Danke FortiSecond,
Danke rfbdoc,

funktioniert.

Erhalte noch eine Fehlermeldung in "CGM CONNECT diagnostics:
Fehlermeldung CGM Connect.png
@ W.Steuber

Ja der Wechsel zu T2MED ist dringend notwendig. Tue mich aber da noch ganz schön schwer. Völlig anderes feeling, Verhalten.. :oops:

Grüsse aus Kiel
Johnny
Sie haben keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Johnny
Beiträge: 1092
Registriert: Freitag 2. Februar 2007, 00:47
17
Wohnort: Kiel
Hat sich bedankt: 108 times
Bedankt: 10 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Johnny »

Entwarnung:
plötzlich ist der Fehler in CGM CONNNECT diagnostics weg. :D
Neu CGM Connect diagnostics.png
Was also habe ich verändert?

Keine Ahnung :oops:

Grüsse aus Kiel
Johnny
Sie haben keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
Nobbie
Beiträge: 1647
Registriert: Samstag 27. Juli 2013, 11:42
10
Bedankt: 1 time

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Nobbie »

Moin,
seit dem aktuellen Update + Patch ist die eAU ein Trauerspiel, dauernd funtioniert sie nicht. Wir machen folgendes: jeden Morgen wird der Kim-Dienst am Server über einen Task beendet und neu gestartet. Bei bedarf starten wir die Batchdatei (s.o.) an der lokalen Station, manchmal mit Erfolg. Was auch helfen kann ist, TM am Server zu starten und da eine eAU zu erstellen, dann funktioniert sie auch schon mal wieder. Da man aber im laufenden Betreib für diese Spielchen meist keine Zeit hat, schalten wir die ab und drucken Sie und sagen dem Pat. dass er sie verschicken muß. Ein Koco-Box Neustart (wie von der Hotline enpfohlen) hat die Situation leider verschlimmbessert.
Morgen probiere ich mal folgendes: vor dem Start von TM lasse ich die Batch laufen, mal sehen ob das hilft.
Gruß Nobbie

Ich werde keine frühe Turbomed - Downloadversion installieren
Nervenarzt
Beiträge: 240
Registriert: Dienstag 14. Juli 2020, 13:26
3
Hat sich bedankt: 26 times
Bedankt: 5 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Nervenarzt »

Also, ich muss der Ehrlichkeit halber einfach mal mitteilen, dass - toi toi toi - bei mir bei zugegebenermaßen seltenem eAU-Versand keine Fehlermeldungen mehr kommen, und auch kein Computer mehr abstürzt ....
Benutzeravatar
Nobbie
Beiträge: 1647
Registriert: Samstag 27. Juli 2013, 11:42
10
Bedankt: 1 time

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Nobbie »

Moin,
wir haben heute die eAU abgeschaltet. Hotline sucht nach der Ursache, kennt sie aber noch nicht. Die bleibt jetzt aus bis das wieder läuft.
Gruß Nobbie

Ich werde keine frühe Turbomed - Downloadversion installieren
Johnny
Beiträge: 1092
Registriert: Freitag 2. Februar 2007, 00:47
17
Wohnort: Kiel
Hat sich bedankt: 108 times
Bedankt: 10 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Johnny »

Danke nobbie für den Hinweis, :P

Bei mir selbst: eAU nie eingeschaltet, KIM nicht etabliert, e-Akte nicht etabliert. Drucken weiterhin auf Papier aus. :mrgreen:

Abstürze halten sich in Grenzen, am Server eigentlich so gut wie gar nicht, an den Clients 1-3x am Tag. :-)


Grüsse aus Kiel
Johnny
scottsdalegirl
Beiträge: 632
Registriert: Dienstag 13. November 2012, 11:51
11
Hat sich bedankt: 29 times
Bedankt: 20 times

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von scottsdalegirl »

Nobbie hat geschrieben:Moin,
seit dem aktuellen Update + Patch ist die eAU ein Trauerspiel, dauernd funtioniert sie nicht. Wir machen folgendes: jeden Morgen wird der Kim-Dienst am Server über einen Task beendet und neu gestartet. Bei bedarf starten wir die Batchdatei (s.o.) an der lokalen Station, manchmal mit Erfolg. Was auch helfen kann ist, TM am Server zu starten und da eine eAU zu erstellen, dann funktioniert sie auch schon mal wieder. Da man aber im laufenden Betreib für diese Spielchen meist keine Zeit hat, schalten wir die ab und drucken Sie und sagen dem Pat. dass er sie verschicken muß. Ein Koco-Box Neustart (wie von der Hotline enpfohlen) hat die Situation leider verschlimmbessert.
Morgen probiere ich mal folgendes: vor dem Start von TM lasse ich die Batch laufen, mal sehen ob das hilft.
Gaanz vorsichtig schließe ich mich an... KIM Dienst immer neu starten, Batch-Datei gleich früh auf allen Rechnern... scheint zumindest Linderung zu bringen.. vorläufig... Danke an alle Findigen hier...
Viele Grüße
Scottsdalegirl
Benutzeravatar
Nobbie
Beiträge: 1647
Registriert: Samstag 27. Juli 2013, 11:42
10
Bedankt: 1 time

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Nobbie »

Moin,
laut Hotline ist die Instabilität bekannt, aber nicht die Ursache. Das aktuelle Update wird da keine Besserung bringen. Warten wirs ab was kommt.
Gruß Nobbie

Ich werde keine frühe Turbomed - Downloadversion installieren
Benutzeravatar
Nobbie
Beiträge: 1647
Registriert: Samstag 27. Juli 2013, 11:42
10
Bedankt: 1 time

Re: eAU-Reparatur-Batch Nummer 2

Beitrag von Nobbie »

Moin,
das eMuster Center schmiert bei uns nicht mehr ab. Ich habe alle alten Einträge gelöscht, seit dem funktioniert es. Die eAU ist bei uns aber wieder abgeschaltet. Wenn die an einem Platz nicht mehr funktioniert, TM beenden, Batch Datei starten, TM starten und warten, dann gehts wieder. Das ist mir aber zu blöd im laufenden Betrieb.
Gruß Nobbie

Ich werde keine frühe Turbomed - Downloadversion installieren
Antworten

Wer ist online?

Mitglieder in diesem Forum: cwang, Semrush [Bot] und 50 Gäste