Beiträge von cybermike

Für die eine oder andere Frage recht nützlich: Penetration: from Application down to OS

Ich war mir sicher, dass dies jemand in seiner Umgebung nachstellen kann, aber egal.

Das Traveler Support Team arbeitet wirklich flink: APAR LO72995
Es wird ein UP2 (publiziert wird das morgen am 11.12.) geben, mit einem HF.

Zitat von taurec

Darf ich mal raten: Ihr habt auf dem Traveler Server genau ein GlobalDomain Dokument mit allen Domains drin ?

Nein, absolut nicht. So eine Konfiguration hab ich auch noch nie gesehen.

Eigentlich wollte ich nur wissen, ob das von euch jemand nachstellen kann/konnte. Aber scheinbar sind wir wieder mal die einzigen weltweit, die auf ein gravierendes Problem gestoßen sind.

Mittlerweile haben wir einen Workaround zusammen mit dem Support gefunden:

Man kann das Caching am Server deaktivieren, indem man in der NTSConfig.xml den Parameter <PROPERTY NAME="TSS_ADDRESSCACHE_ENABLED_AS_MAIL" VALUE="false"/> setzt.
Natürlich ist Vorsicht geboten, der Server muss bezüglich Performance beobachtet werden, da der Lookup beim MailSync nicht mehr über den lokalen Traveler Cache ausgeführt wird!

Lt. Support wird an einem geänderten Caching Verhalten in einer neueren Version gearbeitet. Auf Empfehlung des Supports sollten wir auf die neue UP1 Version (ohne HA und SQL DB) wechseln, dort wären mehr Issues gefixt als in der klassischen Variante. Weiters wurde uns ein "private" Fix angeboten - wir prüfen das gerade. Wenn in der UP1 Installation das Problem ohne obigen Parameter trotzdem gefixt ist, wird es definitiv einen APAR geben.

Zitat von taurec

Steht auf dem iOS Gerät dann die vollständige eMail Adresse oder der vollständige NotesName der Gruppe inkl Domain drin ?

Ganz genau, und zwar die vollständige eMail Adresse des Users, der den Alias "revision@kunde-b.com" hat.

Zitat von taurec

Wie sieht eure Adressauflösung auf dem Traveler Server aus ? Denn wenn er keinen besseren Treffer findet, dann versucht Notes eben einen genau so guten Treffer zu finden, in deinem Fall eben einen User.

Tja, genauso ist es auch - er nimmt den nächstbesten Treffer, egal ob das jetzt der wirkliche User ist oder nicht. Folglich wird das Mail beim Beantworten an einen komplett anderen User versendet - eine Katastrophe schlechthin, vor allem bekommt der User im Regelfall nichts davon mit.

Zitat von taurec

Im Endeffekt müsstet ihr wohl einerseits die vollständige Adressauflösung konfigurieren

?

Zitat von taurec

am besten die Gruppen ebenfalls mitaufnehmen

Absolutes No-Go (logische Gründe die dagegen sprechen siehe weiter oben)

Zitat von heuti

meines wissens nach darf der Traveler Server doch keinen Adresslookup machen, diesen muss er doch immer über den homemailserver des Anwenders machen.
Wäre ja bei einer Mehrmandanten Lösung eine Katastrophe, wenn Anwender der Dom A die Personen aus Dom B sehen und Adressieren könnten,

Prinzipiell hast du vollkommen recht. Aber der Traveler Server hat insgesamt 3 "verschiedene" Lookups:

1. User lookup: to find out who the user is, whether the Traveler server has ACL rights, home mail server, etc. This is required for any Traveler user.
2. Sync lookup: The Apple devices complain about any non-internet addresses, so Traveler attempts to convert any non-internet addresses to internet addresses. Because this is every address (not just those of Traveler users), it is a large number which caused to create a cache of the results so that people sending to the same addresses don't require a lookup all the time. To avoid possible differences between user's mail servers, this is only done on the Traveler server. When Traveler does this lookup, it will use the result if the lookup found exactly one result; any other result causes Traveler to leave the address alone.
3. Device lookup: where the user makes a request in mail, contacts, lookup, etc. to the server to do a lookup. This is done against the user's mail server (in this case it will find the group).

Und wir haben jetzt genau das Problem mit diesem 2. Lookup, mit dem "Cache". Habt ihr das in der Zwischenzeit mal ausprobieren können? Scheinbar verwendet hier keiner einen mandantenübergreifenden EDC...
Da die Mandanten miteinander kommunizieren dürfen/sollen ist das kein Problem. Es wird erst dann ein Problem, wenn eine via Notes eindeutig adressierte Gruppe beim Beantworten vom iOS Device plötzlich an einen ganz anderen User ergeht.

Lt. IBM Support wird in einem "future" Release am Adress-Handling gearbeitet. Nur benötigen wir JETZT eine Lösung, und da sieht es derzeit noch relativ schlecht aus

Zitat von RockWilder

"Revision" ins Shortname-Feld rein zu schreiben, sehe ich schon als "verbiegen" an. Da hat das nämlich sowas von gar nichts zu suchen.

Interessante Ansicht. Wieso darf ich bei einem Personendokument keinen SMTP Alias verwenden? Es steht beim Short-Name nicht "Revision" drinnen, sondern selbstverständlich die vollständige SMTP Adresse (nur um das klar zu stellen). Jeder User kann sich natürlich eine durch den Admin freigegebene Alias Adresse vergeben, das ist ja wohl gängige Praxis. Der "physische" Revisor in Person hat neben seinem "real" name auch einen SMTP Alias der eben "revision@kunde-b.com" lautet.

Zitat von RockWilder

Wenn ich an eine Gruppe schreibe, habe ich keine Domain hintendran. Jedenfalls, wenn ich eine NRPC-Mail schreibe.

Korrekt.

Zitat von RockWilder

Wenn dann ein Gruppenmitglied ein Reply schickt, wird halt im primary und allen weiteren DDs der Name gesucht, ohne den Suffix hintendran. Und wenn nun der (Teil-)String per Zufall in einem Personendokument gefunden wird, nimmt der Router halt an, dass das Dokument damit gemeint ist, erweitert die Adresse und verschickt die Mail halt da hin.

Stopp. Genau hier liegt der Wurm drinnen. Das Mail, welches am iOS Gerät angezeigt wird (ohne auch nur geanwortet zu haben), zeigt im Empfängerfeld bereits den Namen des Revisors von Kunde B an! Dass eine Antwort natürlich auch an diesen gesendet wird ist klar. Ich würde jetzt trotzdem gerne wissen, wer das nachstellen kann - es ist wirklich sehr einfach. Einfach eine Person suchen (in einer anderen Domäne/Organisation im EDC), die einen Alias definiert hat (da gibt es sicher einige). Dann erstellt man eine Gruppe in Domäne A die sich exakt so nennt. Mail an diese Gruppe senden und am iOS kontrollieren - Überraschung

"Verbogen" ist eigentlich nichts, sind ganz normale Personendokumente von allen Kunden in einem EDC zusammengefasst, ein ganz gewöhnliches Directory für Mailing eben.
Es sind nur die Gruppen der Kunden nicht includiert, da

1) nicht notwendig, da die Gruppe ja trotzdem via Notes adressierbar ist (bei Antwort incl. Domänezusatz, oder neuer Mail durch manuelles Hinzufügen der Domäne)
2) viele Gruppennamen redundant und somit unübersichtlich wären (mit unterschiedlichen Members natürlich)
3) interne Gruppen für domänenübergreifendes Routing eigentlich nicht benötigt werden

Der AddresscacheManager darf nicht nur den local part der Adresse checken, sondern muss auch den global part berücksichtigen!
"Revision" ist ja nicht dasselbe wie "revision@kunde-b.com", sofern er auf den ganzen String antwortet. Das Mail wird ja ohnehin vom Home-Mailserver versendet, aber der Lookup wird aus performancetechnischen Gründen vorher im Traveler AddressCache durchgeführt, in meinen Augen aber nicht vollständig korrekt.

Ist ja auch egal, interessant wäre jetzt, ob jemand das Verhalten bestätigen kann. Reproduziert ist dies relativ schnell.

Hallo werte Community,

ich würde gerne wissen, wer einen Traveler Service für mehrere Kunden betreibt (Hub) und folgendes beschriebene Verhalten bestätigen kann.

Konfiguration:

- aktuelles 8.5.3.3.1 Release (klassische Version), Domino 8.5.3.3
- EDC (Extended Directory Catalog) eingebunden (beinhaltet mehrere Domänen/Organisationen)
- Traveler Service steht in einer eigenen Domäne

Ich möchte jetzt wissen, ob wir wieder weltweit die einzigen sind (mit dieser Konstellation), die von einem gravierenden Problem betroffen sind.

Wie lässt sich das Problem reproduzieren?

1) Kunde A schreibt ein Mail an eine interne Gruppe "Revision"
2) Mail wird korrekt via Notes an die Gruppenmember zugestellt und in weiterer Folge an deren iOS Geräte
3) Einer dieser Gruppenmember schickt jetzt ein Anwortmail von seinem iPhone/iPad mit der Option "An Alle" (das ist der springende Punkt!)
4) Die Antwort geht jetzt korrekterweise an den Absender retour, zusätzlich aber an die SMTP Adresse "revision@kunde-b.com" - und leider nicht an die Gruppe "Revision" in der eigenen Domäne!

Normalerweise sollte die Antwort zurück an die Gruppe "Revision" gesendet werden.
Der Traveler AddressCacheManager findet die Adresse "Revision" aber als SMTP Alias Adresse beim Kunden B(!) - da der Revisor des Kunden B ein Alias "revision@kunde-b.com" in seinem Personendokument eingetragen hat.
Achtung, die internen Gruppen der einzelnen Mandanten befinden sich logischerweise NICHT im EDC (nur Personendokumente) - was auch nicht umsetzbar wäre.

Das einzige was ich jetzt eben wissen möchte ist, ob ihr (sofern selbe Konfiguration aktiv) dasselbe Verhalten nachstellen bzw. bestätigen könnt.
Meiner Erfahrung nach tritt das Problem erst seit der Gruppenünterstützung in 8.5.3 auf.

Der normale iOS User bekommt von dem Verhalten meist nichts mit, erst wenn sich der falsche Empfänger meldet
Und wenn sich die involvierten Gruppen dann Geschaeftsleitung, Innenrevision, usw. nennen, dann ist das schon weniger lustig

Mir geht es im Speziellen jetzt nur darum, dass IBM dies publizieren muss - PMR Prio 1 läuft schon.

Danke für euren Input.
Michael

Wir konnten selbes beobachten! Bin seit Version 4.6 Admin, hab derartiges aber noch nie in einer Version festgestellt. Fakt ist, es muss bei der Umstellung von 8.0.x auf 8.5.0 bzw. 8.5.1 passiert sein. Vor 2-3 Monaten wurde umgestellt, letzte Woche hatten zeitgleich 3 User plötzlich 20-30 alte Dokumente in der Inbox (die definitiv schon gelöscht wurden) - aber nur auf einer Replik! Das Datum dieser Dokumente datiert genau auf den den Umstellungstermin. Meine Vermutung -> während der Migration von oben erwähnten Versionen (kurzfristig 2 verschiedenen Versionen!) gab es in der Clusterreplikation wohl einen Bug. Nachdem sich das Problem aber in Grenzen hält, haben wir keinen PMR eröffnet.

Wir haben den Agenten seit 3 Monaten auf "Nach Eingang neuer Mail" --> absolut keine Probleme (Useranzahl ~400)

In größeren Umgebungen würde ich allerdings davon abraten, auf "sofort" umzustellen.

Guckst du hier ;)

Zuhause hast du vermutlich SP2 installiert und in der Firma nicht. Naja, auf jeden Fall wird dir in obigem Thread geholfen.

Ok, dann ist alles in Ordnung. Es muss natürlich auch ein 6.5.4 Server sein, erst in diesem Release ist dieser Bug gefixt (reiner Serverbug).

6.5.4 Client und Server und selbes Problem? Ich hab hier leider keinen im Einsatz zur Zeit. Aber wenns so wäre, sollte man denen das mitteilen :roll:

Zitat

Ausserdem können User mit "Manager" Rechten auch nicht Ihren OOO Agenten aktivieren.

In der Admin4 sind dann Requests erschienen.
Aber nur ein User. Er hat angeblich keine Berechtigung auf dem Server Lotus Scrip/Java Agenten auzuführen.
(Da müssten doch dann alle User drin stehen oder?)

In der admin4 sollten dann alle User drin stehen, die versucht haben, den OOO zu aktivieren.
Sieht mir aber eher nach einem Berechtigungsproblem aus. Wenn der einzelne User kein Recht hat, gilt dies sicher für die anderen auch. Füge mal in den Felder "Run restricted LotusScript/Java agents" und "Run Simple and Formula agents" mit Wildcard deine Organisation hinzu. Vielleicht gibts Probleme mit der Gruppe die drin steht etc. Wenn der Server und die Admin ID berechtigt sind, dann kanns nur an den Berechtigungen liegen.

Jetzt kommen wir der Sache schon näher . Prüf mal, ob Default "Einlieferer"-Rechte in der ACL der admin4.nsf hat. Die User mit Editor Rechten in ihrer ACL stellen dort nämlich die Anforderungen zur Aktivierung des Agenten rein. Frag mich jetzt ja nicht, wieso das seit dem Update nicht mehr funktionieren soll.

In der Admin4 sollten dann Requests auftauchen die wie folgt lauten:

Ansicht: Requests - All Requests by Action - Set User Name and Enable Scheduled Agent

Dort steht dann der Servername drin, und der User, der bearbeitet wird.

Einfach mal prüfen.

Ganz nebenbei, den Server brauchst nicht zusätzlich in den Security Feldern angeben, der ist per Default berechtigt. Wenn, dann eventuell nur im Feld "Administrators".

Also bestehende aktivierte OOO Agenten laufen nicht mehr?
Oder gilt dies nur für frisch aktivierte Agenten?
Haben die User auf ihre Maildaten in der ACL Entwickler oder Editor Zugriff?

Stimmen die Securityeinstellungen noch? Check mal, ob User Agenten ausführen dürfen:

- Run restricted LotusScript/Java agents
- Run Simple and Formula agents

Hier sollte die Organisation mit Wildcard drin stehen (z.B: */Org/DE)

PS: Hast du das Log mal kontrolliert, ob Fehlermeldungen generiert werden?

Ja, du kannst den FP1 installieren, egal welches Language Pack installiert ist. Auch wenn noch kein LP installiert wäre, ist es dir überlassen, ob du zuerst das LP oder den FP installierst. Dies ist aber erst seit Version 6.5.4 so!!
Bei den vorherigen Versionen musste man das LP nach einem FP immer nachinstallieren - ist jetzt definitiv *nicht* mehr so. Der LP Installer erkannte die gepatchten Versionen nicht, darum immer die Probleme.

An den Vortrag von Stephan Waltl werd ich mich wohl noch länger zurückerinnern, der war erste Sahne!

"Wer bitte will den Workplace Client, NIEMAND"

Diesen äußerst lästigen Bug gabs erstmals unter Version 6.0.2 CF2 - gemeldet damals im BPF 2003 - aber anscheinend nicht reproduzierbar lt. IBM/Lotus. :lol:

Jedenfalls hab ich dann erneut im Oktober einen PBR im BPF 2004 gepostet, wieder mit derselben Version 6.0.2 CF2 English. Auf einmal war der Fehler reproduzierbar *lol* - pending Fix in 6.0.5/6.5.4 (befindet sich übrigens grad im "Gold Candidate" Status).

Aus der Fixlist Database 6.0.5/6.5.4:

SPR# TGUZ5YAQP4 - The Admin client will no longer display the Full Text Index directories when displaying Notes only files.
This will improve the display time for the file panel contents when connected to servers with a
large number of full text indexed databases.

Und jetzt wieder in ND7? :cry:

Den Vorschlag von Thorsten solltest du dir zu Herzen nehmen, ein besseres Prozedere gibt es eigentlich nicht. Aja, so nebenbei: Bei deinem Weg würdest du ja die alten Maildatenbanken (die vorher entschlüsselt wurden) auf den Neuen kopieren. Das hiesse ja gleichzeitig, dass du die ACL aller 150 Maildatenbanken manuell auf die neuen Namen ändern müsstest :roll: (da nutzt dir auch kein ACL Manager im Admin Client)

Ist nur ein Ratschlag von jemanden, der Domänen/Organisationsänderungen bereits hinter sich hat (natürlich über den professionellen Weg)

In diesem oder einem anderen Forum gibt es auch etliche Threads, in denen die genaue Vorgangsweise genauestens erklärt wird.

Viel Glück