Erfahrungen TI Migration :
Kocobox alt auf Kocobox neu in Kombination mit CGM KIM CLient Modul und PVS Charly(Solutio)

- ! CGM setzt ziemlich Subunternehmer ein- zumindest bei Kunden wie mir, die kein AIS/PVS von CGM haben
- der bei mir eingesetzt Subunternehmer war pressluftgeschult auf "neuer Konnektor einrichten- und ein bißchen darauf, die Neukonfig in dem CGM PRogramm Z1 und Medistar zu setzen- ich hab den USB STickt der "08-15"SChulung von CGM gesehen: da waren die Dokuunterlagen drauf für Konnektor neu einrichten, und Kochrezept für z1 und Medistar- aus- und fertig
-kenntnisse mit anderen Systemen beim DVO= 0 ,00 - außer KOnnektor neu aufsetzen konnte der, der bei mir war wirklich gar nichts leider- !wer nicht ein typisches CGM AIS hat: muss dringend zusehen, es entweder selbst ab Ende Einrichtung KOnnektor zuendebtingen zu können oder sich Remote vom PVS und/oder Systemadmin (sofern der dazu was weiß konkret) dazuholen

- KiM : trotz gleicher TI-ID: habe mich für dereg/regeg entschieden vorsorglich - hat gut geklappt aber für rereg: ! KIM will neues Passwort - setzt man das alte, steigt rereg mit Fehler aus und man darf wieder von vorn mit Reg.Prozess starten

- SMC_B Wechsel: folgende Beobachtung - die ich nicht ganz einordnen kann fachlich/sachlich: Dem CGM- Subunternehmer-Dienstlakai vor Ort war die ganze Zeit super wichtig, dass wir im KT zunächst die alte SMC-B noch parallel gesteckt lassen. Irgendwie vorsorglich, auch als neue SMC-B schon registirert war und ich musste fast drängeln, dass er dann endlich die neue SMC-B auch ins Kartenterminal verbindlich eingesetzt hat an die Stelle wo die alte war und dann nur noch die alte SMC-B in den Schlitz steckte, wo sonst die eGK Karten drin waren- - das ganze Pipapo mit Abkleben Kartenschlitz hat er vergessen, hab ich dann selbst gemacht, auch die alte SMC-B hab ich dann den Tag drauf selbst rausgemacht- mein PVS kam mit der Kombi SMC-B alt + neu noch beide da, schon sichtlich durcheinander, bot mir die alte SMC-B auch noch an, als die längst von mir entfernt worden war... somit weiß ich nicht ganz, ob das mit "wir lassen beide SMC-B" zusammen so lange es geht, wirklich gute Idee ist- die anderen , die hier ständig mehr an der Front Konnektoren einrichten, werden aber ggf. einen Grund nennen können, warum die CGM EMpfehlung so lautetet?!?

- dran denken: wer schon TLS + zusätzliche Authent. eingerichtet hatte:! neuer Konnektor = neues Zertifikat, yeah = KIM neu aufsetzen, PVS Aufrufkontexte neu usw. - wer noch nicht TLS hatte- CGM ! forciert jetzt im Ggs. zu 2018 "mit TLS" -und das sollte auch laufen, ehe man "alles ok" unterschreibt

- wenn man nicht den FremdPVSHersteller am gleichen Tag wie TI Migration an Ort und Stelle bekommt: mindestens sollte dan CGM , damit man wenigstens eine TI Struktur schon auch ohne PVS praktisch testen kann, einen Thunderbird mit KIM voll lauffähig nachweisen- wenn das läuft, dann weiß man schonmal : https läuft und wenn der KIM gesichert aufgesetzt wurde, läuft auch im Prinzip schonmal gesicherte Verbindung auf Konnektor - mit dieser SIcherheit kann man dann in Ruhe im eigenen PVS auch später noch die restliche Umsetzung machen

-!!! speziell bei Charly hatte ich das Problem, dass zunächst der Charly das Komponentenzertifikat vom Konnektor neu nicht erkannte und mit Zertifikatsfehler sämtliches https verweigerte- das ist aber eine Besonderheit von Charly, der die Trust-CA für den jeweiligen Konnektor aktiv im Rahmen TI KOnfig vom Kunden setzen lässt, während nach meinem EIndruck die anderen PVS Hersteller diese Trust-CA passiv bereits mit UPdate ausrollen:
nach der Anleitung Charly, die mir vorlag, sollte ich als Trust-CA das - Komponentenzertiifkat von https://download.tsl.ti-dienste.de/ runterladen, das zu dem Konnektorbrowserzertifikat passte - und um das rauszukriegen, was passt, sollten wir das Zertifikat von https auf admin interfache konnektor aufrufen- beim alten Konnektor klappte das auch, da erschient dann unter Aussteller GEM.KOMP-Ca1.der u mit dieser Trust-CA in der KOnnektor-Konfig von Charly lief dann auch alles mit TLS- beim neuen Konnektor hingegen bei der neuen Kocobox hatten wir allerdings hier folgendes Problem, dass hier Aussteller fehlte und "Original certificate untrusted"

Anbei mal Browserzert. Kocobox alt und neu im Vergleich:





Und jedenfalls das, was wir als Trust-CA sonst eingespielt hatten im Charly, das GEM.KOMP-CA1.der passte hier nicht mehr, auch ein Einspielen des .pem Serverzertifikates direkt halt nicht- weil ja eben "untrusted".


Konnte man auch gut in Wireshark sehen, dass Konnektor 192.168.100.5 mit Zertfiikatsproblem im TLS Handshake rausflog:





Lösung hab ich dan gefunden, als ich nochmal entgegen Anleitung Charly Skript EHealth genau das EHealth-https-interface Konnektor vom Charly - allso die https://[IPKonnektor}/connector.sds verwendet habe:
Wenn man so den Konnektor im Browser aufgerufen hat, konnte man ein vernünftiges trusted- Zertfiikat herunterladen, wo man unter Aussteller Allgemeiner Name dan GEM.KOMP-CA7 finden konnte: habe mir dann diese Trust _CA bei tls dienste runtergeladen, im Charly eingepflegt und ab dann war alles super und lief wieder mit https:-)





@MLangguth Frage interessehalber: ist das nun ein bug in der Kocobox neu, dass bei Aufruf admin Interface nur ein nontrusted Browserserverzertifikat ausgegeben wird? Oder hat das seine Richtigkeit und ist ggf sogar absichtlich anders gegenüber vorher, z.B. wegen erneuter Änderung Spezifikation an dieser Stelle?

noch 2 Ergänzungen TI Migration:

a)
folgende Skripte/Checklisten "TEchniker" für Migration habe ich zudem noch aus Interesse bekommen können:

1.Original-Todo- Checkliste Hardwaretausch/ TIMIgration von CGM :-)
[[File:Checkliste Ex- Imort.pdf]]
2. Techniker Handout der Subunternehmer Projektgruppe TI von CGM
[[File:Techniker Anleitung.pdf]]
3. Tips für CGM AIS 'Medistar"
[[File:Medistar Check.pdf]] [[File:MEDISTAR_AIS-Dokumentation_ToDos_nach_Konnektortausch (1).pdf]]
4. TIps für ANpassungen AIS "Z1"
[[File:Z1_Anpassungen in Z1 bei Tausch des Konnektors und der SMCB.pdf]]

b)
Ganz wichtig: Während und nach Migration Dokumentation TI sicherstellen und prüfen, dass am Ende in den richtigen Dokumenten alle entscheidenden Passwörter , Pfade für Zertifkate usw. sauber notiert /aktualisiert sind.

!! Theorie und Praxis hinsichtlich Passwort- und sonstiger Dokumentation TI Migration prallen bei Durchführung meiner Beobachtung nach sehr aufeinander- an sich hat CGM ein gutes Konzept für Dokumentation- leider wurde die alte Doku derErstinstallation nicht weitergeführt, es wurde für die DVOs Projekt Mig ein neues .txt ausgerollt, das ausgefüllt und dann wieder, wie schon bei Einführung TI auf dem Desktop (!) hinterlassen für den Kunden- 2018 wie auch jetzt 2022 geschah das wieder ohne jeden Hinweis, dass dieser Lagerort für wichtige Kundendaten aufgrund der Lage der unsicherste ist, weil nach notwendiger Wiederherstellung Betriebssystem oft ganz weg-. und Ohne den Hinweis, dass diese Daten schützenswerte Daten sind, die vielleicht - jedenfalls auf Dauer besser nicht unverschlüsselt da oder sonstwo im Netzwerk ruliegen sollten .

Hinzu kommt noch, dass nicht zuletzt aus Zeitgründen (wenn nicht alles gleich sauber durchläuft, sind 2-3 h oft deutlich zu knapp, da kann der DVO noch so engagiert sein) die Doku nicht zwangsläufig am Ende vollständig ist- meine jedenfalls war es nicht- musste selbst erheblich noch nacharbeiten, dass wieder die Doku für neue Anlage vollständig und aktuell ist.

=)Also es MUSS am Termin Migration einer verbindlich den Passwordwatchdog spielen, wenn man es eh nicht gleich ganz selbst macht und auf sich selbst achtgibt entsprechend, also einen, der dann wirklich aufpasst, dass alle erforderlichen Passwörter am Ende bekannt und dokumentiert sind. Cave: auch Pfade zu Zertifikaten nicht vergessen: z.B. will der KIM Client das Zertifikat nur von lokal beziehen- Charly PVS von Netzlaufwerk ...)

Ich habe mich zudem entschieden, dass alle Passwörter, die nicht geändert werden müssen zwangläufig bei Migration (i.e. soweit ich überblicke alles außer KIM PW nach dereg und PW vom .p12 Clientzert, das neu erstellt werden muss) erstmal jedenfalls der Einfachheit halber gleich bleiben wie bei altem Konnektor und auch gSMC-KT gleiche admin PIN kriegt wie vorher , SMC-B PIN neu gleich bleibt - das hat den Dokuaufwand weitgehend in Grenzen gehalten.

Zur Vorbereitung für Techniker DVO oder auch sich selbst:
Alle Passwörter sauber in einem .txt bereithalten für den Termin - so dass er da nur kopieren braucht und in neue Hardware einpflegen. Das reduziert Eingabefehler (jedenfalls solange man nicht Leerzeichen versehentlich mit kopiert;-)

Anbei so in etwas wie z.B. meine LIste aussieht, die sich für mich in der Praxis bislang bei TI Operationen gut bewährt hat, wenn das alles ausgefüllt ist, was da an Stichpunkten genannt ist:

[[File:TIConfig.txt]]

Vielleicht noch für einige TI MIgranten wichtiger Hinweis: habe jetzt 2 Monate nach Migration die Rechnung von CGM bekommen- im übrigen OHNE dass das Ticket mit Fragen , was ich im September gesetzt hatte, überhaupt wenigstens mit einem Rückruf oder Terminangebot beantwortet wäre und obwohl auf meinem Auftragszettel ausdrücklich vermerkt war, dass zum Zeitpunkt Unterschrift 8.9. zwar der Konnektor getauscht, aber der Status Quo mit ANbindung PVS NICHT erfolgreich wiederhergestellt war

Also ich hätte da glaub ich schon nochmal nachgefragt- CGM konnte ja schließlich nicht wissen, dass jezt alles aufgrund Eigenarbeit am Ende 2 Wochen nach Migration auch wieder ordnungsgemäß lief.

Aber gut, die Philosophien dazu sind sicherlich verschieden.

Jedenfalls:

Bei der Rechnung war mir dann ein Posten aufgefallen für Zusatzleistungen "Passwort-Reset Bestandskonnektor" in Höhe von nett 255Euro- da ich vollzeitig der Migration beigewohnt hatte und auch meine Passwörter ALLE korrekt und lauffähig geliefert habe an dem Tag, war ich doch recht erstaunt- auf Rückfrage hieß es, man habe DAS abgerechnet, was im Abnahmeprotokoll drinstehe.

Habe mir dann mein Abnahmeprotokoll nochmal genau angeschaut:

In der Tat gibt es da unter "Funktionsprüfung" einen Punkt "Sind Zugangsdaten des Konnektors vorhanden" und das haben Sie ordnungsgemäß mit "ja" angekreuzt. Soweit so gut. Und danach war beim Gegenlesen dieser Punkt für mich auch erledigt gewesen.

Leider gibt es bei diesem Punkt noch einen Unter-Unterpunkt, nämlich (sinngemäß):

1. "Wurde ein Passwortreset der Kocobox während Laufzeit durchgeführt?"

2. "Inbetriebnahme der neuen Hardware ohne Übernahme der Altkonfig"

Beide Punkten hatten bei mir in der Tat einen Haken im Protokoll, obwohl das Passwort vom Altkonnektor bei mir vorhanden war und wir auch nachweislich die Altkonfig exportiert und in neuen Konnektor importiert hatten.

Das hatte ich beim Gegenlesen nicht bemerkt. Einfach weil ich auch nicht auf die IDee gekommen bin, dass das bei mir der Fall sein könnte und dass SOWAS noch ein Unterpunkt von "ja, Passwort Konnektor vorhanden" sein könnte.

Wie die Haken da hingekommen sind, weiß ich nicht- evt. sind diese beiden Felder default auf "ja" angekreuzt bei der CGM Vorlage? Oder es ist versehentlich mit angekreuzt worden vom ausführenden Subunternehmer.

Und positiv war auch, dass CGM diesmal vergleichsweise schnell innerhalb von 24h nach meiner Anfrage mir ein Storno der reklamierten Leistung geschickt hat, trotzdem ist vielleicht gut, wenn jeder nochmal drauf achtet:

1. Abnahmeprotokoll besser Wort für Wort lesen incl. Unter-Unterpunkten

2. Rechnung nochmal umgehend kontrollieren, ob sie frei von (nicht erstattungsfähigen) "Zusatzleistungen" ist (TIgel-Leistungen sozusagen;-)