Beiträge von agent_orange

Servus zusammen,

ich kenne das Problem, habe es auch gerade, verstehe allerdings nicht, warum es existiert.
Als ich eben einen 8.5.1FP4-Server auf 8.5.2 upgegradet habe, bekam ich die gleiche Meldung mit dem angeblich nicht passenden LangPack. Der Grund liegt aber auf der Hand. Trotz erfolgreicher Installation des Servers (Die Verzeichnisse wurden ja angelegt, die Setup-Routine lief ohne Fehler bis zum Ende), zeigt die Konsole beim Start nach wie vor Release 8.5.1FP3 (!).
Es scheint also schon beim Einspielen des letzten FP ein Fehler vorgelegen zu haben und die Release-Info nicht korrekt überschrieben worden zu sein. Nur: Wo wird die festgelegt??
Server ist übrigens ein Ubuntu 10.04 LTS.
Weil nun das LangPack bei der Installation eben diese Info abfragt, geht es schlichtweg nicht weiter.

Hat einer ne Ahnung, woher der Domino die Information zum Releasestand zieht? In der notes.ini steht es jedenfalls wohl nicht, die wurde auch korrekt angepasst.

Gruß
Chris

Vielen Dank!
Das hat geholfen. Ich scheiterte an der Tatsache, daß man nur Benutzer ERNEUT zertifizieren kann, hingegen Zertifikate generell über die Konfiguration für jegliche *.id-Dateien neu ausstellen kann.

Benutzer, die ich mit dieser "verlängerten" cert.id neu zertifiziere, tragen im Ablaufdatum des Stammzertifikats nun auch das neue Datum, das ich in eine Zeit weit, weit in der Zukunft gelegt habe ... in einer Galaxie weit entfernt oder so

Grüße
Christian
:idea: :idea: :idea:

Wie hast Du das gemacht? Man kann sich mit einer cert.id nicht anmelden, daher wüßte ich gerne, wie Du sie mit R7 verlängert hast (meinetwegen auch gern mit sich selbst :-))

Gruß
Christian

Danke erstmal!

Ist in der Tat so, daß alle User beim Ablaufdatum des Stammzertifikats jenes der cert.id drinstehen haben. :-x

Ist es nicht unsinnig, daß man der cert.id ein Ablaufdatum geben kann, wenn es so schwierig sein soll, sie zu verlängern???

Also da ich diese Domino-Installation geerbt habe und sie aus alten R5-Zeiten stammt (wenn nicht noch älter), bin ich mir ziemlich sicher, KEIN Ablaufdatum beim Anlegen der cert.id angegeben zu haben.

Was mich jetzt aber doch noch interessiert: Es geht um das Stammzertifikat "/Organisation". Im Prinzip ist das auch wieder nur ein Notes-Dokument. Der einzige Unterschied ist der ellenlange Schlüssel, der das Zertifikat darstellt. Weiß jemand, ob das genau auch dem Zertifikat der cert.id enspricht? :-?

Grüße
Christian

Guten Tag allerseits,

heute habe ich mal ein lustiges Problem. Es ist so lustig, daß ich mir gleich ein Bein rausreiße, damit ich auch mitlachen kann.

Bei einem Kunden kommt seit Tagen bei verschiedenen Notes-Operationen via Lotus Administrator zu der Meldung, daß das Zertifikat ausgestellt auf: /Organisation von Zertifizierer: /Organisation im Juni abläuft.

Schnelles Handeln wäre jetzt gefragt, doch trotz so einiger Lotus-Erfahrung, will mir nicht recht einleuchten, was der Knabe will.

Die cert.id hat doch kein Ablaufdatum, oder etwa doch? Wenn ja, wie soll man sie denn bitte schön verlängern oder neu zertifizieren, wenn nicht mal die passenden Aktionen dafür zur Verfügung stehen?

Hat das jemand unter Euch schon mal erlebt und weiß mit der Meldung was anzufangen, bzw. könnte es auch gar nichts mit der cert.id zu tun haben??

In den Foren wurde das zum Teil schon heftig diskutiert, jedoch meistens im Bezug auf verlorengegangene oder zerstörte cert.id-Dateien, jedoch ist meine noch in einem sehr guten Zustand.

Nicht vorstellen kann ich mir ein Ablaufen der server.id oder der des Administrators, da ich bei beiden Dateien überprüft habe, wie lange sie gültig sind.

Hat jemand noch ne bahnbrechende Idee???

Händeringend dankesagend ;-),

Christian

Nee, es laufen hier zwar Blackberries, aber die haben deswegen noch nie ein Problem gemacht. Es geht ja auch auf allen 6.5.4er Clients, nur an dem 7.0er Client nicht mehr. Weiß der Kuckuck warum...

Christian

Ja, das habe ich auch bedacht und natürlich dem User, den ich vorher in die ACL eingetragen habe und dem ich Vollzugriff erteilte auch sämtliche Rollen zugesprochen.

Es macht nur eben keinen Unterschied. Außer dem User, der bei der Clientneukonfiguration auf dieser Workstation erstmalig angelegt wird, hat kein anderer derartige Zugriffsrechte. Das gilt jetzt wohlgemerkt NUR für die Arbeitsumgebungsdokumente. Alle anderen Typen (Verbindungsdokumente, Kontakte, Konten etc.) lassen sich ohne Probleme anlegen.

Bist Du Dir sicher, daß die "NetCreator"-Rolle tatsächlich für das Anlegen von LocationDocs zuständig ist? Ich hätte eher auf die Verbindungsdocs getippt...

Gruß,
Christian

Guten Tag,

ein altbekanntes Problem unter Lotus Notes ist ja die Tatsache, daß Mails mit der Notes-internen Adresse verschickt werden, wenn das Feld "Internet-Adresse" im Arbeitsumgebungsdokument nicht oder nicht richtig gepflegt wird, bzw. das Arbeitsumgebungsdokument mit einem anderen Benutzer (=andere ID) als demjenigen, für den die Arbeitsumgebung gelten soll, angelegt wird.
Seit ich zu Testzwecken kürzlich auf 7.0 upgegradet habe, gab es zunächst keine Probleme. Jetzt aber stelle ich fest, daß jegliche ID, mit der ich mich auf meinem Client anmelde keinerlei Rechte besitzt, im lokalen Adressbuch neue Arbeitsumgebungen anzulegen. Ich habe das parallel dann auf einem 6.5.4er Client getestet und dort kommt der Fehler nicht vor. Egal mit welcher ID ich mich einlogge, ich kann für diesen User ein location doc anlegen.
Unter 7.0 erhalte ich immer nur die Meldung "Für diesen Vorgang haben Sie nicht genügend Zugriffsrechte". Es bringt auch nichts, dem neuen User volle Zugriffsrechte in der ACL zu geben. Das wirkt sich nullkommanull aus!

Kennt jemand diesen Fehler und weiß Abhilfe?

Ich habe mittlerweile auch ein komplett neues Adressbuch unter 7.0 angelegt, doch selbst dann greift der Fehler. Ist das ein Bug oder ein Feature? Man könnte ja auf den lokalen Zugriffschutz der Datenbank spekulieren, aber dergleichen habe ich nicht konfiguriert.

Danke im Voraus,

Christian