Praktisches Beispiel

Ist doch gut erklärt ....

- Agenten signieren, die im Namen anderer ausgeführt werden:

Geben Sie die Namen von Benutzern und Gruppen ein, die Agenten signieren dürfen, die im Namen anderer ausgeführt werden. Standardmäßig ist dieses Feld leer, d. h. niemand kann Agenten auf diese Weise signieren.
Hinweis Diese Berechtigung sollte vorsichtig verwendet werden, da der Name, für den der Agent im Namen anderer signiert wird, zum Prüfen des ACL-Zugriffs verwendet wird.

- Agenten signieren, die im Namen des Agent-Aufrufers ausgeführt werden:

Geben Sie die Namen der Benutzer und Gruppen ein, die Agenten signieren dürfen, die im Namen des Aufrufers ausgeführt werden, vorausgesetzt, der Aufrufer unterscheidet sich vom Agenten-Unterzeichner. Diese Einstellung wird ignoriert, wenn es sich beim Agenten-Unterzeichner und Aufrufer um dieselbe Person handelt. Diese Einstellung wird derzeit nur für Web-Agenten verwendet. Standardmäßig ist dieses Feld leer, d. h. jeder kann Agenten signieren, die auf diese Weise aufgerufen werden (für die Abwärtskompatibilität).

- Script-Bibliotheken signieren, die im Namen anderer ausgeführt werden:

Geben Sie die Namen von Benutzern und Gruppen ein, die Script-Bibliotheken in Agenten signieren dürfen, die von einer anderen Person ausgeführt werden. Zum Zweck der Abwärtskompatibilität ist das Feld standardmäßig leer, d. h. es werden alle Benutzer und Gruppen zugelassen.

Ok, nehmen wir an, Lieschen Müller ist plötzlich krank geworden. Nun soll ihr OOA scharf geschaltet werden. Bisher bist du mit deiner ID dran gegangen (wenn du ihn aus ihrer Mailbox aktiviert hast), mit einer Admin.ID (dito), oder mit der Server.ID (wenn du die DB unterzeichnet hast, bzw. auf einem Windows-Server den Notes-Client genommen hast). Das kannst du dir in 6 sparen. Jetzt kannst du aus einem Agenten heraus einen anderen speichern (und damit unterzeichnen). Damit läuft der OOA immer noch on behalf of (im Namen von) Lieschen Müller, ist aber mit z.B. der Admin.ID unterzeichnet. Hat den großen Vorteil, der Sender einer Mail bekommt die Nachricht nicht mehr von "DB-Admin" (oder wie auch immer euer Admin heißt), oder vom Server, sondern von Lieschen Müller. Und wer nun den Agenten per Script scharf schalten darf, geben diese Felder an.

Ok, ich gebe zu, der OOA ist ein konstruiertes Beispiel, da auch noch das Profildokument angepasst werden müsste, aber das Prinzip jedenfalls stimmt...

Ein anderes, etwas praktischeres Beispiel. Wir alle kennen den "Update Tasks"-Agenten, der Aufgaben als fällig oder überfällig markiert (einzustellen in den Vorgaben unter "Calendar & To Do -> To Do"). Wir haben uns in unserer Umgebung drauf geeinigt, dass dieser Agent nun auf dem sekundären Clusterpartner zu laufen hat.

Nun war es so, dass wir alle von unterschiedlichen Mailservern kamen und dieser Agent nun so umgestellt werden musste, dass er auf dem Clusterpartner des jeweiligen Mailservers des Users lief. Hier würde nun ein Agent ins Spiel gekommen, der entweder mit meiner ID, mit der Server.ID oder mit einer sonstigen ID unterzeichnet ist. Dieser Agent nudelt nun sämtliche DBs durch und schießt den Agenten so um, dass er auf dem Clusterpartner läuft.

Ich gebe zu, der Faulheit wegen habe ich lieber den Agenten in der Mailschablone umgebogen und den Design-Taks gestartet :lol: Vorteil: 10 Sekunden Arbeit. Nachteil: bei 4 Mailserver (+ Clusterpartner) liegen 4 Mailschablonen rum, die nachträglich wieder zurückgestellt werden mussten :hammer:

Zugegeben: mit dem "Run on behalf of..." habe ich mich erst jetzt im Zuge dieses Threads ernsthaft auseinander gesetzt. Aber besser später ne gute Idee, als gar nicht :roll:

/edit:
der Agent läuft immer auf dem Server, auf dem die DB offen ist, in der der Agent aktiviert wird. Will man nun wirklich sauber bleiben und sicherstellen, dass der Agent immer nur auf dem selben Server läuft, kann man ja eine Art "Kontrollagent" schreiben, der nachschaut wo der Agent scheduled ist und ihn ggf. umschießen