AdminP / Roaming

    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....

    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?!

    Warum ist das inkonsequent ?


    Nur weil etwas funktioniert muss es nicht korrekt sein.
    Und wenn die Dokumentation schon klar aussagt, daß ein bestimmtes Format verwendet werden muss, dann sollte man sich daran auch halten.
    Nimm doch das Beispiel mit dem Netzlaufwerk fürs Datenverzeichnis:
    Das tut ja eigentlich, aber eben doch nicht ganz.
    Und deswegen ist es auch nicht supportet weil eben genau die Probleme bekannt sind.
    Und hier ist es genau das gleiche


    Ohne Grund schreibt das keiner in die Doku.

    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.

    Daß es mit Vorname Nachname funktioniert hat einen anderen Grund: Nämlich daß die Hierarchie bei Eindeutigkeit automatisch ergänzt wird.
    Aber spätestens wenn du einen zweiten User mit gleichen Vor und Nachnamen hast geht es wieder nicht.


    Der hierarchische Name ist vielleicht nicht unbedingt für genau dieses Szenario erforderlich, aber wenn man es im gesamten betrachtet eben doch.


    Wenn schon die Festlegung so klar in der Doku ist, wieso soll ich mich dann mit anderen Varianten beschäftigen, die ja auch deswegen nicht supportet sind, anstatt mich an die Anleitung zu halten.


    Und daß du einen Request nicht nachträglich verändern darfst ist eines der grundlegenden Sicherheitsmerkmale des AdminP Prozesses.


    Ohne dir nahetreten zu wollen finde ich persönlich es eher inkonsequent entgegen der Doku etwas zum Laufen bringen zu wollen, anstatt sich eine saubere Variante im Einklang mit der Doku zu überlegen

    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 ...