Raum- und Ressourcenreservierung

    Zunächst einmal ein Hallo an alle Mitleser (wie ich einer bisher war) und an alle fleißigen Antwortschreiber.


    Wir haben hier ein Problem mit dem Reservieren von Räumen und Ressourcen mit der dazu verwendeten Reservierung's DB (RESERVIE.NSF)
    Als Dominoserver wird die Version 5.0.4 und als Client die 5.0.11 eingesetzt.


    Zunächst hab ich also in der DB einen Standort mit Bezug auf die Notes-Domäne, dem Server und dem DB-Pfad & Namen angelegt.


    Das Hinzufügen der unterschiedlichen Recourcen (2 Besprechungsräume und 2 Beamer) hat ebenfalls problemlos und ohne Fehlermeldung geklappt.


    Im Namens und Adressbuch werden die Räume und Ressourcen auch angezeigt. Somit hat für mich der ADMINP seine Dienste richtig erfüllt.
    Der Scheduler schmeisst beim Start allerdings folgende Fehlermeldung raus:


    Code
    SchedMgr: Fehler beim Verarbeiten des Kalenderprofildokuments (Dok-ID: NT00000912) in Datenbank EigeneDB\Reservie.nsf: Feld '$BusyName' wurde im Profil nicht gefunden


    Das angegebene Dokument (NT00000912) kann ich aber nicht finden. Es ist weder das Standorts-Dokument, noch eines der angelegten Ressourcen.
    Und eine Reservierung ist noch nicht vorhanden.


    Jetzt aber das eigentliche Problem:


    Beim Reservieren eines Raums, oder einer Ressource über einen Kalendereintrag in einem der Kalendare eines Benutzers, bekommt jeder
    beim Speichern & Einladen einen Zustellungsfehlerbericht mit dem Hinweis, dass der Raum oder die Ressourcen nicht im Namens & Adressbuch aufgeführt wären.


    Code
    Benutzer Beamer klein (Beamer klein@DOMÄNE) ist nicht im öffentlichem Adreßbuch aufgeführt


    Das ist aber zu 100% nicht der Fall. Im Domino-Administrator kann ich unter "Personen und Gruppen / Mail-in-Datenbanken und Ressourcen"
    beide Räume und Beamer sehen. Auch bei den Admin-Anforderungen steht nichts, was meiner Beachtung bedarf.


    Hat einer einen Rat für die angestaubte Notes R5 Problematik?

    Wenn die Fehlermeldung exakt so heißt, gab es Fehler beim Anlegen der Ressourcen.
    Räume & Ressourcen brauchen einen Standort, der auch im Namen auftauchen sollte..


    Gruß Steffen

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

    Das ist es wohl leider nicht. Die Räume heissen:


    Code
    Ressourcenname:	Besprechungsraum Geschäftsleitung/Düsseldorf
Ressourcenname:	Besprechungsraum/Düsseldorf


    Wobei "Düsseldorf" der in der Reservierungs-DB verwendete Standort ist. Auch bei den Ressourcen ist das so.

    Kommt die Meldung bei allen Usern oder kann eine lokale, nicht aktuelle Replik eines Verzeichnisses Schuld sein?


    Gibt es mehrere Server im Netz, zu denen die Ressourcen-Einträge im names noch nicht repliziert wurden?


    Hast du schon mal einen updall auf das names gemacht?


    Gruß Steffen

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

    Die Meldung kommt bei allen Usern. Jeder hat übrigens Editor Zugriff auf die Reservierungs-DB. Glaub aber nicht, dass das die Ursache für die Meldung ist.


    Wir haben hier nur einen Server, somit fällt das Replizieren auch weg. das "updall" hat auch keine Änderung gebracht.
    Der Index-Aktualisierungsvorgang wurde gestartet und kurz drauf beendet. Die Fehlermeldung erscheint dennoch.


    Eine lokale Replik existiert auch nicht :(

    Dann würde ich jetzt noch mal die busytime.nsf neu erstellen lassen.
    Dazu muss der Task schedule gestoppt und nach Löschen der DB aus dem Dateisystem wieder gestartet werden.


    Vielleicht kann diese die Ressourcen-Einträge nicht richtig verarbeiten.


    Gruß Steffen


    PS: Bevor du die busytime löscht, sieh dir mal den Befehl "tell sched validate" in der Hilfe an.
    Ich glaube, den gab es bei R5 auch..

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

    Das entwickelt sich zu einer Never ending Story :\


    Das validieren des Scheduler's hatte ich schon erfolglos probiert. Dann hab ich die busytime neu anlegen lassen. Er hat mir allerdings nur diverse Fehlermeldungen alter Kalendereinträge raus geworfen und eben die o.a. mit dem $BusyName


    Noch irgendwelche Ideen, die Du aus dem Hut zaubern könntest?

    Du schreibst, Ihr arbeitet mit Domino 5.0.4. Von Ende 2000 ... wenn ich mich recht erinnere. Aus Zeiten, als IBM Lotus mit dem Thema Calendaring & Scheduling im Massenbetrieb erst Erfahrungen sammelte ...
    Wenn man sich die Fixlists von damals bis heute hinsichtlich Verbesserungen im Bereich C&S / Ressourcenreservierung anschaut, ahnt man, was damals alles noch nicht (so) klappte.
    Ihr habt irgendwann und aus irgendwelchem Grund verpasst, einen sicheren Weg (laufende Updates) zu gehen. Ob Ihr bei diesem Problem mit 5.0.4 noch glücklich werden könnt - ich bezweifele es, kann es aber natürlich nicht ausschliessen.
    Dünner wird es natürlich auch mit Support in den Foren - wie viele freiwillige Masochisten gibt es noch, die sich auch noch um sieben oder acht Jahre alte Versionen kümmern? Auch wenn im Gegensatz zu vielen anderen Systemen immer noch möglich, diesen alten Stoff zu betreiben ...
    Mir fällt jetzt auf jeden Fall auch nichts zusätzliches ein zu dem, was hier schon gesagt wurde.


    Bernhard


    PS: Wenn mich meine Erinnerung nicht trügt (ich war an den Entscheidungen damals zwar selber beteiligt, aber es ist halt dermassen lange her ..) war 5.0.3 in der Firma, in der ich damals gearbeitet habe, die erste intern freigegebene und daher auch eingesetzte 5er Version (Client & Server). 5.0.4 bis 5.0.7 (incl. "a"-Versionen) fielen auch heraus wegen diverser Probleme. Mit 5.0.8 ging es dann weiter.

    Ich würde wohl- da es sich hier um nur vier nicht buchbare Ressourcen handelt- das ganze noch einmal aufbauen...


    Ressourcen wie vorgeschrieben löschen, DB weg, busytime neu, dem System Zeit geben und dann von vorne anfangen.
    Vielleicht ist dies der Weg, auf jeden Fall ist es wohl schneller, als detaillierte Fehlersuche zu betreiben.


    Ist es dann immer noch Mist, kann in der Version 5.0.4 mit Ressourcen nicht gearbeitet werden!


    Gruß Steffen

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

    Danke Steffen für Deine Hilfe. Neu gestrickt hab ich die ganze "Konfig" dafür heute nun zum 2. Mal ... erfolglos.


    Bernhard


    Über Sinn oder Unsinn, eine längst veraltete Software einzusetzten zu diskutieren ist wohl mehr als müßig. Offensichlich gabs hier in der Vergangenheit Gründe dafür nicht zu wechseln.


    Das dann halt Funktionen existieren, die nicht richtig laufen muss man halt akzeptieren. Die Reservierungsfunktion pack ich dann mal auf den großen Haufen. Alles Argumente, einen neuen Weg zu gehen.


    Grüße
    Tobias

    Wenn ich mal von der Tatsache absehe, daß hier eine mehr als 10 Jahre alte Technik eingesetzt wird, die ich inzwischen nicht mal mehr mit der Kneifzange anfassen würde, gibt es in deiner Beschreibung einige Widersprüche.


    Diese deuten darauf hin, daß hier beim Anlegen der Konfiguration nicht laut Anleitung vorgegangen wurde sondern (z.B. durch Copy & Paste oder Umkopieren/Umbenennen ganzer Datenbanken) schon einiges verzapft wurde.


    Zitat

    Wir haben hier ein Problem mit dem Reservieren von Räumen und Ressourcen mit der dazu verwendeten Reservierung's DB (RESERVIE.NSF)


    Also heißt die angelegte Datenbank: RESERVIE.NSF


    Wenn auch die korrekte Schablone verwendet wurde sieht das soweit korrekt aus.


    Zitat


    SchedMgr: Fehler beim Verarbeiten des Kalenderprofildokuments (Dok-ID: NT00000912) in Datenbank EigeneDBReservie.nsf: Feld '$BusyName' wurde im Profil nicht gefunden


    Moment ... eben hieß die DB noch RESERVIE.NSF und jetzt plötzlich EigeneDBReservie.nsf?


    Ich tippe auf sponatane Selbstumbenennung ^^ (das war ein Scherz.)


    Kann also nicht gehen. Interessant wäre jetzt nur, wie heißt denn die DB nun wirklich oder gibt es gar 2?


    Und auf welche davon verweisen die Mail-In-Dokumente des Domino Verzeichnisses?


    Zitat


    Das angegebene Dokument (NT00000912) kann ich aber nicht finden. Es ist weder das Standorts-Dokument, noch eines der angelegten Ressourcen.
    Und eine Reservierung ist noch nicht vorhanden.


    Wie hast du denn gesucht? In den Ansichten? Nicht wirklich, oder? Profildokumente haben eine nette Eigenschaft: man kann sie (auf normalem Wege) nämlich nicht sehen. Das ist der Witz bei den Dingern. Genauso wie man viele andere spezielle Note-Typen nicht in Ansichten finden kann.


    Sofern du also nicht NotesPeek, ein Tool (z.B. die Ytria Tools) oder ein selbstgestricktes Script für die Suche verwendet hast wird es auch dabei bleiben, daß du das Dokument nicht siehst.


    Zitat


    Benutzer Beamer klein (Beamer klein@DOMÄNE) ist nicht im öffentlichem Adreßbuch aufgeführt


    Irgendwie vermisse ich die Standort-Komponente in dem Namen. Laut einem anderen Post von dir müsste der Beamer ja eigentlich
    "Beamer klein/Düsseldorf" heißen.


    Tut er aber nicht. Dann kann er auch nicht per Mail erreicht werden. Logische Konsequenz würde ich einmal behaupten.


    In deinem letzten Post hast du dann noch eine komplett neue Konfig erwähnt. Zum 2. Mal. Nach obiger Beschreibung gab es ja schon 2 Ressourcen-Datenbanken, dann nehme ich an, es gibt jetzt 3?


    Sehr verwirrend, deine Beschreibung. Scheinbar auch für deinen Server verwirrend genug, damit es nicht funktioniert.


    Carsten

    Hallo Carsten!


    Um mal hier die Verwirrung zu klären:


    1. Die DB heisst wie erwähnt RESERVIE.NSF und ja, die korrekte Schablone wurde beim Erzeugen verwendet: StdR50ResourceReservation



    2. Der Name EigeneDBReservie.nsf schließt das Verzeichnis in dem sich die DB befindet mit ein (EigeneDB). Das ist also nur ein Anzeigeproblem hier im Forum. Es hätte Richtigerweise heissen müssen: EigeneDB\Reservie.nsf Und so stehts auch im LOG.


    2a. Halten wir fest: Es existiert nur eine Reservierungs-DB


    3. Da es in der RESERVIE.NSF nur die Dokumente der Ressourcen und das Standortprofildokument gibt, hab ich mir die Dok-ID's selbiger angesehen und keine Übereinstimmung gesehen. Oberflächlich betrachtet gibts also kein Dokument mit der ID. Zusätzliche Tools habe ich zum Auffinden nicht benutzt.


    4. Die Ressourcen haben die Standortinformation in Ihrem Namen eingetragen (Beamer klein/Ausstattung/Düsseldorf)
    Das im Zustellfehlerbericht die Standortinfos fehlen könnte der Knackpunkt sein.
    Eigentlich müsste die Adresse der Ressource dann "Beamer klein/Düsseldorf@domäne" heissen. Richtig?
    Sowohl der Domänenname, als auch der Name des Notes Servers ist im Standortdokument aber vermerkt.
    Wenn ich eine Mail an "Besprechungsraum/Düsseldorf@domäne" schicke, erhalte ich auch keine Fehlermeldung. Also scheinen die ja wohl zustellbar zu sein. Wo steckt dann da der Fehler?


    5. Vor dem Erstellen einer neuen Konfig habe ich selbst verständlich alle Ressourcen und Standorte gelöscht. Nicht via ENTF & F9 sondern über die Funktion, die dafür zur Verfügung steht. Die RESERVIE.NSF hab ich ebenfalls vorher gelöscht. Auch so, wie es sein sollte.
    Also ist der Server hier wohl nicht ganz so verwirrt, wie Du atm Carsten ;)


    Grüße
    Tobias

    Na jetzt hast du ja die Verwirrungen die du vorher verursacht hast soweit beseitigt.


    Stimmen denn die RessourceName Felder deiner Ressourcen, d.h. steht dort der vollständige Name inkl Standort mit drin ?
    Und schau da bitte nicht auf das was dir in der Maske angezeigt wird, sondern direkt in das Feld über die Dokumenteigenschaften

    In den Dokumenten Eigenschaften findet man unter "FullName" den kompletten Namen: "CN=Beamer klein/OU=Ausstattung/O=Düsseldorf" und für den Raum entsprechend: "CN=Besprechungsraum/O=Düsseldorf"

    Tja da steht leider nichts anderes! Feldname ist "ResourceName" und Inhalt ist "CN=Beamer klein/OU=Ausstattung/O=Düsseldorf"


    Das was ich vorhin gepostet hab, war aber aus dem Namens und Adressbuch.

    Zitat

    Eigentlich müsste die Adresse der Ressource dann "Beamer klein/Düsseldorf@domäne" heissen. Richtig?


    Richtig.


    Zitat


    Sowohl der Domänenname, als auch der Name des Notes Servers ist im Standortdokument aber vermerkt.
    Wenn ich eine Mail an "Besprechungsraum/Düsseldorf@domäne" schicke, erhalte ich auch keine Fehlermeldung. Also scheinen die ja wohl zustellbar zu sein. Wo steckt dann da der Fehler?


    In dem Fall vermutlich in der Kalendermaske selber.


    Zur Kontrolle:


    Einfach mal den Router kurz anhalten (te router quit) und eine Einladung erzeugen. Diese aus der mail.box des Servers fischen und irgendwo zur Analyse aufheben (oder zumindest mittels Rechtsklick kontrollieren, was z.B. im Feld SendTo steht).


    Steht dort nicht der vollständige Name sondern nur der CN des Raumes wird die Einladung bereits falsch erzeugt.


    Carsten


    PS: Router wieder starten nicht vergessen ^^: lo router

    Ja, genau so ist es! es wird nur an "Besprechungsraum@domäme" geschickt. Der Standort wird ignoriert. Dann ist mir zumindest mal klar, warum die Reservierungsmails nicht zugestellt werden können.


    So wie ich das verstehe ignoriert er dann den Eintrag der Domäne im Standort Dokument der Reservierungs DB. Ist das jetzt ein Fehler, oder kann man das irgendwo korrigieren. Im Adressbuch steht jedenfalls die Domäne bei den Ressourcen mit drinne.


    Grüße
    Tobias

    Der Fehler liegt hier wohl in der Einladungsmaske.


    Zumindest für die frühen 5er Versionen gibts dazu auch einen Eintrag in der Knowledgebase mit Workaround:


    R5 Resource Reservation Database Does not Resolve Flat Names


    Jetzt kannst du 3 Dinge tun:


    1.) den Workaround benutzen ^^


    2.) auf die letzte 5er Version hochziehen und hoffen, dass der Fehler da weg ist


    3.) eine vernünftige Version einsetzen (sprich: eine aktuelle)


    Mit etwas Programmierkenntnis könnte man den Fehler sicher auch manuell in der Maske beheben, aber wenn ihr das selber könntet dann gäbe es das Posting hier nicht und jemanden beauftragen...naja, ich sags mal kurz: wozu Geld für eine Reparatur einer Uralt-Version rauswerfen.


    Carsten