statistic report DB - fehlermeldung - resource archiv

[luna]

hallo,

ich hab eine kopie meiner resource datenbank erstellt, damit ich alle resourcen von 2002 aufheben kann. das muss ich jedes jahr machen (damit man sieht, wer wann welches auto hatte usw.).
den agent, die dokumente nach x tagen zu loeschen, hab ich deaktiviert.

nun macht aber diese kopie taeglich tausend eintraege in meiner statistic report datenbank (monitoring results), wie z.b.:

Error validating user Badminton/Sports/Munich while processing calendar appointment (NoteID: NT00003C32) in database sanyo\resbup02.nsf: Cannot find user in Domino Directory

oder

Error validating user Pana Board Training/Equipment/Munich while processing calendar appointment (NoteID: NT000010EA) in database sanyo\resbup02.nsf: Cannot find user in Domino Directory

ich kann aber nix finden, in der kopie, was das ausloest. diese DB soll einfach nur dokumente "aufheben" und anzeigen, aber ansonsten ruhe geben.

was kann ich tun, damit die DB nix mehr macht? ich kann nix finden.

danke und gruss,
daniela

[Semeaphoros]

Stell mal den Typ der Datenbank auf normale Datenbank (erster Reiter der Datenbank-Eigenschaften, wenn ich mich nicht irre). Wahrscheinlich steht der auf Mail-File

[koehlerbv]

Datenbanktyp <> "Mail" ? Habe ich hier was verpasst ? Wo steht denn das in den Properties ? Ich glaube, ich muss nochmal auf die Schulbank ...

Ich habe das Problem bisher leider immer nur oberflächlich beobachten (und jeweils beheben) können und kann daher nur ein paar Ansätze bieten:
Verantwortlich für das Problem ist die Scheduler Task, die offensichtlich in DBs nach bestimmten Items sucht und dann daraus schliesst, dass es sich um Kalendereinträge etc. handelt.
Folgende beiden Fälle sind mir besonders gut in Erinnerung:
- Ein "Manager" (die besonders "Schlauen" mit der dicken Brieftasche) meinte, er müsse mal im CalendarProfile seinen Namen nach seinem Gusto anpassen. Alle späteren Kalendereinträge führten zu einem Eintrag wie von "unserem lieben Mond" beschrieben (off-topic: Luna, ich wäre so gern koFr nach Minge gekommen ...). Der Schrott stand dann in seinen Kalendereinträgen in Feldern (habe mir leider nicht alle gemerkt, differierte auch von Doc zu Doc) wie "$BusyName" - alle anderen hatten jedenfalls auch alle mit "Busy" zu tun. Nach dem diese Items per Agent auf den richtigen (Notes-)Name korrigiert waren, passte wieder alles.
- Letzte Woche dann folgender Hammer: Unser Star-Admin beim Kunden, der Rest vom Schützenfest nicht gerade helle in Notes (eben Spezies auf anderen Gebieten). Und dann hebelt es einen unserer (Notes-)LDAP-Server aus (nette Fehlermeldung, die eigentlich nie auftreten sollte: "Error loading LDAP Schema". Wenn jemand mal das Problem hat, findet er hoffentlich über die Suche dieses Posting und fragt mich dann ;-) Habe aber heute keinen Bock mehr, auch das noch aufzumalen ;-)  Also musste ich ran, und während der ganzen Aktion finde ich doch im Log des betreffenden Servers einen Eintrag wie von Luna beschrieben - aber stammend aus der NAMES.NSF des LDAP-Servers !!!
Des Rätsels Lösung - und die ist wirklich mehr als skuril: In der NAMES.NSF steckte von einem längst ausgeschiedenen Mitarbeiter - das KALENDERPROFIL !!! Wie immer das da auch 'reingekommen ist (wir haben uns aber in den letzten Jahren von ein paar "Fachkräfte" trennen müssen ...) - auch das Kalenderprofil enthält derartige Felder, die der Scheduler offensichtlich "aufreizend" findet ...

So, langer Rede, kurzer (Un)Sinn: Wenn jemand keinen Trick weiss, wie man den Scheduler von bestimmten DBs fern hält, wird sich eben dieser immer an Dokumenten in irgendwelchen DBs verlustieren, in den er $Busy... etc-Felder findet.

Über die Hintergründe würde ich mehr erfahren, bin ja nur ein "armer Programmierer" ;-))

Bernhard

[Semeaphoros]

Also, auf die Schulbank musst Du nicht. Das steht tatsächlich meines Wissens nirgends wirklich geschrieben.

Der Datenbanktyp ist auf dem ersten reiter (Basics) der Datenbank-Properties und da gabs in R4.6 grad mal etwa 4 oder 5 Einträge, früher nur grad 2 bis 3. In R5 ist da doch schon eine ganze Liste drin.

Ich vermute, dass der Scheduler diesen Eintrag ebenfalls zu Rate zieht, selber probiert hab ichs auch nicht. Wenn das nix hilft, dann müsste man wohl tatsächlich das Kalenderprofil entfernen.

Interessant zu wissen wäre, was Notes beim Anlegen einer Archiv-Datenbank so alles macht, denn da könnte so ein Problem ja auch mal auftreten.

[luna]

Stell mal den Typ der Datenbank auf normale Datenbank (erster Reiter der Datenbank-Eigenschaften, wenn ich mich nicht irre). Wahrscheinlich steht der auf Mail-File

hi,

also, der datenbank typ steht bei der resourcen backup datenbank auf Standard.

das tut er uebrigens bei mir auch in allen mail datenbanken, die stehen auch alle auf Standard.

gruss,
daniela

[luna]

Wenn das nix hilft, dann müsste man wohl tatsächlich das Kalenderprofil entfernen.

nachdem es am datenbanktyp nicht liegt, weil ja Standard, wie entfernt man so ein kalenderprofil?

ich meine, dieses problem ist ja nicht prio nummer voll high oder so, aber es stoert halt schon, wenn ich in meinem report jeden tag so einen unsinn drin stehen hab, sind ja nicht grad wenig eintraege. muss ja nicht sein.

danke und gruss,
daniela

[stoeps]

Ich denke das ganze Vorgehen ist etwas problematisch, bin mir nämlich nicht sicher, ob der Server mehrere Ressourcen-DBs sauber verwaltet. Macht eine allein schon genug ärger.

Ich muss jetzt kurz weg, schau aber nach was ich noch finde, hab mich schonmal damit befasst.

[Semeaphoros]

Kleines Script oder so .... bin aber im Moment auswärts, sonst würd ich jetzt grad mal nachschauen, aber wer anderes springt hier sicher in die Lücke

[koehlerbv]

Ich befürchte, die Sache mit dem Kalenderprofil bezieht sich auf meinen Erfahrungsbericht von gestern Abend.  Irgendein Dödel hatte ein Kalenderprofil in die NAMES.NSF kopiert - was ja kein einfacher User bewerkstelligen kann.
Bei Euch wird das wohl kaum der Fall sein.
Wie schon geschildert: Notes wird offensichtlich durch $Busy... Felder, die Du ja in jedem Reservierungseintrag hast, verwirrt, die man wohl in einem derartigen Archiv aus allen Docs entfernen müsste...

Bernhard

[Semeaphoros]

Dann wäre mal ein Blick mit NotesPeek in eine Resourcen-DB fällig, was da so alles drin steckt. Offenbar wird ja der DB-Typ nicht verwendet. Die Idee mit $Busy-Feldern ist wahrscheinlich gar nicht übel.

[luna]

dann mach ich mir einfach einen agent, der aus dieser datenbank aus allen dokumenten das $busy feld rausloescht?

das muesst ich doch hinkriegen, oder?  

gruss,
daniela

[koehlerbv]

Jetzt habe ich mich endlich mal aufgemacht und die KBase bemüht ... Siehe unten - ist ja alles sehr schön beschrieben ;-)

Bernhard




Title:   
      SchedMgr: "Error Validating User While Processing Calendar Appointment"
Product:
Platform(s):
   Lotus Domino  >  Lotus Domino Server  >  6.x, 5.x, 4.6x, 4.5x
      Platform Independent
      
Document Number:   1107085   Date:   17.04.2003



      
      
Problem
While viewing the Notes log, you see the following error message listed:

"Error validating user [user name] while processing calendar appointment (NoteID: NT000021AE) in database mail\[xxx].nsf: Can't find user in Name and Address Book"

What does this error mean and how can this be corrected?



Solution
The error has been noted to occur when using the Calendaring & Scheduling functionality of Notes Client and Domino Server.  When you create Calendar entries such as Appointments in your mail file, the entry from the $BusyName field of the Calendar Profile is input into the $BusyName field of each new Appointment.  The $BusyName is pulled from the "Owner" field which is the editable field at the top of the Calendar Preferences/Profile, labeled "Mail File Owner" or "This Mail File Belongs To".    The $BusyName field for the entry is not visible on the document, but can be seen by selecting File, Document Properties and clicking the Fields tab.

You will see no error when creating Calendaring entries, but the Schedule Manager will generate the above error in the log when it does the validation task.  An error will occur with a unique ID number for each calendar entry which holds an incorrect value in the $BusyName field.  The validation task normally runs at 2 AM; however, it can be forced manually by using the command TELL SCHED VALIDATE at the server console.

A simple agent can be used in the database from which the message is being received.  The agent will change the value of the $BusyName field from the old name to the new name.

The agent should be run from the "Meetings" view of the database.
The agent can be set to run "Manually from the Actions menu" on "All documents in view" or "Selected documents in view".
The agent should be a formula agent and set to "Modify documents".
The formula that can be used is:

FIELD $BusyName := "CN = New Name/OU = OrgUnit/O = Org"


Note: It is unlikely that this issue will occur if the proper procedures to change user's Notes names are used.

Supporting Information:

To accurately find what document is causing the problem, the administrator can use the NoteID Database Tool to analyze the Note ID number which is listed in the error message (for example, NoteID: NT000021AE).

To accurately find what document is causing the problem, the administrator can do the following:

1. Select File, Tools, Administration and click the Database Tools button.
2. Select the appropriate server and mail file that is causing the Schedule Manager to generate the error.
3. From the Tool box, select NoteID.
4. Type the alphanumeric characters that follow "NT", excluding the zeros.  For example, if the Note ID is NT000021AE, type 21AE.
5. Select Find.

The document that is causing the problem will then display.

This issue has been reported to Lotus Software Quality Engineering.

[Semeaphoros]

Heisst, wenn man so eine DB archivieren will, muss man das Feld aus jedem Dokument rauskratzen --- Ok, gut zu wissen ....

[luna]

hallo,

also, ich hab jetzt mit dem tip vom notes treffen nochmal in der hilfe nach delete field gesucht und folgendes gefunden:

FIELD $BusyName := @DeleteField;
SELECT @All

damit hab ich nur erreicht, dass das komplette dokument verschwunden ist.

dann hab ich's mal damit probiert:

@SetDocField($Ref; "$BusyName"; "");
SELECT @All

aber das tut gar nix.

dann noch damit:

FIELD $BusyName:=$BusyName;
@SetField("$BusyName";"")

damit hat's dann geklappt. jetzt ist das feld $BusyName in jedem dokument leer. jetzt muss ich nur noch abwarten, was der monitoring result morgen sagt, ob endlich ruhe ist, nach dem loeschen dieses feldes.

ich schliesse den call heute noch nicht, warte erst ab, was die monitoring DB morgen so sagt.

vielen lieben dank an euch alle !
gruss,
daniela

[luna]

hallo,

also, die fehlermeldung, mit der ich den thread eröffnet habe, kommt in der tat nicht mehr.

dafür die:

SchedMgr: Error processing appointment document (NoteID: NT00003C26) in database sanyo\resbup02.nsf: $BusyName item in appointment document is empty

was würdet ihr mir denn empfehlen, was ich das nächste mal machen soll? es ist ja in 3 wochen wieder aktuell, die datenbank von 2003 wegzusichern. und damit meine monitoring datenbank nicht wieder mit der einen oder anderen fehlermeldung überläuft?

ich könnte sie sicherlich lokal kopieren, und wenn einer was braucht, muss ich halt nachschauen. ist aber blöd, wenn ich in urlaub bin.

habt ihr irgendeine idee, wie ich die von 2003 wegsichern kann, ohne dass der server immer was damit machen will?

danke und gruss,
daniela

[koehlerbv]

Hm, $BusyName muss aus dem Dokument ganz 'raus - das Item an sich ist das Leckerli für den Scheduler.
Du schreibst, dass nach @DeleteField das Dokument ganz verschwunden sei. Kannst Du das nochmal erläutern ? @DeleteField haut ja nur das Item in die Tonne, nicht aber das Dokument. Nach einem kurzen Blick in Ansichten habe ich auch dort keinen Bezug auf $BusyName gefunden.

Bernhard

[luna]

hi bernhard,

ja, ich versuch's. ich hab den agent laufen lassen, auf einem bestimmten dokument. danach war das dokument aus der ansicht futsch ! hab's dann nochmal gemacht, vorher einen screenshot im psp geparkt, verglichen. das dok war wirklich weg. aus der ansicht "By Date". aber das duerfte ja egal sein.

dann hab ich mich natuerlich nimmer getraut, weiterzumachen.

ich hab das uebrigens jetzt gerade zum dritten mal ausprobiert, hab dann auch in der ansicht "ByResource" nachgeschaut. das dokument is nimmer da.

und jetzt weiss ich auch, warum !!!

in der selektion der ansicht steht:

& @IsAvailable($BusyName)

ich nehm das jetzt mal raus, und dann schau ich mal, was er anzeigt. melde mich gleich nochmal.

gruss,
daniela

[luna]

genau das war's !!! ich hab das aus der ansicht "ByDate" rausgenommen, und jetzt sind alle dokumente wieder da !!!  

ich lasse jetzt den agent, der das feld löscht, über alles drüberlaufen, und ab morgen müsste dann ruhe im karton sein, mit diesen blöden fehlermeldungen.

vielen lieben dank nochmal für eure hilfe !!!

gruss,
daniela

[luna]

hallo nochmal,

also, das mit dem agent hat ja jetzt geklappt. aber leider war das nicht die loesung fuer mein eigentliches problem. denn jetzt bringt er diese fehlermeldung:SchedMgr: Error processing calendar profile document (NoteID: NT0000094E) in database sanyo\resbup02.nsf: Can't find $BusyName field on profile
die fehlermeldung kommt jetzt weiterhin taeglich in die DB, hat nur einen anderen inhalt.

gibt es noch eine andere moeglichkeit, wie ich vermeiden kann, dass diese feherlemeldung mir die monitoring DB zumuellt?

vielleicht waere eine loesung, eine neue, leere DB zu machen, mit nur den paar feldern, die man braucht, um sich aus history gruenden diese dokumente noch ein jahr anzeigen zu lassen? denke aber nicht, dass das hilft, wenn der server einfach selbstaendig alle doks in allen db's absucht, oder?

vielen dank und gruss,
daniela

[Semeaphoros]

Hmm, da wird man sich überlegen müssen, das Calendar Profil gleich ganz rauszulöschen (oder umzubenennen).  Scheint, dass der Task auf dieses Profil "empfindlich" ist.