Am 29.9.21 habe ich das Problem per Email, s. u., dem CGM-Support geschildert. Keine Antwort bis heute, 29.10.21. Wie ich aus anderen Foren weiß, haben andere Kocoboxnutzer das gleiche Problem. Hat jemand einen Hinweis? Danke!

Seit Firmware 4.2.10 geht der KIM-Versand nicht mehr. Aktuelles Protokoll, Claws Mail (Kocobox 4.2.12):
* Konto: 'zahnarztpraxis.michael.logies@tm.kim.telematik': Verbinde mit SMTP-Server: 192.168.0.28:8465...
[2021-09-29 11:07:01] SMTP< 220 KIM Clientmodul ESMTP
[2021-09-29 11:07:01] ESMTP> EHLO localhost
[2021-09-29 11:07:01] ESMTP< 250-OK
[2021-09-29 11:07:01] ESMTP< 250-SIZE 35882577
[2021-09-29 11:07:01] ESMTP< 250-AUTH LOGIN PLAIN
[2021-09-29 11:07:01] ESMTP< 250-8BITMIME
[2021-09-29 11:07:01] ESMTP< 250-ENHANCEDSTATUSCODES
[2021-09-29 11:07:01] ESMTP< 250 DSN
[2021-09-29 11:07:01] ESMTP> AUTH LOGIN
[2021-09-29 11:07:01] ESMTP< 334 VXNlcm5hbWU6
[2021-09-29 11:07:01] ESMTP> [USERID]
[2021-09-29 11:07:01] ESMTP< 334 UGFzc3dvcmQ6
[2021-09-29 11:07:01] ESMTP> [PASSWORD]
[2021-09-29 11:07:02] ESMTP< 235 2.7.0 Authentication successful
[2021-09-29 11:07:02] ESMTP> MAIL FROM:<zahnarztpraxis.michael.logies@tm.kim.telematik> SIZE=544
[2021-09-29 11:07:02] SMTP< 250 2.1.0 Ok
[2021-09-29 11:07:02] SMTP> RCPT TO:<zahnarztpraxis.michael.logies@tm.kim.telematik>
[2021-09-29 11:07:03] SMTP< 250 2.1.5 Ok
[2021-09-29 11:07:03] SMTP> DATA
[2021-09-29 11:07:03] SMTP< 354 OK
[2021-09-29 11:07:03] SMTP> . (EOM)
[2021-09-29 11:07:03] SMTP< 451 Requested action aborted: error in processing
** Fehler bei der SMTP-Sitzung
*** Fehler beim Senden der Nachricht:
451 Requested action aborted: error in processing

Also ganz am Ende, nach EOM, scheitert der Versand. Das war auch schon mit 4.2.10 so.

Ich hatte immer noch die Hoffnung, Emails empfangen zu können, denn meine Emailclients (Thunderbird, Claws Mail, EPIM, Consys-Dent) kontaktierten den POP ohne Fehlermeldung. Aber diese Hoffnung ist gerade zerstoben, s. u., also Entschlüsselung nicht mehr möglich.

Meine Vermutung mittlerweile: Ihr Firmwareupdate hat das Zusammenspiel Kocobox mit dem Kartenlesegerät kaputt gemacht, so daß weder beim Versand noch Empfang die Schlüssel richtig abgerufen werden.

Ich habe keinen Teil meiner Konfiguration vor oder nach den Firmwareupdates verändert. Also muß es am Firmwareupdate liegen.

Mit freundlichen Grüßen

M. L.
(...)

"error in processing" kenne ich und fand dazu weitere Hinweise in der Log-Datei vom KIM-Client. Bei meinem Problem fand ich dort, dass das ENC Zertifikat des Empfängers nicht gefunden wurde. Scheint hier aber ein anderer Fehler zu sein, da meiner direkt nach MAILTO auftrat.

Bitte mal in den Error Logs des KIM-Client schauen was da steht.

PS: Ich warte auch noch auf Antworten von Telekom und CGM.....

<<Nutzer hat Beitrag gelöscht>>

Da bei mir nahezu gleiche Fehlerkonstellation gewesen , möchte ich noch folgende praktische neue Erfahrungen von dieser Woche jetzt dazu ergänzen und würde daraus resultierend sagen, dass es in jedem Fall bei CGM sehr wesentlich an der Aktualität des KIM liegt- ggf. aber auch nicht nur: evt. sind noch weitere Randbedingungen entscheidend, bei mir war es dann eine fehlende .net.Framework Version (da war die 4.6 , wanted war die 4.7 und nach Nachinstallation dieser Version und ANSCHLIESSEND Neuinstallation KIM aktuellste Version lief alles wieder

Langfassung der Erfahrungen zu der Sache aus CGM Support letzte Woche :

Also, folgende Punkte haben wir nacheinander abgearbeitet:

1. Idee: ursache CryptopAlarm
ich hatte ja noch parallel einen Cryptop-Alarm anstehen auf dem Konnektor-. den haben sie als erstes zurückgesetzt - in der Hoffnung, dass nur der den KIM bremst- war aber nicht der Fall - Alarm war weg und KIM trotzdem weiter down.

2. idee. Aktualität KIM
a) Nur diese .jar -Datei KIM von der 2-7 in die aktuellste 2-11 zu tauschen hat nicht funktioniert (KIM-CM-10.0.2-11.jar...)

b) Dann hab ich gesagt, sollen sie halt den neuen KIM mir drüber installieren, wenn sie sicher sind, dass dann ALLE Einträge noch da sind- wobei der Kollege dann sagte, eben DAS wisse er auch nicht 100% , besser sollten wir dann vorher nochmal - fand ich vernünftig- meine KIM Adresse, solange wir noch können- über den alten Account deregistrieren um dann alles neu aufsetzen und neu registireren zu können, falls erforderlich... Hierbei zeigte sich noch weiteres neues Problem:

Start des KIM Assist über Link "KIM Assist- Konfiguration" brach aber immer im Prozess "Aktualisieren" ab:



lief bis 100 % hoch und dann war er weg- keine Fehlermeldung, einfach App nicht geöffnet danach... somit nix mit deregistrieren- wir haben uns dann mutig entschieden: KIM trotzdem runterschmeißen ganz (cgm hat hierfür KIM Dienst beendet und dann den Dienst über Konsole gelöscht und anschließend die alten KIM Daten im Ordner Programme gelöscht manuell, irgendein Uninstall-Tool speziell wurde nicht benutzt) - der neue aktuelle KIM hatte leider genau das gleiche Problem: Start Kim Konfig =) brach wieder nach Aktualisierung ab"- daher haben sie danach in diesen leeren KIM die Daten manuell eingetragen: KIM config.bat geöffnet, dann hier Infomodell-Daten, URLKonnektor und danach unter Verschlüsselung einstellen die Einträge für POP 3 und SMTP neu gesetzt, da sie aber an den Kim Konfigurator nicht mehr rankamen, mussten sie bei KeyPin erstmal mit Platzhalter als PIN arbeiten...



Danach lief weiter nichts- allerdings kam anderer Fehler wieder, den wir schon von früher kannten, allerdings wohl damals anderer Grund technisch: aber wieder: KIM Dienst ließ sich nicht mehr starten- Fehler: keine Verbindung auf Server (wo bei mir der Client KIM läuft) möglich... passte aber auch letztlich, finde ich, weil ja eben die KIM Konfig mit manueller Eingabe und gesetzten Platzhalterpasswörtern usw. nicht sauber war...

Jedenfalls startete auch der KIM Konfigurator (eigentlich für mich auch erwartungsgemäß, da wir ja nur für den KIM Dienst (!) Änderungen gemacht hatten und nicht an der Konfig-App) dann natürlich immer noch nicht sondern brach weiter ab.

3. Idee: Problem Verschlüsselung
der weiter hinzugezogene Kollege von CGM wollte jetzt die Spur , es liege an der Verschlüsselung, die bei mir eingerichtet sei, weiter verfolgen: !! finde wichtig, dass das hier nochmal steht: meine Erfahrung aktuell: egal mit welchem Support (PVS/KIM ) ich bis jetzt telefoniert habe- sie schmeißen grad gern alle http/TLS auf der einen Seite und die zusätzliche (!) Authentisierung via Clientzert bzw. Username/PW in eine Kiste- ich musste mich recht massiv wehren, dass NICHT bei mir wieder auf dem Konnektor " auch http erlaubt "und "ohne TLS" eingestellt wurde - mehrfach hieß es seitens Support wieder: es läuft nur so, ich habe ihnen dann die Screens gezeigt dass es bei mir sehr wohl mit https läuft und mit TLS nur eben -und dass ich somit sehr sicher bin, dass dies NICHT die Ursache für das Problem ist

!!!hier allgemein !!!! nach Auskunft Support diese Woche: bis auf weiteres kann der CGM KIM Client zwar wenigstens https aber im Zusammenspiel aller beteiligten Komponenten läuft die zusätzliche Authentifizierung noch nicht- die Einrichtung ist zwar beim KIM CGM angelegt als "login" oder "zertifikat" angelegt und lässt sich auch so als Konfi einpflegen- aber aktuell läuft das lt. CGM und deckt sich auch mit meinen Erfahrungen hier auf der Anlage- noch nicht... https ist es aber in jedem Fall - auch wenn die Konfi dann über "ungesichert" aufgesetzt wird , "ungesichert" bezieht sich anscheinend nur auf die fehlende Authentisierung" - dass das fortgesetzt nicht funktioniert ist im übrigen Verstoß gegen die ITSicherheitsrichtlinie , die das eigentlich hier vorschreibt, wenn ich das richtig lese:



4. Idee Problem .net Framework
Dann hat sich dieser Kollege vom CGM Team erinnert, dass sie es neulich in einem Fall hatten, dass .net framework auf der betroffenen Maschine nicht die richtige Version draufgewesen sei: das haben wir dann als nächstes geprüft und ich hatte bei mir nur eine 4.6 Version und der KIM neu braucht 4.7

Nachdem wir das nachinstalliert hatten, haben wir nochmal einen frischen KIM installiert und danach war alles perfekt, ließ sich die gesamte Konfiguration wieder öffnen -und auch das alte KIM Passwort usw. waren erhalten geblieben trotz dieses Hin und Her...:-)
und wir hatten nicht deregistrieren und anschließend neu registrieren brauchen...

P.S.
übrigens: auch wenn ich wieder zu lange warten musste auf den SupportTermin( dazu haben wir separaten Beitrag, der das Problem aufgreift und ich hab es dem Management von CGM auch nochmal geschrieben als Mail) kann ich nur sagen, dass ich mit dem Termin an sich, als er dann war , inhaltlich in der Summe wieder wie auch die Male zuvor erneut sehr zufrieden war: wieder ein sehr engagiertes und sehr freundliches Technikerteam, was letztlich nicht nur mein Problem gelöst hat sondern auch nebenbei noch alle weiteren Fragen, die ich zum Thema Konfiguration TIKomponenten inzwischen auch noch hatte, ebenfalls ausführlich noch gleich mit beantwortet hat :-)

<<Nutzer hat Beitrag gelöscht>>

Zitat von FS007 im Beitrag #5

---

KIM Client die Version 4.7 erfordern würde: Bei mir läuft das Ganze nämlich mit Version 4.0.0 dieses Frameworks.

---

<<Nutzer hat Beitrag gelöscht>>

da ja bei/nach Autoaktualisierung der Abbruch kam bei mir - es gibt ja auch noch eine separate KIM Updater.exe bei mir ... vielleicht ist die das dann und Sie haben diese Echse nicht, weil die im PVS mit Gesamtupdate integriert ist?

Ansonsten fiele mir nur noch ein: dass bei Ihnen es ein Client ist, wo der KIM sitzt (mit Win 10 vermutlich) , weil CGM den KIM ja lokal haben möchte- und bei mir ist es , weil Charly den KIM auf dem Server braucht Betriebssystem Server 2016.
Ob das einen Einfluss hat für die Fragestellung hier mit einmal geht 4.0.0 und dann in anderem System nur 4.7- das kann ich allerdings nicht einschätzen, da fehlen mir Erfahrung und Wissen..

<<Nutzer hat Beitrag gelöscht>>

danke für den Hinweis- wieder was dazugelernt:-) - ich hatte die Tatsache, dass es lokal bei CGM laufen soll/kann immer so interpretiert, dass je Maschine wo es laufen soll, der KIM Client installiert werden soll oder alternativ (!) eine Netzwerkinstallation möglich ist- so stand das meine ich sehr sicher im KIM Skript anfang 2021, aber ich hatte nichts gelesen, dass der KIM nur einmal überhaupt je Netzwerk draufsein darf.... aber wenn Sie das so schreiben, wird das stimmen, da bin ich sicher...vielleicht steht das bei CGM im Skript jetzt ja auch so drin;-)... ich hatte das nicht mehr weiter verfolgt, weil bei mir der KIM sowieso ausschließlich auf dem Server laufen soll, weil Charly den Zugriff KIM so macht, dass das ClientModul auf dem Server laufen MUSS...

<<Nutzer hat Beitrag gelöscht>>

KIM-Assist, die Software der CGM für Einrichtung und Betrieb von KIM, halte ich aktuell nach meinen heutigen Erfahrungen für einen unausgereiften Schrotthaufen, mit dem ich eher zufällig erneut ins Ziel humpeln konnte:

Wie bereits geschrieben, gingen seit Kocobox-Firmware 4.2.10 der KIM-Versand und die Entschlüsselung empfangener Mails bei mir nicht mehr, was sich durch 4.2.12 nicht besserte. Davor keine Probleme mit 4 Emailclients (Claws Mail, Thunderbird, EPIM, Consys-Dent).
Also dachte ich heute, installiere KIM-Assist mal neu. (Habe mit 1.0.15 angefangen, aber der Programm zeigte mittlerweile an, es sei auf 1.0.23, also sind Autoupdates im Hintergrund gelaufen) - also das Verzeichnis "C:\Program Files (x86)\Kim Assist" umbenannt.
1. Erfahrung: Zum Download angeboten wurde die Version 1.0.22, die gleich nach Installationsbeginn auf 1.0.23 aktualisiert wurde. Die Neuinstallation führte zwangsweise in eine Neuregistrierung meiner eHBA-Emailadresse in der TI, die fehlschlug, weil die Adresse ja schon registriert war. Die Installation lief also nicht sauber durch mit dem Ergebnis, daß danach der KIM-Assist-Dienst (=Emailproxy) sich nicht mehr starten ließ, d. h. beim Start hängen blieb, mit einer entsprechenden Windowsfehlermeldung.
2. Also mein altes KIM-Assist-Verzeichnis (als Kopie) wieder hergestellt (Dienst ließ sich starten), KIM-Adresse deregistriert (schloß mit Fehlermeldung ab, hat aber geklappt), KIM-Assist-Verzeichnis wieder gelöscht.
3. Erneute Neuinstallation, die etwas weiter durchlief, also bis zur Registrierung der KIM-Adresse (die angeblich fehlschlug, wie die Deregistrierung angeblich fehlgeschlagen war - beide Dinge hatten aber stattgefunden), um dann mit dem gleichen "Fehler 4400" abzubrechen. Gleiches Fehlerbild: KIM-Assist-Dienst ließ sich in den Windowsdiensten nicht starten.
4. Okay, dachte ich, diese Dreckssoftware schreibt trotz aller von mir eingegebener Daten offenkundig ihre Konfigurationsdateien nicht vollständig, wenn sie meint, daß etwas schief gelaufen ist, und dann hängt sich der KIM-Assist-Dienst beim Start auf.
5. Also habe ich mit dem Total Commander alte und neue Installation bitweise verglichen. Und dann habe ich in eine Kopie meiner alten Installation die Dateien kopiert, die mir bei der neuen Installation geändert und möglicherweise wichtig vorkamen (umgekehrt fehlten in der neuen Installation offenkundig einige meiner alten Konfigurationsdateien). Das waren folgende geänderte Dateien:
C:\Program Files (x86)\Kim Assist\data\KIM_Client-Modul\config-cm-windows(32bit).bat
C:\Program Files (x86)\Kim Assist\data\KIM_Client-Modul\start-cm-windows(32bit).bat
Und folgende neue:
C:\Program Files (x86)\Kim Assist\data\KIM_Client-Modul\libs\common\jna-5.8.0.jar
C:\Program Files (x86)\Kim Assist\data\KIM_Client-Modul\libs\common\jna-platform-5.8.0.jar
C:\Program Files (x86)\Kim Assist\data\KIM_Client-Modul\libs\common\KIM-CM-10.0.2-11.jar
6. Dann habe ich einen Emailclient gestartet, ohne große Hoffnung. KIM-Senden und -Empfangen haben aber überraschenderweise funktioniert. Ich mußte nur in meinen 4 Emailclients das zwangsweise bei der Neuregistrierung meiner Emailadresse geänderte Paßwort für POP u. SMTP neu setzen (d. h., in der Neuinstallation muß zumindest die Konfig-Datei dafür geschrieben worden sein). Meine Abwesenheitsnotiz wie alte Emails waren nach Registrierung wieder da.
7. Fazit: CGM hat es in 6 Wochen (Empfangsbestätigung v. 14.9.21) nach meiner Problemmeldung nicht geschafft, das Problem einzugrenzen und mir aus der Patsche zu helfen. Meine Erfahrungen oben verweisen darauf, daß der Autoupdateprozeß von KIM-Assist fehlerbehaftet ist, sonst hätten essentielle Dateien nicht fehlen dürfen. Und eine Neuinstallation scheint mit der aktuellen Softwareversion gar nicht möglich zu sein bzw. war mir nicht möglich. (Ich zweifle nicht daran, daß in der CGM-Hotline Leute sitzen, die in Konfigurationsdateien manuell arbeiten können, aber das kann ja nicht das Ziel sein.)
8. Die Qualitätskontrolle durch die Gematik funktioniert nicht. Wenn Software- oder Firmwareupdates von TI-Komponenten diese lahmlegen können, ohne daß die Gematik das selbst mitbekommt, kann man von einer TI mit definierten, abgenommenen, funktionierenden Komponenten, die interoperabel sind, nicht ausgehen.

<<Nutzer hat Beitrag gelöscht>>

Was mich überrascht hat, ist, daß ich für KIM-Assist kein Deinstallationprogramm unter "Apps und Features" (Win 10) gefunden habe. Es gibt allerdings, habe ich gerade gesehen, C:\Program Files (x86)\Kim Assist\UninstallCM.bat, die aber nur den Dienst zu deregistrieren scheint. Ich habe mit dem Regscanner (Nirsoft) die Registry nach "KIM" durchsucht und 230 mehr oder weniger einschlägige Einträge gefunden. Es könnte sein, daß der noch installierte Dienst oder nicht entfernte Registryeinträge eine Neuinstallation verhindert haben, s. o. Jedenfalls gibt CGM in seinem Handbuch "Installationsanleitung CGM KIM Assist Standalone" (CGMCOM-7026_c1134_TI_KIMInstall_280621_CC_V2.pdf) fast keine Hinweise, was im Falle einer Reinstallation zu tun ist. Da steht nur: "Clientmodul Sollten Sie CGM KIM nicht mehr verwenden, können Sie das Verzeichnis des CGM KIM- Assist von Ihrem PC entfernen. Der Standardpfad lautet: C:\Program Files (x86)\KIM Assist"
Das NET-Framework sollte unter Windows 10 doch auf dem aktuellen Stand sein, dürfte also nicht die Ursache bei mir sein:
https://docs.microsoft.com/de-de/dotnet/...rectedfrom=MSDN

Könnten Sie noch einmal prüfen, welches Verzeichnis unterhalb von C:\Program Files (x86)\Kim Assist für "jeder" beschreibbar ist? Ich habe das gerade bei mir mit AccessEnum geprüft, https://docs.microsoft.com/en-us/sysinte...oads/accessenum
Bei mir ist danach alles in Ordnung. Ich habe AccessEnum dann noch über C:\Program Files (x86) laufen lassen u. bin woanders fündig geworden (Openlimit, ZÄK Westfalen-Lippe...).