Wenn man denn Servicezeiten hat...........
Filemon/Procmon gibts glaube ich nicht für OS/400...
Naja, ich werde mal weiter forschen, die Idee mit dem Clustermember ist gut....
Danke einstweilen
Wenn man denn Servicezeiten hat...........
Filemon/Procmon gibts glaube ich nicht für OS/400...
Naja, ich werde mal weiter forschen, die Idee mit dem Clustermember ist gut....
Danke einstweilen
hmmmm.....
genau das wollte ich vermeiden.
Server runterfahren ist nicht so einfach.............
Gibt es einen anderen Ansatz?
Eine Datensicherung habe ich natürlich.
Aber ich wollte dem Problem erstmal so beikommen.
Wie führe ich ein Offline Fixup durch?
Hallo allerseits,
ich habe ein Problem auf einem Domino 7.0.3FP1, auf OS/400.
Beim Zugriff auf eine Datenbank kommt der Fehler
Database collection open error: /domino/data/xxx.nsf: Database is corrupt -- Cannot allocate space
Error updating views in Domino Directory(s): Database is corrupt -- Cannot allocate space
ein Fixup läuft ohne fehler durch, einen compact kann ich nicht tun, da die DB noch in Benutzung scheint. Meldung:
Database open error: xxx.nsf: Database is currently in use by you or another user
Error compacting xxx.nsf: Database is currently in use by you or another user
Soweit, so klar. ein 'show opendatabases' listet die DB auch auf.
Ein 'drop' auf die DB hilft allerdings nicht weiter.
Wie kann ich identifizieren, welcher Prozess die DB in Benutzung hat?
Bzw. weiss jemand eine Lösung für mein Problem mit dem generellen Zugriff auf diese Datenbank?
Bin für jeden Tip dankbar!
Vielen Dank und Grüße
Alexander May
ja habe ich.......
Sorry....
Mea Culpa.
Die Regel wurde erst deaktiviert und danach gelöscht.
Grüsse aus Hockenheim
Der autoForward geht immer an die selbe Person. Und es sind keinerlei Forwardings bei Terminen etc definiert.
Der Name des Empfängers taucht auch, wenn ich mir die DB mit scanEZ anschaue, in keinem Profildokument o.Ä. auf......
nein.... leider nicht....
es sind definitiv alle mails.....
ich habe gerade eben festgestellt, wenn man eine neue regel definiert, z.b. mail von yxz weiterleiten an abc, und eine mail eingeht, für die diese regel greift,
dann ist diese nämliche mail nicht von der ominösen weiterleitung betroffen......
kleiner hinweis noch....
Es handelt sich um einen Domino-Cluster......
vielleicht hilft das noch jemandem....
Kann da irgendwo noch eine Information ge-cached sein oder so?
nein.....
'leider' nicht.....
ich bin echt am Verzweifeln
sorry,
ich meinte, dass die betreffenden user intern und innerhalb einer domäne sind.
hmmmm
es sind nur interne user und nur eine domain.....
ja, das haben wir.
es sind einige Adressbücher per Directory Assistance eingebunden.
Wo liegt da die Problematik?
Hallo allerseits nochmals.
Ich bin mittlerweile am verzweifeln.....
Ich habe mittlerweile sämtliche Regeln im Profildokument in allen Variationen deaktiviert und/oder gelöscht.
Leider habe ich immernoch das Problem, dass bei einigen Usern ein 'autoForward' besteht.
Auf der Serverkonsole kommt auch 'mail was autoforwarded to.....'
Wo kann das Verhalten noch herkomme? Ich bin mittlerweile echt ratlos...
Router neustarten bringt auch nichts....
Bin für jeden Tip dankbar...
Gruss
Alexander
Hallo Allerseits,
ich habe auf einem 7.0.3FP1 auf OS/400 V5R3M0 folgendes Problem:
Ein User richtet eine Regel ein, welche ein Forward seiner Mails zu einer anderen Adresse bewirkt. Funktioniert soweit auch.
Wenn diese Regel danach deaktiviert und/oder gelöscht wird, ist die Weiterleitung aber nach wie vor aktiv. D.h. die Mails werden weiterhin weitergeleitet. Im Server-Log steht dann so etwas wie 'Message auto-forwarded to XYZ'.
Woran kann das liegen? Wie kann ich diesen Zustand abstellen?
Bin für jeden hinweis dankbar.
Vielen Dank und Grüsse
Alexander May
Danke für die Antwort!
Das Problem entsteht allerdings, wenn der Benutzer an eine Gruppe im Adressbuch versendet.
D.h. er hat eigentlich keine Möglichkeit das zu beeinflussen.
Es müsste also eine Möglichkeit geben das Serververhalten zu ändern.
Hallo Forum,
wir haben gelegentlich das Problem, dass Mails per SMTP nach extern gehen, welche eine grosse Zahl Empfänger im 'TO'-Feld trägt.
Intern werden diese korrekt behandelt, nach extern per SMTP i.d.R. auch.
Einige Empfänger solcher Mails scheinen damir jedoch Probleme zu haben, ihr SMTP-Gatewas weist die Mail ab mit
SMTP error from remote mail server after end of data:
host mail.firma.de [xxx.xxx.xxx.xxx]: 500 Line too long
Hat jemand so etwas schonmal gehabt? Kann man das Verhalten unseres Domino-Servers hier parametrieren, dass das Feld 'gesplittet' wird oder ähnliches?
Szenario:
Domino 7.0.3FP1 auf OS/400 V5R3M0
Bin für jeden Tip dankbar.
Mit freundlichen Grüssen
Alexander May
Danke erstmal für die antworten.
Also eine generelle präferent habe ich nicht.
Nur der gedanke des Clusterings über die Leitung macht mir etwas Zahnschmerzen.
Homeserver für entfernte User Kann auch der entfernte Server sein.
Dann wäre die Zustellung an diesem Standort kein Problem. Zu bemerken wäre dann aber eine Verzögerung, wenn Mails an den Lokalen Cluster zugestellt werden... oder?
Hallo Allerseits,
ich habe folgende Problemstellung: Ich habe Lokal einen Domino-Cluster, bestehend derzeit aus zwei Servern.
Die Anforderung ist, einen entfernten Standort anzubinden.
Weiter ist gefordert, dass an dem entfernten Standort ein subjektiv 'zügiges' Arbeiten möglich ist. Daher soll dort ein weiterer Domino-Server aufgebaut werden.
Wird dieser Replikationsserver, so wären die Forderungen erfüllt. Ich habe jedoch nach meinem Kenntnisstand das Problem, dass ich mit Verzögerungen beispielsweise der Mailzustellung Entfernt-->Lokal zu rechnen habe, aufgrund der Replikationszyklen.
Mein Gedanke war nun, den entfernten Server mit in den Cluster aufzunehmen, sodass aufgrund der Clusterreplikation quasi ein 'permanentes' Replizueren stattfindet.
Hat jemand mit so etwas erfahrungen? Ist das praktikabel? Quasi ein cluster mit nicht lokalem Clustermitgliedern?
Bin dür jeden Tip dankbar,
Vielen Dank schonmal
Grüsse
Alexander May
Vielen Dank für die Hilfe, habe den Eintrag im Profildokument entsprechend geändert.
Danke nochmals allen.