Beiträge von grunz

    Die Doku ist zwar schön und gut, aber leider muss man sich dann auch hin und wieder mal der Realität in Form einer über Jahre gewachsenen Umgebung stellen, die dabei auch schon durch diverse Hände gegangen ist. Ohne jetzt meinen Vorgängern die komplette Schuld an der Misere in die Schuhe schieben zu wollen, schleppt man trotzdem doch so die ein oder andere Altlast mit sich rum...
    Im konkreten Fall wird es bei uns leider nicht möglich sein, die Active Directory Benutzernamen zu ändern, da viel zu viele Anwendungen davon abhängig sind. Insofern wäre die Verwendung des Shortname als eindeutiger Schlüssel eine wirklich extrem charmante Lösung gewesen, aber in dem Punkt wiederhole ich mich langsam.
    Offensichtlich gibt es keine Doku-konformen Alternativen, so dass ich mich unweigerlich damit beschäftigen muss, wie man es trotzdem zum Laufen bekommt. Ich kann mich natürlich auf den Standpunkt zurückziehen, dass das alles nicht supported wird, aber damit ist leider auch niemandem geholfen ...

    Ich finde es zumindest insofern inkonsequent, als dass in der von mir beschriebenen Situation entgegen der Doku der hierarchische Name nicht unbedingt erforderlich ist. Ich habe den Ablauf gerade mal einfach nur mit dem Vor- und Nachnamen in der clientconfig.txt getestet - ohne OU und Certifier im Namen. In dem Fall wurden die Replica Stubs für localfeedcontent.nsf und roamingdata.nsf anstandslos vom AdminP erzeugt.
    Ich wäre ja schon zufrieden, wenn ich den AdminP irgendwie davon überzeugen könnte, die auf den beschriebenen Fehler gelaufenen Request irgendwie trotzdem zu verarbeiten. Habe zwztl. sogar schon mal mit ScanEZ versucht den Request auf meinen eigenen Benutzernamen umzuschreiben, aber das läuft dann in einen anderen Fehler: RoamExtFiles; Error: The selected user's additional roaming files should have already been created for the client version specified.

    Wieso war mir bloß schon vorher klar, das von Dir jetzt genau dieser Einwand kommt ... ;)
    Ist zwar schön und gut, dass der Name "eigentlich" hierarchisch sein soll, aber dann war es von den Entwicklern an der Stelle auch sehr inkonsequent überhaupt den Shortname beim ersten Start zu akzeptieren. In dem Fall würde ich dann mal ganz dreist erwarten, dass der Rest auch funktioniert.
    Wie auch immer - es wäre jedenfalls eine echt charmante Lösung, wenn das mit dem username=%username% klappen würde, und wir das doofe Loginscript einsparen könnten, aber das ist uns wohl leider nicht vergönnt.
    Gibt's sonst noch Ideen/Einwände zu dem Thema?!

    Hallo zusammen,


    folgende Situation:


    wir nutzen derzeit noch 8.5.1er Clients in der Basic-Konfiguration, bei denen zudem auch noch das Notes-Data-Verzeichnis auf einem Netzlaufwerk liegt. Ich bin mir selbstverständlich darüber bewusst, dass das mit dem Netzlaufwerk nicht supported wird. Da uns das auch immer wieder Probleme bereitet, wollen wir nun auch endlich davon weg - habe auch lange genug Überzeugungsarbeit leisten müssen...


    Wir möchten nun jedenfalls alle Benutzer zu Roaming-Benutzern machen, und anschließend den vorhandenen Notes-Client gegen eine Installation autauschen, welche nicht mehr auf das Netzlaufwerk angewiesen ist.


    In dem Zusammenhang kommt der Notes.ini-Parameter "setup=clientconfig.txt" zum Einsatz. In der Clientconfig.txt haben wir wiederum den Parameter username=%username% gesetzt.
    Unsere Windows Benutzernamen bestehen aus einem Buchstaben gefolgt von vier Ziffern, also z.B. A1234. Im Lotus Notes haben wir diese (Windows-)Benutzernamen als Shortnames im Personendokument hinterlegt. Der Client erkennt darüber auch bei der Erstanmeldung anstandslos den passenden Benutzer, zieht sich die User-ID aus dem ID-Vault, die Roaming-Datenbanken vom Server, usw. usf.
    Der Teufel steckt aber mal wieder im Detail... Wie erwähnt setzen wir bislang den Basic-Client ein, möchten aber bei der Gelegenheit möglichst auch direkt auf den Standard-Client umstellen. Wenn nun jemand der bislang an einem Basic-Client Roaming Benutzer war, und somit nur die bookmark.nsf und names.nsf auf dem Server im Roaming-Verzeichnis liegen hat, nun das erste mal in der "neuen Installation" den Client startet, dann wird ein AdminP-Request erzeugt, um die fehlenden Roaming-DBs des Standard-Clients auf dem Server zu ergänzen (localfeedcontent.nsf & roamingdata.nsf). Dummerweise wird dieser Request aber unter Verwendung des Shortnames signiert, woraufhin der AdminP die Abarbeitung verweigert:


    Error: Admin Process: The signer of this request must be the Roaming user affected by the request.


    Eine Möglichkeit wäre nun mit einem Loginscript für jeden Benutzer eine eigene Clientconfig.txt zu schreiben, in welcher der Parameter "username" in der Form "Vorname Nachname" individuell gesetzt wäre. Fände ich aber nicht so schick... Hat evtl. sonst noch jemand eine schlaue Idee, wie man dem Problem auf andere Art und Weise Herr werden könnte? Wäre natürlich Klasse, wenn der AdminP irgendwie von der korrekten Identität überzeugt werden könnte, aber die Hoffnung habe ich praktisch aufgegeben....

    Wie schon gesagt habe ich das auch versucht, doch mir scheint, dass die Anleitung nicht mehr für 8.5.x gilt, bzw. dass diese Funktion unter 8.5.x einfach nicht mehr unterstüzt wird. Jedenfalls habe ich es wie in der Anleitung beschrieben trotz mehrfacher Wiederholung nicht hinbekommen.
    Bleibt zudem auch weiterhin die Frage, ob man im Standardclient neben der Einführungsseite auch die Anzeige der Konfigurationsseite unterdrücken kann.

    Darfst gerne vorbeikommen und das bei unseren 1500 Usern durchklicken ... ;)
    Aber im Ernst - es geht selbstverständlich darum, dass dies voreingestellt werden muss. Eine manuelle Anpassung durch den User steht nicht zur Diskussion.


    Wie ich gerade festgestellt habe bewirkt der Parameter com.ibm.rcp.jfaceex/overrideAutoStart=com.ibm.rcp.gettingstarted.GettingstartPerspective
    nur, dass im STANDARD Client die Anzeige der Einführungsseite unterdrückt wird. Im Hitnergrund öffnet sich dann aber weiterhin die oben erwähnte Konfigurationsseite. Kann man die ggf. auch irgendwie unterdrücken, wenn man es denn einmal schaffen würde, dass sich der Workspace zumindest öffnet?

    Hallo,


    kann mir evtl. jemand bestätigen, dass die im folgenden Artikel beschriebene Vorgehensweise auch noch im aktuellen 8.5.2er Client (oder neuer) funktioniert?


    https://www-304.ibm.com/suppor….wss?rs=0&uid=swg27003219


    Ich habe die Schritte leider nun schon mehrfach durchexerziert, aber das Ergebnis entspricht leider nicht den Erwartungen. Der Client startet immer mit der Konfigurationsseite auf der die Optionen "Eigene Startseite erstellen" und "Was gibt's neues in Lotus Notes 8.5" angeboten werden. Letzeres habe ich auch bereits versucht über den folgenden Eintrag in der plugin_customization.ini zu unterdrücken:


    com.ibm.rcp.jfaceex/overrideAutoStart=com.ibm.rcp.gettingstarted.GettingstartPerspective


    - Patrick

    Nein, da hängt (leider) noch so einiges an fremder ( bzw. gemieteter) Infrastruktur davor. Die Mails werden vom Mailserver unseres Providers via SMTP an unsere Dominoserver übergeben. Zumindest die Received-Zeilen im Header lassen mich auch glauben, dass da alles mit rechten Dingen zugeht, denn dort steht die eigentlich Zieladresse vollkommen korrekt drin. Nur eben in dem vom Domino-Server hinzugefügten BCC-Feld kommt dieser Schrott dazu...

    Der Aufhänger für die Aktion sind externe, bzw. genauer gesagt SMTP-Mails. Wir nutzen ein Produkt namens "team-mail" von der Firma Tolina. Ín dem Zusammenhang mit der Nutzung dieses Tools haben wir Probleme, wenn dort Mails reinkommen bei denen sich die Zieladresse im Header von jener im Envelope (SMTP - RCPT TO) unterscheidet. In unserem Fall passiert das vornehmlich dann, wenn eigentlich nicht an uns adressierte Mails direkt vom empfangenden Mailserver an uns weitergeleitet werden. Da diese Weiterleitung gewissermaßen nur im Envelope passiert, fehlen team-mail nach der Zustellung durch unseren Router die im Envelope enthaltenen Infos über die eigentliche Zieladresse. Daher ist mir die Option zur Ergänzung der Adresse im BCC-Feld des Headers in dem Zusammenhang sehr willkommen. Allerdings wär's halt deutlich schöner, wenn die Adresse auch korrekt hinterlegt würde...

    Nein - die Notes-Domäne heisst bei uns lediglich "Company" um mal bei dem Beispiel zu bleiben. Der FullQualifiedHostname einer der Server lautet allerdings z.B. "company-mail01.company-domaene.intra"
    (man ersetze "Company" jeweils durch den echten Firmennamen - der Rest ist exakt so wie in den obigen Beispielen). Der Server nimmt daher an der Stelle ganz eindeutig Bezug auf seinen eigenen FQHN, und verwendet den Domain-Part zum generieren der Adresse für's BCC-Feld. Mails werden mit unterschiedlichen Domains versendet, aber niemals mit "company-domaene.intra" - das steht auch nirgendwo in der Konfig. Daher kann es der Server mit 100%iger Sicherheit nur vom eigenen FQHN ableiten - vielleicht macht er auch einen Reverse-Lookup auf seine eigene IP, aber das kommt dann auf's selbe raus....
    Zum Mailen kommen nur Domainnamen wie "company-konzern.de" oder "company-ag.de" zum Einsatz.

    Meinst Du den Punkt bei ...@company-domaene.intra ? Diese Domain wird allerdings überhaupt nicht zum eMailversand verwendet (wie man auch an dem TLD-Suffix ".intra" sehen kann) - die hat sich der Server augenscheinlich aus seinem eigenen FQHN abgeleitet, denn das ist die einzige Stelle an der dieser Domainname auftaucht. Die eigentlichen Maildomains haben andere Bezeichnungen.

    Die Option "Internet address lookup" ist bereits aktiviert.
    Die anderen Optionen lauten wie folgt:


    Local part formed from: "Shortname"
    Domino domain(s) included: "None"
    Domino domain(s) position: "Left of '@'"
    Domino domain separator: "% - percent sign"


    Die Option Domino domain(s) included - "None" scheint der Server dabei auch komplett zu ignorieren, denn die Domino-Domain wird ja definitv drangeklebt...


    Andere Ideen/Vorschläge?

    Hallo,


    ich habe kürzlich die Option "If each recipient's address does not appear in any address header, then add their address to the BCC list" in der Konfiguration unserer Domino-Server aktiviert.
    Das klappt auch mehr oder weniger wie ich es erwarten würde, allerdings mit einem kleinen Schönheitsfehler:
    Die Adressen die in das BCC-Feld im Header geschrieben werden, sehen etwas hässlich aus, wie im nachfolgenden Beispiel dargestellt.


    Bcc: Vorname_Nachname/OU/Company%Company@company-domaene.intra


    Gibt es an der Stelle irgendeinen Möglichkeit den Server dazu zu zwingen, genau die Adresse zu verwenden, die er beim SMTP RCPT TO übergeben bekommen hat? Im obigen Beispiel wäre das wowas wie vorname.nachname@company-zusatz.de


    -Patrick

    Gibt es hierzu evtl. noch irgendwelche neuen Erkenntnisse? Ich würde gerne den Standard-Client in Kombination mit Servergespeicherten Windows-Profilen nutzen und bin auch auf das Problem mit diesem überlangen Dateinamen gestoßen. Das Ausschließen der kompletten .metadata-Verzeichnisstruktur vom Windows-Roaming ist auch nicht optimal, da in dem Pfad z.B. auch die zuletzt geöffneten Tabs gespeichert werden. Wäre klasse wenn irgendjemand noch einen anderen Workaround parat hätte....

    Hallo,


    erhalte seit kurzem auf einem Linux-Client die im Betreff genannten Fehlermeldung. Komplettes Löschen bzw. Zurücksetzen des Data-Verzeichnisses des betroffenen Accounts hat leider nicht geholfen. Google ist in dem Fall auch nicht sehr ergiebig. Kann jemand evtl. auf den folgenden Artikel zugreifen und den Inhalt mal hier posten? Komme da mit meinen Rechten nicht dran - darin soll's aber angeblich um genau dieses Problem gehen:


    http://www-01.ibm.com/support/…crawler=1&uid=swg1LO56796