Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: eknori am 29.06.09 - 08:49:34
-
Mich würde interessieren, ob es doch schon ein paar ( mehr ) Unternehmen gibt, die DAOS produktiv einsetzen. Mich interessieren primär nicht so sehr die Daten der Ersparnis. Die sind ja schon zu Genüge an vielen anderen Stellen im Web beredet worden.
Bei einem klaren JA ist die Anzahl der Datenbanken interessant;
bei einem klaren NEIN interessiert mich, was gegen den Einsatz von DAOS spricht;
bei einem "Wieder abgeschaltet" gibt es sicherlich auch eine kleine Begründung für diesen Schritt.
Vielen Dank im Voraus für eure zahlreichen Beiträge ...
-
bei einem klaren NEIN interessiert mich, was gegen den Einsatz von DAOS spricht
Weil noch nicht auf 8.5 sind :P....
Aber ja, ich Plane es sicherlich zu gegebener Zeit einzusetzen.
-
bei einem klaren NEIN interessiert mich, was gegen den Einsatz von DAOS spricht;
Nein, weil wir unsere Notes-Dokumente direkt archivieren (Single-Instance) und somit unsere Notes-Datenbanken klein halten.
-
Hallo zusammen,
ich greife mal diesen alten Thread wieder auf.
Ganz allgemein gefragt: Würdet Ihr sagen, dass DAOS ein robustes Feature ist, das man bedenkenlos einsetzen kann ?
Ich musste mir heute von einem Dienstleister anhören, dass "DAOS nicht zu empfehlen sei, da sollte man besser die Finger von lassen".
Ich habe allerdings den Verdacht, dass dieses Statement eher den Unwillen zur Erbringung der gewünschten Dienstleistung kaschieren soll. >:(
Hintergrund dazu:
Wir setzen schon seit einiger Zeit DAOS auf einem Server produktiv ein, allerdings nicht in erster Linie, um Duplizität zu vermeiden sondern hauptsächlich, weil wir bei einer Datenbank mit sehr vielen Dokumenten (>600000), die noch dazu alle Anhänge beinhalten, keine andere Möglichkeit der Realisierung haben - die logische Größe der DB liegt mittlerweile bei 223 Gbyte, die physikalische bei 3 Gbyte. Erstaunlicherweise ist das ganze sogar noch performant, obwohl wir ursprünglich von weit weniger als der Hälfte an Dokumenten und Speicherplatz ausgingen, aber wie das ja immer so ist ...)
Unsere Backup-Software hat schon von Anfang an Probleme, diesen Server über die Notes-API zu sichern (eingesetzt wird "BackupExpress" von Syncsort). Die o.g. Aussage stammt von einem für Syncsort zuständigen Dienstleister.
Da wir vorhaben, unsere gesamte Server-Infrastruktur Domino-seitig auf den aktuellen Stand zu bringen und dabei zumindest bei den Mailservern auch DAOS einzusetzen, kann ich mich mit so einem Statement naturgemäß nicht zufrieden geben, daher meine Frage an Euch, bevor ich bei Syncsort entsprechend Krach schlage.
Falls Ihr (positive wie negative) Erfahrungen mit der Datensicherung bei DAOS-Servern habt, wäre ich daran natürlich auch sehr interessiert ... :)
Danke und Beste Grüße
Ozzy
-
ALSO: Datensicherung und DAOS IST ein Thema. Die Begründung ist recht einfach:
Durch DAOS werden viele -mehr oder weniger- kleine und grosse Dateien in einem Verzeichnis abgelegt.
Die Maximalgrösse des Verzeichnisses beträgt dabei standardmässig 40.000 Dateien.
Wenn Du jetzt mal versuchst, ein solches "Volles" DAOS- Verzeichnis nur im Explorer anzuzeigen, dann wirst Du -je nach Plattenperformance- mehrer Minuten bis Stunden warten...
Das selbe passiert bei der Sicherung. Wenn man jetzt also -entgegen der Empfehlung von IBM- jeden Tag eine Vollsicherung probiert, dann wird man irgendwann einfach an die Zeitgrenzen Stossen (Habe schon Sicherungen über mehr als 12Stunden gesehen).
Sichert man aber inkrementell, dann ist das kein Thema mehr, weil DAOS- Dateien unveränderlich sind.
Wir haben DAOS bei vielen Kunden (20 - 2.000 User) im Einsatz und würden es JEDERZEIT jedem empfehlen.
Gut: Bei einem Kunden ist zweimal der Katalog irgendwie beschädigt gewesen, was dazu geführt hat, dass DAOS alle Attachment noch einmal abgelegt hat. Das lies sich aber mit einem doasmgr resync beheben, und ist jetzt seit längerem nicht mehr aufgetaucht.
Ansonsten kann ich nur sagen: Super Feature, super Funktionalität, habe noch keine Nachteile gefunden...
-
Ich habe allerdings den Verdacht, dass dieses Statement eher den Unwillen zur Erbringung der gewünschten Dienstleistung kaschieren soll. >:(
Ja, den Verdacht würde ich auch haben.
-
Hallo Namensvetter (ich heiße auch Torsten ohne "h" ;-) ),
vielen Dank für die schnelle und ausführliche Antwort !
Unser derzeitiger DAOS-Server läuft auf einem 64bit-SLES 10 (demnächst SLES 11), insofern ist da nix mit Explorer, aber ich weiss natürlich, was Du meinst ;D !
Wir machen die Base-Sicherungen am Wochenende , dazwischen nur inkrementell. Das ist auch gar nicht das Problem, sondern eher, dass BackupExpress mit schöner Regelmäßigkeit den Domino Server zum crash bringt, und zwar dergestalt, dass er trotz aktivierter automatischer Server-Wiederherstellung nicht von allein wieder hochkommt.
Aber das will ich hier gar nicht weiter vertiefen, da soll sich dann mal schön der Dienstleister drum kümmern ...
Nochmal danke !
Gruß
Torsten aka Ozzy
-
Wenn wir schon bei diesem Thema sind, wage ich anzumerken, dass DAOS bei Dokumenten mit Anhängen,
die mit einem privaten Schlüssel verschlüsselt sind, an seine "Grenzen" stösst.
Soll heissen, solche Dokumente werden dann nicht, wie es logisch wäre, vom Server unangetastet gelassen,
sondern leider "versucht" DAOS die Anhänge auch solcher Dokumente zu "detachen", was dann leider
zum Komplettverlust des jeweiligen Anhanges führt.
Ansonsten funktioniert es fehlerfrei .... ---> im Unterschied zum Vorläufer "Shared Mail"
Gruss,
Joachim
-
Ja :-) ... nach Testsystem derzeit als "Produktiv"-PoC mit 8.5.2 FP2 auf
- CentOS 5 (32) mit ca. 20 Usern
- WinDoze 2008R2 mit ca. 40 Usern
soweit problemlos. Backup mit Arkeia 9 und BE 2010 R3.
-
Wenn wir schon bei diesem Thema sind, wage ich anzumerken, dass DAOS bei Dokumenten mit Anhängen,
die mit einem privaten Schlüssel verschlüsselt sind, an seine "Grenzen" stösst.
Soll heissen, solche Dokumente werden dann nicht, wie es logisch wäre, vom Server unangetastet gelassen,
sondern leider "versucht" DAOS die Anhänge auch solcher Dokumente zu "detachen", was dann leider
zum Komplettverlust des jeweiligen Anhanges führt.
Nur mal interessehalber :
Heißt das im Klartext, daß verschlüsselte Attachments durch DAOS "zerstört" werden ? Oder wie darf ich das verstehen ?
-
Heißt das im Klartext, daß verschlüsselte Attachments durch DAOS "zerstört" werden ?
Richtig ! So war es gemeint ...
P.S. "Logisch" scheint mir das schon, da ja ein Server einen Privaten Schlüssel eines Nutzers im Nomalfall nicht haben
kann. Trotzdem wird der Anhang "detacht"... und das soll / darf nicht sein ...
Gruss,
Joachim
-
@Joachim!
Du hast das aber nicht probiert oder? Es ist nämlich völlig unlogisch, dass der Anhang beschädigt wird, wenn er detached wird. Der Inhalt des Anhangs verändert sich ja nicht, sondern wird nur wo anders gespeichert. Probiert dein Szenario mal aus und poste dann das Ergebnis, bevor noch jemand verunsichert wird.
Grüße
Ralf
-
Probiert dein Szenario mal aus und poste dann das Ergebnis, bevor noch jemand verunsichert wird.
ICH poste nichts, ohne dass ich das vorher selbst verifiziert habe.
( --> deshalb bin ich hier auch nicht der "Massen" - Poster ) :)
Wir haben das mit Maildatenbanken von Anwendern getestet, wo es Dokumente mit Anhängen gibt, die mit privaten Schlüsseln der User abgespeichert ( verschlüsselt ) wurden.
Die privaten Schlüssel befinden sich, wie bei Notes so üblich, in den User-ID´s der Anwender.
( ---> es sind also NICHT die öffentlichen Schlüssel gemeint, die auch im Personendokument im NAB auftauchen ! )
Gruss,
Joachim
-
Also ich habe gerade folgende Schritte ausprobiert:
Einen geheimen Schlüssel in meiner ID erstellt.
Ein neues Dokument in meiner Maildatenbank erstellt, für die DAOS aktivert ist. In den Dokumenteigenschaften den geheimen Schlüssel ausgewählt und einen Dateianhang hinzugefügt, der grösser als die Minimumgrösse für DAOS ist. Beim Speichern schreibt Notes, dass das Dokument mit dem geheimen Schlüssel verschlüsselt wird.
Ich kann das Dokument, dannn mit meiner ID problemlos wieder öffnen und auch der Anhang funktioniert einwandfrei.
Was machst du anders, dass es bei dir nicht funktioniert?
Grüße
Ralf
-
Also wenn ich mir Ulrichs Posting http://www.eknori.de/2009-04-14/daos-encrypted-mail/ ansehe, sollten verschlüsselte Mails auch mit DAOS funktionieren.
-
ja, es werden logischerweise unterschiedliche NLOs angelegt. Aber funktionieren sollte das ganze doch ganz normal!
-
Hallo,
wird bei uns nicht eingesetzt bzw. in Erwägung gezogen da wir eine Archivierungssoftware eines anderen Herstellers bereits im Einsatz haben.
Grüße
Christian
-
@Christian!
Kannst du mir sagen, inwiefern DAOS etwas mit Archivierung zu tun hat? DAOS hat doch eine ganz andere Funktion wie Archivierung. DAOS kann z.B. ganz massiv Bandbreite bei der Replikation sparen. Wie soll das eine Archivierungslösung können.
Grüße
Ralf
-
Ich bin jetzt nicht Christian, aber wir haben auch wegen der Einführung eines Archivsystems auf die Nutzung von DAOS verzichtet.
Wir archivieren sämtliche Mails aus den Maildatenbanken der User. Nach momentan drei Monaten werden die Attachments entfernt und durch einen Link auf die archivierte Mail ersetzt. Attachments liegen somit maximal drei Monate auf unseren Dominoservern.
Sonstige Anwendungen, die Attachments enthalten, haben wir nur in überschaubarer Menge und mit geringem Datenvolumen.
Aus den Gründen haben wir DAOS nicht aktiviert.
-
Was machst du anders, dass es bei dir nicht funktioniert?
Nichts ! :)
Unsere Infrastruktur übrigens:
- Domino 8.5.1 FP3 ( WIN 2003 Server 64-bit); LN Basic-Client 8.5.1 FP3
Effekt, wie schon beschrieben, also wenn ich dann als Benutzer die Mail mit dem Anhang öffne, habe ich als Anhangsgrösse 0 Byte und bekomme den Anhang NICHT geöffnet ..
P.S. Wenn ich heute noch dazu komme, kann ich versuchen, einen Screenshot zu machen ...
Gruss,
Joachim
-
Unsere Infrastruktur übrigens:
- Domino 8.5.1 FP3 ( WIN 2003 Server 64-bit); LN Basic-Client 8.5.1 FP3
Bist du dir sicher, daß es am Verschlüsseln liegt? Bei der 8.5.1 FP3 gab es verschiedene Probleme mit DAOS und PULL Replication. Warum macht ihr nicht wenigstens ein Update auf das aktuellste FP für 8.5.1?
-
... ich habe DAOS vor einiger Zeit nach einem erfolgreichen Test auf einem produktiven Server eingeschaltet. Dabei entstand ein "lustiger" Nebeneffekt, den wir erst später festgestellt hatten.
Neben der daoscat.nsf wurde austomatisch eine zweite Datenbank dieses Namens in einem neu erstellten Verzeichnis erzeugt. Die DB selbst ließ sich nicht öffnen und es kam eine Meldung, dass die DB korrupt sei. Das Unterverzeichnis selbst hatte ein äußerst seltsames Sonderzeichen im Namen.
Alles funktionierte zunächst scheinbar problemlos, bis wir eine Sicherung zurückspielen wollten. Das Einlesen der Ordnerstruktur führte dazu, dass die Backupsoftware zu 100% abstürzte und den Domino mitriss. Das Backup war also nicht mehr zu gebrauchen. Nach dem Löschen des seltsamen Ordners wurde beim Domino-Neustart jedesmal ein Ordner mit kryptischen Namen und einer defekten daoscat.nsf angelegt, allerdings jedesmal ein anderer.
Der Domino wurde neu installiert und anschließend sogar auch das Betriebssystem. Das Verhalten auf dieser Maschine blieb gleich. Nach dem Ausschalten von DAOS lief dann wieder alles. Ich habe nie rausbekommen, was die Ursache dafür war ...
Gruß
Wolfgang
-
Bist du dir sicher, daß es am Verschlüsseln liegt?
Was ist heute schon "sicher" ... aber Fakt ist, dass dieser "Effekt" eben nur mit verschlüsselten Dokumenten auftritt.
Warum macht ihr nicht wenigstens ein Update auf das aktuellste FP für 8.5.1?
War bisher noch keine "Zeit" dazu. Ist eine zweistellige Anzahl von Servern.
Aber nächste Woche geht es Richtung 8.5.2 mit dem aktuellsten FP.
"Stay tuned" ... als erste "Aktion" nach dem Update werde ich sicherlich nochmals DAOS aktivieren und testen.
Gruss,
Joachim
-
ich habe DAOS bei mehreren Servern produktiv im Einsatz, beim größten mit ca. 1000 Mail- und Projektdatenbanken, ca. 1,5TB
bei 8.5.1 und 8.5.2 mit gelegentlichen Fehlern, weil der Anhang nicht gefunden wurde, seit 8.5.2FP2 treten keine Fehler mehr auf
:D
-
DAOS kann z.B. ganz massiv Bandbreite bei der Replikation sparen.
Hä? DAOS ist doch eine zu tiefst "lokale" Eigenschaft die nur jeweils einen Server betrifft. Meintest Du ev. I/O statt Bandbreite?
-
Hi,
DAOS kann z.B. ganz massiv Bandbreite bei der Replikation sparen.
Hä? DAOS ist doch eine zu tiefst "lokale" Eigenschaft die nur jeweils einen Server betrifft. Meintest Du ev. I/O statt Bandbreite?
Nein, er hat schon recht. 2 DAOS-enabled Server können untereinander kommunizieren, dass sie ein Dokument mit dem Anhang XYZ replizieren möchten und dass dieser Anhang den Hash-Code ABC hat. Hat der Zielserver bereits ein DAOS-Attachment mit Hash-Code ABC, wird das bei der Replikation weggelassen. Ist aber nur beim "normalen" Replizieren anwendbar. Das "beschleunigte Replik-Erstellen" (a.k.a. Kopieren auf OS-Ebene) kann die Funktion nicht.
Gruß,
Patrick
-
Hallo Wolfgang,
... ich habe DAOS vor einiger Zeit nach einem erfolgreichen Test auf einem produktiven Server eingeschaltet. Dabei entstand ein "lustiger" Nebeneffekt, den wir erst später festgestellt hatten.
Neben der daoscat.nsf wurde austomatisch eine zweite Datenbank dieses Namens in einem neu erstellten Verzeichnis erzeugt. Die DB selbst ließ sich nicht öffnen und es kam eine Meldung, dass die DB korrupt sei. Das Unterverzeichnis selbst hatte ein äußerst seltsames Sonderzeichen im Namen.
Hatten wir auch mal:
-> http://www-01.ibm.com/support/docview.wss?uid=swg1LO52581
Gruß,
Patrick
-
Hi,
wir haben Anfang des Jahres auf R8.5.2FP2 gewechselt und vor ca. 2 Monaten
auch auf 2 Servern DAOS aktiviert. Bisher haben wir keine Probleme damit.
mfg Christian
-
... ich habe DAOS vor einiger Zeit nach einem erfolgreichen Test auf einem produktiven Server eingeschaltet. Dabei entstand ein "lustiger" Nebeneffekt, den wir erst später festgestellt hatten.
Neben der daoscat.nsf wurde austomatisch eine zweite Datenbank dieses Namens in einem neu erstellten Verzeichnis erzeugt. Die DB selbst ließ sich nicht öffnen und es kam eine Meldung, dass die DB korrupt sei. Das Unterverzeichnis selbst hatte ein äußerst seltsames Sonderzeichen im Namen.
Hatten wir auch mal:
-> http://www-01.ibm.com/support/docview.wss?uid=swg1LO52581
... die genaue Version bei uns zu diesem Zeitpunkt weiß ich jetzt nicht mehr.
Das mit dem Third Party Produkt in dem Artikel finde ich jedoch klasse. Auf unserem Server war keines außer dem IBM-eigenen Tivoli Data Protection for Lotus Domino. ;D
Gruß
Wolfgang
-
Hi,
DAOS kann z.B. ganz massiv Bandbreite bei der Replikation sparen.
Hä? DAOS ist doch eine zu tiefst "lokale" Eigenschaft die nur jeweils einen Server betrifft. Meintest Du ev. I/O statt Bandbreite?
Nein, er hat schon recht. 2 DAOS-enabled Server können untereinander kommunizieren, dass sie ein Dokument mit dem Anhang XYZ replizieren möchten und dass dieser Anhang den Hash-Code ABC hat. Hat der Zielserver bereits ein DAOS-Attachment mit Hash-Code ABC, wird das bei der Replikation weggelassen. Ist aber nur beim "normalen" Replizieren anwendbar. Das "beschleunigte Replik-Erstellen" (a.k.a. Kopieren auf OS-Ebene) kann die Funktion nicht.
Gruß,
Patrick
Ach ja richtig, darauf hab ich ganz vergessen. Das funktioniert ja mit dem Client auch. :)
Danke.
-
Hallo Wolfgang,
Hatten wir auch mal:
-> http://www-01.ibm.com/support/docview.wss?uid=swg1LO52581
... die genaue Version bei uns zu diesem Zeitpunkt weiß ich jetzt nicht mehr.
Das mit dem Third Party Produkt in dem Artikel finde ich jedoch klasse. Auf unserem Server war keines außer dem IBM-eigenen Tivoli Data Protection for Lotus Domino. ;D
[/quote]
Da schließt sich der Kreis. Auf dem Server, auf dem das Problem auftrat, war auch TSM installiert. In einer Version, die eigentlich DAOS-aware ist...
Merke: Tivoli != Lotus
Ergo: 3rd Party ;-)
Gruß,
Patrick
-
Hallo Martin,
Ach ja richtig, darauf hab ich ganz vergessen. Das funktioniert ja mit dem Client auch. :)
Danke.
DAOS ist nur serverseitig und für den Client transparent. Was soll da mit dem Client funktionieren? ;-)
Gruß,
Patrick
-
Wenn ein >=8.5.1 Client ein Dokument an den Server schickt, dass Anhänge enthält, wird auch zuerst der Hash geschickt und falls der Anhang im Daos bereits vorhanden ist werden die Anhänge nicht mehr übertragen.
Deshalb auch meine Verwunderung, warum manche DAOS nicht einsetzen, weil sie eine Archivierung haben. Gerade das klassische Weiterleiten von mails mit Anhängen wird mit DAOS super beschleunigt.
Grüße
Ralf
-
Hallo Ralf,
Wenn ein >=8.5.1 Client ein Dokument an den Server schickt, dass Anhänge enthält, wird auch zuerst der Hash geschickt und falls der Anhang im Daos bereits vorhanden ist werden die Anhänge nicht mehr übertragen.
Das ist mir jetzt neu. Man lernt halt nie aus! ;-)
Hast du vielleicht eine Technote, in der das Verhalten beschrieben ist? Danke :-)
Gruß,
Patrick
-
Kein Problem
https://www-304.ibm.com/support/docview.wss?uid=swg21411307&wv=1
Grüße
Ralf
-
Danke Ralf, ich war grad anderwertig beschäftigt.
-
@Ralf_M_Petter
Hallo Ralf,
aus den gleichen Gründen die Ingo bereits beschrieben hat. Ich vermute wir setzen das gleiche Produkt ein.
Grüße
Christian
-
Ich verstehe nur nicht, warum bei euch DAOS und Archivierung eine entweder oder Entscheidung ist!
DAOS für Anhänge die gerade an viele Benutzer verschickt werden und Archivierung für den Kram, den die User nicht löschen möchten.
Ich kenne kein 3rd Party Produkt, das mit DAOS nicht zu Recht kommt, also warum nicht kombinieren?
Ich schicke jetzt ein 10 MB Attachment an 100 User, ohne DAOS knapp 1GB Plattenplatz muß beschrieben und gesichert werden. Mit DAOS schreibt der Server ca. 10-15 MB und das war es.
Replizierung zwischen Servern wird beschleunigt, der Platz wird besser genutzt.
-
Kombinierbar wäre das auf jeden Fall. Alles andere wäre auch peinlich für IBM (siehe Signatur) ;)
Aber:
DAOS schalte ich ja nicht mal eben ein und es läuft dann ohne weitere Aktionen vor sich hin. Soweit ich das mitbekommen habe, muß man sich ja mindestens um das Thema Backup/Restore Gedanken machen.
Und wenn ich mir die Auslastung meiner Admin-Kollegen anschaue, haben die momentan andere Sorgen.
Darum haben wir erstmal auf DAOS verzichtet, denn durch die Archivierung und das Entfernen von Attachments aus archivierten Mails erzielen wir zumindest schon mal einen gewissen Effekt, was das Datenvolumen auf den Servern und in den diversen Repliken betrifft.
-
Servus,
Da geb ich dir Recht, ich muss mir Gedanken zur Einführung machen und auch ein paar Dinge planen. Wobei das nicht schlimm ist und grad das Restorethema nicht schlimm ist, bei entsprechender Vorplanung.
Ich wollte nur klarstellen, dass beide Funktionen parallel möglich und auch sinnvoll sind, schliesslich hat am Anfang des Freds jemand gefragt ob er es einsetzen soll und da hörten sich manche Antworten so an wie: Nö brauchen wir nicht wir archivieren, bzw wir haben uns dagegegen entschieden weil wir archivieren.
-
Ich denke, das muß halt jeder für sich abwägen. Ich will mich hier auch nicht rechtfertigen (brauche ich auch nicht ;)). Wir hatten halt einfach unsere Gründe, warum wir auf DAOS verzichtet haben.
Daß z.B. die 8.5er Clients da auch von profitieren, wie Ralf das beschrieben hat, wäre sicherlich ein zusätzlicher Vorteil. Für uns greift das nur momentan leider nicht, weil wir "gezwungen" sind 8.0.2 einzusetzen.
Das Thema der Replikation zwischen Servern ist in unserem Konstrukt auch nicht so relevant, da über 90% der Maildatenbanken alle auf einer Maschine liegen und wir zwischen den Servern keine Maildatenbanken replizieren. Und wie ich schon geschrieben hatte, haben wir nur wenige Anwendungen, die viele Attachments verwalten.
-
:) Versteh mich nicht falsch, klar muss das jeder selbst abwägen, aber ich erwarte in einem Thread, in dem jemand Ideen sucht, ob er DAOS verwenden will oder nicht, evtl ein paar Hintergrundgedanken, warum ihr euch dagegen entschieden habt.
Ich weiß auch, daß der Thread zwischendurch abgedriftet ist und sich viele der Posts v.a. um das Auftreten von Fehlern drehen und die Posts über den Nichteinsatz darauf Bezug nehmen.
Kein Angriff, nur eine Info, daß paralleler Einsatz möglich ist.
-
@Christoph
Du hast natürlich recht, die DAOS Funktionalität und Archivierung schließen sich nicht gegenseitig aus. In einem größeren Konzern sind aber oft weitere Dinge zu berücksichtigen:
- Standards , wir sind Teil eines internationalen Konzerns, haben die das noch nicht evaluiert oder zum Standard erklärt = no go
- sicher mag das kompatibel sein zu bestehenden Archivlösungen nur wir betreiben auch ein Shortcutting der Anhänge die dann im Langzeitarchiv verschwinden, die kurzzeitig verbleibenden dann zusätzlich mit DAOS abzuhandeln lindert meist die Schmerzen nicht, die sind dann nicht mehr der Plattenplatz sondern die Anzahl der Dokumente in einer DB
- aus meiner langjährigen Erfahrung mit Notes ist ein neues Feature, so nützlich es auch erscheinen mag, immer auch eine potentielle neue Fehlerquelle selbst wenn es derzeit wohl durchaus ohne größere Komplikationen läuft.
Ich erinnere mich da nur an tolle neue Featueres wie Notes -> DB2 was nun eingestampft wird oder Single Copy Template was wir selber eingesetzt haben und womit ich nervlich um Jahre gealtert bin. Auf einige der Probleme mit dieser Funktion war die Aussage eines IBM Mitarbeiters aus dem Techlab auf einer Konferenz nur , da haben sie einen Single Point of Failure in Ihrem Konzept.
Namens-Ähnlichkeiten mit der Funktion sind rein zufällig ;D
Viele Grüße
Christian
-
So, wie "versprochen", gebe ich das Feedback zur Problematik der verschlüsselten Dokumente mit DAOS.
Kurz und knapp:
- erst das Update der Server auf 8.5.2 FP2 hat diesen Effekt behoben
Also, "Feuer frei" für die sorglose Nutzung von DAOS... aber erst ab 8.5.2 FP2 ;D
Gruss,
Joachim