Beiträge von grunz

hallo zusammen!

habe leider gerade ein seltsames problem mit unserer raumbuchungsdatenbank:

in der datenbank wurden vier konferenzräume und einige andere ressourcen wie z.b. beamer und "leihnotebooks" hinterlegt. bislang lief auch alles wie am schnürchen, doch kürzlich fiel jemandem auf, dass keiner der vier räume nach dem 14.10.2006 als verfügbar angezeigt wird. somit kann man diese räume auch an keinem datum nach dem 14.10 buchen. alle anderen ressourcen zeigen dieses problem nicht. ich habe selbstverständlich bereits die einstellungen der räume überprüft, ob diese nur bis zu einem bestimmten datum verfügbar sein sollen, was man ja durchaus einstellen kann. leider ist es aber offenbar nicht ganz so einfach.. habe auch bereits vergeblich versucht durch explizites setzen der betreffenden einstellung auf ein datum in ferner zukunft, die vermeintlich irgendwo im hintergrund gespeicherte, fehlerhafte einstellung zu überschreiben.
ein testweise neu angelegter raum lässt sich ohne derartige probleme buchen.
da für die betreffenden räume in der vergangenheit noch bis zu einem unbestimmten zeitpunkt buchungen für daten nach dem 14.10. vorgenommen werden konnten, wäre es schön, ohne ein löschen und neuanlegen der räume zu einer lösung zu kommen, damit die benutzer die räume nicht wieder alle neu buchen müssen.

wo könnte man da mal ansetzen?

habe irgendwo gelesen, dass man durch löschen der clubusy.nsf evtl. etwas erreichen kann, bin mir aber unsicher, ob das noch irgendwelche anderen, negativen folgen nach sich zieht. hat da jemand erfahrungen?

ich vermute als ursache ja schon, dass der server gerade zum weltuntergangsorakel mutiert und buchungen nach dem datum für sowieso vollkommen überflüssig erachtet ..

besten dank für's zuhören
patrick

hallo,
das problem stand offenbar im zusammenhang mit der installation des deutschen languagepacks für den domino 7. habe den domino 7.0.1 mit FP1 kürzlich ein weiteres mal neu installiert, und dabei dann mal das deutsche languagepack weggelassen. seither läuft die kiste offenbar nun wieder rund.
grüße,
patrick

hat sich mehr oder weniger geklärt - hab das problem an den rim support gemeldet und die haben's dort wohl reproduzieren können. man kümmert sich wohl schon um eine lösung.

hallo,

der vor einigen tagen erschienene hotfix1 für bes 4.1.1 verweigert die installation auf meinem domino-server. die fehlermeldung des windows installers besagt folgendes:

"Der Upgradepatch kann vom Windows Installer-Dienst nicht installiert werden, weil das Programm, das aktualisiert werden soll, möglicherweise fehlt, oder weil der Upgradepatch eine andere Version des Programms aktualisiern würde. Stellen Sie sicher, dass das zu aktualisierende Programm auf dem Computer installiert ist, und dass Sie den richtigen Upgradepatch installieren."

laut release notes sollte der zu aktualisierenden BES die versionsnummer 4.1.1. bundle 29 haben, was in meinem fall eindeutig korrekt ist. auch eine erneute installation des service pack 1 für BES 4.1 konnte keine abhilfe schaffen. sachdienliche hinweise zur lösung des problems wären sehr willlkommen!

wir nutzen da eine meiner meinung nach deutlich elegantere lösung:

unsere benutzer verwenden als mailtemplate das bei openntf.org verfügbare, erweiterte mailtemplate, welches u.a. sozusagen die struktur der names.nsf in die normale mail-db integriert. damit hat man nun im prinzip die möglichkeit auf die verwendung der normalen names.nsf als adress-db zu verzichten, bzw. diese mit dem direkt in die mail-db integrierten kontakte-ordner zu synchronisieren. der clou ist, dass man im BES als quelle für's adressbuch einfach die normale mail-db des benutzers angeben kann, sofern der benutzer eben diesen kontakte-ordner innerhalb seiner mail-db verwendet. unter "aktionen -> adressbuch synchonisierien" findet man einen agent, der das normale names.nsf adressbuch mit dem kontakte ordner innerhalb der maildb abgleicht. den agent könnte man sicherlich auch noch so einstellen, dass der im hintergrund in regelmäßigen abständen synct.

will ja nicht undankbar erscheinen, aber der artikel bezieht sich offensichtlich auf unix-server, und enthält zudem noch deutlich weniger brauchbare informationen zu dem thema, als es die hilfedatei des domino adminstrators bei einer suche nach dem stichwort "nsd" zu tage fördert....

ich könnte da in dem zusammenhang etwas konkretere tips gebrauchen, auf was man da in solch einer situation speziell achten sollte - insbesondere im zusammenhang mit dem BES, der vermutlich nicht ganz unschuldig an dem problem sein wird. der BES ist derzeit gewissermassen mein einziger "strohhalm" bzw. "verdächtiger", da er den einzigen offensichtlichen unterschied zum "ersten" server bildet.

das windows log ist an der stelle leider vollkommen unbrauchbar und sagt dbzgl. überhaupt nichts relevantes aus. es ist auch eben nicht so, dass ich nicht mehr remote übers netzwerk auf den server draufkäme: remote-desktop usw. funktioniert problemlos und der server ist auch prinzipiell im netzwerk erreichbar. er "unterhält" sich ja sogar offenbar noch mit seinem clusterpartner, wie oben beschrieben. offenbar ist aber eben die nserver.exe für die verbindungen auf den für notes relevanten ports zuständig und nimmt dort eben nichts mehr an.

ein nsd-dump wäre sicherlich auch hilfreich, wenn der server denn "richtig" crashen würde, was er aber ja eben NICHT macht. nur die nserver.exe "hängt" und der server nimmt eben keine notes-verbindungen mehr an.
falls nsd in solch einer situation aber dennoch einen aussagekräftigen output erzeugen könnte, wäre es interessant zu erfahren, wie ich diesen denn bekommen und interpretieren kann!?

Hallo zusammen,

habe hier ein gravierendes Problem mit einem unserer beiden Domino-Server, der sich leider seit drei-vier Wochen in unregelmäßigen Abständen - dummerweise nahezu täglich - aufhängt. Die Server sind in einem cluster verbunden, und Hard- und Softwareseitig identisch ausgestattet (Domino 7.0.1 FP1 mit deutschen Languagepack auf Windows Server 2003 mit allen verfügbaren Servicepacks und Patches). Der einzige gravierende Unterschied zwischen den Servern ist, dass auf dem zweiten Server ein Blackberry Enterprise Server mitläuft (v4.1.1). Glücklicherweise arbeiten die User derzeit noch alle auf dem ersten Server, so dass diese von dem Problem selten etwas mitbekommen...

Der Server crasht allerdings nicht "richtig" - man kann im Taskmanager sehen, dass alle dominotypischen Prozesse weiterhin aktiv sind. Lediglich der Prozess nserver.exe steht mehr oder weniger konstant auf 23-25% CPU-Last, als wäre er mit irgendetwas schwer beschäftigt. Man kann in der Situation halt "nur" nicht mehr remote per Notes auf den betreffenden Server zugreifen. Auch die Blackberry-Tasks scheinen erstmal normal weiterzulaufen, da man in der Situation z.B. auch noch neue Emails auf dem Blackberry empfängt und auch z.B. das Adressbuch über den Blackberry abfragen oder Notes-verschlüsselte Mails entschlüsseln kann. Auch die Replizierung im Cluster klappt offenbar erstmal noch für einige Zeit, denn sonst würde der BES keine neuen Mails empfangen können. (Neue Mails werden am "ersten" Server abgeliefert, und entsprechend zum zweiten, der auch den BES beherbergt, repliziert)

Leider kann ich das erste Auftreten des Problems zeitlich nicht mehr mit irgendeiner Konfigurations- oder Softwareveränderung in Verbindung bringen, was die Ursachenforschung erheblich erschwert. Auch die Logfiles sind für mich derzeit nur wenig aufschlussreich, wie im (anonymisierten) Auszug unten zu sehen ist. Das Problem tritt auch nicht immer zur gleichen Zeit auf: mal passiert's mitten in der Nacht, mal morgens früh um 8 (wie heute) oder auch irgendwann im Laufe des Tages. Habe schon diverses ausprobiert, wie z.B. das "große Service": compact & fixup & update über alle DB's laufen lassen, sowie die in der Zwischenzeit sowohl für Domino als auch für Blackberry erschienenen Patches und Service-Packs installiert. Das Verhalten bleibt aber leider weiterhin bestehen. Man sieht nur, dass irgendwann die Meldung Error "connecting to server domino-2/XYZ: Remote system no longer responding" im Log, bzw. auf der Konsole auftaucht. Sobald das eintritt, kann ich den Lotus Domino Service aber immerhin noch "normal" über den Windows-Service-Manager beenden. Sofern ich den Domino als Programm starte, kann ich auch über die geöffnete Konsole den Befehl "restart server" absetzen, was dann auch immerhin noch zum gewünschten Erfolg führt.

Am liebsten würde ich ja irgendwie mal in den nserver.exe Task "reinschauen" um zu sehen, womit der sich in der Situation gerade rumplagt...

Konkret wäre die Frage, was man in solch einer Situation noch machen kann, um die Fehlerursache zumindest ein wenig näher eingrenzen zu können.

Da ich noch relativ "frisch" in der Domino-Administration bin, wären mir sachdienliche Hinweise zur Lösung des Problems, die für Euch in solchen Fällen vermutlich schon ganz selbstverständlich sind, eine wirklich große Hilfe!

Im Extremfall bliebe mir wohl nur noch der Gang zu einer Firma wie EBF oder Pentos, die das ganze System dann mal zerpflücken müssten. Das würde ich allerdings wirklich nur sehr ungerne machen, da dies sicherlich mit nicht gerade unbeträchtlichen Kosten verbunden sein würde...

Auszug aus dem heutigen Logfile des "Problemservers" (Kategorie Miscellaneous Events):

17.08.2006 08:03:44 {Test User/XYZ} SRP: TID=219138, RID=-919131822, NID=A5CA, type MAIL returned DELIVERED
17.08.2006 08:04:14 Begin MIME to CD Conversion (Process: ? (000016C4:00000006), Database: CN=domino-2/O=XYZ!!mail\user_t.nsf, Note: 0000864A)
17.08.2006 08:04:14 End MIME to CD Conversion (Process: ? (000016C4:00000006), Database: CN=domino-2/O=XYZ!!mail\user_t.nsf, Note: 0000864A)
17.08.2006 08:05:20 BES pending count 1125, sent 35, queued 1090
17.08.2006 08:06:16 Chronos: Full text indexer terminating
17.08.2006 08:07:53 {Test User3/XYZ} OTAFM: notification sent to handheld, TID=219139
17.08.2006 08:08:58 AMgr: Executive '3' shutting down. Process id '8044'
17.08.2006 08:08:58 AMgr: Executive '2' shutting down. Process id '6616'
17.08.2006 08:09:00 Admin Process: Searching Administration Requests database
17.08.2006 08:09:22 Begin MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 End MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 Begin MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 End MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 Begin MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 End MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 Begin MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 End MIME to CD Conversion (Process: ? (000016C4:00000009), Database: CN=Domino-1/O=XYZ!!mail\user_t.nsf, Note: 0000A5CE)
17.08.2006 08:09:22 {Test User/XYZ} Message sent to handheld (PIN 12345678, "mail\user_t.nsf" on CN=Domino-1/O=XYZ): folder "($Inbox)", posted date 17.08.2006 08:07:10, added date 17.08.2006 08:09:22, TID=219140, RID=-2088378925, NID=A5CE
17.08.2006 08:09:36 {Test User2/XYZ} Message queue: total pending packets=235, packets sent to wireless network=5, internal packets=0, queued events=231
17.08.2006 08:09:54 Error connecting to server domino-2/XYZ: Remote system no longer responding

17.08.2006 08:10:20 BES pending count 1127, sent 37, queued 1090
17.08.2006 08:11:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 End MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 End MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 End MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 End MIME to CD Conversion (Process: ? (000016C4:00000011), Database: CN=Domino-1/O=XYZ!!mail\user2_t.nsf, Note: 0000CEEE)
17.08.2006 08:11:06 {Test User2/XYZ} Queued new message (PIN 12345678, "mail\user2_t.nsf" on CN=Domino-1/O=XYZ): folder "($Inbox)", posted date 15.08.2006 19:24:20, added date 17.08.2006 08:10:42, TID=219141, RID=-1996432940, NID=CEEE
17.08.2006 08:12:05 Error connecting to server domino-2/XYZ: Remote system no longer responding

17.08.2006 08:12:32 {Test User2/XYZ} Message queue: total pending packets=370, packets sent to wireless network=5, internal packets=0, queued events=366
17.08.2006 08:13:14 {Test User3/XYZ} Message queue: total pending packets=1, packets sent to wireless network=1, internal packets=0, queued events=1
17.08.2006 08:13:34 {Test User3/XYZ} Message queue: total pending packets=54, packets sent to wireless network=5, internal packets=0, queued events=50
17.08.2006 08:14:01 {Test User5/XYZ} Queued new message (PIN 12345678, "mail\user5_t.nsf" on CN=Domino-1/O=XYZ): folder "($Sent)", posted date 17.08.2006 08:13:40, added date 17.08.2006 08:13:41, TID=219142, RID=-712753835, NID=16E1A
17.08.2006 08:14:12 Begin MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:12 End MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:12 Begin MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:12 End MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:12 Begin MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:12 End MIME to CD Conversion (Process: ? (000016C4:00000005), Database: CN=Domino-1/O=XYZ!!mail\user3_t.nsf, Note: 000F22E6)
17.08.2006 08:14:15 Error connecting to server domino-2/XYZ: Remote system no longer responding

17.08.2006 08:15:20 BES pending count 1129, sent 37, queued 1092
17.08.2006 08:16:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 End MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 End MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 End MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 Begin MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 End MIME to CD Conversion (Process: ? (000016C4:00000016), Database: CN=Domino-1/O=XYZ!!mail\user4_t.nsf, Note: 000884EE)
17.08.2006 08:16:06 {Test User3/XYZ} Queued new message (PIN 12345678, "mail\user4_t.nsf" on CN=Domino-1/O=XYZ): folder "($Inbox)", posted date 17.08.2006 09:13:19, added date 17.08.2006 08:15:40, TID=219143, RID=-628009514, NID=884EE
17.08.2006 08:16:25 Error connecting to server domino-2/XYZ: Remote system no longer responding
17.08.2006 08:16:30 Error connecting to server domino-2/XYZ: Remote system no longer responding
17.08.2006 08:16:30 Error connecting to server domino-2/XYZ: Remote system no longer responding
17.08.2006 08:16:30 Error connecting to server domino-2/XYZ: Remote system no longer responding
17.08.2006 08:16:30 Error connecting to server domino-2/XYZ: Remote system no longer responding

das problem hatte ich auch schon einige male. ich meine bei uns hätte da immer der neuaufbau der ansichtsindizes über strg-umschalt-f9 in kombination mit einem fixup geholfen.

wir verwenden für solche zwecke das tool "corporate mail manager". schau mal auf http://www.unternehmen-online.de - kostet zwar eine stange geld, bietet aber diverse möglichkeiten für sog. signatur-marekting!

zu 1.) nein - mir geht es nicht um sammel-inboxen, sondern um eine normale user-mailbox, in der prinzipiell auch private mails landen könnten. rechtlich gesehen ist das aber prinzipiell kein problem, wenn der abwesende user ohnehin explizit zustimmt, den zugriff auf die datenbank während seiner (i.d.r. urlaubsbedingten) abwesenheit an einen kollegen zu deligieren.

zu 2.) externe verschlüsselung steht (vor)erst mal nicht zur debatte. möglichkeiten/erfahrungen zur zertifizierung einer selbstsignierten domino-ca durch einen kommerziellen anbieter wie verisign & co. wären für mich aber durchaus auch von großem interesse. nach meiner recherche gibt's da aber offenbar generell nur solche "halben sachen" wie unter http://www.geotrust.com/produc…_certificates/georoot.asp

zu 3.) das ausscheiden des mitarbeiters wäre an der stelle das geringste problem. da könnte man ja z.b. auch über die programmierung eines agents nachdenken, der die nachrichten des ausgeschiedenen benutzers einmalig entschlüsselt und in dieser form in die mailbox des nachfolgers kopiert, der eine eigene, neue id bekommt.
mir geht es aber vielmehr um die kurzfristigen vertretungs- bzw. deligierungsmöglichkeiten! wäre halt ziemlich doof, wenn der urlauber das kennwort seiner notes-id an eine vertretung weitergeben müsste, die dann ggf. auch noch zwischen zwei arbeitsumgebungen oder gar zwei rechnern hin und herwechseln müsste... mit der normalen deligierung müsste man eben nur zwischen zwei karteireitern im eigenen notes-client hin und herspringen, was selbstverständlich deutlich angenehmer ist.
wir verwenden domino 7.0.1FP1 mit Notes 7.0 / 7.0.1. fortschritte habe ich bei dem thema bisher leider noch keine erzielt....

tja, scheint wohl doch ein generelles problem zu sein, wenn man die resonanz auf die frage betrachtet

gibt's denn überhaupt keine möglichkeit, den geheimen part des notes-schlüssels aus einer benutzer-id zu extrahieren (und ggf. in eine andere aufzunehmen?)? der notes-client scheint die export-richtung ja offensichtlich nicht out-of-the-box zu unterstützen.

hat vielleicht schon mal jemand die funktion "notes zertifikate importieren (in id-datei aufnehmen)" für irgendetwas sinnvolles verwendet, und wenn ja - wofür?! steht diese funktion etwa auch nur im zusammenhang mit der einfachen erneuerung des zertifikates, die man z.b. nach verlust bzw. kompromittierung des schlüssels durchführt?

tja, die replizierung läuft nun bei den erwähnten dateien offenbar korrekt ab - zumindest sieht man z.b. bei der anzahl der dokumente keinerlei unterschied mehr. darüberhinaus sieht man bei den änderungsdaten der dateien, dass diese jeweils immer nur um wenige sekunden voneinander abweichen.

nun verwende ich das domino domain monitoring, welches einen entsprechenden, vordefinierten test enthält, um zu prüfen ob die drei dateien korrekt repliziert werden. die entsprechende "probe" in der ddm.nsf unter "replication -> scheduled replication checks" habe ich so konfiguriert, dass explizit die beiden in der domain vorhandenen server geprüft werden sollen. das mistviech generiert aber trotzdem noch andauernd neue events, wobei es behauptet, dass die dateien NOCH NIE repliziert worden sind! aufgrund der erwähnten beobachtungen, kann das nun wirklich beim besten willen nicht stimmen...

gibt's dafür irgendeine erklärungsmöglichkeit?

hi,
ich konnte durch das löschen der datei perweb.nsf häufig erreichen, dass html-mails die zuvor nicht korrekt dargestellt wurden, (bilder fehlten sehr häufig) danach wieder richtig angezeigt werden. ist vielleicht mal einen versuch wert...

grüße,
patrick

ok - besten dank für den hinweis - da hatte ich in der tat noch eine größere wissenslücke! bin bislang in der tat davon ausgegangen, dass der cluster-replikator den "normalen" replikator ersetzt, bzw. überflüssig macht. da muss ich auf jeden fall nochmal ein wenig mehr lesen...

dazu noch'ne gaaaaanz doofe frage auf die schnelle:

für die normale replizierung müsste in meinem fall mit nur zwei servern, ein entsprechendes verbindungsdokument zum jeweils anderen server ausreichend sein, in welchem der replikation task auf enabled steht, und in entsprechenden intervallen ausgeführt wird, richtig?

Hallo,

habe zwei Domino 7.0.1 Mail-Server im Clusterverbund. Server A ist Administrationsserver der Datenbanken und Server B dient der Lastverteilung. Nach der Aktivierung des Domino Domain Monitorings bekomme ich auf Server B laufend eine Warnmeldung in der Konsole und den Logs welche besagt, dass die Datenbanken events4.nsf, names.nsf und admin4.nsf seit längerer Zeit nicht mehr mit anderen Servern repliziert wurden:

23.07.2006 05:04:51 names.nsf has not replicated (PULL) with ANY server since 22.07.2006 16:26:12 (12 hours ago)
23.07.2006 05:04:51 names.nsf has not replicated (PUSH) with ANY server since 22.07.2006 16:48:03 (12 hours ago)
23.07.2006 05:04:51 admin4.nsf has not replicated (PULL) with ANY server since 22.07.2006 20:19:35 (8 hours ago)
23.07.2006 05:04:51 admin4.nsf has not replicated (PUSH) with ANY server since 22.07.2006 20:19:35 (8 hours ago)
23.07.2006 05:04:52 events4.nsf has not replicated (PULL) with ANY server since 22.07.2006 20:25:52 (8 hours ago)
23.07.2006 05:04:52 events4.nsf has not replicated (PUSH) with ANY server since 22.07.2006 20:26:07 (8 hours ago)

Offenbar ist die Meldung aber nicht korrekt, denn der Cluster Replikator scheint seine Sache schon ganz gut zu machen. Bei einer Kontrolle der betreffenden Datenbanken konnte ich das angebliche Problem auch nicht bestätigen, da diese offenbar den gleichen Inhalt haben. Die Anzahl der Dokumente stimmt nahezu exakt überein, und auch die aktuellen Einträge werden korrekt hin und her repliziert.

Muss ich mir trotzdem Sorgen machen?

Viele Grüße,
Patrick

hallo zusammen,
bin gerade dabei die möglichen fallstricke bei der einführung einer notes-basierten verschlüsselung innerhalb unseres unternehmens auszuloten. dabei bereitet mir die verschlüsselung in kombination mit der bei uns hin und wieder verwendeten zugriffsdelegierung auf maildatenbanken anderer mitarbeiter (z.b. bei urlaub, krankheit oder nach dem ausscheiden des ma's aus dem unternehmen) einige sorgen/probleme...
bei der konstellation, dass z.b. benutzer A zugriff auf die mail-db von B erhalten soll, ist es B logischerweise nicht möglich, die von A verschlüsselten emails zu lesen, ohne den zur verschlüsselung verwendeten, privaten schlüssel von A zu kennen/besitzen.

da dachte ich mir: sollte ja kein größeres problem darstellen - importieren wir eben die benutzer-id von A in jene von B, was über den dialog unter "datei -> sicherheit -> benutzersicherheit -> ihre identität -> ihre zertifikate -> zertifikate abrufen -> notes zertifikate importieren (in id-datei aufnehmen)" durchaus machbar erscheint. der assistent läßt mich dabei auch die id-datei von B öffnen, fragt das entsprechende kennwort der id-datei von B ab, bricht aber dann mit folgender meldung ab:

"Der öffentliche Schlüssel kann nicht akzeptiert werden, da kein passender öffentlicher Schlüssel in der ID-Datei vorhanden ist."

was will mir diese meldung bloß sagen?!? habe zwischenzeitlich alles möglich ausprobiert, und konnte zumindest ausschließen, dass es sich um ein problem speziell mit den verwendeten user-id's handelt. habe diverse zusätzliche testuseraccounts samt passender notes-zertifikate erstellt, doch das problem scheint da doch eher globaler natur zu sein....

über mögliche lösungsansätze oder alternativen würde ich mich sehr freuen!

viele grüße,
patrick

ah - nochmals danke für den tip! die einstellung hatte ich auch schon im verdacht. hat die sessionbasierte variante (bei einem einzelnen server) irgendwelche kriegsentscheidenden vorteile, oder kann man die getrost ignorieren?

taurec:

danke für den tip mit dem realm! habe das nun mal ausprobiert, aber wundere mich ein wenig über das ergebnis... (bei der gelegenheit habe ich den server übrigens auch auf die verwendung von internet-site-dokumenten umgestellt, falls das relevant ist)
bislang war es so, dass man einen logndialog vom browser bekommen hat. nach der umstellung erhält man nun eine relativ hässliche htmlseite, welche die eingaben an /names.nsf?Login schickt. hab ich da was falsch gemacht?!

ich denke du solltest einfach mal probieren, ob du schon bei der abfrage des servernamens die dyndns-adresse eingeben kannst. ansonsten versucht outlook wahrscheinlich immer nur eine lokale namensauflösung über netbios.
alternativ würde ich mal versuchen, ob man in der hosts-datei von windows einen alias auf den dyndns eintrag machen kann.