Zitat von FS007 im Beitrag #15

---

Nur mal nebenbei: das "S" von SMTP steht eigentlich für "Send"....

---

welcher SMTP-Port könnte denn der richtige sein? Ich habe 25,465,587,2525,8083,8086,8088 ausprobiert ohne Erfolg.
Welcher funktioniert bei Ihnen?
Auf AUTO oder wie?
Der POP3-Port 995 funktioniert ja wohl ohne Probleme.

Schauen Sie sich doch lieber die Situation vorort an, also welcher Port denn da offen ist.
ZB mit netstat. Sonst ist das ja nur ein frustrierendes Rumprobieren.

alle diese Ports werden vom medatixx-Programm automatisch freigegeben.Und sind es auch laut netstat und medatixx-hotline.

netstat sollte auch unter Windows nicht anzeigen (man belehre mich eines Besseren, wenn ich irre), welche Ports "freigegeben" sind (in der Freiwall nehme ich an, meinen Sie), sondern auf welchen Port ein Programm lauscht oder eine Verbindung gerade hergestellt ist.
Daher kann ich Ihre Aussage nicht einordnen.
Zudem würde mich wirklich wundern, wenn auf allden von Ihnen angegebenen Ports lt. netsat ein Programm lauschen sollte.

Nochmal explizit: Es geht da gerade nicht um Freigaben in einer Firewall - die Sie ja lt. Ihrer Aussage oben sowieso abgeschaltet haben. Es geht darum, herauszufinden, wo denn überhaupt eine Verbindung erwartet wird auf dem Rechner mit KIM-Modul.

@cus2002 Gut wär mal ein Screenshot vom Fehlerbild und ein paar Zeilen vom Log, wo man den Fehler erkennt aus: C:\ProgramFiles (x86)\medatixx GmbH & Co. KG\ServiceProvider_*\Plugins\KIM\ID*\cm.fehler & cm.ablauf & SMTPprotocol und aus %programdata\medatixx GmbH & Co. KG\ServiceProvider_*\Kim.logfile

Dann könnte man auch mal ohne Vermutungen diagnostisch exakter vorgehen.
Ist es ein Server mit welcher Windows Server Version oder ein Windows 10 Hauptrechner den Sie nutzen?

Es ist ein Windows 10 Hauptrechner, ein Ixxserver mit Client , kein Terminalserver-System.
Für die Übersendung der logfiles bin ich ehrlich gesagt zu bange, wenn man das medatixx und cgm - hacking und die folgenden Katastrophen bedenkt.Sorry.

medatixx will nächste Woche den 3. grossen Reparaturversuch online wagen.Wieder inclsusive Entwicklung und Konsil mit der KV wegen dem LDAP.

Neuigkeiten von medatixx:
Alles richtig installiert.Alle Ports korrekt.Alle Adressen korrekt eingetragen,LDAPS korrekt erreichbar.Sogar die Krankenkassen und andere Ärzte normal erreichbar.Die LANCOM -Box ist optimal eingerichtet,alle Ports frei, zunächst vermutet, dass die LANCOM das Absende-Zertifikat nur zerstückelt übertragen will(macht die LANCOM auf Programmierung), tut sie aber nicht,Zertifikate korrekt.
Aber: UNSERE Absenderzertifikate in KIM werden nicht übertragen, d.h. der Brief und der Inhalt sind korrekt, aber der Absender fehlt.
medatixx arbeitet in deren Laborumgebung weiter dran, kann aber dauern, wenn sie bei mir in der Produktivumgebung alles testen würden, würde es 3 Tage dauern.
Ich wäre 1 von hundert, deshalb Fehlersuche aufwendig.

<<Nutzer hat Beitrag gelöscht>>

medatixx: Es muss an der LANCOM VAW 1781-Box liegen . Alle 5 Kollegen,die denselben KIM-Fehler haben, haben eine Lancom-Box .
Lancom wird den Fall übernehmen und möglicherweise die Box austauschen müssen.

Langes Gespräch mit medatixx heute : Fakt ist, dass die eAU und das eRP ganz sicher kommen werden, wahrscheinlich zum 1.1.23 spätestens.
Sonst hätte Lauterbach und Leyck Dieken viel zu viel Geld ausgegeben bisher. Ist also Prestigesache.
Leider klappt KIM bei mir als 1 von 5 medatixx-Praxen nicht,niemand weiss ,woran es liegen könnte, Lancom wäre in Verdacht, weil alle 5 Praxen Lancom Router hätten.
Lancom selber kennt aber kein KIM und kann damit nicht umgehen oder es blockieren.Auch kein Virenscanner kennt KIM oder kann es blockieren.
IBM als Hersteller des KIM-Client ist leider nicht zu einer Laborprüfung zu überreden, über 5 Fälle lachen die nur, eine Laborumgebung wäre zu aufwendig.
Es bleibt also nichts als abwarten,ob sich irgendwann mal eine Fehlerlösung zeigt. medatixx ist bis zum 31.12.22 jedenfalls optimistisch.

<<Nutzer hat Beitrag gelöscht>>

Vielleicht wäre es eine Überlegung wert, mal zu schauen, ob beim LANCOM die automatische PMTU-Anpassung an ist (zur Optimierung bei VoIP).
Das kenne ich als "lustige" Fehlerquelle bei VPNs. Runtergeschraubt bis auf ca 500Bytes - das wird dann nett.
Allerdings sollte dann viel mehr nicht klappen. :) Aber es schadet ja nicht, mal einen Blick draufzuwerfen - nur um's auszuschließen?

alle angedachten Einstellungen laut einer Liste von Lancom seien bei mir schon nachgeprüft/umgestellt worden . medatixx
(Seifenblase : platz )