Beiträge von RockWilder

    Mails welche uns der Dienstleister als NRPC-Mails schickt nicht in SMTP umgewandelt werden

    Werden sie nicht.
    Entweder es kommt eine SMTP-Mail, dann ist es eine Konfigurationseinstellung auf seiten eures Dienstleisters. Oder es ist eine SMTP-Mail, dann wird sie -unter der Voraussetzung, dass eure Config (siehe: Server-, Domänen-, Verbindungsdokument(e), gewünschtes Empfangsformat im Personendokument) korrekt ist- nicht in STMP umgewandelt.

    Ich verstehe es immer noch nicht ?(
    Ihr erhaltet eine NRPC-Mail, wollt sie aber als SMTP-Mail haben? Oder erhaltet ihr eine NRPC-Mail, die "falsche" Headerinformationen haben? Oder erhaltet ihr eine SMTP-Mail, anstatt einer NRPC-Mail, und diese ist malformed?


    Dein Server kann nur nnehmen, was er auch erhält. Wenn die eingehende Mail -wie auch immer- nicht dem entspricht, was ihr erwartet, wendet euch halt an euren Dienstleister. Seine Mail, sein Server, sein Problem.

    Ich meine das Profildokument, wo du bspw. auch den Owner der Mailbox einträgst.


    Schau dir bei IBM mal folgende Artikel an:
    Mail rule issues with Notes/Domino mail template
    Deleted mail rules still run and/or enabled mail rules do not run
    Knowledge Collection: IBM Notes and Domino mail rules


    Es wird in den related articles auch auf NotesPeek verwiesen. Das Tool ist ganz praktisch, um etwas mehr zu sehen, als es im UI dargestellt wird. Zur Manipulation von Dokumenten taugt es aber nicht, es ist R/O.
    Willst du bspw. Feldinhalte manipulieren, wirst du entweder skripten müssen, oder -was bedeutend einfacher ist- Tools von Drittanbietern verwenden. Ytria hat ScanEZ im Angebot, damit kann man so ziemlich alles anstellen, was die Backends von Client und Server auch können. Und sogar noch ein Stück weit mehr. Will man in die Tiefe einsteigen, wird man über kurz oder lang nicht drumherum kommen.

    Hast du im Profildokument nachgeschaut, ob die Regel tatsächlich nicht existiert? Kann auch sein, dass sie einfach nur nicht in der Ansicht auftaucht. In diesem Fall sicherstellen, dass es nur eine Ansicht mit diesem Namen gibt (werden LPs falsch eingespielt, kann es zu Dopplungen kommen).


    Warum ein "Dummy-User" und nicht das Kalenderprofil mit dem Namen der DB betankt?

    Zusätzlich zu den beschriebenen Problemen, sehe ich noch das Problem mit der Absenderadresse. Deutscher User schickt eine Supportmail, die landet zeitgesteuert bspw. in den USA, dort antwortet jemand, der User bekommt eine Mail von support.usa@abc.com. Wenn er darauf antwortet, landet die Mail zwangsweise wieder in den USA, unabhängig davon, ob es innerhalb deutscher Bürozeiten ist.
    Die Idee, nur eine DB zu haben, in der dann meinetwegen zeitgesteuert die Mails auf die internationalen Teams verteilt werden (bspw. wie von Rudi beschrieben: eine Ansicht, die nach Team kategorisiert), halte ich für eleganter.


    Hinzu kommt das doppelte Vorhalten der Mails: einmal in der zentralen DB und dann jeweils in den internationalen Ablegern davon ... doppelter Platz- und Sicherungsbedarf ohne erkennbaren Nutzen.


    Lösen lässt sich deine Anfrage schon, kein Ding. Die spannende Frage ist aber, ob das Gesamtkonstrukt wirklich so geschickt ist, oder ob du dir darüber erst Gedanken machen möchtest, wie das zu optimieren ist.

    Moijn!


    Zunächst einmal: bitte nicht zwei voneinander unabhängige Frage in einem Thread zusammenfassen. Das macht die Sache nicht übersichtlicher.


    Zum ersten Problem:
    Policy-Dokumente werden in ihrer eingestellten Reihenfolge eingelesen. Das heißt: ein Dokument, das nach einem anderen eingelesen wird, überschreibt die eingestellten Werte des Ersten. Entweder in beiden Dokumenten darauf achten, dass die selben Einstellungen vorgenommen werden oder aber die Dokumente so staffeln, dass sie sich nicht "in die Quere" kommen. Siehe dazu auch: Domino Policy Precedence Explained


    Zum zweiten Problem:
    Da scheint das Archivprofildokument einen Schlag zu haben oder gänzlich abhanden gekommen sein. Bitte entsprechend prüfen und ggf. die Suchfunktionen des Forums oder der Suchmaschine des geringsten Misstrauens verwenden.

    Eine kleine Ergänzung zu Ronkas Ausführungen: anstatt den jeweils aktuellen Bearbeitungsstand bspw. einer Excel-Tabelle rumzuschicken, wo jeder dann wiederum seine Aktualisierungen vornimmt und irgendwer muss all das zusammenführen, sollte man dringend auf DAOS setzen. So kann eine Person erst das Dokument in den Bearbeitungsmodus schalten, dann die Excel-Tabelle bearbeiten und speichern und alle anderen, die diese Mail ebenfalls erhalten haben, haben somit immer den aktuellen Stand. Auf diese Weise lässt sich das beschriebene Problem lösen, dass irgendwann mal an unzähligen Orten unzählige Versionen rumliegen und mglw. ein User mal auf eine veraltete Version zugreift. DAOS bietet weiters Verschlüsselung von Haus aus ... auch etwas, was Filer nicht ohne Weiteres beherrschen.


    Wenn innerhalb von Abteilungen, Projektgruppen, etc. regelmäßig Dateien hin und her geschickt werden, ist das ganz klar ein Problem der Arbeitsorganisation. Nicht nur hier, aber insbesondere hier, wären Team-Mailboxen vorzuziehen. Somit lässt sich verhindern, dass Mails mit Anhängen in User-Mailboxen landen und die 500 MB auffressen. Von möglichen Fällen, wo ausgerechnet im Urlaub der Person A eine Person B die Daten braucht, aber aufs Mailfile von A nicht zugreifen darf, nicht erst zu reden.

    Hallo und willkommen im Forum!


    Doch, du kannst diesen Agenten pro Datenbank implementieren und aktivieren. Das Vorhaben wird so in der Form allerdings nicht oder bestenfalls mit einigen Handständen realisierbar sein.


    Du kannst einen solchen Agenten in der DB XYZ erstellen, die Memo-Maske anpassen und im Query-/PostOpen-Event den Agenten starten. Das Problem ist allerdings dabei, dass sich das Dokument damit ändert, im UI also neu geladen werden muss. Alles machbar, aber schön ist anders.
    Alternativ kannst du in einer DB einen Agenten erstellen, der nach Eingang neuer Mail läuft. Da das aber auf dem Server und nicht im Client passiert, muss nicht nur der User, sondeern in dem Augenblick auch der Server Zugriff auf den Share haben. Das wiederum bedeutet, dass der Server nicht mit dem System-Account laufen daarf, sondern unter einem lokalen oder AD-User. Hier bedingt das Eine zwangsläufig auch das Andere.


    Die Frage ist, wofür das Gesamtkonstrukt überhaupt gut sein soll. Mail- und/oder Anhangsarchivierung realisiert man lieber mit geeigneten Tools und nicht auf diese Art und Weise. Weiters ist es sehr wahrscheinlich, dass du dir damit mehr Probleme einhandelst, als du löst. Ich denke da auch, aber nicht nur, an DAOS. Und natürlich auch daran, dass der Share ratz-fatz voll laufen wird. Beispiel: User A schickt Anahang an User B, User C und User D. Die wiederum schicken jeweils eine Antwort auf die Mail, inkl. Anhang, an alle anderen. Innerhalb von 2 oder 3 Mailwechseln hast du schonmal ein Dutzend Anhänge auf dem Share liegen. Multipliziert mit der jeweiligen Anhangsgröße und der User ... viel Spaß dabei. Haben alle Anhänge den selben Namen, werden ohne weitere Sicherheitsvorkehrungen (bspw. im Agenten selbst) "alte" Anhänge mit "neuen" Anhängen gleichen Namens überschrieben.


    Unterm Strich musst du dir sehr genau überlegen, was exakt du erreichen willst und ob du das überhaupt erreichen musst. Von einem technischen Standpunkt her betrachtet, der prinzipbedingt keine alternative lässt. Geht es nur um "och ... ist vorgeblich bequem für die User", dann lass die Finger davon, oder implementiere eine geeignete Archivsoftware.

    Weil LotusScript naturgemäß nicht von sich aus OS-Variablen expandiert. Woher soll es auch wissen, ob mit Prozent- oder mit Dollarzeichen gearbeitet wird? So in der Form erwartet das Skript einen Pfad, der in seiner Struktur einen Ordner namens "\%USERNAME\%" (man beachte die escapten Prozentzeichen!) enthält. Den wirst du mit großer Wahrscheinlichkeit auf keinem Windoof-System vorfinden.
    Dazu gibt es aber die Environ Funktion. Environ("Username") sollte den Benutzernamen zurück geben, diesen Return Value wiederum kannst du an "downloadfolder" verfüttern.


    /edit:
    Torsten war schneller :thumbup:

    Mittel Policy kann der Mailserver festgezurrt werden. Sind beide Server innerhalb der selben Domain, sollte es -zumindest theoretisch- auch kein Problem mit Verbindungsdokumenten geben, da der DNS-Name (alternativ: IP, aber das will man nicht) des neuen Servers vom alten erfragt wird.
    Wenn es dennoch nicht tut, muss dann doch turnschuhadministrativ die AU des Users kontrolliert werden, ob er nicht "rein zufällig" den Haken gesetzt hat, dass der AdminP das Dokument nicht aktualisieren darf.

    taurec meinte damit vermutlich 2 Dinge:
    1) hast du die User manuell in die Gruppe eingetrage oder per Script? Das kann den Unterschied ausmachen, ob im Item "Members" dann "CN=Lieschen Mueller/O=Certifier" oder einfach nur "Lieschen Mueller/Certifier" enthalten ist.
    2) sind die User mit dem vollqualifizierten Namen eingetragen? Also: "Lieschen Mueller/Certifier" oder einfach nur "Lieschen Mueller".

    Für einen kleinen Workflow (Usermanagement) benötige ich die Möglichkeit, via @mailsend ein Reply vornehmen zu können.
    (...)Wie sieht die Formel "funktionstüchtig" aus? Hab da noch nichts zu gefunden.

    Wirklich? In dem Falle versuche es mit How to Use LotusScript to Programmatically Create a Reply Message with an Attachment.


    Dann gleich die nächste Frage .. bezüglich Ein- und Ausblenden von Designelementen (z.B einen Aktionsbutton, den ich nur den Mitgliedern einer bestimmten Gruppe zugänglich machen möchte ...) Ganz stumpfe Frage: wie geht das?

    Rolle in ACL erstellen, Rolle Gruppe zuweisen, Hide-When Formel verwenden: How to Write a Hide Formula.



    Zu beiden Fragen gibt nicht nur Google eine Reihe an Hinweisen, auch die Forumssuche hätte weiterhelfen können.