Zitat von MLangguth im Beitrag #16

---

Wenn allerdings ein Hersteller z.B. die ICCSN der Karte bei der Registrierung irgendwo intern ablegt (z.B. um sie später beim Konnektor leichter finden zu können) und nicht vorgesehen hat, dass diese interne Info korrigiert werden kann, DANN kann es den Bedarf für solche ein Vorgehen geben.

---

medatixx arbeitet ja mit ibm zusammen, da ist es ebenfalls so. KIM wird an ICCSN der Karte (normal SMC-B, Ausnahme eHBA) gekoppelt, ich weiß allerdings nicht ob eher medatixx oder eher ibm Schuld ist, ich weiß nur das ich alle 5 Jahre viel zu tun haben werde.

Hallo Junioruser1976 der 08.09 (ihre TI Migration) liegt ja nun in der Vergangenheit. haben sie die Kim Adresse vor dem
Vorgang deregistriert? Erfolgte auch ein Wechsel der SMC-B und wurde diese manuell in das Infomodell des Konnektors
eingetragen?

Hallo,

ja, Migration war mit SMC-B Wechsel.

Ich habe nach Rücksprache mit CGM und in Abstimmung mit dem von CGM pressluftgeschultgen Subunternehmer, dem ich zugeteilt war, vor Migration noch mit der alten SMC-B den CGM KIM vorsorglich deregistriert und nach neuem Aufsetzen des Konnektors mit neuer SMC-B neu registriert. Ob das nun technisch sicher nötig ist oder nicht, ich habe nicht gegengetestet, weil ich nicht ohne not den KIM zersägen wollte bei mir: an sich ist meine TI-ID gleich geblieben - und es gibt inzwischen Stimmen, die sagen, dass bei bestimmten Anwendungen von CGM , z.B. Z1, wohl auch es ohne Kim dereg/rereg gehen soll oder bereits gegangen sei- u.a. seien das Applikationen, wo man die Ti_ID auch im Frontend der KIM Konfig sehe als Eintrag?!? - umgekehrt: Level 2 MigrationsSpezialisupport von CGM war sich super sicher, dass man IMMER dereg/rereg machen MUSS und die waren schon beleidigt, weil ich 2x zu verschiedenen Uhrzeiten diese gleiche Frage an verschiedene Personen gestellt hatte;-)

Nebenbei :
Am 8.9. als wir re-registrieren wollten, ist der KIM zunächst mit Fehler 4400 = kritisches technisches Problem- immer ausgestiegen- fand ich spooky, weil ich eigentlich sehr sicher war, dass ich nix falsch gemacht habe- Lösung kam dann am Folgetag mit Level 3Support, der fröhlich verkündete, dass zu der Zeit, wo wir re-registrieren wollten der VZD etc. down war - leider, ohne dass man mir als Kunden oder dem DVO das mal mitgeteilt hätten- hätte uns viel Zeit gespart- und auch ti-radar undtistatus hatten dazu keine Meldung, grrr- schreibe das mal als Erfahrung hier mit rein - weil- man kommt ja so schnell in den Flow, dass es immer die eigene Anlage ist und die eigene TI-Konfig- grad wo der KIM ja jetzt eigentlich stabiler läuft insgesamt- aber es kann eben doch auch immer wieder ein Problem draußen sein...

Als VZD etc. wieder online waren am 9.9. konnte ich problemlos den KIM dann re-registrieren- will sagen: Aufrufkontext erstmal im Frontend KIM neu setzen auf gesicherter Modus mit p.12 ClientZert.- KIM reregistireren, dann config.bat im Backend mit adminrechten (!) aufrufen , neues Zertifikat einpflegen, WMS Konfig auf neues Zertifikat+ neues PWort ändern - und dann KIM neu starten ...!! bei Rereg will der KIM verpflichtend neues PW, gibt man das alte ein- kommt ganz zum Schluss Fehler und zurück auf Los - man kann dann den ganzen Kram (Mandant, Aufrufkontexte ...) wieder von vorne neu eintragen...

SMC- B wurde manuell im Infomodell Konnektor eingetragen, alte SMC-B rausgelöscht.