[geloest] Domino 8.5.2 Maildatenbank - Can't find $BusyName field on profile

[DunkelHut]

Hallo Allerseits,

Ich habe hier unter folgender Konfiguration, folgendes Problem:

Server

• Lotus Domino 8.5.2
• Windows Server 2008 Standard 64 Bit

Client

• Lotus Notes 8.5.2 Standard Client
• Windows 7 64 Bit

Fehler

• RnRMgr: Error processing calendar profile document (NoteID: NT0001F296) in database mail\username.nsf: Can't find $BusyName field on profile
• SchedMgr: Error processing calendar profile document (NoteID: NT0001F296) in database mail\username.nsf: Can't find $BusyName field on profile

Erscheinung

• Startprobleme des Client
• Replizierungsprobleme des Client
• diverse Erscheinungen wie 3x Editor Toolbar hintereinander

unternommene Schritte

• (server) compact -i -c -d mail\username.nsf
• (server) fixup -F -O mail\username.nsf
• (server) load convert -u -e -inherit -g"German" mail\username.nsf * mail85.ntf
• Neuinstallation des Standardclient

Die Datenbank des Users ist 4,6 GB groß. Trotz der oben beschriebenen Maßnahmen ändert sich nichts.
Wenn ich die Datenbank am Client "offline verfügbar" mache, dann beginnt er die Replizierung problemlos, wird sie aber unterprochen wird die Datenbank nie wieder syncronisert, wird teilweise sogar aus dem Syncronisierung rausgenommen. Insofern die Datenbank noch in der Replizierung drin steht, kommt dann bei der Datenbank die Meldung "Remotesystem antwortet nicht mehr" allerdings replizieren alle anderen Datenbanken inkl. die Roaming Datenbanken problemlos mit dem selben Server weiter.

Wo liegt eurer Meinung nach das Problem ?

Gruß
Stefan

[Tode]

Also: Erstmal zu den RnRMgr und Sched- Fehlermeldungen: Die haben NICHTS mit den anderen Problemen zu tun, und können im Normalfall ignoriert werden. Wenn Sie zu sehr nerven: Schau Dir das betroffene Profil mit notespeek an, da siehst Du dann, ob es sich um ein "gültiges" Dokument oder um eine "Leiche" handelt und kannst dann dementsprechend einen Agenten schreiben, der Dir das Dokument mit der NoteID holt und korrigiert oder löscht (je nachdem was Dir die Untersuchung per notespeek sagt).

Die anderen Probleme können verschiedenste Ursache haben, ich würde raten, dass es sich wohl um ein Datums- / Uhrzeitproblem handelt.

Mögliche Ursachen:
- Falsches Datum in Dokumenten / Replizierprotokoll der lokalen oder Serverdatenbanken (Replizierprobleme)
- Defekter Workspace- Ordner (Startprobleme)
- Defekte bookmark.nsf (Editor- Toolbar)
- Defekte desktopX.ndk

HTH
Tode

[ascabg]

Hallo,

Soweit ich das beurteilen kann, hat Dein dargestellter Fehler nichts mit den Problemen des Clients zu tun.

Der Fehler sagt doch nur das dem RnMgr das besagte Feld im Profile fehlt.

Schon mal das besagte Profile aufgerufen und neu gespeichert?
(ist das Calendar Profiles)


Andreas

[DunkelHut]

Hallo Torsten,

Also: Erstmal zu den RnRMgr und Sched- Fehlermeldungen: Die haben NICHTS mit den anderen Problemen zu tun, und können im Normalfall ignoriert werden. Wenn Sie zu sehr nerven: Schau Dir das betroffene Profil mit notespeek an, da siehst Du dann, ob es sich um ein "gültiges" Dokument oder um eine "Leiche" handelt und kannst dann dementsprechend einen Agenten schreiben, der Dir das Dokument mit der NoteID holt und korrigiert oder löscht (je nachdem was Dir die Untersuchung per notespeek sagt).

- Das Tool kannte ich noch nicht. Danke für den Tip. Mal schauen was sich mir da so anbietet.

Die anderen Probleme können verschiedenste Ursache haben, ich würde raten, dass es sich wohl um ein Datums- / Uhrzeitproblem handelt.

Mögliche Ursachen:
- Falsches Datum in Dokumenten / Replizierprotokoll der lokalen oder Serverdatenbanken (Replizierprobleme)
- Defekter Workspace- Ordner (Startprobleme)
- Defekte bookmark.nsf (Editor- Toolbar)
- Defekte desktopX.ndk

- Da ich den Client vollkommen neu aufgesetzt habe und dürfte von all dem an sich doch nichts reinstreuen ?
- Alles was da bei Client ankommt stammt von der Datenbank auf dem Server. Ausnahme hierbei sind vielleicht nur die Daten die aus dem Roamingverzeichnis kommen. Zu welchem Zeitpunkt die aktualisiert werden kann ich nicht sagen. In diesem Fall wäre es dann rein die bookmark.nsf. Die hatte ich bei der Reparatur der Userdaten leider außer Acht gelassen. Denkst Du das eine defekte bookmark.nsf aus dem Roamingverzeichnis solche Auswirkungen haben kann ?

Gruß
Stefan

[Tode]

ja, definitiv

[DunkelHut]

Hallo Andreas,

Danke für den Hinweis.

Schon mal das besagte Profile aufgerufen und neu gespeichert?
(ist das Calendar Profiles)

Kannst Du mir beschreiben wie das mit dem aufrufen und speichern der Profile geht ?
Im Moment verstehe ich da nur Bahnhof.

Gruß
Stefan

[DunkelHut]

ja, definitiv

...dann setz ich da mal an...  :-)

Danke !

Gruß
Stefan

[ascabg]

Kannst Du mir beschreiben wie das mit dem aufrufen und speichern der Profile geht ?
Im Moment verstehe ich da nur Bahnhof.

Ist eigentlich ganz einfach.
Mailfile oeffnen, Button "More" (Mehr) anklicken und hier den Punkt "Preferences" (Vorgaben).
Eventuell etwas aendern und mit "OK" den Dialog wieder schliessen.


Andreas

[DunkelHut]

Hallo Andreas,
  Danke, das habe ich dann jetzt verstanden...

[DunkelHut]

...trotz allen guten Tips, die Replikation der Userdatenbank bricht immer wieder ab.
 

[koehlerbv]

Stefan, hör' mal mit der "Userdatenbank" auf. Das ist eine stinknormale Datenbank wie alle anderen auch. Nur zufällig ist es die Mail-Db des Users, der sie lokal replizieren will.

Was hast Du denn bisher explizit in Bezug auf die Replikation Client-Server vorgenommen? Wie verhalten sich andere DBs dieses Clients bei der Replikation?

Bernhard

[Tode]

Hast Du die Standard- Vorgehensweise für Replizierprobleme schon durch?

- Replizierprotokoll überprüfen
- log.nsf des Clients auf Replizierfehler checken
- evtl. Replizierprotokoll auf lokal und server löschen (wenn Du Dir der möglichen Konsequenzen bewusst bist)
- Acl checken
- fixup, compact, updall auf lokale und serverreplik (lokal per cmd aus client- programm- verzeichnis)
- lokale Replik wegschmeissen und neu erstellen
- testen, ob andere datenbanken replizieren
- cache.ndk löschen, desktop komprimieren
- Arbeitsumgebung neu erstellen, weil dort auch Informationen zur Replikation gespeichert sind (u.a. Die Inhalte der Replikatorseite)

Gruss
Tode

[DunkelHut]

Stefan, hör' mal mit der "Userdatenbank" auf. Das ist eine stinknormale Datenbank wie alle anderen auch. Nur zufällig ist es die Mail-Db des Users, der sie lokal replizieren will.

Was hast Du denn bisher explizit in Bezug auf die Replikation Client-Server vorgenommen? Wie verhalten sich andere DBs dieses Clients bei der Replikation?

Bernhard

Hallo Bernhard, Hallo Torsten,

wie ich unten schon geschrieben habe, ich habe den Client vollkommen neu aufgesetzt, diesem Sinn folgend den Client über die Windows Bordmittel deinstalliert und die Verzeichnisse hinterher per Hand gelöscht, sowohl das Programmverzeichnis als auch das Data Verzeichnis, eben um auszuschließen das da vom Client her irgendwelcher Müll da reinleuchtet.

Heute Morgen habe ich testhalber besagte Datenbank mal auf einen anderen Client repliziert und siehe da, die Replikation lief problemlos durch.

Hier im Forum habe ich einen Beitrag gefunden in dem berichtet wird, wie bei einem anderen User ebenso gar wunderliche Dinge beim Zugriff auf die Datenbank passiert sind. In diesem besagten Fall ein ODS Problem. Der Admin hat dann im letzten Versuch so eine Replik erzeugt, das Orginal auf dem Server gelöscht und die Replik statt dessen auf den Server kopiert. Hinterher war dann alles Piano.

In diesem speziellen Fall hatte IBM im PMR so reagiert, daß sie an dieser Stelle sagten das sie da nicht mehr weiterhelfen können.

Ich werde das jetzt in gleichem Maße vornehmen, ergo die Replik vom Client gegen die Datenbank auf dem Server tauschen und dann hier über das Ergebnis berichten.

Danke für eure Hilfe und Gedanken...
Gruß
Stefan

[DunkelHut]

...gesagt getan, ich habe die besagte Datenbank auf dem Server gelöscht und die lokale Replik auf den Server kopiert. Jetzt schmeißt die Console folgende Warnung raus:

This database has local access protection (encrypted) and you are not authorized to access it

Auf dem anderen Client (Admin) kann ich die die lokale Replik dieser Datenbank aber öffnen und da steht unter Eigenschaften nichts von Verschlüsselung, weder unter  "Geheime Verschlüsselungsschlüssel" noch unter "Öffentliche Verschlüsselungsschlüssel". Wenn ich über den Server drauf zugreifen will, kommt ebenso die Meldung "Die Datenbank hat lokalen Zugriffsschutz (verschlüsselt). Sie sind nicht berechtigt darauf zuzugreifen"

Habt ihr eine Idee was das nun soll ?

[m3]

Die lokale Datenbank nicht über das Filesystem sondern über den Notes Client auf den Server "kopieren" bzw. was Du willst ist ja ein "Replizieren".

[DunkelHut]

Die lokale Datenbank nicht über das Filesystem sondern über den Notes Client auf den Server "kopieren" bzw. was Du willst ist ja ein "Replizieren".

Hallo Martin,

danke... Du hast recht. Man sollte sich der Notes/Domino Bordmittel bedienen damit sich der Kreis wieder schließt.

Bevor ich Deine "Erinnerung"   gelesen hatte, habe ich aber über den anderen Client, da noch mal die Eigenschaften geprüft und da war bei "verschlüsselt" dann wirklich ein Haken drin. Den habe ich dann rausgemacht, dann wurde die Datenbank "automatisch"  komprimiert und ich konnte sie dann unverschlüsselt dem Server wieder zuführen (auf Dateiebene kopiert).

Die gute Botschaft ist, daß das Problem so wie es jetzt aussieht durch das ersetzen der Datenbank behoben wurde. Die Client jenes Users repliziert nun so wie es sein soll. Es erscheinen auch glaubwürdige Replizierungsinformationen und nicht irgendwelcher Müll wie "18.769 Aktualisierungen:Dauer 1 Minute", die Progressbar rückt friedlich weiter und bleibt nicht bei 8% stehen obwohl weiter Daten geschoben werden, die Aktualisierungen zählen analog zur Progressbar hoch. Die Meldung "Can't find $BusyName field on profile" auf der Serverkonsole ist auch verschwunden.

Danke... für eure Tips und eure Hilfe.
Gruß
Stefan