Beiträge von CarstenH

Es geht auch ohne Serverneustart:

(in einer nicht geclusterten umgebung)

console: tell sched quit
busytime.nsf löschen
console: load sched

Achtung: Der Scheduler kann jetzt eine ganze Weile brauchen bis die Info verfügbar ist, je nach Anzahl und Größe eurer Kalendernutzer kann das u.U. bis in den Stundenbereich gehen. Bei "normalgroßen" Umgebungen gib dem Prozeß mal 10 Minuten Zeit alles zu durchsuchen und einzutragen.

vorausgesetzt die busytime ist wirklich die ursache...meist ist das freizeitprofil eines nutzers der grund, bitte mal in dessen kalendervorgaben prüfen ob wirklich freie zeiten vorgegeben und der zugriff auf die freie-zeit-info nicht vom nutzer gesperrt wurde. alles in seinen vorgaben. diese werden vom scheduler gelesen. es sind nicht nur die kalendereinträge die vom scheduler gelesen werden.

Geht in der Kombination leider nicht über die Standard-Delegierung.

Mit einem Trick gehts trotzdem:

1. bei der GF in Werkzeuge->Vorgaben, Zugriff+Delegierung
2. Sekretärin eintragen, Recht "alle Mails lesen"
3. Ok, Dialog schließen
4. Datenbank->Zugriff (ACL öffnen)
5. Sekretärin dort zusätzlich das Recht geben "Öffentliche Dokumente schreiben"

Damit ist die gewünschte Kombination eingestellt. Achtung: Bitte die GF darauf hinweisen, daß mit dem Recht alle Mails lesen zu dürfen ebenfalls alle Kalendereinträge verbunden sind die das Häkchen "privat" haben. Bei ausschließlichen Kalenderrechten wäre dem nicht so.

Wenn die GF Mails bekommen möchte, die von der Sekretärin nicht gelesen werden sollen/dürfen müssen diese Mails verschlüsselt gesendet sein.

Wenn die GF selber Mails sendet, die die Sekretärin nicht lesen soll dann muß im Notesclient der GF der Haken "Gespeicherte Kopie der gesendeten Mail verschlüsseln" gesetzt sein (zu finden in den Benutzervorgaben des Clients).

$AssistMail="1" wird immer gesetzt wenn eine automatisierte mail generiert wurde. damit "erkennen" sich automatische mails und es wird gleichzeitig verhindert, daß sich 2 agenten dadurch gegenseitig endlos antworten zuschicken. dürfte tatsächlich bei dir das problem sein, denn alles andere hat ja funktioniert.

kommt drauf an ob das c:\temp im quellcode der website-agenten fest verdrahtet ist oder ob das das reguläre temp-verzeichnis ist. ohne temp-verzeichnis dürfte es sowieso probleme geben, da der server zwingend eine stelle braucht wo er temporäre dinge ablegen kann.

Für das Signieren sollten Designerrechte ausreichen - allerdings sind Managerrechte natürlich auch ok ;=)

Es wird nicht simpel im Personendokument "eingestellt" sondern da läuft ein wenig mehr ab, u.a. müssen vom Administrationsprozeß die Userverzeichnisse mit den zu roamenden Datenbanken generiert werden etc.

Schau in die Admin-Hilfe unter:
"Nicht-Roaming-Benutzer in Roaming-Benutzer ändern"

Dort steht was da eigentlich passiert und welche Voraussetzungen benötigt werden.

Wir sollten einen Wochenpreis für besonders lustige oder interessante Posts einführen...für diese Woche nominiere ich dann gleich mal die Wortschöpfung Kreuzzertifizierung

Früher hieß das mal Querzulassung, seit einiger Zeit nun aber schon Gegenzertifikat. Aber ok ;=) Das kommt aus der PKI-Schiene, bei Notes heißt das (noch) anders.

Ganz ohne Gegenzertifikat geht das Ganze nicht. Mindestens eine Seite muß ein Gegenzertifikat ausstellen sonst geht gar nichts.

Wenn ihr die Kontrolle über eine Seite habt dann zertifiziert simpel die fremde Organisation gegen. Dann können auch die ID's der fremden Organisation bei euch in Gruppen etc aufgenommen werden. Personendokumente sind eigentlich nicht notwendig, wenn das Mailsystem weiterhin auf der anderen Seite genutzt wird.

PS: Sorry für die Nominierung des Wortes *gg*

Das muß innerhalb der Anwendung verhindert werden, z.B. durch leicht unterschiedliche Rechte oder Masken etc. Hängt von der Anwendung ab. Man kann sogar eine selektive Replik auf Server 2 in Betracht ziehen die die Anhänge gar nicht mehr enthält.

Dem Server selbst würde ich nicht versuchen Rechte in Verzeichnissen zu entziehen, mit sowas riskiert man böse ServerCrashs...

In den 5er Releases wurde bei "Sign all Designdocuments" eine fest verdrahtete Auswahl von Elementen signiert, und die auch nur, wenn der letzte Unterzeichner des Elements nicht bereits die Person war, die die neue Signatur erzeugt.

Wurde mit einer der ersten 6er Versionen gefixt. Mit dem 6.5er Client könnte es insofern klappen (außer wenn man die Server-ID nehmen möchte, das klappt nicht weil die ja vom 5er Server ausgeführt werden würde)

Das einzige Problem mit einem parameterlosen compact -a ist die Tatsache, daß der Compact dann alles ohne Kontrolle archiviert wo es irgendwer (vielleicht auch nur spaßeshalber) eingetragen hat. Viele testen sowas in irgendwelchen DB's und da ja ohne compact -a nichts passiert denken sie "hmm, geht nicht" und vergessen daß sie diese Einstellung mal irgendwann gemacht haben.

Wird jetzt irgendwann Monate später ein globales compact -a gefahren dann passiert mit einem mal doch was...ohne daß derjenige noch damit rechnet.

Da man in den Archivierungsoptionen auch einstellen kann "Löschen OHNE Archvieren" könnte das ggf. tödlich sein...

Also: globales Archvieren nur nach vorheriger Kontrolle aller DB-Archivierungseinstellungen ;=) Wenn Dokumente weg sind warst DU es schließlich...und wenns erst nach etlichen Tagen/Wochen wer merkt dann hast sicher nichtmal mehr das passende Backup

Zitat

Änderungen an Agent könnten verloren gehen, weil sich die Master-Kopie von Agent in einer anderen Schablone befindet...

dieser Text weist darauf hin, daß die Datenbank ihr Design von einer zentralen Vorlage erhalten hat und mit dieser Vorlage weiter verknüpft ist. Änderst du irgendwas an der Datenbank wird das vom Domino mit dem nächsten Lauf des Design Tasks wieder überschrieben. Steht eigentlich exakt so da und ist exakt so zu verstehen. Sozusagen eine Warnung: Alles was sie ab hier ändern kann umsonst sein wenns in der kommenden Nacht wieder rückgängig gemacht wird.

Im Klartext: Nein daran liegts nicht wenn der oOo bei dir nicht das richtige tut.

Zitat

(Agent öffnen, Quellcode anschauen)

das bezog sich nicht darauf daß du dir den quellcode auf fehler anschauen sollst sondern daß man die infos was der agent tut nur anhand des quellcodes nachvollziehen kann. damit du dir diesen nicht selber anschauen mußt habe ich ja bereits im klartext unter c) beschrieben was da abläuft.

deine kontrollaufgabe besteht jetzt darin, für deine testmail jeden der von mir aufgeführten punkte einzeln aus- oder einzuschließen.

sinngemäß: mail kommt von A an B. B hat oOo-Agent von heute bis morgen aktiv.

Prüfung der 1. Aussage:
- ignoriere alle mails deren datum vor dem ersten tag der abwesenheit liegen*
Ergebnis:
- mail von A kam heute (also Aussage FALSCH)
- im oOo-Profil steht heute als erster Abwesenheitstag (also Aussage FALSCH)

Prüfung der 2. Aussage:
- ignoriere alle mails von anderen ooo bzw. generell von agents erzeugte mails
Ergebnis:
- mail von A wurde von ihm selbst geschrieben (also Aussage FALSCH)

Prüfung der 3. Aussage.... usw.

Wenn alle Aussagen FALSCH liefern kommst du irgendwann bei der Zeile "Mail erzeugen" an, ab da mußt du das Router-Log und das allgemeine Log (Verschiedene Ereignisse) checken ob die Mail oder der Agent erwähnt werden. Du kannst auch (z.B. abends) den Router simpel stoppen bis der Agent gelaufen ist und die Mail dann in der/den mail.box(en) suchen.

Im allgemeine Log (Verschiedene Ereignisse) suchst du weniger nach der Mail als mehr nach Ausschriften wie "...nicht berechtigt" o.ä. da für den Mailversand oder bestimmte Aktivitäten des Agenten unterschiedliche Rechte gebraucht werden.

Ich nehme die Einstellungen mal für dich auseinander:

(* und ** hinter den Einstellungen beachten, werden weiter unten erläutert)

a) im Agent-Zeitplan:
(Agent öffnen, Eigenschaften, Laufzeit, Zeitplan)
-------------------------------------------------------
- starte 1x täglich um 01:00 nachts (vorgabe bei R4+R5, kann im agent-design im zeitplan geändert werden)

b) im Agent-Ziel:
(Agent öffnen, Eigenschaften, Laufzeit, Ziel)
---------------------------------------------------
- arbeite alle mails ab die seit dem letzten lauf (oder der aktivierung) hinzugekommen sind

c) im Agent-Quellcode (Script):
(Agent öffnen, Quellcode anschauen)
--------------------------------------------
- ignoriere alle mails deren datum vor dem ersten tag der abwesenheit liegen*
- ignoriere alle mails von anderen ooo bzw. generell von agents erzeugte mails
- ignoriere alle mails die sich der user selber geschickt hat
- ignoriere alle mails von absendern die im ooo-profil als nicht zu beantworten angegeben wurden*
- ignoriere alle mails von absendern die bereits einmal eine ooo-nachricht seit dessen aktivierung bekommen haben**
- beantworte alle mails deren kriterien nicht zum ausschluß geführt haben und füge absender der liste im profildokument hinzu

* wird vom User im Abwesenheitsprofil angegeben
(Mail-DB des Users, Aktion Abwesenheit [Text unterscheidet sich zwischen Notesversionen, gemeint ist die Stelle an der der User den Abwesenheitsagenten konfiguriert und den Zeitraum eingibt])

** Liste wird in separatem profildokument geführt und mit jeder aktivierung wieder gelöscht und neu begonnen. Dieses Dokument kann ggf. mit Tools wie NotesPeek (zu finden unter http://www.notes.net in der Sandbox) gelesen werden.

Mehr Infos gehn jetzt wirklich nicht mehr dazu. Das kann so schon fast in die FAQ, wenns nicht für jede Notesversion leicht unterschiedlich wär ;=)

Einfach setzen und gleich wieder auslesen ;=) Das liefert die Information ganz sicher ;=)

Die Log's passen nicht zusammen - das Agentlog ist von 10:37 und das Maillog von 8:16 insofern kann das nicht stimmen?!

Es gibt keinen "Befehl" den man dem Agenten geben kann, der Agent ist eine Scriptroutine die keinerlei Parameter annimmt sondern immer nach seinem programmierten Schema abläuft.

Wenn du die Punkte aus meinem anderen Topic einzeln durchgehst und prüfst (immer JA/NEIN dahinterschreiben, so als wärst du der Agent) kommst du sehr schnell auf potentielle Fehler. Beachte dabei auch, daß der Agent von der Aktivierung an jedem Absender nur 1x eine Antwort schickt, ein zweiter Test mit der gleichen Mailadresse klappt nur wenn man den Agenten erst de- und dann wieder aktiviert. Steht aber auch in dem oOo-Topic. Schrittweise prüfen dann findet man die Ursache eigentlich schnell.

stimmt *g*

nehme den punkt dann mal zurück da ich mich von seiner frage nach dem serverprotokoll hab irreführen lassen ;=)

sorry about - nobody is fehlerlos *g* im feinsten d-inglish

Nein, ich meinte nicht das Serverprotokoll sondern (wenn du es nochmal liest bitte) das Agentprotokoll (Agent->Protokoll) das via Designerclient für jeden Agenten eingesehen werden kann.

Aber da in deinem Serverlog ja nun schon genug zu sehen ist, wissen wir daß der Agent gelaufen ist.

Das "Hinzufügen zur Liste" in deinem Log läßt auf einen korrekt arbeitenden Agenten schließen, wenn du dir unter meinem letzten Link nochmal die Arbeitsweise des oOo anschaust tut er das nämlich nur, wenn eine entsprechende Beantwortung stattgefunden hat. Ob die Mail rausgegangen ist hängt vom Router ab (Mailverfolgung falls aktiviert durchführen bzw. sonst Mailprotokoll zur entsprechenden Zeit im Serverlog checken). Weiterhin solltest du (wie ebenfalls schon von mir angesprochen) das Außer-Haus-Profil checken, denn dort könnte der Nutzer ja den Haken gesetzt haben, an bestimmte Domänen keine oOo-Nachrichten zu versenden. Stand also eigentlich alles da, prüfe das so bitte schrittweise damit nicht alles doppelt gepostet werden muß was schonmal dastand.

Einziger "Trick" der mir ohne Tools einfällt wäre die Kennwortänderung im Browser zu verbieten (Konfigurationsdokument) und den Nutzer somit zu zwingen das per Notes zu tun. Dann wäre ein identisches Kennwort sichergestellt.

Problem ist ja sonst, dem Nutzer die Kennwortänderung nur zu erlauben, wenn dessen Workstation oder die gespeicherte ID permanent zur Verfügung steht, dann könnte man evtl. mit der API in Verbindung mit der DSAPI was tun.

Also für die Umstellung 4->6 muß der Client auf MESZ (CEDT) gebracht werden, also der Sommerzeithaken (und damit verbunden NOTES.INI und korrekte Windowszeitzone). Danach sind alle Einträge auf Zeitzone zu prüfen und alles was im Kalender an Einträgen zwischen dem 1. und letzten Tag der Sommerzeit liegt muß per Script auf MESZ gebracht werden. Dabei ist die Verschiebung der Einträge zu beachten die im gleichen Script zu erfolgen hat.

Wenn alle Einträge korrekt mit MEZ (CET) und MESZ (CEDT) versehen sind kann die eigentliche Umstellung reibungslos erfolgen (sofern auch das Windows beim Nutzer die Sommerzeit aktiv hat).

Zur DER Frage ;=) Der Agent besteht aus 2 Teilen, nämlich ein Teil vor und ein Teil nach der Umstellung. Zu dem Agenten gehören mehrere Protokolldatenbanken und Mails in denen der User auf Knöpfchen drücken muß (da die Umstellung mit seiner ID auf dessen Client läuft zu einem Zeitpunkt der dem User paßt). In den Scripten sind noch viel mehr Dinge drin als du brauchst, da mein Kunde zeitgleich eine Migration seiner Mitarbeiter auf einen anderen Certifier in einer neuen Domäne wünschte und gleichzeitig auf die alten Server noch für Altanwendungen weiter zugegriffen werden mußte. Da gabs mit Verschlüsselung, Signaturen und Berechtigungen einiges anzupassen. Insofern ist das ganze so für dich nicht verwendbar. Dazu kommt, daß der Kunde die gesamte Programmierung und Migration bezahlt hat und das Ergebnis sein geistiges Eigentum ist das ich damit nicht weitergeben darf und werde selbst wenn die Sachen nach 2 Jahren die das her ist noch in irgendeiner Form vorhanden sein sollten (sorry aber so sind die Regeln).

Sind in dem entsprechenden Orndernamen Umlaute bzw. Sonderzeichen verwendet worden? Wenn ja, einfach mal umbenennen bzw. Ordnernamen kürzen, auf deutsch migrieren und dann versuchen zurückzubenennen.

Die Prüfmethoden für Agenten sind sehr spezifisch, insbesondere weil es Vordergrund- (Clientausführung) und Hintergrundagenten (Serverausführung) gibt. Man kann einen Hintergrundagenten unter R5 nicht ohne weiteres schrittweise testen, das ist erst ab ND6 mittels servergestütztem Agentdebug möglich.

Insofern ists sehr schwierig (aber sicher nicht unmöglich) eine allgemeine Testanleitung zu liefern.

Bei Hintergrundagenten ist es sinnvoll, zunächst den tatsächlichen Status im Agentprotokoll nachzuschauen (Designerclient, Agentprotokoll) Dort erfährt man ob der Agent seit der Aktivierung bereits gelaufen ist. Alles weitere ergibt sich dann aus dem Ergebnis.

Wie hast du den oOo-Agent denn getestet und wie sind die Einstellungen im Abwesenheitsprofil sowie welche Ausführungszeit und welcher Ausführungsserver stehen im Agenten?