TI-Dienste CGM KIM auf 1.11 updaten (Kurzform) - Updated²

[MVZPirna]

Deregistrierung ist bei mir vollständig gelungen, nachdem ich auf den Installer im Unterordner CGMKIM15 geklickt und mit der rechten Maustaste Deinstallieren ausgewählt habe. Dann Rechnerneustart. Dann war alles weg. Ich hatte noch das Problem, dass ich anfangs versucht hatte, das Problem remote zu lösen. Dann merkt sich das System aber den falschen Rechner, von dem man aus zugreift. Es ging nur an dem Server mit immer wieder neuen Starts nach jedem Schritt. Turbomed habe ich dann erst ganz zum Schluss wieder auf dem Server mit Administratorenrechten gestartet.
Zwischendurch hatte ich sogar den Eindruck, dass das neue Menü, das man über Praxisdaten -> Zusatzdaten -> KIM 1.5 aufruft, die Installation wieder zerschießt. Habe deswegen dann nur noch zur Kontrolle das eCockpit aufgerufen, da war dann nach dem beschriebenen Vorgehen KIM unerwartet grün. Nun kann ich wieder in Turbomed KIM-Nachrichten versenden und empfangen. Dieses neue Menü unter Zusatzdaten habe ich seither nicht mehr aufgerufen, weil mir dieses irgendwie sehr suspekt vorkommt. Ich mag es nicht ausprobieren, aber ich hatte nach unzähligen Stunden den Eindruck, dass die 3 Regenwolken die Installation zerstören.
Ich wünsche allen Leidensgenossen viel Erfolg!

[rfbdoc]

Meine Beobachtung ist eine andere
Ob vor Ort der Remote macht keinen Unterschied.
Über folgendes Vorgehen ist mir die Deregistrierung und Neuregistrierung von Kim (remote) gelungen:
Auf www.meine-ti.de eine neue CVS Datei herunterladen.
Mit dem darin augeführten neuen Passwort die Kim Adresse deregistrieren und im Anschluss sofort wieder neu registrieren.
Stand aktuell: Kim läuft .
Mal sehen was morgen in der Praxis funktioniert.

Hintergrund: Ich hatte mir gestern und heute eine CVS heruntergeladen und dabei festgestellt, dass die Kennwörter
unterschiedlich sind. Mit dem Kennwort der zuletzt heruntergelade Datei liefen Deregistrierung und Neuregistrierung problemlos durch.

[FortiSecond]

Meine Beobachtung ist eine andere
Ob vor Ort der Remote macht keinen Unterschied.

Oh, kann aber einen Unterschied machen:
Bei RDP wird der Name des fernen PC als Stationsname in TM genutzt. Ist dieser nicht im Infomodell, gibt es keine TI.
Ausnahme? Die Sitzung wurde lokal gestartet und dann aus der Ferne übernommen.

Umgehungsmöglichkeiten:
Teamviewer und Co. melden sich trotzdem "lokal" an, so dass der echte Stationsname in TM erscheint.
Unter Windows konnte der alte 2X-RDP-Client einen Clientnamen "faken".
Unter Linux gibt man Remmina und FreeRDP problemlos einen beliebigen Clientnamen mit.

[rfbdoc]

may be
Der aus meiner Sicht entscheidende Unterschied zu früher ist ja jetzt die neue Passwortabfrage sowohl bei De- als auch bei Neuregistrierung.
Da scheint es offensichtlch notwendig zu sein ein tagesaktuelles Passwort über www.meine-ti.de abzufragen.
... so meine vage Vermutung
Bei mir hat es Remote über wireguard funktioniert.
PS: bei sind alle Rechner in Infomodell... das macht vieles unproblematischer

[j.kuepper@gmx.de]

... die Anleitung hilft schon mal super, leider hängt es bei mir im Browser (habe schon mehrere jetzt versucht).
Nach der Fehlermeldung geht es nicht weiter, - bei anderen Seiten kann ich die quittieren und übergehen- hier nicht.

Gbits dafür eine Lösung?

[FortiSecond]

... die Anleitung hilft schon mal super, leider hängt es bei mir im Browser (habe schon mehrere jetzt versucht).
Nach der Fehlermeldung geht es nicht weiter, - bei anderen Seiten kann ich die quittieren und übergehen- hier nicht.

Gbits dafür eine Lösung?

https://localhost:8000 aufrufen, dann müsste die Sicherheitswarnung kommen, die sich bestätigen lassen sollte.

Falls bereits ein anderer (älterer) Dienst auf 8000 läuft, ist eine Anpassung nötig.

[nmndoc]

@FortiSecond wie muss denn das Hauptpasswort aufgebaut sein? Bei uns will er es nicht annehmen (dh Konfiguration abschließen Button nicht anklickbar)

[FortiSecond]

@FortiSecond wie muss denn das Hauptpasswort aufgebaut sein? Bei uns will er es nicht annehmen (dh Konfiguration abschließen Button nicht anklickbar)

An sich recht üblich: Zahlen, Buchstaben groß und klein, Sonderzeichen.

Aber TM selbst erstellt ein mehr als 20 Zeichen langes Zufallspasswort wie kjh234jh4§kldsfklhdsa$dfkljdfs23423d. Es ist nicht rechnerabhängig, sondern wird neu erstellt bei Reparaturinstallation (wenn KIM 1.5 vorher entfernt wurde).
Selbst wenn man es ausliest (Trick 42) und man dann für grüne Wolken sorgt, gibt es immer noch den Fehler, dass TM trotz Kommunikation mit dem CM bei der KIM-Nutzung (Abruf/Versand) auf die Konnektor-IP zugreift. Zwecklos.

[nmndoc]

bei uns ist der "Tooltip" / popup mit dem mutmaßlich PW-Richtlinien leider außerhalb des Bildschirmrandes ...
Der Punkt ist: Die KIM CM Oberfläche gibt an, dass "Die applikation bisher nicht mit einem Haupt-PW initialisiert wurde" - das wollte ich nun tun aber irgendwie willer er das nicht

[FortiSecond]

bei uns ist der "Tooltip" / popup mit dem mutmaßlich PW-Richtlinien leider außerhalb des Bildschirmrandes ...
Der Punkt ist: Die KIM CM Oberfläche gibt an, dass "Die applikation bisher nicht mit einem Haupt-PW initialisiert wurde" - das wollte ich nun tun aber irgendwie willer er das nicht

Wie wäre es mit VonD0CZuDoC# ?
Lässt sich später ändern, wenn man sich als Admin einloggt.