ID-Datei ist keine ID-Datei oder beschädigt

[lime]

Hallo,

wir hatten letzte Woche in einer Landesstelle Rollout neuer Clients. Dabei wurde das OS von Vista auf W7 umgestellt, und ab jetzt wird auch die aktuelle Notes Client Version verwendet (8.5.2, vorher war es noch 8.5)

Die IDs mit denen die User einsteigen, liegen auf einem Netzlaufwerk, damit hat es bis jetzt nie Probleme gegeben.
Ich habe bei der Umstellung nach dem einrichten der Clients lediglich die desktop8.ndk wieder reinkopiert ins Data Verzeichnis, damit ich nicht alle Kacheln manuell wieder hinzufügen muss. Aber ansonsten habe ich Notes bei den Usern komplett neu konfiguriert, und auch die ursprüngliche ID-Datei auf dem Netzlaufwerk wieder angegeben - die Kennwörter der ID-Dateien hatte ich vorher allerdings mittels ID-Vault zurückgesetzt.

Es war dann aber bei *fast* allen Usern die ID-Datei kurze Zeit nach der Umstellung plötzlich beschädigt - es ist die Meldung erschienen: angegebene ID-Datei ist keine ID-Datei oder beschädigt.

Wie kann das sein? Ich habe nur das Kennwort zurückgesetzt, sonst nichts, das hat bis jetzt auch immer funktioniert.

Ich habe dann bei betreffenden Usern eine neue ID-Datei aus dem Vault extrahiert, und diese dann anstatt der alten verwendet. Das hat dann geklappt - bei allen Usern bis auf zwei.
Bei diesen 2 Usern tritt es seit dem regelmäßig auf, dass immer wieder die Meldung erscheint, dass die ID-Datei keine ID-Datei ist oder beschädigt ist. Ich muss dann immer wieder eine neue ID aus dem Vault extrahieren, dann funktioniert es wieder eine Zeit lang.
Aber auf lange Sicht kanns das auch nicht sein. Hat jemand eine Idee, warum die ID-Dateien scheinbar immer wieder "von alleine" beschädigt werden?
Liegt es daran, dass die ID-Dateien auf einem Netzlaufwerk liegen, oder was könnte sonst die Ursache sein?

Bin für jeden Tipp dankbar,

lg
Verena

[m3]

Wenn die IDs in der Vault liegen, brauchst Du das Netzlaufwerk weder für die Archivierung, noch für die Installation. Wenn keine ID lokal vorliegtr, holt er sich die automatisch aus den IDVault.

Der Rest des Datenverzeichnisses liegt hoffentlich lokal, oder?

[lime]

Ja, aber wir wählen generell beim ersten Starten von Notes den Pfad der IDs immer manuell aus (eben auf dem Netzlaufwerk), damit die User sich auch auf anderen PCs in ihr Notes einwählen können.
Dass Lotus auch so zum Öffnen ginge, weil es diese "user.id" aus dem Vault (?) rauszieht und diese dann im Data-Verzeichnis als "user.id" anlegt, weiß ich eh, nur wir möchten die ID auf dem Netzlaufwerk gesichert haben unter dem Namen des jeweiligen Benutzers und nicht lokal irgendwo als "user.id" rumliegen haben...

genau, der Rest des Data Verzeichnisses ist auf lokal auf C:

lg, Verena

[Gandalf98]

Hi Verena,

ihr habt also eine Installation mit dem Data Verzeichnis auf einem Netzlaufwerk? (Roaming User mit der sogenannten "Terminalservervariante")
oder
Ist nur die ID auf dem Netzlaufwerk?

Warum er die ID geschreddert hat kann ich nur raten, ist dies ID wirklich kaputt? Also auch über den Adminclient nicht zu öffnen?

Hatte die ID einen Schreibschutz?

Gruß
Michael

[lime]

Hi Michael,

wie ich bereits geschrieben habe, haben wir die Installation/das Data-Verzeichnis lokal auf C:, und nur die ID-Dateien auf dem persönlichen Netzlaufwerk des jeweiligen Users abgelegt.
Also keine ("echten") Roaming-User.

Die ID-Dateien hatten keinen Schreibschutz.

In dem einen (Härte-)Fall haben wir jetzt den Benutzer neu angelegt, weil wirklich JEDEN Tag die neu aus dem ID-Vault herausgezogene ID-Datei wieder "defekt" war, also nicht mehr zu öffnen gegangen ist (die übliche Meldung vom Notes Client: angegebene Datei ist keine ID-Datei oder beschädigt). (Die alte ID-Datei wurde in dem Fall natürlich auch immer noch als defekt gemeldet.)

Was bei zwei anderen Benutzern auffällig war: die ursprüngliche ID-Datei die schon als "defekt" von Notes gemeldet wurde und deswegen eine neue erstellt wurde, hat nach ein paar Tagen plötzlich wieder funktioniert! Dafür die neu erstellte dann wieder nicht, die war dann "defekt" (zumindest schreibt das Notes immer so hin)

Danke, Lg, Verena

[Gandalf98]

HI Verena,

ok den User neu anzlegen war ne gute Idee.

Man sollte aber herausfinden was die ID  Files für ein Prblem haben.
Kommst du an den Public Key der kaputten ID-? Dann mal mit denen vergleichen die im DD abgelgt sind.
Du schreibst ihr habt nur das BS und die Clients verändert. Nichts an der verschlüsselung oder an den Schlüsseln der USER verändert.
Warum ich frage ob die ID schreibschutz hat. Wenn der Clint nicht in die ID-schreiben kann kannst du so eine Meldung bekommen.

Habt ihr Shared Login aktiviert?
Dann mal hioer schauen:
https://www-304.ibm.com/support/docview.wss?uid=swg21450471
Gruß
Michael