fehlende Einträge mobiles Adressbuch

  • Hallo zusammen,


    wir haben für Notebookuser ein Mobiles Adressbuch (Extended Directory Catalog). Wenn ich nun "offline" arbeite und eine Adresse auswähle, wird die Adresse bei der Auflösung in der Adresszeile zwar gefunden (der Eintrag steht auch in der Personenliste), beim senden kommt dann aber die meldung, dass die Adresse nicht vorhanden ist. Das roblem ist, dass es bei einigen Adressen funktioniert, bei anderen aber nicht. Ich kann in den Personendokumenten der names.nsf keinerlei Unterschiede zwischen den Dokumenten finden.


    Wäre für jede Idee dankbar.

  • wenn ich dich richtig verstanden habe, dann nutzt ihr ein zusätzliches adressbuch für eure notebooks. hat denn diese adressbuch den namen names.nsf oder ist da anders benannt worden?


    z.b. adressbuch_notebook.nsf oder ähnlich?
    diese könntest du dann lokal replizieren und in die notes.ini des clients eintragen...


    wie gesagt, bin mir nicht sicher ob ich dich richtig verstanden habe.


    willkommen im forum

    -*-*-*-*-*-*-*-*-*-*-*-


    woher soll ich wissen was ich denke, bevor ich höre was ich sage???

  • Hallo,


    es handelt sich nicht um ein zusätzliches Adressbuch, sondern um ein kompaktes. Das ist eine Notes Standardfunktion. Hier liegen nicht die einzelnen Personendokumente drin, sondern eine komprimierte Form aller Personendokumente. Somit ist das "Mobile Adressbuch" um ein vielfaches kleiner. Für die Adressierung neuer Mails im Offline Modus ist dieses zusätzlich zum persönlichen Adressbuch des Users in den Benutzervorgaben hinterlegt.
    Das Mobile Adressbuch (Extended Directory Catalog) wird über den Dircat Task zyklisch neu aufgebaut.

  • Lass mal die Ansichts-Indizes neu aufbauen
    oder
    leg mal eine neue Replik an
    und guck, ob der Fehler immer noch da ist.


    Wenn er noch da ist, liegt es am MDC auf dem Server.
    Dann hier auch mal einen updall drüber laufen lassen.
    Des weiteren den ganzen Katalog löschen und mit
    load dircat dbname.nsf
    neu aufbauen.

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

  • Habe alle Tips ausprobiert. Nix hat geholfen.
    Letzte Aktion war, dass ich das mobile Adressbuch gelöscht und neu erstellt habe. Gleicher Effekt, die Einträge bestimmter User werden beim senden nicht gefunden. Somit liegt die Vermutung nahe, dass bereits der Eintrag in der names.nsf defekt sind oder zumindest eine Macke haben. Nach Vergleich bestimmter Einträge in der names.nsf sind keine Unterschiede zwischen denen die im mobilen Adressbuch funktionieren und nicht funktionieren zu sehen. Auch ein FixUp der names.nsf bringt kein besseres Ergebnis. Bin im Moment ratlos.


    Noch einige Ideen ??

  • neuer versuch:-)


    also, du hast dir einen neuen dircat zusammengebaut, diesen replizieren deinen notebook-user auf ihr dataverzeichnis lokal. dann gibst du in der notes.ini vom client an, dass names=names.nsf,dircat.nsf
    in der adressierung lokal wird dir das adressbuch angegeben, obder die datensätze sind nicht vollständig. hat der user denn noch den alten dircat bei sich und der wird nicht sauber überschrieben?
    hast du den auch schon load dircat dc.nsf -r angegeben, damit der nochmal ganz vom server aufgebaut wird?

    -*-*-*-*-*-*-*-*-*-*-*-


    woher soll ich wissen was ich denke, bevor ich höre was ich sage???

  • genauso ist es. Nicht nur das das neue mobile Adressbuch auf lokal repliziert wurde, anschließend wurde auch der Notes Client beendet und die Cache.ndk gelöscht. In den Benutzervorgaben wurde dann bei den lokalen Adressbüchern die names.nsf (persönliches Adressbuch) und das neue mobile Adressbuch eingetragen. Ein updall -R auf dem Server für das mobile Adressbuch wurde auch mehrfach durchgeführt. Das persönliche Adressbuch muss in den Benutzervorgaben als erstes Adressbuch eingetragen werden, da hier die Arbeitsumgebungsdokumente hinterlegt sind.

  • die Adresszeile enthält den Namen gemäß der Notes Konvention:
    Beispiel "erna meier/xxx. Alle User um die es geht sind Notes User die im zentralen Adressbuch "names.nsf" hinterlegt sind. Der Witz ist ja, dass der offline user den namen normal aus dem mobilen Adressbuch auswählen kann und dieser auch richtig aufgelöst wird (wie Beipiel oben). Nur wenn dann gesendet wird, kommt das Meldungsfenster mit der Meldung "Keine Übereinstimmung";"Dieser name befindet sich in keinem Adressbuch".

  • ja, funktioniert auch.


    Habe mittlerweile festgestellt, dass folgendes nicht funktioniert.


    Wie oben beschrieben, wird der Name ja gemäß Notes Konvention aufgelöst: Beispiel Erna Mueller/xxx. Wird der nicht funktionierende Name aus dem Adressbuch ausgewählt, wird er auch automatisch vervollständigt. Der Unterschied vom nicht funktionierenden zu den funktionierenden ist, dass der funktionierende so aufgelöst wird:
    Erna Mueller/xxx@xxx. Wenn ich den nicht funktionierenden in diesem Format manuell eintippe, kann er auch gesendet werden. Seltsam ist, dass in der Ansicht des mobilen Adressbuch auch die nicht funktionierenden Namen mit der vollen Domänenadresse angezeigt werden. Im Moment glaube ich, dass die Ursache eventuell im Design des mobilen Adrsssbuches oder in der Mail Schablone liegen könnte. Aber, ich habe zwei Beispiele (funktionierenden und nicht funktionierenden) in der names.nsf Feld für Feld verglichen. Sie scheinen identisch zu sein.


    Mittlerweile ist zwar mein Ergeiz geweckt, aber der Zustand nervt trotzdem.


    Vielen Dank für das Interesse an meinem Problem.

  • Nach langer Suche habe ich auf der IBM Seite die Rekonstruktion des Fehlers und einen Lösungsansatz gefunden. Jetzt funktioniert es, auch wenn ich Fehler, Ursache und Lösung nicht wirlich nachvollziehen kann.


    Hier der IBM Text:


    Problem
    Using a Last Name that has different First Name variations found in the Directory Catalog (DirCat), you create a new memo and use type-ahead to perform the name lookup. In the Notes 6.5.2 client, it is working as expected and the type-ahead finds the expected names; however, you receive the ambiguous names dialog box with no suggestions in the Notes 6.5.3 client.



    Steps to reproduce:
    1. Replicate a local copy of the Directory Catalog and your mailfile. Make sure the Directory Catalog is sorted by Last Name.
    2. Switch to a Location document (e.g., "Island" or "Home") so you are disconnected from the network.
    3. Select File -> Preferences -> User Preferences -> Mail . Add the filename of the local replica of the Directory Catalog to the "Local address books" field.
    4. Create a new Memo.
    5. In the "To:" field, type in a user's Last Name and the first few initials of their first name. For example, to search for John Doe you would type "Doe Jo" (without the quotes).
    6. Press the F9 key.


    o In the 6.5.2 client, the type-ahead completes and the name displays as expected.
    o In the 6.5.3 client, the ambiguous names dialog is displayed containing no suggestions. This is not what is expected.


    7. If you click OK the "To:" field appears blank. However, if you click CANCEL or press the ESC key, the name is resolved.
    8. Blank out the name (if it is not already) and type in the user's Last Name.
    9. Press the F9 key. You are not presented with any name suggestions.

    Cause

    Solution
    This issue was reported to Quality Engineering and has been addressed in Notes/Domino 6.0.5 and 6.5.4.


    Excerpt from the Lotus Notes and Domino Release 6.0.5 / 6.5.4 MR fix list (available at http://www.ibm.com/developerworks/lotus):


    Directory Services


    * SPR# CSMH65WPRX - The Ambiguous Names dialog box did not display suggested names when using the offline Directory Catalog. This fix is addressed in the Client and Server code, depending on where the search is being done. Searching for names that were sorted by last name require a full text search in order to find the users. So, for example, in Off-line directory catalogs, when you hit F9, your search is performed on the client, because your dircat is local. If the Directory Catalog is located on the server, then the fix is on the server side because the searching will be issued against the server.
    This problem was a regression introduced in 6.5.3 and has been fixed in 6.0.5 and 6.5.4.



    Workarounds:


    * Add another Directory Catalog that is sorted by Distinguished Name (First Name) to the local configuration (e.g., names=names, lndircat, fndircat). This will also provide for First and Last Name addressing.



    OR


    * When the "No Match" dialog appears, click the CANCEL button or press the ESC key. When actually sending the mail, click on "Send Anyway".




    Supporting Information:
    This issue can also affect Notes users who have a LAN connection and use the server-based Directory Catalog for name resolution and addressing. There is also an additional symptom of the @Domain not being appended to the recipient's name, which can result in a message delivery failure.

  • dann kann es ja nur daran gelegen haben, dass du die ersten paar zeilen vom vornamen nicht angegeben hast. den rest hast du ja bereits mehrfach versucht....das war aber schon immer ein kleines problem beim arbeiten mit dem dircat.


    es leben notes...notes works as designed :lol:

    -*-*-*-*-*-*-*-*-*-*-*-


    woher soll ich wissen was ich denke, bevor ich höre was ich sage???

  • habe Deine letzte Anmerkung mit zeilen des vornamens nicht verstanden. ich habe die fehlerbeschreibung der ibm so interpretiert, dass es ein versiosfehler von notes ist. der nachteil bei dem jetzt eingeführten workaround ist, dass die namenseinträge nur nach vornamen gefunden werden können.


    ansonsten sind die vornamen aber richtig gepflegt

  • tschuldigung dass ich erst jetzt antworte.


    ja, die meldung kommt erst beim senden.
    Kann mit der Arbeitsumgebung nicht viel zu tun haben, da das mobile adressbuch ja gerade für den Inselbetrieb gedacht ist. Da beim auflösen der mailadressen immer erst die lokalen adressbücher durchsucht werden, steht das mobile adressbuch immer vor dem serveradressbuch. egal in welcher umgebung ich mich befinde.